[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                          G. Kowack
Internet-Draft                                                 Riveronce
Expires: June 23, 2011                                 December 20, 2010


                    Motivations for Recommendations
            draft-kowack-rfc-editor-model-v2-motivations-00

Abstract

   This memo provides the background and motivations for the
   recommendations made in draft-kowack-rfc-editor-model-v2-overview-00.
   It represents the perspectives resulting from an individual
   managerial and analytical effort of nearly one year's duration.  It
   contains a summary of the factors considered to be essential to the
   job of RFC Series Editor (RSE).  This includes a summary of the work
   done as part of the RFC Editor, the differences between [RFC5620]and
   the [I-D.v2-overview] recommendations, a discussion of development
   work that should be done, and an assessment of the time needed to
   perform the RSE job.  There is also a section listing and responding
   to questions surrounding the recommendations.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 23, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Kowack                    Expires June 23, 2011                 [Page 1]

Internet-Draft       Motivations for Recommendations       December 2010


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.














































Kowack                    Expires June 23, 2011                 [Page 2]

Internet-Draft       Motivations for Recommendations       December 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Key Observations and Drivers of Design Choices . . . . . . . .  5
   3.  What Does the RFC Editor Do? . . . . . . . . . . . . . . . . .  8
     3.1.  Editing Work is Performed by Production Center Staff . . .  8
     3.2.  How is the RFC Editor Managed? . . . . . . . . . . . . . .  9
       3.2.1.  Coordination and Meetings  . . . . . . . . . . . . . .  9
     3.3.  Why the RFC Editor and Series Still Need a Manager . . . . 10
       3.3.1.  Scale, Complexity, Formality, and Duration Make
               Management Inevitable  . . . . . . . . . . . . . . . . 11
       3.3.2.  The Community's Way of Doing Business Has its Own
               Overhead . . . . . . . . . . . . . . . . . . . . . . . 12
     3.4.  What Does the RFC Series Editor Do?  . . . . . . . . . . . 12
       3.4.1.  Addressing questions and problems from within the
               RFC Editor . . . . . . . . . . . . . . . . . . . . . . 13
       3.4.2.  RSE Activity Example: Ensuring and Improving
               Access to RFCs . . . . . . . . . . . . . . . . . . . . 14
       3.4.3.  RFC Editor Escalation Procedure  . . . . . . . . . . . 16
   4.  Differences between V2-Overview and RFC 5620 . . . . . . . . . 18
     4.1.  General and Design Strategy Differences  . . . . . . . . . 19
     4.2.  Specific Differences . . . . . . . . . . . . . . . . . . . 20
       4.2.1.  Series Editor Authority and Supervisory Duties . . . . 20
       4.2.2.  RFC Editor Oversight Committee and RSAG  . . . . . . . 21
       4.2.3.  Decommissioned RFC Series Advisory Group . . . . . . . 22
       4.2.4.  The IAOC and IAD . . . . . . . . . . . . . . . . . . . 23
       4.2.5.  The Series Editor and General Management Issues  . . . 23
   5.  RFC Editor and Series Development Work . . . . . . . . . . . . 23
     5.1.  Update, Improve, and Reorganize the Style Manual . . . . . 24
     5.2.  Develop and Publish a Procedures Manual  . . . . . . . . . 25
     5.3.  Improvements to the RFC Editor Web Pages . . . . . . . . . 25
     5.4.  Investigate Enhanced Training for RFC Authors  . . . . . . 25
     5.5.  Investigate Providing Support for RFCs in Additional
           Languages  . . . . . . . . . . . . . . . . . . . . . . . . 26
     5.6.  Consider Supporting RFC Clusters and Enhanced RFC
           Annotation . . . . . . . . . . . . . . . . . . . . . . . . 26
     5.7.  Investigate Reinforcing the Status of the Series as
           Academic Publications  . . . . . . . . . . . . . . . . . . 26
     5.8.  Investigate Formal Persistent Names or Identifiers for
           RFCs . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     5.9.  Lead Discussion on Universal Access and the ASCII
           Format of Normative Versions of RFCs . . . . . . . . . . . 27
   6.  RSE Time Requirements  . . . . . . . . . . . . . . . . . . . . 27
     6.1.  General Recommendations  . . . . . . . . . . . . . . . . . 27
     6.2.  Current Level of Effort  . . . . . . . . . . . . . . . . . 28
     6.3.  Additional responsibilities under V2-Overview  . . . . . . 29
     6.4.  Which Levels of Appointment Make Practical Sense?  . . . . 30
     6.5.  Orientation Time Requirements  . . . . . . . . . . . . . . 31



Kowack                    Expires June 23, 2011                 [Page 3]

Internet-Draft       Motivations for Recommendations       December 2010


   7.  Key Questions and Answers  . . . . . . . . . . . . . . . . . . 31
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 34
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 34
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 34
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35














































Kowack                    Expires June 23, 2011                 [Page 4]

Internet-Draft       Motivations for Recommendations       December 2010


1.  Introduction

   As Transitional RFC Series Editor (TRSE), I performed the job of RFC
   Series Editor (RSE or "Series Editor") throughout 2010.  While
   actively engaged in the role, I was to analyze work requirements,
   engage in community discussion, and recommend changes as necessary to
   [RFC5620].  (Note to the reader: I use 'community' to refer to anyone
   who participates in, or uses the output of, the technical,
   organizational, and other discussions associated with the I*
   entities.)  A specific problem was also to be addressed: the defined
   RSE position must attract qualified candidates.  Those
   recommendations are summarized in [I-D.v2-overview].  This memo
   provides the background and motivations for the recommendations.  It
   pays particular attention to the role of the Series Editor and how
   [I-D.v2-overview] differs from [RFC5620].  This document is not a
   community document.  Rather, it contains the perspectives resulting
   from an individual managerial and analytical effort of nearly one
   year's duration.

      If the community wants an RFC Editor that is responsive and
      productive, then the IAB must appoint an RFC Series Editor who has
      management and development skills and who is given authority
      across the entire Editor."> I observe that a segment of the
      community wishes to minimize the role of the Series Editor,
      envisioning the job as merely a senior editor.  My experience this
      year demonstrates that this will limit the ability of the RFC
      Editor to deal with its backlog of development requirements and
      its ability to adapt to emerging community issues.  The scale,
      complexity, and richness of the subject matter of the Editor
      create regular demands for management and coordination.


2.  Key Observations and Drivers of Design Choices

   The key observations behind, and drivers of the design for
   [I-D.v2-overview] are:

      The RFC Editor must work, and be structured to work, in the
      community's interest.

         The RFC Editor (or 'Editor') must not allow anyone to have
         inappropriate influence over, or 'capture' the Editor - using
         it in his own interests.  This includes the Series Editor,
         staff, contractors, unauthorized I* entities, individuals, or
         groups.  For all substantive issues, the community must clearly
         be in charge.





Kowack                    Expires June 23, 2011                 [Page 5]

Internet-Draft       Motivations for Recommendations       December 2010


      Issues addressed by the Series Editor consistently demand a high
      degree of publications-related knowledge and analytical skills not
      common in our community.

         Because RFCs do not change once they are published, prospective
         innovations must be thought out in advance very carefully and
         with special attention to unexpected consequences, putting a
         premium on expertise and prior experience.  During 2010, I did
         not see issues that were rudimentary or only required text
         editorial skills.  Rather, each issue required deliberate
         review and analysis to uncover its character and extent, often
         including RFC Editor staff, RSAG members, and community
         members.  These required sophisticated management and service
         design skills, not merely editing skills.

      There is a substantial body of important RFC Editor and Series
      development work waiting to be done.

         A priority is protection against RFC Editor service
         interruptions.  Included are improvements in documentation of
         editorial practices and processes, Series access, guidance for
         authors, and the RFC Editor web site.  Support for end-user
         ease of understanding what RFCs are required to implement
         specific services, persistent name technology, and others, have
         been cited by community members.

      A balance must be maintained between (i) demands of RFC
      production, and (ii) RFC Editor and Series development.

         During 2010, RFC production worked well - confirming that part
         of the model - in part because it allows editorial staff to
         focus on production.  Staff must participate in Editor and
         Series development, which must be balanced with production
         work.  This balance can be assured only by having an
         experienced, knowledgeable, manager with explicit
         responsibility for the performance of the entire Editor.

      As defined in RFC 5620, RFC Editor management structure is complex
      and unclear.

         The Series Editor is responsible for resolving policy issues
         and providing "executive level management" of their
         implementation, but does not have authority to assign
         resources.  Today, this gap is filled by the IAD and IAOC,
         which are not structured for the requisite publications
         expertise or focus.  There is also a regular oversight meeting
         during and between IETF meetings, called by the IAD, and
         attended by the IAOC chair, the streams, AMS staff and



Kowack                    Expires June 23, 2011                 [Page 6]

Internet-Draft       Motivations for Recommendations       December 2010


         management, and the Series Editor.  The IAB, to which the RSE
         reports, has a very heavy workload, multiple competing
         priorities, and is not structured for publications expertise.
         Clarifying authority and responsibility is required to attract
         a qualified Series Editor.

   The major design choices in [I-D.v2-overview], and thus the
   recommended changes to [RFC5620] are:

   o  Balancing operation and development of the RFC Editor and the
      Series requires leadership by a single professional who has
      authority over each part of the RFC Editor (with production
      delegated to contractors), the separate development of each,
      operation of the RFC Editor as a whole, and for overall
      development of the RFC Editor and the Series.

   o  Community interests will be best supported if there is one person
      responsible to the community for all RFC Editor issues, and to
      whom the community can point if the RFC Editor is not acting in
      the community's interest.  This person must have no other
      interests.

   o  The RFC Series Editor role requires an experienced manager with
      expertise in technical writing, technical publishing, and
      technical series development.

   o  To ensure the fact and visibility of working in the community
      interest, and to support the Series Editor, [I-D.v2-overview] adds
      an RFC Editor Oversight Committee, whose members will be drawn
      from the community and have prior experience in publications.  The
      now-redundant RFC Series Advisory Group would be disbanded,
      although a slow transition is recommended to maintain
      institutional memory.

   The proposed Series Editor role is conceptually equivalent to the
   head of a publications department in a technical organization.

   The community has not yet converged on a common view of the span of
   authority and responsibility of the Series Editor, the type and level
   of expertise required, or the structure of RFC Editor oversight.
   Through a description of the work of the RFC Series Editor as
   performed during 2010 and related observations, this memo seeks to
   motivate necessary changes to the Series Editor, including attracting
   suitable, qualified candidates.







Kowack                    Expires June 23, 2011                 [Page 7]

Internet-Draft       Motivations for Recommendations       December 2010


3.  What Does the RFC Editor Do?

   The following is based on my experience as TRSE during 2010.  I call
   out those cases where the role differs from RFC Editor Model (Version
   1) described in [RFC5620], based on how the role presented itself to
   me, and as a consequence how I now believe it needs to be organized.

   RFC Editor output is produced through two functions: the RFC
   Production Center (or RPC), and RFC Publisher (the 'Publisher').  Per
   [RFC5620], the Series Editor provides "Executive-Level management".
   During 2010, In order to observe how the model is currently working,
   I intervened as little as possible in RPC or Publisher activities.

   Here is a review of some aspects of performance that I observed:

      Day-to-Day, the RFC Editor Model works well for basic RFC
      production and publication.

         During 2010, RFC production has been steady.  There is general
         satisfaction with the rate and quality of output, with the
         service provided by the editorial staff, and with their
         responsiveness.  Staff of the Production Center and Publisher
         staff understand their jobs and are focused; I did not observe
         anything blocking their performance.

      Day-to-Day, the streams model works well.

         The participants in and leadership of each of the streams
         appear to understand the scope of their subject areas.  I have
         not observed any problems, nor heard any substantive concerns,
         about how each should use the services of the Editor.  All
         discussions of inter-stream conflicts were satisfactorily
         resolved by the concerned parties, following documented
         procedures

   I observe that, following many years of experience and refinement,
   the RFC Editor is highly organized for steady-state RFC production
   and publication using a single, narrow service and editorial model.
   However, this is not the entire range of required RFC Editor
   services, as I will describe in following sections.

3.1.  Editing Work is Performed by Production Center Staff

   The RFC Production Center (RPC) center is provided by AMS under
   contract.  It performs regular RFC Editor document production.  AMS
   also provides the RFC Publisher service.

   Following generally-accepted editorial style and procedures, much of



Kowack                    Expires June 23, 2011                 [Page 8]

Internet-Draft       Motivations for Recommendations       December 2010


   which is lore learned by editorial staff over many years, editors
   receive approved documents from the streams; they make textual
   changes for correctness and clarity, and formal changes, such as
   formatting and adding specific boilerplate text; they engage IANA as
   necessary.

   The Production Center has its own director, an AMS staff member.  She
   manages the day-to-day activity of the editorial staff, including
   document assignments and customer interaction.  She also works as an
   individual contributor alongside the other editorial staff, and is
   the senior and most experienced editor.  The Production Center
   publishes regular production reports, comprised primarily of
   statistics.

   The staff of the Production Center are the Editor's most frequent
   point of contact with stream participants and approvers.  They
   provide the vast majority of production-oriented services.  In excess
   of 90% of drafts come from the IETF stream.  Furthermore, the
   Production Center director acts as liaison to the IESG, to whom she
   submits regular reports; these are available on the RFC Editor web
   site.  Consequently, the majority of document-oriented interaction
   and support is between the Production Center and one of the four
   streams.

   As with other service organizations dominated by a single user or
   customer, it can be inherently challenging to provide balanced
   service and support to all of the other customers.  During the TRSE
   period, I did not observe any problems or complaints in balancing
   Editor resource allocation across the streams.  Beyond that, however,
   there is a substantial backlog in non-production services and
   capabilities that have not been adequately addressed or implemented,
   nor integrated into a long-term plan with specific priorities; nor
   has their content and value been sufficiently represented to the
   community.  I address these in Section 5.

3.2.  How is the RFC Editor Managed?

3.2.1.  Coordination and Meetings

   A weekly teleconference of all RFC Editor staff is attended regularly
   by the:

   o  Series Editor,

   o  Production Center staff and director,

   o  AMS management,




Kowack                    Expires June 23, 2011                 [Page 9]

Internet-Draft       Motivations for Recommendations       December 2010


   o  AMS technical staff, and

   o  Independent Submissions Editor (ISE).

   During the RFC Editor meeting, ongoing issues and monthly output are
   reviewed and discussed.  Topics frequently include issues for which
   current policy is insufficient.  These often turn to review and
   analysis of past and current practices, including their origins and
   varying application over the years.

   Attendees are presently based in different locations throughout the
   continental US, plus the Independent Submissions Editor in New
   Zealand.  I have not observed any problems arising from the remote
   distribution of staff.  To the contrary, everyone appears diligent at
   keeping this from becoming an issue.

   The RSE is RFC Editor liaison to the IAB, for whom he prepares
   regular reports.  During 2010, the RSE attended IESG meetings, as a
   visitor sitting in for orientation while TRSE.

   During IETF meetings, the IETF Administrative Director (IAD) also
   calls a regular RFC Editor lunch comprised of the IETF Administrative
   Oversight Committee (IAOC) chair, stream approver chairs, the RPC
   director and invited staff, AMS management, and the RSE.  These
   participants review and discuss overall RFC Editor activity as well
   as stream observations.  This is the one regular meeting at which
   most of the leadership cited in the Model meet face to face.  There
   is also an RFC Editor teleconference between IETFs, also called and
   led by the IAD, during which RFC Editor issues are reviewed.  This is
   consistent with [RFC5620], although not explicitly called for.

   Senior RPC staff, the ISE, and RSE, are available to community
   members during IETF meetings.

   The RSAG is unstructured and, except for a regular "Tuesday lunch"
   during IETFs, has no regularly scheduled meetings, nor structured
   reports.  Per 5620, the RSAG is available on request of the RSE to
   answer questions, provide advice, and to help formulate
   recommendations to the IAB when necessary.

3.3.  Why the RFC Editor and Series Still Need a Manager

   Throughout its entire history, the Editor and the Series have been
   led by a single manager, beginning with Jon Postel and then Joyce
   Reynolds and Bob Braden.  The current success of the Editor and the
   Series is due significantly to this historical fact.





Kowack                    Expires June 23, 2011                [Page 10]

Internet-Draft       Motivations for Recommendations       December 2010


3.3.1.  Scale, Complexity, Formality, and Duration Make Management
        Inevitable

   Successful organizations invariably grow along multiple dimensions.
   They get larger and more complex, accumulate practices and precedents
   for decision-making, and become more sophisticated at their work and
   their understanding of their environment.  They have correspondingly
   richer and more complex interactions with other entities that are
   evolving similarly.  Good organizations strive to keep their
   structure and practices simple, and to avoid creating unnecessary
   bureaucracy.  However, scale and duration have implicit overheads
   that cannot be ignored.  All these things are true of the I* and the
   RFC Editor.

   As organizations grow and as complexity increases, ad hoc
   coordination becomes less and less effective, and the cost of failing
   to coordinate matters increases.  In the Editor, when a policy issue
   arises it presents a practical problem: a decision needs to be made
   but extensive discussion and coordination is nearly always required.
   Resolution is not necessarily obvious or straightforward, and there
   may be broad implications.  Making concerted decisions is especially
   important because the community wants I* entities to be responsive -
   to their comments, questions, requests for information, and requests
   for changes or corrections to problems.  Someone needs to be sure
   these processes are managed well, and brought to timely conclusions.

   The I* has grown sufficiently large and complex that issues which
   appear to be simple are often very subtle, and their resolution may
   have far-reaching conclusions sensitive to the particulars of the
   decision.  For the RFC Editor, someone has to own that effort.  The
   point person must vet it past experts, bring it to the community,
   anticipate the consequences of the different options, and be
   insightful at finding a suitable outcome when the right choice may be
   far from obvious.

   We need to acknowledge that such activities cannot be managed in an
   ad hoc way, nor should they be assigned to staff that have regular
   production duties - the split interest would mean serving both
   purposes poorly.

   There is another oft-neglected point.  Explicit assignments of
   responsibility let everyone know who is responsible.  If responsible
   parties are good at their jobs and are transparent about their work,
   everyone knows how the decisions are being made.  This markedly
   reduces the overheads suffered by suspicion-prone (meaning just about
   all) organizations.  If, on the contrary, responsible parties are not
   formally and publicly appointed, then others will surely step in when
   they think they are needed, often with the best of intentions, but



Kowack                    Expires June 23, 2011                [Page 11]

Internet-Draft       Motivations for Recommendations       December 2010


   will too often make decisions that align more with their particular
   perspectives than with the long-term interests of the broader
   community.

3.3.2.   The Community's Way of Doing Business Has its Own Overhead

   Every organization has its own style for doing business, including
   the I* entities.  The I*'s preference for open participation and
   extensive discussion ensures that all major changes require
   significant effort by a representative of the RFC Editor.

   This has two broad consequences.  First, many initiatives should be
   carefully considered and developed before they are taken to the
   community.  Not doing so can waste valuable time and cause
   unnecessary contention while the actual issue is still being
   clarified.  Nevertheless, community review will often require a
   substantial amount of attention and calendar time to make progress.
   This is the environment in which the RFC Editor finds itself, and it
   may account for some of the historical debate about its purposes and
   processes.  The second is that, serving the community in this
   environment requires a dedicated, focused expert who has no other
   interests, who can devote the time (including months or years of
   developing perspectives) and energy to make this process work.

3.4.  What Does the RFC Series Editor Do?

   Per [RFC5620], the primary job of the RSE is to lead development of
   new policy when current policy is insufficient.  RFC activity in this
   area may originate from within the RFC Editor, the community, other
   I-star entities, or from the Series Editor's own work.  The Series
   Editor does this work in conjunction with the Editor, the RSAG (or
   the REOC in the future), and the community, and involves the IAB as
   necessary to ensure compliance with community interest and
   appropriate processes.

   The Series Editor provides guidance when the layer below - the
   Production Center staff or the Publisher - encounters a situation
   that is not clearly covered by existing policies or practices.  RFC
   5620 calls for the Series Editor to carry such issues to the RSAG and
   the community for discussion and resolution.  However, [RFC5620] is
   silent about the authority of the Series Editor over RPC and the
   Publisher when small issues arise day to day, or when the Series
   Editor must make resource allocation decisions.

   Per [RFC5620], and as practiced this year, the Series Editor does not
   participate in day-to-day production and publication activities, or
   any other regular production activities.  The RSE, like any other
   manager, does not do the work of the layer that reports to him



Kowack                    Expires June 23, 2011                [Page 12]

Internet-Draft       Motivations for Recommendations       December 2010


   (although the analogy is limited; under [RFC5620], the RPC does not
   report to the RSE).  The RSE is not and should not act as a "team
   leader", a supervisor who is also a regular individual contributor
   working alongside other team members.

   During 2010, as RSE I participated in the following, also consistent
   with [RFC5620]:

   o  requests for policy clarification and decisions from the
      Production Center,

   o  questions from, and discussion with, the community and beyond,

   o  regular weekly meetings of the RFC Editor, per above,

   o  various general meetings, including three IETFs (Anaheim,
      Maastricht, and Beijing), and

   o  liaison and reporting to the IAB, including participating in
      regular teleconferences and occasional retreats.

   I also responded to an author complaint by initiating an escalation
   procedure.  However, [RFC5620] does not clearly authorize the RSE to
   do so.

   The RSE activities I describe here are exclusive of my TRSE
   activities.  The latter consisted of research, surveying the
   community, preparing and delivering various interim presentations and
   reports, and the production and discussions of my final
   recommendations.

   Immediately below, I describe in more detail Editor-originated policy
   discussions of issues that arose from the community and beyond, and
   from my experience performing an escalation procedure.

3.4.1.  Addressing questions and problems from within the RFC Editor

   When RFC Editor staff comes upon an issue not addressed by current
   editorial policy, that issue becomes an agenda item at the next RFC
   Editor meeting.  It is impressive how complex these issues can be,
   how often they touch upon many different dimensions of Editor work
   and the Series, how intricate and extensive their implications can be
   for Editor practices and the Series, and how much investigation it
   can take to pry loose all the issues.  If we are unable to resolve a
   question swiftly, as RSE I bring it to the RSAG

   During this period, typically several issues typically arose each
   month from within the RFC Editor.  All required significant



Kowack                    Expires June 23, 2011                [Page 13]

Internet-Draft       Motivations for Recommendations       December 2010


   discussion.  We usually asked the following sorts of questions:

   o  What exactly is the issue?

   o  Is the issue reasonable, and is there a genuine need for
      resolution?

   o  Is it already covered by existing editorial policy, or will it
      require an editorial policy addition or reduction, or other
      permanent change, or a one-time exception to policy?

   o  What implications might this have for how the relevant stream, and
      the other streams, will use the Series in the future?

   o  Is the policy in question tightly linked, or derived from, some
      other policy?  If so, who are the relevant authorities (e.g., a
      stream) and how should that be handled?

   o  Is this an isolated case that can be resolved by the Editor, or is
      it significant enough, or does it have serious enough
      consequences, to require discussion by the community or the IAB?

   o  What sort of effect might the proposed change have on readers and
      end-users?

   o  What short and long-term effects might it have on the Series?

   The important questions often concerned impact on RFC Editor
   processes and the Series, and the Series' long-term character.
   During 2010 we were not presented with issues primarily having to do
   with technical writing.  Nor did we see issues with significant
   computer-scientific content related to protocols - that is, issues
   outside the scope of the Editor.  I provide here an example of issues
   presented to and discussed within the Editor, after which I review my
   experience in leading an "escalation procedure".

3.4.2.  RSE Activity Example: Ensuring and Improving Access to RFCs

   Early this year, we received a request from a company doing business
   with the US Government.  Among other things, they wanted to know how
   to fill out a required form on the sources of IETF standards,
   including the publisher of RFCs.  The RPC sought guidance because
   there was no previous policy about who is the publisher of RFCs.
   After brief discussion we realized there was no obvious answer.  I
   took that issue to the RSAG.

   This also triggered a discussion about the RFC Series' ISSN
   (International Standard Series Number).  ISSNs are often used to



Kowack                    Expires June 23, 2011                [Page 14]

Internet-Draft       Motivations for Recommendations       December 2010


   search for periodicals and disambiguate references.  During 2008, the
   IETF Trust obtained an ISSN for the Series from the ISSN
   International Centre.  However, we weren't sure whether the ISSN was
   still valid (or what the policy was for expiration), or whether we'd
   already answered questions therein about who is the publisher of
   RFCs.  We checked and confirmed that our ISSN was still valid.

   We were unable to find any reference to our ISSN over the web, nor
   through any of the major electronic card catalogs.  No one had
   apparently been assigned responsibility for following through after
   obtaining the ISSN.  I contacted old colleagues at one of the largest
   universities libraries in the world, and had them add the Series ISSN
   to their card catalog.  Nearly all major libraries cross-reference
   their catalogs, so our ISSN can now be found all over the world.

   I mention this to provide a distinct example of loose ends around the
   management of the availability of the Series.  If someone out in the
   world uses the same sorts of tools that the community does, and looks
   at things the way the community does, then there is a good chance
   they will be able to find the Series, get to the web site, and
   continue from there.  But, for someone not like us, for instance an
   academic, it may be a different story entirely.  And access is an
   identified priority for the Editor and the Series.

   These examples may appear small, but they sum to significantly
   reduced Series availability.  They also illustrate how the Editor,
   outside of document production, depends upon someone's just happening
   to notice an issue - that someone typically being a random volunteer
   willing to take initiative.

   This is not a criticism of anyone involved in these issues.  In the
   past, there has been such a narrow focus on production, probably
   necessarily so, that this sort of broader management was not given
   the necessary priority.  The best remedy will be to task someone with
   general assignments (e.g., "ensure access"), to develop a big
   picture, seek out all the relevant parts, and then be given the
   authority and resources to drive those issues to completion.

   The RFC Editor is uniquely positioned within the I*: it is a major
   formal vehicle through which the world obtains the work of the
   community.  It is vital that this Editor ensures availability to the
   entire world, especially when many people may not use the same access
   techniques, as does the community.

   A related subject is that we have not posted convenient examples for
   how RFCs should be referred to in other documents.  This lack of
   guidance increases the chance that references will be inaccurate or
   ambiguous.  Work has already been done on increasing the vitality,



Kowack                    Expires June 23, 2011                [Page 15]

Internet-Draft       Motivations for Recommendations       December 2010


   breadth of use, influence, and stature of the Series by demonstrating
   that RFCs are as rigorously reviewed as publications in conventional
   academic journals.  Early in January 2010, RSAG members Brian
   Carpenter and Craig Partridge published "Internet requests for
   comments (RFCs) as scholarly publications" in ACM SIGCOMM Computer
   Communication Review.

   Apprised of these developments, I called for the formation of an "RSE
   Committee" on Citations.  A member of the RFC Series Advisory Group
   (RSAG) led this committee whose membership came from the community (a
   general call was made for members on the rfc-interest list.)  They
   were asked to:

   o  determine the right ISSN entry format for the RFC series and
      ensure it is accessible in the global database of library
      electronic card catalogs (WorldCat),

   o  determine how documents in the RFC series should cite other RFCs,

   o  recommend how RFCs should be cited using the ACM, IEEE and MLA
      reference formats, and

   o  recommend how RFCs should be represented in Bibtex.

   This assignment conveniently combined issues of the ISSN and library
   user access issues with those of reference examples.

   The committee has been working on these related issues during 2010
   and I expect to see their recommendations shortly.  Those will be
   vetted by the RSAG and posted for discussion and review by the
   community.

   The Series Editor's choice of this new, experimental model for
   addressing Editor issues demonstrates how the RSE can have
   significant positive influence, by crafting ways to investigate and
   develop issues.  In the future, this should be done with the advice
   and consent of the RFC Editor Oversight Committee.

   An important part of the managerial expertise required of the RSE is
   not just to know how to investigate issues and drive them to
   conclusion, but to know how best to harness the interest of the
   community in the process.  Doing this well will improve overall
   outcomes by insuring their alignment with community interest.

3.4.3.  RFC Editor Escalation Procedure

   During 2010, I received only one significant complaint about
   editorial performance.  How this was handled is useful input into



Kowack                    Expires June 23, 2011                [Page 16]

Internet-Draft       Motivations for Recommendations       December 2010


   understanding the sort of managerial activities that will
   occasionally, and unavoidably, be required.

   The complaint was from the author of a document while it was being
   edited.  After extensive discussions with the author and the RPC
   staff member and director I was unable to satisfy the author and
   initiated an escalation procedure.  Since there was no procedure
   specified for dealing with such cases, I notified the RSAG and the
   IAB, kept them apprised of my activities, and frequently requested
   feedback as the process unfolded.

   I reviewed RPC editorial practices and performance with the voluntary
   support of the Independent Submission Editor (ISE).  RPC management
   was highly responsive and supportive.  I communicated my observations
   to the author.

   Neither the specifics of the complaint nor the outcome are
   significant.  What is significant, however, is that this case
   illustrates a general limitation of [RFC5620], which does not clearly
   assign (to the Series Editor or to anyone else) authority for
   initiating or managing such a procedure.  Nor does it do so more
   broadly by, for example, assigning authority for day-to-day oversight
   of the RFC Editor.  The most obvious candidates for this
   responsibility would be the IAD and IAOC due to their contractual
   oversight role, or to the Series Editor.  I found that this task
   required a high degree of editorial background, and knowledge of
   current practices and the immediate circumstances of the RFC Editor.
   Furthermore, as I requested time and attention from RPC staff, it
   became clear that there would be noticeable impact on the rate of
   RFCs output by the Editor.  However, [RFC5620] does not give the RSE
   authority or responsibility for Editor output, which could cause him
   to pay insufficient attention to any impact on productivity.
   Finally, although the RPC director was exceptionally supportive, this
   might not have been the case.  The RSE needs sufficient authority to
   insist upon support, in case future RPC management is not as
   enlightened.

   I also observed that the procedure, as performed, required far more
   than simple expertise in technical writing.  Issues that came to
   light included:

   o  Should we have more than one level of editorial service, to
      include, for example, elevated priority or assignment of more
      experienced editors in the case of especially complex documents or
      those with problematic audiences?

   o  If there are to be different levels of service, or if there are
      more frequent complaints, how much time and effort should be



Kowack                    Expires June 23, 2011                [Page 17]

Internet-Draft       Motivations for Recommendations       December 2010


      invested in either, and how should those be prioritized against
      production of other RFCs?

   o  Where is the dividing line, between authors of drafts and
      editorial staff, for responsibility for editing quality?

   o  Should the RFC Editor ever recommend that an author seek the
      assistance of an outside editor, prior to submission; and if so,
      based upon what criteria?

   o  How should escalation procedures be performed in the future?

   Responding to questions of this sort with appropriate procedures
   requires an understanding of technical writing practices, experience
   managing the editing of publications, and sensitivity to the long-
   term implications of any intervention for the character and quality
   of the series.  Experts should guide the resolution of these sorts of
   issues.  Furthermore, insofar as it is possible, leadership should be
   continuous (that is, fixed to a role and not assigned on a case-by-
   case basis) to provide institutional memory in case there are
   repeated reviews.

   I observe a gap in [RFC5620] between day-to-day production by the
   RPC, and the policy development and execution authority of the RSE.
   I recommend that this gap be filled by the RSE, the only person who
   will have the requisite editorial and managerial expertise.  The RSE
   should be responsible for, and have authority over, Editor output.  I
   also observe that day-to-day oversight by the Editor requires a level
   of experience beyond that of the IAD and the IAOC.

   Finally, there is an issue of community and I* responsibility to
   professional staff.  If we are going to evaluate staff, that
   evaluation must be led by our most qualified people.  This not only
   includes critical analysis of work performance and subsequent
   recommendations and implementing of remedies.  It also includes
   defending our professionals' performance when they are doing their
   work well under contentious or politically charged circumstances.
   Doing anything less is organizationally irresponsible and risks
   unfair treatment of our contractors' staff.  Only a knowledgeable,
   continuously involved, authorized professional manager and supervisor
   can reasonably satisfy this requirement.


4.  Differences between V2-Overview and RFC 5620







Kowack                    Expires June 23, 2011                [Page 18]

Internet-Draft       Motivations for Recommendations       December 2010


4.1.  General and Design Strategy Differences

   [RFC5620] aims to ensure community control by dividing responsibility
   for the RFC Editor into multiple functions, allowing each to be
   contracted or appointed separately: the Production Center, Publisher,
   Series Editor and RSAG, and the Independent Submissions Editor and
   Independent Submissions Editorial Board.  This division permits each
   part to focus on its mission.  It also permits the community to more
   clearly see the performance of each part, which facilitates
   performance review.  Indeed, this breaking out of the Production
   Center and Publisher has been highly successful.

   [RFC5620] does an excellent job of establishing part-by-part focus on
   each Editor component, but its "divided responsibility" strategy,
   carried all the way up to the oversight of RFC Editor operations,
   does not establish any corresponding integration of managing the
   operation of the Editor.

   The IAOC and IAD continue their historical authority for management
   of the contracts, and the IAB for arms-length oversight.  This is
   appropriate for those specific responsibilities.  However, as defined
   in [RFC5620], the Series Editor has authority only for what is left
   over: exploring and discussing issues as they arise from the
   community or within the Editor.  Unfortunately the result is a
   minimal and apparently unappealing job.

   Though not obvious from a first reading of [RFC5620], my experience
   of day-to-day operation of the RFC Editor and performance of the
   Series Editor role exposed a critical flaw: no one entity or person
   is assigned responsibility for bringing together all the different
   inputs from the Editor, plus input from the community and beyond, and
   making them all work together under the very serious demands of
   document production.  This is required so that the RFC Editor as a
   whole operates smoothly and efficiently.

   This lack of defined overall management authority also contributed to
   the failure to find a satisfactory candidate.

   [RFC5620] distributes authority for the Editor across two committees
   and two managers.  This division is problematic.  Committees are
   widely understood to be excellent at ensuring that multiple interests
   are addressed, but not at integrating inputs into a single, focused
   plan, nor for driving insights when developing such plans.
   Committees also, often with the best of intentions, suffer from
   having divided interests.  Being comprised of members from disparate
   entities or parts of the community, they may, even unknowingly, have
   divided interests.  This applies to the management structure in
   [RFC5620].  Without some one person assigned responsibility for



Kowack                    Expires June 23, 2011                [Page 19]

Internet-Draft       Motivations for Recommendations       December 2010


   overall management and development of the Editor, the community has a
   very difficult, perhaps impossible job, of knowing who is responsible
   for what is being done, and whom to talk to when there is
   dissatisfaction.

   Furthermore, [RFC5620] explicitly chooses not to define a reporting
   structure for the RFC Editor.  Instead, it treats the reporting
   structure as an implementation detail, to be established or changed
   by the IAOC on a case-by-case basis.  There are three issues
   associated with this approach.  First, the duration and intensity of
   community debate indicates that this issue needs to be resolved by
   the community as a basic design decision of the Editor.  Second,
   reporting structure is fundamental to defining the RSE role,
   including qualifications and level of experience.  Finally, it is
   extremely unlikely, as has already been demonstrated, that a
   motivated, qualified profession would accept that the reporting
   structure is to be determined in the future.  [I-D.v2-overview]
   brings this decision to the fore for community consideration.  It
   also makes future changes to the reporting structure substantive,
   permitting changes only with the approval of the IAB.

   V2 Overview makes the Series Editor responsible to the community for
   the overall performance and operation of the RFC Editor.  In this way
   the community will always know who is responsible for the Editor and
   the Series, and that the Series Editor has no other interest.

4.2.  Specific Differences

4.2.1.  Series Editor Authority and Supervisory Duties

   Under [RFC5620], the responsibilities of the Series Editor are
   limited and insufficient.  The Series Editor is responsible for
   addressing shortfalls in policy by taking them to the RSAG and the
   community for discussion and community resolution and, as required,
   confirmation by the IAB.  The RSE is also responsible for
   'implementation', without explaining what this means and without
   empowering the RSE to achieve implementation.  That is, [RFC5620]
   does not state that the RSE has authority to direct the resources of
   the Editor (the Production Center and Publisher) in any
   implementation.  It is likely that in many cases the Production
   Center would temporarily need to reduce their rate of document output
   in order to implement a new policy, and would need to be directed to
   take such actions.  The RSE should be able to provide directions to
   do so after discussion and review by the streams and the REOC.
   However, under [RFC5620] the RSE would need to seek permission from
   the contract administrators, the IAOC or IAD.  This is problematic.
   First, understanding the impact of any change on RFC production is
   best done by someone who has intimate knowledge of the production



Kowack                    Expires June 23, 2011                [Page 20]

Internet-Draft       Motivations for Recommendations       December 2010


   process, and to ensure community alignment; this should be done by
   under Series Editor leadership with the Production Center director.
   Second, putting control in the hands of the IAOC (or IAD) is
   problematic in that the IAOC and IAD are not structured for such
   publications expertise, and have multiple responsibilities that could
   conceivably compete with their attention to this subject.  Finally,
   not having this sort of responsibility, and instead having to go
   through "contracts administration" (which is how it could be
   perceived) each time there was a sub-contract level change, would be
   unnecessary overhead, and very likely unacceptable to any qualified
   RSE candidate.

   Supervision should be the responsibility of the most knowledgeable
   and experienced manager available.  If there is to be an RSE, why not
   assign a direct supervisory role to the position, rather than put
   supervision in the hands of staff that are less knowledgeable (w/r/t
   editing and publications)?  The same argument applies to reviews of
   performance.  The RSE should lead reviews of the performance of the
   contractors, while the IAOC should lead annual reviews of Editor
   performance overall.

   Nothing here is an argument against oversight, which this memo
   maintains is required.  RFC Editor oversight must be focused, must
   have a suitable level of understanding or experience in publication,
   and must support the RSE via an "advise and consent" model.

   The sorts of issues managed by the RFC Editor are different from
   those of the IAD and IAOC.  The IAD and IAOC regularly agree to new
   contracts with significant financial exposure for the overall
   organization.  The RSE will only rarely (perhaps once every few
   years) be involved in teamwork regarding major financial commitments
   (for example, when RFC Production Center and Publisher contracts are
   renewed or re-bid).  Most of the time, the RSE will be involved
   primarily in many small daily and weekly decisions regarding
   editorial and publication work and policies.  Such decisions will
   only occasionally have contractual consequences.  In this case, it is
   not necessary to have the same degree of executive involvement by the
   REOC, as is the case with the IAOC.

4.2.2.  RFC Editor Oversight Committee and RSAG

   Under 5620, the IAB provides oversight for the RFC Editor both in
   terms of chartered responsibility and regular reporting.  However,
   the IAB is involved in a great many priority issues that compete with
   the RFC Editor, and cannot give a great deal of time or attention to
   the RFC Editor.  Furthermore, the skill set required of IAB members
   conflicts with the skill set required of those who would directly
   oversee the RFC Editor and RSE.



Kowack                    Expires June 23, 2011                [Page 21]

Internet-Draft       Motivations for Recommendations       December 2010


   Under [RFC5620], the RSAG is an informal advisory body with no
   authority for oversight of the Series or the RSE.  Having oversight
   authority would be awkward at best, since it is the Series Editor who
   nominates RSAG members.

   V2 Overview calls for the formation of an RFC Editor Oversight
   Committee (REOC), that follows an "advise and consent" model to
   support the Series Editor and ensure alignment with community
   interests.  This committee is structured to focus strictly on RFC
   Editor issues, and should be populated with members with significant
   interest, experience and expertise in the area of technical editing,
   publishing, and the Series itself.  This is not a re-labeling of the
   RSAG.  The REOC is selected differently (by the IAB, not the RSE),
   has a different mission (oversight, not strictly advice), and real
   authority (consent, which may be denied).

   The role of the REOC is significantly different from that of the
   IAOC, in spite of having a similar name.  The IAOC is directly
   involved in contractual, legal, and financial matters at the
   administrative level, and at least 3 times a year has to investigate,
   plan, and make major financial commitments for IETF meetings.  The
   RSE and REOC will only be involved in such matters every few years,
   as the contracts for the RPC and Publisher renew.  Even then, the RSE
   and REOC will be involved primarily as publications subject matter
   experts and not as financial administrators or contracts specialists.
   Rather, the RSE and REOC will focus on the large number of policy and
   operational issues, and their complex interactions and relative
   priorities that are of interest to the Editor and thus to the
   community.

   This motivates the "advise and consent" REOC model, in place of
   having the RSE reporting to a management committee.  The RSE should
   have far more publications and editorial expertise than the
   collective of the REOC, have much more intimate knowledge of all the
   day-to-day issues, and should thus be able to take a more leading
   role - all the while with the consent of the REOC.  This approach
   will ensure alignment with community interest while encouraging
   initiative and innovation.

   The IAB will retain its chartered responsibility for the RFC Editor,
   and will be consulted by the REOC on substantive policy questions.
   Thus the IAB will be relieved from involvement in day-to-day
   questions by delegating much of its oversight role to the REOC.

4.2.3.  Decommissioned RFC Series Advisory Group

   In [RFC5620], RFC Series Advisory Group (RSAG) members are nominated
   by the RSE and approved by the IAB.  The RSAG has few formal duties.



Kowack                    Expires June 23, 2011                [Page 22]

Internet-Draft       Motivations for Recommendations       December 2010


   V2 Overview decommissions the RSAG to avoid redundancy with the REOC
   and thus reduce committee overhead.  For transparency,
   [I-D.v2-overview] states that the Series Editor may have advisors,
   and that their names should be publicized.  There is nevertheless a
   need for continuity and maintenance of institutional memory within
   the RFC Editor.  The RSAG members should be asked to remain on board
   at least until the REOC is fully oriented and up to speed.  This is
   consistent with the text in V2 Overview that states that the RSE may
   have informal advisors.  (Since that text is not strictly necessary,
   it may be removed from V2 Overview depending on community input.)

   Although not a major design flaw, it is notable that [RFC5620] takes
   a contradictory approach to the RSAG.  RSAG has no real authority,
   being largely an informal team of advisors nominated by the RSE.
   Membership under such terms does not typically require approval,
   although [RFC5620] mandates IAB approval of RSAG nominees.
   [I-D.v2-overview] corrects this situation by disbanding the RSAG,
   giving the REOC significant authority, and mandating IAB authority
   for selecting REOC members.

4.2.4.  The IAOC and IAD

   [I-D.v2-overview] does not call for any change in the chartered
   responsibilities of the IAOC.  It does explicitly propose to have the
   RSE (as the resident editorial and publications expert) join the IAOC
   when it is reviewing contractor performance, re-issuing of contracts,
   preparing requests for proposals, and reviewing bids.

4.2.5.  The Series Editor and General Management Issues

   V2 Overview gives the Series Editor exclusive direct management over
   its facilities by assigning him responsibility for overall
   performance of the Editor.  All current regular meetings should be
   reviewed, and possibly put under RSE management, to avoid any
   confusion about where Editor directions are coming from.


5.  RFC Editor and Series Development Work

   The following steps to improve the series and its accessibility are
   based on input from community members and on my own experience and
   analysis.  Unless otherwise stated, these are areas requiring
   eventual attention, not a list of efforts that the RSE should
   necessarily engage in immediately.  Each will require leadership by
   the Series Editor to ensure responsiveness, knowledgeable discussion
   within the community, and reasonable progress towards a consensus
   solution.  Leadership is also necessary to ensure correct
   prioritization of this type of work, and that all changes work well



Kowack                    Expires June 23, 2011                [Page 23]

Internet-Draft       Motivations for Recommendations       December 2010


   together.

   Because the work of the community is done almost entirely by
   volunteers, the Series Editor should be careful not to interfere with
   or replace volunteer activities.  Very often the Series Editor will
   not actually direct various activities but rather will make sure that
   critical issues are being addressed and that participants are aware
   of the big picture.

5.1.  Update, Improve, and Reorganize the Style Manual

   The RFC Style Manual (or 'Guide') is a lightly organized collection
   of seven web pages on the RFC Editor site.  Those include several
   different documents (one of which is an expired Internet Draft);
   various parts are redundant; and there is limited information to
   guide the novice's use of and interpretation of the Manual.  One
   community member mentioned that various parts of the RFC style were a
   major input to the style guide of his own corporation (a major
   software developer).  His colleagues need to be able to refer to the
   RFC Style Manual, which they say they cannot do in its present state.
   Fixing this problem will increase the consistency and stature of the
   Series.

   The Style Manual as it stands is insufficient to direct substitute
   editors in case of an unexpected break in service.  The Manual should
   be reorganized, consolidated, and updated as necessary.  This should
   include a part-by-part review for currency and accuracy.

   Community members have suggested the Manual be divided into two
   sections: a small, slowly evolving core of 'musts' to be enforced by
   Editor staff.  This core should be kept as minimal and
   straightforward as possible.  It should be augmented by a larger,
   more quickly developing set of guidelines for authors, possibly in a
   separate document.  The core information should be published as an
   RFC, while more frequently changing sections (e.g., the abbreviations
   list) could be left to (or incrementally updated as) web pages.

   The Editor does not presently recommend any general style manuals
   (e.g., The (University of) Chicago Manual of Style) to guide authors
   above and beyond the RFC Editor Style Manual.  The Editor should do
   so, but, to ensure that the Series does not become stylistically
   narrow, might better suggest several widely accepted style manuals
   that authors might refer to than require their adherence to one
   particular manual.

   The above are rough suggestions.  General and detailed decisions
   should be left up to the incoming Series Editor with support from the
   Editor staff, REOC members, and in concert with the community.  The



Kowack                    Expires June 23, 2011                [Page 24]

Internet-Draft       Motivations for Recommendations       December 2010


   new Series Editor should consider establishing a standing committee
   comprising knowledgeable people from each of these groups.  I see no
   reason why there cannot be far more direct participation by the
   community in this effort than in the past.

5.2.  Develop and Publish a Procedures Manual

   There is no one place (particularly, not among the RFC Editor web
   pages) where one can find a definitive description of the processes
   followed by the Editor, and how the Editor interacts with the
   Streams.  As previously identified, the Procedures Manual, along with
   the Style Manual, is the core device for ensuring quick guidance of
   alternate editors in case of an unexpected interruption in service.
   As with the Style Manual, a comprehensive effort should be undertaken
   to collect all relevant policies in one place, once again involving
   staff, committees and knowledgeable community members.

   Particular attention should be paid to documenting procedures at the
   correct level of detail.  Many procedures fall near the boundary
   between common sense, editorial lore, and a need for formal
   documentation.  The Procedures Manual should be designed to permit
   incremental addition over the years; all participants should guard
   against adding more detail than is necessary.

5.3.  Improvements to the RFC Editor Web Pages

   Community members frequently assert that the RFC Editor web site is
   rudimentary, has an old-style look and feel, and needs to be
   reorganized for clarity.  The web site is a key entry point for
   access to the Series, and especially to facilitate new authors'
   understanding of how to write an Internet draft on the way to
   publishing an RFC.  Given the community's increasingly international
   membership, adding support for languages other than English may in
   time be appropriate.

   The Series Editor should consult with the Oversight Committee and the
   community to explore how the site might be improved, and formulate a
   plan for doing so depending upon acquisition of resources including
   volunteers.

5.4.  Investigate Enhanced Training for RFC Authors

   The Editor provides an orientation for draft writers during the IETF
   week that focuses on draft- and RFC-specific issues.  Enlarging this
   orientation to provide general guidance for how to write technical
   documents could we an efficient was to assist both authors and
   production center staff.  I am not suggesting that the Series Editor
   personally provide this training, which requires very specific



Kowack                    Expires June 23, 2011                [Page 25]

Internet-Draft       Motivations for Recommendations       December 2010


   skills.  Rather, the RSE should join with the streams to identify if
   there are efficiencies to be gained by one or more types of such
   training, and to determine if a plan should be developed for
   obtaining that training, which can be very expensive to produce.
   Contracting with an outside training organization is one option.

5.5.  Investigate Providing Support for RFCs in Additional Languages

   Our community is constantly becoming more international.  Some
   suggest we may be asked, for example, to improve the ease of
   participation by non-native English speakers by providing pointers to
   unofficial translations of RFCs.  We may eventually wish to certify
   such translations as being within certain quality criteria.  The RFC
   Editor's responsibilities may grow to include ensuring that such
   requests by community participants (or RFC end-users) are handled
   expeditiously.  If work begins in this area, it should be done in
   concert with other internationalization efforts, such as support for
   non-English languages in the RFC Editor web site, as mentioned above.

5.6.  Consider Supporting RFC Clusters and Enhanced RFC Annotation

   At present, if one wishes to know the relationships between various
   RFCs, one has to read the metadata and 'walk' from RFC to RFC.  Also,
   despite the enormous body of knowledge in the community, there is no
   commonly available facility that describes:

   o  clusters of RFCs and their relationships (a 'cluster' is any
      collection of RFC that are of interest to someone who has
      collected information on them),

   o  annotations of RFCs, (these could include, for example, notes
      provided by readers of RFCs indicating their experience as they
      implemented a particular service; annotations could be graded for
      usefulness, using a reader-entered ranking system),

   o  service descriptors (anyone wishing to implement transport, for
      example, could use descriptors to locate, readily and
      unambiguously, all current RFCs required to implement that
      technology).

   Volunteer work in this area is already under way.  The Series Editor
   should informally encourage and support these efforts and investigate
   whether more significant support should be given.

5.7.  Investigate Reinforcing the Status of the Series as Academic
      Publications

   How to increase the standing of the RFCs and the Series in the



Kowack                    Expires June 23, 2011                [Page 26]

Internet-Draft       Motivations for Recommendations       December 2010


   academic world is already under discussion.  This process may be
   valuable to continue.

5.8.  Investigate Formal Persistent Names or Identifiers for RFCs

   I am told that Digital Object Identifiers (DOIs) have become common
   in academic publishing, and that citations more and more often
   require DOIs.  We do not presently have any plans to provide URIs
   (Uniform Resource Identifiers) or DOIs for RFCs.  The RSE should
   begin a process to determine whether there is a need for such
   facilities, and if so what sort of process should be followed to
   determine what needs to be done and how to do it.

5.9.  Lead Discussion on Universal Access and the ASCII Format of
      Normative Versions of RFCs

   A significant number of community members have noted that discussion
   about the ASCII format goes through cycles of intensity.  The Series
   Editor will need to participate in these discussions and attempt to
   make them productive.  One of the identified problems is the limit of
   ASCII art.  Community members tell me that they cannot produce
   complex mathematical notation using ASCII, which they claim keeps
   them from publishing certain RFCs (if this is so, then our
   universality-oriented policy is keeping some RFCs from being created
   in the first place).  Another concern is the impossibility of
   representing author names that require non-ASCII character sets.  The
   Series Editor and Oversight Committee should survey community
   thinking on the subject, decide whether and when a comprehensive
   review should take place, and specify the process(es) that review
   should follow, while keeping in mind the need for long-term
   accessibility of archival documents.


6.  RSE Time Requirements

6.1.  General Recommendations

   A one-third-time appointment is the absolute minimum for the Series
   Editor position for the appointee to provide ongoing leadership and
   to represent the Editor and the Series on an ongoing basis.

   Additional time is required to discuss, analyze, prioritize,
   communicate, and guide through to implementation the regular flow of
   development issues that come to the Editor (exclusive of ongoing
   document production).  Still more time is required to participate in
   exceptional events, such as community controversies or debates,
   customer complaints that could result in escalation procedures, or
   time-consuming external demands.  Altogether, these tasks add a



Kowack                    Expires June 23, 2011                [Page 27]

Internet-Draft       Motivations for Recommendations       December 2010


   minimum of roughly 20%-time, to bring the position to a minimum half-
   time appointment.

   An appointment beyond half-time would be reasonable but is not
   strictly required.  Above that level depends upon the desire by the
   community for faster or additional Series and Editor development.

   These observations are based on the work level analysis below, and
   are consistent with my sense of the character and scale of the work
   as I experienced it.

6.2.  Current Level of Effort

   Currently, and consistent with [RFC5620], the RSE regularly
   participates in (exclusive of TRSE work):

   o  various regular meetings (IETF, IAB, etc),

   o  ad hoc community interaction face to face, via email, face to
      face, phone, etc.,

   o  frequent interaction with the production center and the RSAG,
      including investigation of practices and policy issues, and

   o  research, analysis of, and planning of various initiatives and
      their implementation.

   These are activities are structurally required or follow from
   continuing community interest.  Below are rough estimates for some of
   these activities.  For convenience I assume 12 four-week months a
   year, and represent a week as 2% of a year, and a month as 8.5% of a
   year (both rounded down slightly).  These are well within the
   accuracy of these sorts of observations.

      Regular meetings:

         IETF meetings:

            3 per year, 1 week per meeting, plus an equal amount of
            preparation and follow-up time. 1.5 months per year, or 12%
            time.

         RFC Editor weekly meetings:

            1 hour each, plus 1 hour of prep and/or follow-up. 8 hours
            per month (12 days / year), or 6% time.





Kowack                    Expires June 23, 2011                [Page 28]

Internet-Draft       Motivations for Recommendations       December 2010


         IAB bi-monthly meetings:

            2 hours each, plus 2 hours report preparation time, bi-
            monthly. 8 hours / month (12 days / year), or 6% time.

         Total time, regular meetings:

            approximately 25%-time requirement.

         See Section 6.3, below, for how these values correspond to the
         anticipated workload cited in [I-D.v2-overview].

      General Representation and Communication:

         E-mail, rfc-interest list, phone conversations, etc:

            4 hours/week (24 days/year), or 12 % time.

         The span of communications, including email traffic, on which
         the Series Editor needs to be current, requires a considerable
         time investment.  The RFC Editor is a place where many
         different activities of the community meet.  Recent discussions
         about the standards process are an example.  The RFC Series
         Editor needs to follow such discussions to maintain general
         community context, to anticipate impact on the Editor or the
         Series, and to represent his observations.  Preparing for
         participation in email threads requires a significant amount of
         time.

         Total time, regular meetings and general communications:

            this is slightly more than a 1/3 time appointment (37%,
            which is 25% plus 12%).  This is within the range of
            accuracy of the 1/3 time appointment recommendation above.

6.3.  Additional responsibilities under V2-Overview

   Under [I-D.v2-overview], time previously required for interaction
   with the IAB and RSAG will be replaced by interaction with the REOC.

   I anticipate that the REOC will eventually meet monthly for one to
   two hours, but initially, every two weeks.  There will also be
   somewhat more frequent discussions between the RSE and individual
   REOC members, which I anticipate will depend upon the level of Editor
   and Series development work.  Overall, I expect that the time devoted
   to upwards reporting will increase slightly compared to past
   practice.




Kowack                    Expires June 23, 2011                [Page 29]

Internet-Draft       Motivations for Recommendations       December 2010


      Major Planning Cycles, Annual and Multi-Year:

         In addition to ongoing work there will be annual reviews of
         Editor performance.  Also, every few years there will be major
         investments of time devoted to reviews of long-term performance
         of contractors, and constructing new requests for proposals.

         Annual reviews of RFC Editor and Publisher:

            1 week, or 2% time.

         This activity slightly increases the average yearly commitment
         of the Series Editor, but does not alter my one-third-time
         recommendation.

      End-of-Contract review of performance of Production Center and
      Publisher:

         This item includes joint work with the IAD and IAOC on major
         reviews, revisions to contracts, creation of new requests for
         proposals (RFPs), preparation for and participation in bidders
         conferences, and reviews of bids.

         End of Contract Reviews:

            4 weeks (although in case of very large changes, time
            requirements could be much greater). 8% time.

         Because the new contract activities occur so irregularly, I do
         not explicitly include them in the annual baseline.  They are
         better considered as part of project work.

6.4.  Which Levels of Appointment Make Practical Sense?

   Practically speaking, just two work level ranges are sensible and
   would be acceptable to a professional: full-time; or a defined level
   up to and including 50 or 60%.

   Increasing the level much above 50% but not up to 100% could be
   problematic.  Few people find themselves able to limit themselves to,
   for instance, an 80% job; at some point there is a strong tendency
   for such a position to become full-time.  It is commonplace in our
   industry, and in publishing, for "full-time" professionals to far
   exceed 40 hours per week.  This indicates that once the job's minimum
   time requirements begin to exceed ~60% of a nominal 40-hour work
   week, the community will get much more value for money from a full-
   time employee.




Kowack                    Expires June 23, 2011                [Page 30]

Internet-Draft       Motivations for Recommendations       December 2010


6.5.  Orientation Time Requirements

   Learning the Series Editor job will be very time-consuming, depending
   upon the level of orientation and support provided and the
   appointees' prior knowledge of the environment.  My experience
   suggests that a relative novice will require approximately 6 months
   to get up to speed; even someone quite familiar with our environment
   will take at least several months.  I strongly recommend development
   of an orientation plan, to include multiple orientation meetings
   (working sessions well beyond getting-to-know-you meetings), walks
   through all key RFCs, and extensive review of all other relevant
   documents and processes.


7.  Key Questions and Answers

   Over the years, the RFC Editor has had progressively narrower scope
   and authority.  After removing any influence over the technical
   content of RFCs, splitting out the Independent Submissions Editor
   role, and moving the technical editors into a separate organization,
   why is an RSE necessary at all?

      [RFC5620], documenting an earlier consensus, mandates an RSE role.
      My experience in the position has documented (above) significant
      outstanding management and development issues.  Many of these
      cannot be ignored and, if not managed explicitly, could end up
      being done in an ad hoc fashion, and quite possibly badly.  I
      present reasons, above and below, why a committee is unlikely to
      do the job effectively.

   Can't the Production Center Director do the job?

      In spite of the excellence of the entire RFC Production Center
      staff at technical writing, and their understanding of the current
      state of Editor practice, they have not had prior experience at
      the sort of work I describe.  Furthermore, assigning the RSE role
      to Production Center management could create a problematic
      division of their attention and eventually either the planning or
      the production would suffer.  Asking a single person to fill both
      positions will make it more difficult for the community to observe
      and assess how matters are being prioritized.  Finally, a very
      significant part of the incoming RSE role will be to review all
      the editorial and other practices of the Editor to develop a real
      and complete Style Manual and a real and complete Procedures
      Manual; someone other than the production staff must do this.
      Otherwise, the community can have no confidence that the process
      will provide insurance against breaks in editorial service.  Said
      differently, Production Staff cannot be expected to review



Kowack                    Expires June 23, 2011                [Page 31]

Internet-Draft       Motivations for Recommendations       December 2010


      themselves, which would be a conflict of interest.  And, as
      described below, the necessary review requires more, and more
      continuous, attention and focus than can be expected of those
      volunteers who oversee the RSE.

      I emphasize that these are structural observations and in no way
      any criticism of staff or AMS.  All have performed professionally
      and diligently during my tenure.

   Can't a Community Committee do the Job?

      A committee is simply not a good vehicle for discerning and
      pursuing strategic needs, particularly if the committee has other
      duties or is made up of members with varied interest.  A committee
      can provide support, guidance and oversight, but cannot do the
      primary thing this job requires: focus on uncovering Editor issues
      and driving them to conclusion, in combination, and in a way that
      improves the long-term performance of the RFC Editor.  That means
      making sense of the entire Editor, its operations, policies and
      relationship to staff, the community and other community entities.
      This includes establishing means to ensure no interruption of
      service.  Lessons from management, and past experience in the
      community, argue that a single professional responsible for making
      this happen, and for being accountable for it happening, is
      necessary.

   Should the RSE come from the community or should an outsider do the
   job?

      Someone from the community may be able to do the job, but only if
      qualified as defined above and in [I-D.v2-overview].  However,
      significant publications management experience and expertise in
      not widely found in the community.  Furthermore, there is a great
      opportunity for the community to find an experienced outsider who
      will drive new thinking and debate.  This is far less likely with
      someone from the community.

      Keep in mind that the REOC and IAB, and an anticipated,
      predictable degree of community participation, will provide a very
      rich and steady flow of community input on all issues.

   After the reductions in the RSE role mentioned above, is there
   anything left to attract an experienced publications professional?

      There can be, if the job is appropriately structured, and properly
      supported by the REOC, IAB, and the community.  The RFC Series is
      one of the most important technical collections in history.  Many
      qualified professionals would leap at the chance to lead the



Kowack                    Expires June 23, 2011                [Page 32]

Internet-Draft       Motivations for Recommendations       December 2010


      community in improving the Series and the operation of the Editor.
      They would also love to learn how and why this amazing Series and
      innovative community work; this is a real career builder.
      However, the incoming RSE must understand that their job is to
      lead the community in discovering, defining, prioritizing, and
      agreeing on changes, improvements and innovations, and then
      implementing them.  (This, in spite of the confusing terminology
      of the Editor: the RFC Editor is actually a publisher, the RFC
      Publisher is actually an archive and access server, and the RFC
      Series Editor is actually the head of a publications department in
      which there are four 'editors' not appointed by the Series Editor
      -- the four stream approvers.)  In years past, this might not have
      been attractive to a publication professional, which would have
      expected far more control.  However, in significant part thanks to
      the Internet, the world of publications has changed.  An example
      of this is Wikipedia, whose leadership provides an environment for
      a community of writers and editors, establishes rules, and lets
      the world of contributors do the rest.  However, the role is still
      somewhat thin compared to the degree of autonomy usually granted
      to professionals leading this scale of series and sort of effort.
      Hence, his having authority over the Production Center and
      Publisher is all the more important; not giving the RSE this
      authority could preclude attracting strong candidates.

   Can a Volunteer to the Job?

      Of course it is possible, if the community can find someone
      qualified and willing to do the job.  However, that appears
      unlikely, for structural reasons.  In our community, those who
      occupy senior positions that require a substantial fraction of
      their time, such as membership in the IAB or IESG, require
      substantial support from their employers; this is effectively
      'seconding' an employee to the volunteer job.  Employers do this
      because of the strategic value and stature it brings their
      organizations.  This value is often related to the strategic
      insights and influence that follow from the roles, and such value
      depends on the Community work the 'seconded' professional does
      being strategic to the employer.  This does not generally apply to
      editing.  Finding an organization in the publications world that
      would support a 'seconding' is unlikely.  Conclusion: Seeking
      volunteers, may be a time and energy-consuming dead-end.  It could
      be done on a limited basis before reverting to seeking a paid
      professional.

      There is another issue.  This job is complex, difficult, rich with
      personalities and opinions.  Paying someone to do it may be
      required for him to insure continuity under the challenges and
      pressures that will invariably occur.



Kowack                    Expires June 23, 2011                [Page 33]

Internet-Draft       Motivations for Recommendations       December 2010


   What keeps the Series Editor from having undue influence or
   'capturing' the community and making them dependent upon him?

      First, a major goal of the RSE is to ensure that no one in the
      Editor, or outside the Editor, can have undue influence, and that
      includes him.  When writing the documents that ensure quick
      provision of alternate editing resources, he must also document
      his part in those processes and decisions.  The REOC should remain
      diligent about this his supporting this requirement, and they have
      tools at their disposal to be sure they can do so.  First, the RSE
      will not have any control of his own over Editor resources; my
      recommendations require that he not come from any of the other
      contractors of Editor services.  Second, they should have enough
      expertise to review the RSE's work to ensure it is complete.
      Third, the recommendations stipulate a 3-year term of office; long
      enough to learn the job and get good at it, but not long enough to
      insert himself irreversibly into various relationships, and short
      enough that the clock will run out on its own in a reasonable
      amount of time.  Finally, the RSE is a planning and oversight job.
      Except for brief intervals when the RSE is critically important to
      development of some activity, they should not be important to any
      real-time events during which they could 'squeeze' the community.
      Professionals being very good at their jobs, and providing great
      value to the community, has nothing to do with 'capture'.  Using
      that, or other values, to gain improper results of any form in
      defiance of community will, does.


8.  IANA Considerations

   None.


9.  Security Considerations

   None.


10.  Normative References

   [I-D.v2-overview]
              Kowack, G., Ed., "RFC Editor Model Version 2",
              I-D draft-kowack-rfc-editor-model-v2-overview-00,
              November 2010.

   [RFC5620]  Kolkman, O. and IAB, "RFC Series Editor Model (Version
              1)", RFC 5620, August 2009.




Kowack                    Expires June 23, 2011                [Page 34]

Internet-Draft       Motivations for Recommendations       December 2010


Author's Address

   Glenn Kowack
   Riveronce

   Email: glenn@riveronce.com













































Kowack                    Expires June 23, 2011                [Page 35]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/