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

Versions: 00

Network Working Group                                     G. Kowack, Ed.
Internet-Draft                                                 Riveronce
Expires: April 29, 2011                                 October 26, 2010


                       RFC Editor Model Version 2
                  draft-kowack-rfc-editor-model-v2-00

Abstract

   The RFC Editor publishes the Internet's archival series of technical
   and informational documents.  RFC 5620 defines RFC Editor Model
   Version 1, whose implementation began in January 2010.  Model 1
   divides RFC Editor activities into a number of components, including
   the RFC Series Editor (RSE).  During 2010, a "Transitional RFC Series
   Editor" performed and evaluated the RSE role.  Based on direct
   experience, extensive discussions with the community, and research,
   the TRSE provides this updated version of RFC 5620.  This draft
   revises the RSE job description, and makes recommendations for the
   search and selection process for a permanent RSE.  This memo also
   clarifies RFC Editor and RSE activities using established approaches
   of management and oversight of a publication service, tailored for
   the style of the Internet technical community.  Careful attention is
   paid to ensuring stable operations.  This document observes that RSE
   responsibilities demand a very high level of editorial and managerial
   expertise.

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 April 29, 2011.

Copyright Notice

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



Kowack                   Expires April 29, 2011                 [Page 1]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   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
   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.


Table of Contents

   1.  Executive Summary: Refinements to the RFC Editor Model . . . .  4
   2.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  RFC Editor Model . . . . . . . . . . . . . . . . . . . . . . . 10
   4.  RFC Series Editor  . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  RSE Executive-Level Management . . . . . . . . . . . . . . 13
     4.2.  RSE General Responsibilities . . . . . . . . . . . . . . . 20
     4.3.  RFC Series Editor Specific Responsibilities  . . . . . . . 26
     4.4.  RSE Professional Qualifications  . . . . . . . . . . . . . 29
     4.5.  RSE Term of Office . . . . . . . . . . . . . . . . . . . . 30
   5.  Independent Submission Editor  . . . . . . . . . . . . . . . . 30
     5.1.  Independent Submission Editor General Responsibilities . . 30
     5.2.  ISE Professional Qualifications  . . . . . . . . . . . . . 31
     5.3.  ISE Term of Office . . . . . . . . . . . . . . . . . . . . 32
     5.4.  Independent Submission Stream Editorial Board  . . . . . . 32
   6.  RFC Production Center  . . . . . . . . . . . . . . . . . . . . 32
   7.  RFC Publisher  . . . . . . . . . . . . . . . . . . . . . . . . 33
   8.  Committees . . . . . . . . . . . . . . . . . . . . . . . . . . 34
     8.1.  RFC Series Advisory Group (RSAG) . . . . . . . . . . . . . 34
   9.  Resolution of Disagreements  . . . . . . . . . . . . . . . . . 36
     9.1.  Disagreements between RFC Editor Components and Model
           Participants . . . . . . . . . . . . . . . . . . . . . . . 36
     9.2.  RSE Review of Inter-Stream Conflicts . . . . . . . . . . . 37
   10. Re-Establishing an RFC Editor Stream Capability  . . . . . . . 37
   11. Future Considerations  . . . . . . . . . . . . . . . . . . . . 38
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 38
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 38
   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 39
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 39
     15.2. Informative References . . . . . . . . . . . . . . . . . . 39
   Appendix A.  2010-11 RSE Search and Selection Process  . . . . . . 39
     A.1.  Overview and Criteria  . . . . . . . . . . . . . . . . . . 39
     A.2.  Structure  . . . . . . . . . . . . . . . . . . . . . . . . 40
     A.3.  Stream Appointments  . . . . . . . . . . . . . . . . . . . 40
     A.4.  RSAG Appointees  . . . . . . . . . . . . . . . . . . . . . 40



Kowack                   Expires April 29, 2011                 [Page 2]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


     A.5.  SSC Regular Member Qualifications  . . . . . . . . . . . . 41
     A.6.  Additional Qualifications for Streams Appointees . . . . . 41
     A.7.  Additional Qualifications for RSAG Appointees  . . . . . . 41
     A.8.  Non-Voting Members . . . . . . . . . . . . . . . . . . . . 42
     A.9.  SSC Assistants and Additional Expert Advisors  . . . . . . 42
     A.10. SSC Approval of Job Description  . . . . . . . . . . . . . 42
     A.11. Financial and Legal Preparations . . . . . . . . . . . . . 42
     A.12. SSC Alignment with RSE Job Description . . . . . . . . . . 43
     A.13. SSC Call for Candidates  . . . . . . . . . . . . . . . . . 43
     A.14. Applications and Short List  . . . . . . . . . . . . . . . 43
     A.15. Confidentiality  . . . . . . . . . . . . . . . . . . . . . 44
     A.16. Best and Final . . . . . . . . . . . . . . . . . . . . . . 44
     A.17. IAB Process Review . . . . . . . . . . . . . . . . . . . . 44
     A.18. IAOC / SSC Joint Negotiation . . . . . . . . . . . . . . . 45
     A.19. SSC DRAFT SCHEDULE . . . . . . . . . . . . . . . . . . . . 45
     A.20. No Suitable Candidate  . . . . . . . . . . . . . . . . . . 45
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46


































Kowack                   Expires April 29, 2011                 [Page 3]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


1.  Executive Summary: Refinements to the RFC Editor Model

   The RFC Series is the Internet technical community's official medium,
   through which it communicates with itself and the rest of the world.
   The RFC Editor is the community-defined and -supported function that
   accepts documents from different streams, makes textual edits for
   clarity and formal correctness as prescribed in the RFC Series Style
   Manual, and publishes and archives those documents as RFCs for free
   access by everyone.

   RFC 5620 first defined the components and processes of the present-
   day RFC Editor (Model Version 1), including the RFC Series Editor
   (RSE) as its leading component.  However, the attempt to hire a new
   RSE proved difficult and resulted in retention of a Transitional RSE,
   or TRSE.  The TRSE was asked to perform the RSE functions described
   in RFC 5620, to determine if those descriptions matched what was
   needed and, if necessary, recommend changes to the role of the RSE
   and refinements to the RFC Editor model based on his experience.  The
   central observation of the TRSE is that:

   the RSE role demands the expertise and experience of a senior manager
   and subject matter expert in technical writing, technical publishing,
   and technical series development.

   This observation drives the clarifications and changes recommended
   here to RFC Editor Model Version 1.  Although modest, these changes
   are fundamental to the future success of the RFC Editor's service to
   the Internet community.  The first clarification is:

   the overall leadership and management of RFC Editor functions must be
   by the RFC Series Editor - the editorial and publications subject
   matter and management expert.

   However, this general leadership must be tempered by two
   considerations.

   o  The Internet technical community has requirements, processes, and
      traditions that must be followed by the RSE and across the entire
      RFC Editor function

   o  The line between the responsibilities of the RSE and of the IETF
      Administration and Oversight Committee (IAOC) must be clarified.

   The new model combines RFC Editor leadership as it would be practiced
   in a typical not-for-profit organization with the following Internet
   community-driven practices:





Kowack                   Expires April 29, 2011                 [Page 4]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   o  seek community input appropriately and widely,

   o  encourage volunteer initiative and contribution, and

   o  practice supervision according to specified procedures.

   This model recommends collaboration between the RSE and the IAOC
   analogous to the partnership between line management and finance as
   practiced in most modern corporations:.

   o  The RSE is responsible for regular editorial activities
      management, including long-term editorial planning.

   o  The IAOC retains its leadership of legal and financial matters.

   The RSE reports to the IAB for general matters.  The IAB retains its
   responsibility for ensuring proper RSE policy formation and
   adherence.

   Additional recommendations for changes to model provided in RFC 5620
   include:

   o  The independence of the Independent Submission Stream and
      Independent Submission Editor (ISE) is reiterated.

   o  The role of the RSE Advisory Group (RSAG) is marginally expanded
      to ensure the RSE follows community will and to provide counsel to
      the IAB when the RSE is either unavailable or the subject of a
      discussion.

   This memo also clarifies the RSE's responsibility for maintaining
   Series quality.  The updated model divides Series continuity, a key
   element of the RSE role, into editorial and operational continuity.
   To accomplish the former, the RSE is to maintain and develop the RFC
   Series Style Manual.  To ensure the latter, the RSE is to develop and
   maintain the RFC Series Procedures Manual.  To return the RFC Editor
   to its historical level of independence, this memo recommends
   creation of an RFC Editor stream.

   Finally, an updated RSE search and selection process is proposed.
   This process is rooted in community participation, qualified
   participants and expert advisors, and follows carefully described
   procedures and elements to ensure a successful hire.

   An unexpected consequence of the TRSE effort is that most of the
   changes proposed for the updated model return the RFC Editor to the
   style and perspective used during the first 40 years of its life,
   although adapted to today's structure and operation of the technical



Kowack                   Expires April 29, 2011                 [Page 5]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   community.  This memo concludes that this time-proven arrangement is
   the best way, to serve the requirements of the Internet technical
   community.


2.  Background

   The RFC Series is the Internet technical community's official medium,
   through which it communicates with itself and the rest of the world.
   6,000 RFCs since 1969 comprise one of the most extensive and
   influential technical series in history.  Without openly available
   RFCs, the Internet could not have been built, could not operate, and
   could not continue its remarkable advance.  The RFC Editor is the
   community-defined and -supported function that accepts draft
   documents from the community, makes textual edits for clarity and
   formal correctness, and publishes and archives those documents as
   RFCs freely accessible by everyone.

   RFC 5620 first defined the components and processes of the present-
   day RFC Editor, including the RFC Series Editor, its leading
   component.  This document clarifies the role of the RFC Series Editor
   and other RFC Editor components.  The origin of these changes go back
   to the very start of the series.

   The role of RFC Editor dates back to the publication of RFC 1 in
   April 1969.  One of the longest standing institutions in the Internet
   community, the RFC Editor thus predates the IETF (the producer of
   Internet Standards) by nearly two decades.

   Initially, the role of the RFC editor was played by a single
   technical expert who,like other community members and leaders in
   those days, was supported by outside funding.  The RFC Editor
   initiated and participated in the highest level of policy debates,
   and made unilateral decisions of great significance to the community
   including, until the mid-1990s, decisions about RFC technical
   content.

   The high degree of autonomy of the RFC editor reflected the culture
   of the technical community in those days, when a new and rapidly
   changing environment relied heavily upon individual initiative.
   Moreover, Jon Postel, the first RFC Editor, had a genius for giving
   power to the community and creating new forms of community
   participation and contribution.  There was little or no perceived
   need for careful resolution, in advance, of issues surrounding roles
   and authority.  The relative informality of that era was widely
   accepted and allowed the community to be free of the collective
   overhead of financial administration.




Kowack                   Expires April 29, 2011                 [Page 6]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   The RFC Editor wore multiple hats, even counting only those related
   to editorial work.  These included acting as an editor, manager of an
   editorial service, manager of a technical series, manager of
   intellectual property and of an archive, maker of RFC Editor policy,
   and leader in policy implementation.  Informal processes were widely
   accepted as sufficient for managing these multiple complex roles.

   By the mid-1990s, the Internet's transition from being a primarily
   research-oriented facility was coming to an end.  Research funding
   for the RFC Editor would not much longer be available.  In
   cooperation with the community, the Internet Society began to fund
   the RFC Editor directly.  The RFC Editor was in a new position, its
   support now coming directly from the community it served.  The
   demands on the RFC Editor were increasing as the community produced
   more documents -- and desired more timely editorial processing of
   those documents.

   With the addition of editorial staff, the RFC Editor grew from a
   single editor into a team; a division of labor began, and management
   overhead increased.  While all the functions of the RFC Editor
   remained the responsibility of one individual during this period, the
   RFC Editor had progressively less authority to make technical changes
   to submitted drafts.  The other institutions of the Internet
   technical community were also evolving, becoming more deliberately
   structured and formal.  These changes were partly a natural
   consequence of organizational maturation and growth.  They were also
   motivated, as stated in RFC 4844, by these considerations:

   "...the Internet engineering and research community as a whole has
   grown and come to require more openness and accountability in all
   organizations supporting it.  More than ever, this community needs an
   RFC Series that is supported (operationally and in terms of its
   principles) such that there is a balance of:

   o  expert implementation;

   o  clear management and direction -- for operations and evolution
      across the whole RFC Series (whether originating in the IETF or
      not); and

   o  appropriate community input into and review of activities."

   The community reached a consensus, documented in RFC 4844, on a more
   rigorous framework for the RFC series and the "RFC Editor function"
   (a term RFC 4844 introduced, to clarify that it could be performed by
   one or more persons).  In doing so, it took steps to pry apart and
   further define various responsibilities.  That included definition of
   the RFC streams, which to the present day comprise:



Kowack                   Expires April 29, 2011                 [Page 7]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   o  IETF Document Stream,

   o  IAB Document Stream,

   o  IRTF Document Stream, and

   o  Independent Submission Stream.

   RFC 4844, however, intentionally made no attempt to explore the
   internal organization of the RFC Editor.  That task fell to RFC 5620,
   published in August 2009.  RFC 5620 defined or clarified the roles of
   the four major components of the RFC Editor: the RFC Series Editor,
   the Independent Submissions Editor, and the RFC Production Center and
   the RFC Publisher.  RFC 5620 separated these in part to permit
   flexible implementation (separately or by combinations of
   contractors).  During this same period, the IAB chose to move
   editorial and archiving services from the University of Southern
   California's Information Sciences Institute to the winner of an open,
   competitive RFP bid.

   The IEFT Administrative Oversight Committee (IAOC) established two
   new agreements: one for the independent submissions editor, the other
   for a single organization to provide a production center and
   publication services.  The production center houses all the RFC
   editorial staff and their internal manager; the publisher is a server
   on which all RFCs and drafts are published, archived, and made
   available to all.  The RFC Editor began to operate under the new
   model in January 2010, and continues to do so today.

   A simultaneous and extensive effort to locate an RFC Series Editor
   did not yield an appointment.  Concerned with series continuity, the
   IAB created a temporary position, the Transitional RFC Series Editor
   (TRSE).  The TRSE was to do the job of the RFC Series Editor and
   maintain series continuity through 2010.  Based on direct experience,
   the TRSE was to determine RSE requirements and propose an updated job
   description, and corresponding RFC 5620 revisions.  This document,
   Version 2 of the RFC Series Editor Model, results from that effort.

   For the RSE job description to result in a successful engagement, it
   must satisfy several challenges.  First, it must reflect the inherent
   complexity of the RSE role.  As defined in 5620, the RSE works on
   four levels:

   o  with the community, to obtain their perspectives on policy and
      policy requirements,

   o  with community leaders to investigate and determine policies and
      implementations,



Kowack                   Expires April 29, 2011                 [Page 8]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   o  with staff and contractor management for provision of specified
      services, and

   o  as the executive-level manager of the RFC Series.

   Second, many RSE work items are specific to this role and this
   community.  The job must satisfy the editorial, publication,
   distribution, and promotional needs of the series.  The RSE job
   description must carefully define the RSE's relationship to other
   community entities.  This is one of the few times there will be a
   community-supported job with extensive involvement in policy
   development and, in some cases, in policy setting (e.g., certain
   components of the Style Manual).  That involvement, and the overall
   conduct of the Editor, must be consistent with community requirements
   and values.

   Third, any job needs to be sensibly structured.  The description must
   be clear and unambiguous.  Each individual task must be reasonable
   and do-able, and the entire set of tasks must make sense in
   combination.  Responsibility and authority must align.  The job
   requirements must be broadly consistent with the skills and
   experience level of a single appointee.

   Finally, to serve the community, the Series Editor must have the
   freedom to be professional while under contract to the IAOC and
   subject to review by the IAB -- neither of which can be expected to
   include individuals with the same level of editorial background or
   expertise.  The Series Editor must be able to balance his/her own
   initiative and decision-making with the right amount of community
   dialog, in the right way, at the right times.

   These, then, are the considerations that the TRSE believes central to
   success in attracting, hiring, and retaining a qualified candidate.

   The revised model addresses these considerations by clarifying RSE
   responsibilities and relationships and by describing accepted
   community consultation practices.

   Many of the updates here are straightforward descriptions of how the
   Transitional RFC Series Editor executed the role during 2010.  Where
   possible, this version retains the text and arrangement of the
   original RFC 5620.  This version is consistent with RFC 4844 (as was
   RFC 5620).

   The IAB intends publication of this second version to complete the
   current cycle of RFC editor model development.  A newly appointed RFC
   Series Editor should be able to begin work under a job description
   that is complete, well structured, and reasonable, one that will



Kowack                   Expires April 29, 2011                 [Page 9]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   allow the vast majority of the new RSE's time and energy to be
   devoted to doing the job rather than to coping with structural or
   other changes.  Of course such changes, small or large, may be
   required as the position evolves.  The RSE and RSAG, along with the
   IAB, must continue to monitor the efficacy of the RSE model and
   respond to changing circumstances As always, the IAB invites the and
   community to provide observations and suggestions.


3.  RFC Editor Model

   The RFC Editor model divides the responsibilities for the RFC Series
   into the following components:

   o  RFC Series Editor ('RSE') and RFC Series Advisory Group (RSAG),

   o  Independent Submission Editor ('ISE') and Independent Submission
      Editorial Board (ISEB),

   o  RFC Production Center (RPC), and

   o  RFC Publisher (RFC Pub).

   The RFC Series production process under this structure is
   schematically represented by the figure below.  All major components
   are present.  The figure only roughly depicts oversight relations.

























Kowack                   Expires April 29, 2011                [Page 10]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


                                     +---------+  +---------+
                                     |         |  |         |
                                     |   IAB   |  |   IAOC  |
                                     |         |  |         |
                                     +-----+---+  +--+------+
     +......RFC Editor.....................|.........|........+
     .                                     |         |        .
     .   +-------------+  +----------+  +--V---------V--+     .
     .   |             |  |          |  |               |     .
     .   | Independent |  |   RFC    |  |      RFC      |     .
     .   |   Stream    |  |  Series  <..>    Series     |     .
     .   |  Editorial  |  | Advisory |  |    Editor     |     .
     .   |   Board     |  |  Group   |  |               |     .
     .   +-----------+-+  +----------+  +-+--------+----+     .
     ............+   |                    |        |          .
                 .   |                    |        |          .
   +-----------+ . +-V-----------+   +----V--+   +-V-------+  .  +-----+
   | Community | . | Independent |   |  RFC  |   |         |  .  |     |
   |    at     +---> Submission  +--->       |   |   RFC   |  .  |  E  |
   |  Large    | . |   Editor    |   |   P   |   |         |  .  |  n  |
   +-----------+ . +-------------+   |   r   |   |    P    |  .  |  d  |
                 +.................+ |   o   +-->|    u    +----->     |
   +-----------+   +-------------+ . |   d   |   |    b    |  .  |  U  |
   |           |   |             | . |   u   |   |    l    |  .  |  s  |
   |    IAB    +--->     IAB     +--->   c   |   |    i    |  .  |  e  |
   |           |   |             | . |   t   |   |    s    |  .  |  r  |
   +-----------+   +-------------+ . |   i   |   |    h    |  .  |  s  |
   +-----------+   +-------------+ . |   o   |   |    e    |  .  |  &  |
   |           |   |             | . |   n   |   |    r    |  .  |  R  |
   |   IRTF    +--->    IRSG     +--->       |   |         |  .  |  e  |
   |           |   |             | . |   C   |   |         |  .  |  a  |
   +-----------+   +-------------+ . |   e   |   |         |  .  |  d  |
   +-----------+   +-------------+ . |   n   |   |         |  .  |  e  |
   |           |   |             | . |   t   |   |         |  .  |  r  |
   |   IETF    +--->    IESG     +--->   e   |   |         |  .  |  s  |
   |           |   |             | . |   r   |   |         |  .  |     |
   +-----------+   +-------------+ . +-------+   +---------+  .  +-----+
                                   .                          .
                                   +..........................+

                Ordinary RFC Series production and process

   In the model, drafts are separately produced and approved through one
   of the streams; they are then submitted to the RFC Editor.  The four
   current streams are described in [2].  Under the model, the streams,
   themselves parts of the community, are the direct "production side
   customers" of the RFC Editor.  Those include draft authors and
   editors, various committees unique to each stream, and the stream



Kowack                   Expires April 29, 2011                [Page 11]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   approvers.  These actors singly and collectively receive editorial
   service from the RFC Editor.  Those include the RFC Production Center
   accepting submitted drafts, providing editorial feedback and
   guidance, making format and editorial changes, and producing numbered
   RFCs archived and freely available to all via the Publisher.  Readers
   and other users of RFCs (e.g., mirror sites), and users of Publisher
   services such as search, are referred to here as RFC Editor
   "consumption-side customers."

   Final decisions about the technical content of individual documents
   are the exclusive responsibility of corresponding stream approvers.
   Cases will arise in which editorial staff recommend a text change
   (for example, to correct grammar) but the author perceives a change
   in technical meaning.  When this occurs, editorial staff should
   review the text and advise the author (about, for instance, how the
   text is likely be read by typical readers of English).  But the
   stream approver will always have final say.

   The model allows for implementation of RFC Editor components and
   their functions under separate or joint contractual arrangements.
   Bidders may make proposals that include one or more contractors.
   Much of the reporting structure is subject to change over time and
   will depend on plans and the manner in which contracts are awarded.
   Details of the implementation are the responsibility of the RFC
   Series Editor and the IAOC, including when and how the reporting
   structure can be changed (see Section 4.1.5).

   However, to preclude conflicts of interest and to support balanced
   and independent management, the RSE must not be from the same
   organization as any of the other components of the RFC Editor, unless
   the IAB acts to override this provision in a specific instance, which
   it will do only after reviewing the matter with RSAG.


4.  RFC Series Editor

   The RFC Series Editor (variously 'RSE' or 'Series Editor') is an
   executive-level manager and subject matter expert in technical
   writing, publishing, and series development.  The Series Editor is
   responsible for the entire RFC Editor and all its components,
   functions, and staff, separately and in combination -- including the
   RFC Publisher and the RFC Production Center.  The RSE is the only
   component of the RFC Editor with this scope and authority.  The
   Independent Submission Editor, Independent Submission Stream, and
   Independent Submission Stream Editorial Board, however, function
   independently of the RFC Series Editor.  The RSE obtains advice and
   analysis from the RFC Series Advisory Group, or RSAG.




Kowack                   Expires April 29, 2011                [Page 12]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   The RFC Series Editor is an individual who has direct reports
   including contractors and managers.  The RSE may have assistants.
   The RSE appointee is a specific individual, not an organization or an
   alternate.  Under exceptional circumstances when the RSE is
   unavailable, a temporary substitute may be made, but only with prior
   approval of the IAB, and only after the IAB has consulted the RSAG.

   Section 4.1, immediately below, defines the role of the Series
   Editor.  It describes where and how RSE management practices must
   follow internet community practices and requirements.

4.1.  RSE Executive-Level Management

   Performing the RSE role requires the expertise and experience of a
   senior managerial professional in technical writing, publications and
   series development.  The position has extensive content and RFC-
   Editor-wide scope, and is expected to entail a multi-year term of
   office (see section 3.6).  The RSE will initiate and lead many
   discussions, make many day-to-day decisions, and set editorial
   policies.  This individual cannot help but have tremendous influence.
   The approach here is to grant the RSE explicit formal authority to
   match the requirements of the job (and, where appropriate, its
   implicit influence).  That authority is tempered by a context of
   customary practices that ensure the RSE acts in the interest of the
   community.

   In RFC Editor Model Version 1, the community outlined the role of,
   and delegated various authorities to, the RFC Series Editor.  The RSE
   was to exercise "executive-level management over many of the
   activities of the RFC Publisher and the RFC Production Center...".
   However, RFC 5620 did not attempt to define "executive-level
   management" nor explain how that might change as the RFC Editor Model
   evolved.

   This document defines RSE "executive level management" beginning with
   regular professional practices in typical not-for-profit
   organizations, including:

   o  directing day-to-day operations,

   o  reviewing processes, structures, and performance, and making
      changes,

   o  analyzing customer requirements and strategic opportunities,

   o  developing long-term goals and plans, including budgeting,





Kowack                   Expires April 29, 2011                [Page 13]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   o  interacting with and supporting peers and colleagues,

   o  reporting upwards and to constituents, and

   o  representing their function in the marketplace.

   However, leadership in the Internet community is not practiced as in
   many other organizations.  In particular, as the community's
   perception of a decision's importance increases, the greater is the
   need for community review and discussion, in order to reach community
   consensus.  More than in other organizations, some decisions will
   require broad community participation during their development.

   In such cases, what counts is the RSE's ability to inspire, support
   and distill community discussion.  To be successful, the RSE must be
   free to do, or facilitate, the following:

   o  make broad analyses of the scene,

   o  discover items in need of change or repair,

   o  determine possible fixes,

   o  collect and present all pertinent information,

   o  initiate and organize community discussion,

   o  help the community reach a consensus, and then

   o  implement the decision.

   Performing this role is leveraged by the RSE's having a "bully
   pulpit" - an excellent platform from which to speak.  The RSE must be
   able to speak to an issue, making arguments on their own merits; but
   the RSE cannot expect to be successful simply by "asserting
   authority".  The process described here will afford the RSE
   opportunities to make major contributions and have significant
   impact.  The RSE's relatively unusual (in our community) incoming
   publications expertise, knowledge gained from day-to-day RSE work
   experience, and time in grade will give this individual considerable
   leverage.  To be able to exercise the sort of consensus-building
   leadership envisioned for this role, the RSE must not be blocked from
   investigating any subject within the scope of the RSE job
   description, or from using professional techniques of the RSE's
   choosing.

   As the RSE and RFC Editor staff apply their specialized knowledge,
   they will develop unique perspectives and insights.  They must be



Kowack                   Expires April 29, 2011                [Page 14]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   free, and encouraged, to shape those insights into their own unique
   vision for the RFC Series.  Only through this process will they be
   able to make a full contribution to the community and continue to
   develop, and realize the full potential of the RFC Series.  Freedom
   to practice their profession is also fundamental to attracting top
   rank candidates and to retaining a qualified, motivated, senior
   publications management professional.

   Section 4.1.1 to Section 4.1.6 discuss six areas in which community
   principles and processes modify conventional management practices or
   are of particular importance.  The RSE must:

   o  seek appropriate community discussion and input,

   o  obtain opinion from across the entire community,

   o  encourage and support volunteer initiative and contribution,

   o  supervise according to specified procedures,

   o  cooperate with the IAOC, and

   o  report to the IAB for general matters and to the IAOC for RSE
      contract requirements while following community direction.

4.1.1.  Seek appropriate community discussion and input

   Determining the long-term direction and evaluating overall
   performance of the RFC Editor is the privilege of the Internet
   community.  In principle, the community could at any time require as
   much discussion, or prior approval, as they wish on any matter.
   However, the community elected to create the RSE position with
   certain responsibilities and authorities.  The community will get the
   best results if the RSE is trusted to identify when to act
   independently and when to seek community discussion and review prior
   to acting.

   To support community consideration of RFC Editor issues, the RSE will
   ensure the RFC Editor will:

   o  use open and transparent processes,

   o  make regular reports,

   o  encourage and participate in discussions with the community across
      a wide range of RFC Editor related subjects, and





Kowack                   Expires April 29, 2011                [Page 15]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   o  follow community consensus.

   The RSE must be liberal in what is reported, whether or not specific
   items appear to require community discussion or consensus (except, of
   course, when standard personnel practices require discretion).

   The RSE is responsible for balancing decision-making independence
   with prior discussion and approval by the community.  Within scope,
   the RSE is free to make decisions, determining case-by-case how much
   prior discussion is appropriate.  Nevertheless, the RSE is
   responsible for gaining the community's acceptance of those decisions
   and must be prepared to act accordingly if acceptance is not
   obtained.  The RSE should not act, or appear to act, in an abrupt or
   unilateral manner.

   The RSE must also remain open to and seek input from the community as
   to whether they are achieving the right balance of independence and
   input on individual decisions and in aggregate.  The RSE is expected
   to seek the guidance and counsel of the RSAG in these matters.  RSAG
   members will maintain their own dialog with community members to
   ensure the RSE is aware of community thought, to assist the RSE in
   distinguishing between useful and frivolous input, and to help the
   RSE refine his approach to this process.

   Subjects for which prior community notice or discussion must always
   occur include those that:

   o  directly and significantly affect community activities (e.g., a
      change in the Procedures Manual where RFC Editor staff interact
      with the streams),

   o  change long-standing practices that have customarily required
      community discussion or consensus (though of course these
      practices may change over time),

   o  are significant and irreversible, and

   o  significantly impact the look and feel of the series, or how the
      series can be used.

   Subjects for which discussion does not need to occur include those in
   which:

   o  the Series Editor has been previously authorized to set policy
      (e.g., in parts of the Style Manual),

   o  a decision is based on another authority's mandate (e.g.,
      personnel confidentiality practices, IETF Trust requirements),



Kowack                   Expires April 29, 2011                [Page 16]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   o  the matter is strictly one of internal management within the RFC
      Editor,

   o  a decision has been previously made on RFC Editor policy in
      agreement with the community (i.e., the RSE is able to say "this
      has already been agreed") or a schedule of discussions has been
      agreed but certain dates have not arrived, and

   o  the differences among outcomes are too slight to justify
      consultation (in practice this will apply to relatively minor
      issues).

   The community must aim to provide input on RFC Editor performance in
   a concerted and constructive way.  This is especially true regarding
   individual performance of RFC Editor staff.  The RSE must ensure that
   the community can easily provide such input, maintaining appropriate
   confidentiality (e.g., for personnel issues).

   On occasion, the community may fail to respond to repeated calls for
   comment, or their responses may be incomplete.  In such cases
   (optionally after seeking advice from the RSAG), the RSE is free to
   make a decision.  As always, the RSE should report such decisions,
   and seek community input as to whether these decisions might need to
   be revisited in the future.

   Another example of a boundary of community participation in decisions
   concerns the Style Manual.  The Manual could consist of two major
   sections.  The first would contain rules of usage and layout that RFC
   Editor staff must follow when producing RFCs.  This part would be as
   small as practical.  The second part would consist of guidance and
   examples of usage, grammar, punctuation and such for authors of
   drafts.  The first part depends upon editorial and publications
   expertise; the RFC Editor would determine its content.  The second
   part would be created with direct community participation, to ensure
   its usefulness.

4.1.2.  Obtain opinion from across the entire community

   The RSE must seek and obtain input from across the entire community.
   As the RSE and staff gain new insights and a broad vision for the
   Series and the RFC Editor, they must communicate this in reports to
   encourage input from and discussion with every part of the community.

   Internet technical community entities and leaders often do not
   exercise 'leadership' or represent constituencies as one finds in
   conventional organizations.  Rather, they have expertise,
   responsibility, and authority to work within specific areas.  For
   every significant decision they must seek community opinion, engage



Kowack                   Expires April 29, 2011                [Page 17]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   in discussion, and give the community opportunity to review and
   comment.  When working with these entities, the RSE must not give
   them primacy over community consensus, nor give undue weight to
   particular entities.

   The RSE is free to participate in debates with the same degree of
   knowledge, initiative, insight as employed anywhere in the community,
   including other senior leadership positions.

4.1.3.  Encourage volunteer initiative and contribution

   Volunteers have always done the work in the community.  They have
   shown exceptional initiative and industry.  The vast majority of
   things get done because an individual or group takes action, often
   without prior official 'approval'; frequently there is no structure
   in place to even grant approval in the first place.  The RSE must
   work with and encourage volunteer initiative.  In addition, in order
   to maintain community participation, the RSE should convert volunteer
   activities into staff activities only if doing so is required to get
   the job done, and when the job is important enough to warrant
   allocating resources.  Although the RSE may be responsible for
   specific items, it is not necessary for the RSE to be the one who
   does them, only that they get done.  This requires that the RSE (a)
   not obstruct community initiatives, (b) engage the community when an
   area that requires their participation does not yet appear to have
   active attention, and (c) support the community in determining
   requirements, including quality requirements.

   The community has a long practice of engaging volunteers from its
   different entities in such a way that participation and authority
   have been distributed and expanded, rather than collected and
   concentrated.  The RSE must continue this practice, which has been
   one of our great strengths.

4.1.4.  Supervise according to specified procedures

   The closeness of RSE supervision of RFC Editor components and staff
   depends upon the degree to which the job is defined (often through
   community process), and includes direct community participation

   Current operations of the RFC Production Center illustrate one end of
   this spectrum.  The PC performs a well-defined function and works
   closely with the streams.  RFC Production Center activities are
   specified by contract, the Procedures Manual, and the Style Manual.
   The RSE will manage this sort of component using conventional
   contract management practices in line with these processes.  The RSE
   will not supervise this component closely; contractor internal
   management will do that.  Rather, the RSE will provide direction and



Kowack                   Expires April 29, 2011                [Page 18]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   guidance where agreed procedures are unclear or where Production
   Center performance is not within specification.  Contractor
   management may request direction, or the RSE may initiate direction.
   The RSE may require changes to formal procedures and implementation
   by the contractor.  The RSE will inform the community and request
   reviews at least to the extent that procedural changes affect or are
   of interest to the community.

   At the other end of this spectrum are, for example, direct reports or
   assistants to the RSE.  How analysts or assistants perform their work
   will not typically be of interest to the community and this work is
   not typically structured around formal processes.  The RSE should
   supervise this sort of staff as closely as the she believes
   necessary.

4.1.5.  Follow IAOC-RSE cooperation practices

   If the RSE anticipates procedural or other changes with contractual,
   legal, or financial consequences, they must seek the counsel of and
   action by the IAOC.  Similarly, the IAOC must request RSE
   participation and counsel where administrative, financial or legal
   matters require managerial changes.  Thus, the IAOC continues to
   exercise its responsibility and authority for financial and legal
   matters as in RFC Editor Model Version 1.  The IAOC and RSE are
   expected to resolve most issues without involving the IAB.  But when
   they are unable to reach agreement, IAB guidance must be sought.

   Both short and long-term issues are to be handled in the same manner.
   Long-term issues include long-term planning activities, revised and
   new plans, contracts and other agreements, and requests for proposals
   (RFPs).  The RSE and IAOC will jointly evaluate bids and make
   recommendations for awards.  As above, the RSE will act as the
   subject matter expert for editor-related services, and will seek
   input from and represent content issues to the community.  The IAOC
   as above, will take lead on financial, contract, and legal issues.
   The IAB, as above, will be the final arbiter when the RSE and IAOC
   cannot agree.

   The internal and external reporting structure of the RFC Editor may
   not be changed without the approval of the RSE and the IAOC.  This
   includes contract-mandated changes.  As with other such decisions,
   the RSE and IOAC must bring disagreements to the IAB for review and
   resolution.

   Questions relating to contractor or individual performance may be
   raised by either the RSE or IOAC, including recommendations to
   terminate the contract of an individual or contractor.  The RSE and
   IAOC must each respond to a concern or proposal of the other.  If



Kowack                   Expires April 29, 2011                [Page 19]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   they cannot agree on a remedy after extensive review and discussion,
   they must bring the issue to the IAB.

   Although the RSE is not required to make regular reports specifically
   to the IAOC, they must keep the IAOC informed of events with
   anticipated administrative, legal, or contractual consequences.  The
   RSE must support IAOC planning cycles and general administrative
   requirements.  The IAOC must similarly keep the RSE informed of
   anticipated administrative, legal, or contract issues that may effect
   the RFC Editor.

4.1.6.  Report to IAB in general, IAOC for RSE

   The RSE listens to, takes input from, and makes reports to the
   community, as described above.

   The RSE reports to the IAB as necessary to support the IAB's role in
   ensuring proper management of the RFC Editor.  This includes regular
   written reports, which will be publicized.

   The RSE reports to the IAOC specifically regarding the RSE's work
   contract.  If the IAOC has concerns about RSE contractual
   performance, they should first bring them to the RSE.  If they cannot
   agree on a resolution, the matter must be taken to the IAB for
   consultation.

   RSE reporting to the IAOC for matters directly related to the RSE's
   contract is distinct from, and must not be confused with, cooperation
   between the RSE and IAOC regarding general and financial management
   of the RFC Editor, as described in Section 4.1.5.  Both the RSE and
   the IAOC must not allow the reporting relationship to influence the
   cooperative relationship, and vice versa.

   The RSE must keep the IAOC informed so they may fulfill their
   obligations regarding legal and financial oversight of the RSE
   contract.  If there is a disagreement in this area, the IAOC and RSE
   must bring that to the attention of the IAB, which will have the
   final word on the subject.

   The IAOC cannot on its own remove the RSE from office.  If there is a
   persistent concern about RSE contractual performance, it must be
   reviewed by the IAB.  The IAB must in turn consult with the RSAG.

4.2.  RSE General Responsibilities

   The RFC Series Editor is responsible for, and has authority in, the
   following areas




Kowack                   Expires April 29, 2011                [Page 20]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


4.2.1.  Maintain Series Continuity

   There are many issues associated with RFC Series continuity,
   including the look and feel of the series, indexing methods, policies
   for and accessibility of the publications, archiving and publication
   policies, IPR and copyright issues, errata policies and procedures,
   and publication format policies.  Series continuity comprises
   editorial continuity and operational continuity.

   Editorial continuity is the maintenance and development of the
   editorial character of the Series (e.g., look and feel) in a way that
   preserves the constancy of the series.  Constancy means that changes
   will be made only when there is good reason to do so; when changes
   are required (e.g., in the format of RFCs)), they will be done in a
   deliberate, evolutionary way that respects the long-standing
   editorial practices of the series.  Changes will be made with input
   from editorial staff, and will be available for review by and input
   from the community.  The more substantive, broad, or abrupt a
   proposed change, the more important it will be to solicit agreement
   from the community before making the change.

   The RFC Series Style Manual is the primary vehicle for maintaining
   constancy in, and making changes to, editorial continuity.  The RSE
   will prepare and maintain an RFC Style Manual to describe clearly the
   grammar, style, usage, typography, punctuation, and spelling
   standards that will guide the drafting and editing of RFCs, so that
   all publications will appear in clear, concise technical prose.  The
   primary audiences for the Style Manual are authors, editors, the
   stream managers, the RFC Production Center, and the RFC Publisher.
   Implementation of many continuity-related decisions within the Style
   Manual will reside with the RFC production and publishing functions,
   as directed by the RSE.

   Operational Continuity.  Over the long run, editorial staff must
   produce RFCs from drafts at least at the same rate the streams submit
   drafts.  Operational continuity is maintaining and planning for
   consistent, regular output from RFC Editor staff including
   contractors.  This includes all related editorial staff support
   activities, including feedback and advice for authors and streams,
   regular reports, liaison activities, and attendance at meetings.

   If there is a disruption of editorial services, the RFC Series Editor
   and the IAOC are responsible for promptly acquiring and directing new
   resources to maintain RFC output.  New teams of editors or additional
   contractors may be needed.  The RSE must keep the RFC Editor
   Procedures Manual and Style Manual up to date to provide sufficient
   direction to alternate editors, per above.  The RSE must maintain
   sound understanding of those processes in order to direct new



Kowack                   Expires April 29, 2011                [Page 21]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   resources when required.  We refer to maintaining editorial output
   during a disruption as "exceptional continuity".

   As in all matters when planning for or maintenance of operational
   continuity has legal or contractual consequences, the RSE will
   communicate and coordinate with the IAOC.

4.2.2.  Maintain and Develop RFC Series Quality

   RFC Series quality is the collective responsibility of the Internet
   technical community.  The RFC Series Editor shares responsibility for
   editorial quality with the other members of the RFC Editor.  The
   streams each have responsibility for technical and content quality in
   their respective areas.

   The RSE's quality responsibilities include editorial quality
   delivered through published RFCs, editorial service (or process)
   quality provided to the streams, and quality of access,
   accessibility, and access services for users.  The RSE must develop
   and maintain output measurement techniques and statistics collection
   in order to monitor and improve service (production) quality.  The
   RSE is also responsible for advancing the overall quality of the
   series, in cooperation with the community and its entities,
   especially the streams.

4.2.2.1.  Quality

   Editorial quality management comprises changes made by RFC Editor
   staff as drafts are refined into published RFCs.  Editorial quality
   must meet the requirements of three groups:

   o  authoritative community entities (e.g., the IETF Trust regarding
      IP notices),

   o  authors and streams ("producer-side service quality"), and

   o  re-distributors and users of RFCs ("consumption-side quality")

   The RFC Series Editor must maintain and develop editorial quality
   that satisfies and balances requirements of all three groups.  During
   2010, it was determined that the community has almost no knowledge of
   the demographics of RFCs end-users, of how they use RFCs, or end-user
   requirements.  The RSE should seek to learn more about RFC end-use
   and end-users to inform quality-related decisions, discussed
   immediately below in Section 4.2.2.2.  Work to date suggests that the
   end-user community may include the following groups:





Kowack                   Expires April 29, 2011                [Page 22]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   o  RFC implementers.  This group intersects with working group
      participants.  The latter is an unknown proportion of the former,

   o  network operators (of RFC implementations),

   o  academics, researchers and students,

   o  marketers, and requirements writers,

   o  policy-makers, and

   o  re-distributors (e.g., mirror site operators) and publishers.

   The RSE should improve collective understanding of the demographics
   of RFC use and its implications for RFC quality.  The RSE should seek
   community participation in this effort, especially stream members.
   The RSE should discuss findings with the community and streams to
   determine any impact on editorial goals and practices.

4.2.2.2.  RFC Editor production and service quality

   There are the three principal RFC Editor services, each with specific
   quality requirements:

   o  processing of drafts into RFCs and support for authors and the
      streams, provided by the RFC Editor,

   o  access-related services provided via the RFC Publisher, and

   o  general writing guidance and training for authors and others in
      the streams.

   Draft processing and support ("production-side support") .
   Presently, the RFC Editor provides only one level of editing and
   support, which is minimal and does not vary according to the needs of
   particular drafts.  The RSE will continue to develop practices in
   this area to respond to changing general needs and specific draft-
   editing requirements.  In the latter case, the RSE will investigate
   whether a "red flag" service is appropriate.  Such a service,
   available on authors' request, would give special attention to drafts
   thought to be particularly complex, extensive, or to have an
   especially critical audience.  The RSE will determine whether there
   are resource consequences to planned changes to editorial practices.

   Access-related services.  Access-related services include web site
   services such as search and indexing tools.  The RSE should continue
   to develop these services.  As stated above, most implementation will
   be by contractors and volunteers.



Kowack                   Expires April 29, 2011                [Page 23]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   Stream and author guidance and training During 2010, the RSE received
   repeated requests for general technical writing training, especially
   for non-native speakers of English.  The RSE should investigate this
   area and look for opportunities to reduce authors' costs (largely in
   time), improve the quality of drafts submitted, and reduce RFC Editor
   processing time and costs.

4.2.2.3.  Performance Measures and Statistics

   As executive-level manager, the RSE will direct development of
   carefully-targeted RFC Editor performance measures, including
   statistics, their graphical representation, and publication on the
   RFC Editor web site and elsewhere.  Creating meaningful production
   statistics is complex, subtle, and error-prone.  Even simple and
   obvious statistics can mislead observers and motivate suboptimal
   editing and production.  The RSE will improve measures to illuminate
   productivity and minimize distortion.  The RSE will aid the community
   in understanding the meaning and limitations of published statistics.

   The RSE will use performance measures as input to planning with the
   IAOC and to inform contracts, contract revisions, and requests for
   proposals.

4.2.2.4.  RFC Editor and RSE professional expertise

   The RSE will maintain RFC Editor professional expertise in two areas.
   The RSE will ensure that staff and contractors maintain minimum
   standards of, and steadily improve, professional skills and
   knowledge.  Staff professional advancement is the responsibility of
   the RSE.  Contractor professional development is the responsibility
   of the contractor, as directed by the RSE by inclusion in contracts.

   The RSE is responsible for maintaining and developing his own
   expertise as needed to support the requirements and processes
   described in this document.  This includes developing intimate
   knowledge of editorial practices and procedures to protect the
   community from service disruption, developing editorial services and
   the Series overall, and advising the community and staff.

4.2.2.5.  Survey Overall Series Quality

   [RFC5620] section 3.1 states that the RFC Editor is to exercise
   "executive-level management over the implementation of policies,
   process, and procedures established to ensure the quality and
   consistency of the RFC Series."  The RSE will at least once every
   three years survey overall Series quality to verify that the Series
   is meeting the needs of the community at large, production side
   customers (streams), consumption side customers (end users), and



Kowack                   Expires April 29, 2011                [Page 24]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   others.  This evaluation will include analyses of long-term quality
   trends and measures.  The RSE will seek the streams' participation.
   The RSE will publish a report, preferably jointly with the streams,
   including recommendations for improvements.

4.2.3.  Represent the RFC Series to the Community

   The RSE will represent the RFC Editor, the Series, and its long-term
   development, to the community.  This includes keeping the community
   informed of ongoing activities and progress against plans, analyses
   and observations, exceptional items, and long-term plans.
   Accordingly, the RSE will participate in RFC Editor on-line
   facilities such as web sites, and editor-oriented mail lists and
   discussion media.  The RSE is responsible for ensuring that every
   inquiry or complaint about the Series receives a timely and
   appropriate response.

4.2.4.  Represent and promote the RFC Series to the outside world

   The RSE will represent and promote the Series to the outside world.
   Promotion concerns:

   1.  Identifying and communicating with those who would benefit from
       the RFC Series, and showing them where and how to access the
       series.  Promotion complements accessibility.  This includes
       ensuring the RFC Series is accessible via conventional means,
       such as electronic card catalogs, and ISSN numbers, which must be
       kept current.

   2.  Improving broad awareness of the role of, and contributions by,
       the technical community widely, and in targeted communities.
       Increasing the stature of the Series reinforces other community
       initiatives.

   Promotion can rapidly become very costly in both time (especially
   management opportunity cost) and money.  The RSE's priority is to do
   at least rudimentary promotion that is economical and readily
   accomplished.  The RSE should undertake extensive promotions only
   after discussion with the community.  Explanations of costs and
   specific, targeted benefits should always accompany recommendations
   for promotional efforts.

   Over the long run, the RSE should survey comparable organizations and
   series to see how they promote themselves and what that suggests for
   RFC Series promotion.






Kowack                   Expires April 29, 2011                [Page 25]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


4.2.5.  Identify and lead community discussion

   In collaboration with the RFC Series Advisory Group (RSAG), the RSE
   will identify and lead community discussion of important issues and
   opportunities facing the RFC Series.  The RSAG may formally request
   that the RSE to investigate areas it believes have not been
   sufficiently addressed.

4.3.  RFC Series Editor Specific Responsibilities

   In addition to the processes, requirements, and activities above, the
   RSE is responsible for the following specific items.  Some major
   items described above are repeated here.

4.3.1.  General Planning, Prioritization, and Reporting

   Many of the responsibilities and tasks in this document are open-
   ended.  The RSE cannot accomplish all these tasks at the same time
   with any reasonable level of resources.  The RSE must manage the
   extent of tasks, and their prioritization and execution.  The RSE
   must clearly communicate plans and expectations to the community and
   other entities.

   1.  Within 6 months of the RSE's appointment, or a date agreed with
       the IAB, the RSE will publish an initial work plan and road map.
       The RSE will indicate which initiatives and activities will be
       focused on over the remainder of the first calendar year,
       including their own activities and those of other RFC Editor
       Components.  These plans will distinguish between ongoing
       operational duties and focused initiatives.  In developing this
       initial plan, the RSE will have had the assistance of the RSAG.

   2.  By 5 December each year thereafter, the RSE will publish a plan
       and road map for the upcoming calendar year.

   3.  By 1 February each year, the RSE will publish an Annual Report of
       the RFC Editor.  This will include a review against the preceding
       year's plans and highlight lessons learned that are reflected in
       the new calendar year plan and road map.  Summary statistics will
       be included.  The RSE may ask RFC Editor components to produce
       relevant reports on request.  The RSAG will review and comment on
       the RSE's draft before the final annual report is published.

   The RSE will issue a monthly report for delivery to the IAB and
   publication to the community.






Kowack                   Expires April 29, 2011                [Page 26]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


4.3.2.  RFC Series Continuity

   The RSE will take all steps necessary to maintain the editorial and
   operational continuity and consistency of the Series consistent with
   the procedures described elsewhere in this document.

   The RSE will maintain the Style and Procedures Manuals in support of
   consistency and proper RFC Editor operations.  The Procedures Manual
   will include a description of tasks performed by the RSE.

   The RSE will publish a long-term schedule for regular (by default
   annual) updates to and reviews of, each document.  This does not
   preclude occasional or as-required incremental updates to these
   documents.

4.3.3.  Reviews

   The RSE may conduct reviews of any process or component of the RFC
   Editor at any time.  The RSE will conduct annual assessments of the
   RFC process and of all components of the RFC Editor (ISE and Stream,
   RFC Production Center and RFC Publisher).  Reviews will incorporate
   feedback from the RSAG and will include input from the community.
   Reviews will be presented to the IAB and be available to the
   community.

   Reviews of the ISE will follow procedures that respect the
   independence of the ISE and Independent Submission Stream.  In
   particular, the RSE will request a member of the RSAG to
   independently create and chair an Independent Submission Stream and
   Editor review committee.  The committee will consist of 5 regular
   members, at least three of whom will come from the RSAG; two may come
   from the community, appointed by the chair after an open call to the
   community.  The RSE and the chair of the IS review committee will
   jointly develop a review process and outline, which will then be
   independently completed by the review committee.

   Comprehensive annual reviews may prove costly and unnecessary.
   Accordingly, the RSE may elect, after discussion with the IAB, RSAG,
   and IAOC, to alternate limited and comprehensive reviews on two or
   three-year cycles.

   The RSE will participate, on request, in IAB-initiated external
   reviews of the RFC Editor and/or any of its components, and will
   support and coordinate with the IAB and/or IAOC as required.







Kowack                   Expires April 29, 2011                [Page 27]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


4.3.4.  Regular RFC Editor Operations and RFC Series Oversight

   The RSE will manage day-to-day operational issues that have not
   previously been delegated (i.e., to contractors), including:

   1.  managing issues as they arise from the streams (production side
       customers), community, entities, and from within the RFC Editor
       components,

   2.  resolving resource allocation questions, including balancing
       stream requests for priority handling of drafts,

   3.  organizing, structuring, and leading regular and special RFC
       Editor meetings,

   4.  participating in author document reviews,

   5.  developing and maintaining FAQs for RFC publication, and

   6.  administering and participating (directly or via delegates) in
       various (e.g., rfc-interest) RFC Editor-related mailing lists.

4.3.5.  Ongoing Developmental Issues

   The RSE will:

   1.  work with the stream managers in maintaining policies for an RFC
       errata process,

   2.  develop policies for the types of indexes that the RFC series
       will support by default and the metadata that may be required to
       support those indexes, and

   3.  approve tools for the validation of syntax of documents
       containing formal languages.

4.3.6.  Liaison, Coordination, and Collaboration

   The RSE will:

   1.  provide all necessary points of contact and services to support
       policy inputs and questions (from, for example, the community or
       other entities),

   2.  take part in formal meetings, telechats, and other communications
       among entities (e.g., IESG and IAB), as well as general meetings
       such as the IETF, or retreats, as required.  The RSE will make
       reports as required,



Kowack                   Expires April 29, 2011                [Page 28]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   3.  conduct coordination meetings (including, e.g., telechats) with
       the streams (production-side customers) and components of the RFC
       Editor,

   4.  liaise and work with the IAB so that the IAB may be confident
       there has been sufficient community review before significant
       policies or policy changes are adopted, and

   5.  participate, on request, in IAB-initiated external reviews of the
       RFC Editor and/or any of its components, coordinating with the
       IAB and/or IAOC as required.

4.3.7.  Process and Document Evolution and Innovations

   The RSE will consider innovations to improve efficiency,
   coordination, transparency, and quality.  The RSE will continuously
   monitor the RFC production process for possible improvements, and
   propose and evaluate experiments as input to RSE recommendations.
   The RSE will also, as appropriate, support process experiments
   proposed by the Internet community.

4.3.8.  Organize and Structure Performance Measures

   The RSE is responsible for requesting appropriate contractor reports,
   including statistics.  Contractors will allocate sufficient resources
   to satisfy reporting activities and to respond to requests for
   changes.

4.4.  RSE Professional Qualifications

   The RFC Series Editor provides general and editorial leadership of
   the RFC Editor, and meets the following qualifications unless noted
   otherwise:

   1.  Experience as a senior manager and subject matter expert in
       technical writing, technical publications, and technical series
       development.  Executive management experience must be
       commensurate with the requirements outlined elsewhere in this
       document and the many aspects of the RSE role, including the
       tasks of coordinating the overall RFC Editor process,

   2.  Experience with complex organizations with substantial group
       processes.  The RSE must be skilled at participating in group
       processes, managing and getting value from them.  The RSE must
       understand and appreciate delegation.  Experience with and
       understanding of the IETF and RFC process is desirable.





Kowack                   Expires April 29, 2011                [Page 29]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   3.  Good understanding of the English language and technical
       terminology related to the Internet,

   4.  Excellent skill communication and, especially, listening,

   5.  Independent worker, and

   6.  Experience as an RFC author is desirable.

4.5.  RSE Term of Office

   The default RSE term of office is five years with no restrictions on
   renewals, and with provision for shorter actual contracts and
   intermediate reviews.  Individual contract periods may be shorter due
   to practical issues.  Specific contract duration will be determined
   by the IAOC with participation by the RSE Search and Selection
   Committee, per their defined participation in the hiring process, and
   with the agreement of the IAB.  Terms of office for the RSE, ISE, and
   RFC Production Center must be adjusted to avoid concurrent
   transitions.


5.  Independent Submission Editor

5.1.  Independent Submission Editor General Responsibilities

   The Independent Submission Editor (ISE) provides general and
   editorial leadership of the Independent Submissions Stream.  The ISE
   is an individual who may have assistants and who is responsible for:

   1.  Maintaining technical quality of the Independent Submission
       stream.

   2.  Reviewing, approving, and processing Independent Submissions.

   3.  Forwarding to the Production Center the Internet-Drafts that have
       been accepted for publication as RFCs in the Independent
       Submission Stream.

   4.  Reviewing and approving RFC errata in Independent Submissions.

   5.  Coordinating work and conforming to general RFC Series policies
       as specified by the IAB and RSE.

   6.  Providing statistics and documentation as requested by the RSE.

   7.  Providing sufficient resources (i.e., ISE time) to support RFC
       Series Editor reviews of the Independent Submissions Stream, and



Kowack                   Expires April 29, 2011                [Page 30]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


       external reviews of the RFC Editor initiated by the IAB or IAOC.

   8.  Being available when possible to participate in escalation
       procedures and RFC Editor focused internal reviews.

5.2.  ISE Professional Qualifications

   The Independent Submission Editor is a senior position for which the
   following qualifications are desired:

   1.  Technical competence, i.e., broad technical experience and
       perspective across the whole range of Internet technologies and
       applications, and specifically, the ability to work effectively
       with portions of that spectrum in which no personal expertise
       exists.

   2.  Thorough familiarity with the RFC series.

   3.  An ability to define and constitute advisory and document review
       arrangements.  If those arrangements include an Editorial Board
       similar to the current one or some equivalent arrangement, assess
       the technical competence of potential Editorial Board members.

   4.  Good standing in the technical community, in and beyond the IETF.

   5.  Demonstrated editorial skills, good command of the English
       language, and demonstrated history of being able to work
       effectively with technical documents and materials created by
       others.

   6.  The ability to work effectively in a multi-actor environment with
       divided authority and responsibility similar to that described in
       this document.

   The Independent Submission Editor may seek support from an advisory
   board Section 5.2qu and may form a team to perform the activities
   needed to fulfill his responsibilities.

   The individual with the listed qualifications will be selected by the
   IAB after input is collected from the community.  An approach similar
   to the one used by the IAB to select an IAOC member every other year
   (as described in Appendix A) should be used.  While the ISE itself is
   considered a volunteer function, the IAB considers maintaining the
   Independent Submission stream within the RFC Series part of the IAB's
   supported activities, and will include the expenses made for the
   support of the ISE in its IASA-supported budget.





Kowack                   Expires April 29, 2011                [Page 31]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


5.3.  ISE Term of Office

   The default ISE term of office is five years with no restrictions on
   renewals, and with provision for shorter actual contracts and
   intermediate reviews.  Individual contract periods may be shorter due
   to practical issues.  Terms of office for the RSE, ISE, and RFC
   Production Center should be staggered to avoid terminating
   concurrently.

5.4.  Independent Submission Stream Editorial Board

   The Independent Stream Editor is supported by an Editorial Board for
   the review of Independent Submission stream documents.  This
   volunteer Editorial Board currently exists, and its members serve, at
   the pleasure of the ISE.  The existence of this board is simply noted
   within this model; additional discussion is out of scope for this
   document.


6.  RFC Production Center

   RFC Production is performed by a paid contractor, and the contractor
   responsibilities include, under the direction of the RSE:

   1.   Editing inputs from all RFC streams to comply with the RFC Style
        Manual,

   2.   Creating records of edits performed on documents;

   3.   Identifying where editorial changes might have technical impact
        and seeking necessary clarification,

   4.   Engaging in dialogue with authors, document shepherds, IANA,
        and/or stream-dependent contacts when clarification is needed,

   5.   Creating records of dialogue with document authors,

   6.   Requesting advice from the RFC Series Editor as needed,

   7.   Offering suggestions to the RFC Series Editor as needed,

   8.   Providing sufficient resources to support reviews of RFC
        Publisher performance by the RFC Series Editor and external
        reviews of the RFC Editor initiated by the IAB or IAOC,

   9.   Coordinating with IANA to perform protocol parameter registry
        actions,




Kowack                   Expires April 29, 2011                [Page 32]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   10.  Assigning RFC numbers,

   11.  Establishing publication readiness of each document through
        communication with the authors, document shepherds, IANA and/or
        stream-dependent contacts, and, if needed, with the RFC Series
        Editor,

   12.  Forwarding ready-to-publish documents to the RFC Publisher,

   13.  Forwarding records of edits and author dialogue to the RFC
        Publisher so these can be preserved, and

   14.  Liaising with various streams as requested by the RSE.

   The RFC Production Center contractor should be selected by the RSE
   and IAOC through an open RFP process.  The RSE and IAOC will seek
   bidders who, among other things, are able to provide a professional,
   quality, timely, and cost- effective service against the established
   style and production guidelines.  Contract terms, including length of
   contract, extensions and renewals, shall be as defined in an RFP.
   The opportunity to bid shall be broadly available.


7.  RFC Publisher

   The RFC Publisher comprises the managed computing resources where
   RFCs and related information are archived, publicized, and that
   support open access.  Included are the management services required
   to support and maintain that capability.  The term "RFC Publisher"
   does not follow common usage; it does not in any way refer to the
   senior manager in a publishing organization.

   RFC Publisher responsibilities include:

   1.  Announcing and providing on-line access to RFCs.

   2.  Providing on-line system to submit RFC Errata.

   3.  Providing on-line access to approved RFC Errata.

   4.  Providing backups.

   5.  Providing storage and preservation of records.

   6.  Authenticating RFCs for legal proceedings.

   All these activities are under general supervision of the RSE, who
   will provide an appropriate level of coordination with the streams



Kowack                   Expires April 29, 2011                [Page 33]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   and other entities as required

   The publisher is inherently a far simpler service to implement and
   manage than any other component of the RFC Editor.  Experience gained
   during 2010 shows that combining the publisher with another
   subcontract (in this case the IETF Secretariat contract) can be
   effective and can reduce management overhead.  Separate publisher
   implementation could increase overhead costs.


8.  Committees

8.1.  RFC Series Advisory Group (RSAG)

8.1.1.  Charter

   The RSAG provides expert, informed guidance (chiefly) to the RSE in
   matters affecting the RFC Series' operation and development.  That
   includes providing long-term perspective in support of consistency
   and constancy of the RFC Series interpretation over time.  Such
   matters include, but are not limited to, issues in operation of and
   planning for RFC model components, and consideration of additional
   RFC streams, to give a sense of the range of topics covered.

   The RSAG serves four functions:

   1.  advising the RSE, upon request, on matters related to operation
       and direction of the Series,

   2.  supporting the RSE's connection to and alignment with the
       community through informal community discussions, and by
       discussion with the RSE about their observations regarding
       community opinion and RSE engagement with the community,

   3.  participating, and providing leadership, in RSE analysis and
       review committees on request of the RSE, and

   4.  providing counsel to the IAB or IAOC in situations where the RSE
       cannot be available.

   The group provides guidance to the RSE, who as required will address
   operational issues or opportunities with other components of the RFC
   Editor.  In cases where these issues have contractual or financial
   effects, the RSE works cooperatively with the IAOC, as described
   elsewhere in this document.  The RSAG also serves to advise the RSE
   on long-term, large-scale developments for the RFC Series.  This
   informs the proposals the RSE takes to the community for discussion,
   and to the IAOC as proposals for implementation.



Kowack                   Expires April 29, 2011                [Page 34]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   The RSAG will assist the RSE in identifying and leading community
   discussion of important issues and opportunities facing the RFC
   Series.  In this way, the RSAG ensures the RSE is aware of community
   opinion and requirements.  In turn, the RSE must keep the RSAG
   sufficiently informed of major issues and plans so that the RSAG may
   interact with the community knowledgeably; and so that in cases where
   the community, the IAB, or the IAOC require (as described above), the
   RSAG will be able to provide their informed counsel.

   The RSAG is chartered by the IAB.  As such, the RSAG operates
   independently of the IAB to fulfill that charter.  The IAB retains
   its oversight role and is responsible for ensuring that the community
   has adequate discussion of important topics.

8.1.2.  Membership

   RSAG full (non-liaison) members are all at-large members; they do not
   represent a particular RFC stream or any organizations.  The RSE is a
   member, and unless she chooses otherwise, RSAG chair.  Full members
   serve staggered, 3-year terms, with no limit on renewals.  There is
   no hard upward limit on the number of full RSAG members, but it is
   anticipated that it will remain roughly around the "low teens" to
   facilitate committee management and ease of discussion.

   The RSE selects members for their experience and interest in the RFC
   Series as well as in editing and publishing.  Outside (non community
   members) editorial and publishing experts may be members, especially
   well-known leaders in technical writing and publications.  Outside
   experts must not be more than a minority of full members.  In
   particular, there is no requirement or expectation that RSAG members
   will be IAB members.  The Series Editor proposes RSAG members in
   consultation with sitting RSAG members; the IAB then confirms and
   formally appoints those members.

   In addition to full members, each RFC stream approver will appoint a
   liaison to the RSAG to provide context specific to their stream.  The
   liaisons need not be members of the stream approval bodies.
   Initially, there will be no IAOC or IAB liaison for their oversight
   role; however, as experience is gained, the IAOC, IAB, or RSAG may
   request such liaisons.

   Unless explicitly indicated otherwise, only full RSAG members will
   provide direct counsel to the IAB or IAOC.

   The RSAG does not select or appoint the RSE, or any other component
   of the RFC Editor model, although it is an important resource for
   informing any selection process.




Kowack                   Expires April 29, 2011                [Page 35]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   The full members will serve at the pleasure of the IAB -- appointed
   by the IAB, and if necessary, removed by the IAB, which will only be
   done for reasons of professional misconduct or long-term non-
   participation.  The IAB must confer with the RSE and the full members
   before removing a member.

   During the term of the Transitional RFC Series Editor, the RSAG has
   been on interim status.  Once appointed, the new RSE will ask
   standing members to indicate their staggering preferences; the RSE
   will then determine and publicize terms of appointment, and declare
   the RSAG to be on permanent status.


9.  Resolution of Disagreements

9.1.  Disagreements between RFC Editor Components and Model Participants

   If during the execution of their activities, a disagreement arises
   over an implementation decision made by one of the components in the
   model, any relevant party should first request a review and
   reconsideration of the decision with the other party or parties, and
   inform the RSE that this activity is underway.  All parties should
   work informally and in good faith to reach a mutually agreeable
   conclusion.  If the parties resolve the issue, they should inform the
   RSE of the resolution and specify any procedural or other changes
   that it may entail.

   If one party still disagrees after the reconsideration, that party
   should ask the RSE to undertake a formal review.  The RSE must inform
   and engage the RSAG in their advisory capacity, and may call for a
   review committee including members of the RSAG.  The RSE and RSAG
   should seek to reach rough consensus on the resolution of the matter.

   If there is a technical or procedural matter that concerns the IAB,
   or an administrative, legal, or financial issue that concerns the
   IAOC, the RSE may request the guidance or participation of either or
   both of those bodies.  If the disagreement directly involves the RSE,
   the RSE may ask the IAB to mediate or appoint a mediator to aid in
   the discussions, although the IAB is not obliged to do so.  The RSAG
   should be used in this capacity unless there is good reason it should
   not (such as if the RSAG itself is a party to the disagreement).

   If a timely decision cannot be reached through discussion, mediation,
   and mutual agreement, the Series Editor is expected to make whatever
   decisions are needed to ensure the smooth functioning of the RFC
   Editor function.  Such decisions must follow proper community-
   oriented practices as described in Section 4.




Kowack                   Expires April 29, 2011                [Page 36]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   RSE decisions of this type are limited to the functioning of the RFC
   Editor processes and evaluation of whether current policies are being
   implemented appropriately or need adjustment.  As described in
   Section 4, final decisions about the technical content of individual
   documents are the exclusive responsibility of the stream approvers
   for those documents.

   If a disagreement or decision has immediate or anticipated future
   contractual consequences, the Series Editor must identify the issue
   to the IAOC and, if the RSAG has provided related advice, the RSE
   should forward that to the IAOC.

9.2.  RSE Review of Inter-Stream Conflicts

   Streams are encouraged to resolve conflicts on their own.  Any stream
   approver may request RSE review of an inter-stream conflict at any
   time.  Review by the RSE must include assembling a review committee
   of four disinterested RSAG members plus the RSE, who will chair the
   committee.

   RSE recommendations must be consistent with existing RFC-documented
   policy, insofar as documented policy covers the issue.  RSE
   recommendations may not use informal (that is non-RFC) statements of
   practices such as those found in stream-internal documentation (such
   as web pages).


10.  Re-Establishing an RFC Editor Stream Capability

   Before publication of RFC 4844, the RFC Editor could produce RFC
   Editor -related documents whenever the RSE thought them necessary,
   without approval from other entities.  By formally dividing new
   document production into four distinct partitions, RFC 4844
   eliminated this capability.  Today, if the RSE wishes to publish an
   RFC, it must be approved by one of the streams.  None is suitable;
   each could impose process or content requirements on the RSE, which
   could reduce the RFC Editor's independence.  This might be especially
   so if the draft in question has impact on one or more of the streams.
   Adding new processes to permit RFC Editor publications to each stream
   would be complex and time-consuming, and would not clearly result in
   a satisfactory process.  The Independent Submissions Stream, being a
   general-purpose stream under the RFC Editor, might appear suitable.
   However, if an RFC Editor draft were politically significant, some
   parties might put pressure on the Independent Submissions Editor- and
   on the RSE - which could jeopardize Independent Stream autonomy.

   The RSE must take all steps necessary to create an "RFC Editor
   Stream" as soon as practical.  The RFC Editor Stream charter is to



Kowack                   Expires April 29, 2011                [Page 37]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   produce Informational RFCs pertaining to the RFC Series in general,
   to the operation, practices, and performance of the RFC Editor, and
   to editorial subjects of interest to the community, including authors
   and draft editors from the streams.  The Series Editor will be the
   stream approver.  The RSE may accept and publish in-topic documents
   from outside the RFC Editor.  The full members of the RSAG will
   comprise the (strictly) advisory editorial board of the RFC Editor
   stream.  The RSE, in cooperation with the RSAG, will define a
   document approval process for this stream, to be presented to the
   community for review and feedback.

   Section 5, [RFC4844], discourages the creation of new streams.  In
   order to be economical about adding this stream, the RFC Editor
   Stream could be the designated as the future repository of archived
   (and discontinued) series.  In this case, it might be useful to begin
   the concept of the 'sub-stream', under which different 'adopted'
   archived series might reside.


11.  Future Considerations

   In time, it may be necessary to provide oversight for the RFC Editor
   that is more active, focused and expert than is possible under the
   IAB.  In that case, it may be useful to divide the RSAG into two
   groups.  One could continue to provide guidance, the other could
   undertake the responsibilities and activities currently performed by
   the IAB.


12.  IANA Considerations

   This document defines several functions within the overall RFC Editor
   structure, and it places the day-to-day coordination of registry
   value assignments with the RFC Production Center under the direction
   of the RSE.  The IAOC will continue to facilitate the establishment
   of the relationship between the RFC Editor and IANA.

   This document does not create a new registry nor does it register any
   values in existing registries, and no IANA action is required.


13.  Security Considerations

   The same security considerations as those in RFC 4844 apply.  The
   processes for the publication of documents must prevent the
   introduction of unapproved changes.  Since the RFC Editor maintains
   the index of publications, sufficient security must be in place to
   prevent these published documents from being changed by external



Kowack                   Expires April 29, 2011                [Page 38]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   parties.  The archive of RFC documents, any source documents needed
   to recreate the RFC documents, and any associated original documents
   (such as lists of errata, tools, and, for some early items, non-
   machine-readable originals) need to be secured against failure of the
   storage medium and other similar disasters.

   The RSE and IAOC should take these security considerations into
   account during the implementation of this RFC Editor model.


14.  Acknowledgments

   [ed., TBD]


15.  References

15.1.  Normative References

   [RFC4844]  Daigle, L. and IAB, "", 4844 RFC, July 2007.

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

15.2.  Informative References

   [RFC4333]  Huston, G. and G. Wijen, "The IETF Administrative
              Oversight Committee (IAOC) Member Selection Guidelines and
              Process", RFC 4333, December 2005.


Appendix A.  2010-11 RSE Search and Selection Process

   This appendix describes the structures and processes for finding and
   selecting the first long-term RFC Series Editor, specifically during
   late 2010 and early 2011.

A.1.  Overview and Criteria

   Five community members will serve on a seven-member RSE Search and
   Selection (SSC) committee.  The design of this committee aims to
   satisfy several key requirements.  To ensure a representative range
   of points of view, the committee will be populated from different
   parts of the community.  Committee members will have expertise in
   community processes, and there will be advisors from relevant
   professions.  The SSC selection process will ensure that members will
   have the requisite background and skill for their mission.  The
   process is defined to reduce confusion or risk of process failure.



Kowack                   Expires April 29, 2011                [Page 39]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   Finally, the committee is intentionally small to permit quicker
   action and easier exchange of information.

A.2.  Structure

   The seven-member SSC will consist of five regular (voting) members:

   o  two regular members appointed by the stream approvers,

   o  two regular members appointed by RSAG regular members (that is,
      liaisons will not participate in the RSAG selection process),

   o  one regular member appointed by [ed., TBD].

   plus two non-voting advisors:

   o  a volunteer Human Resources (HR) professional from the computing
      or networking industry, and

   o  the Transitional RFC Series Editor

   All SSC members will be at-large members; each is to represent the
   community, not the group that appointed them.  The committee will
   select a chair among the regular members.  The SSC may appoint
   assistants as required.  Decisions will be by rough consensus unless
   the committee chooses other processes.

A.3.  Stream Appointments

   The IETF stream approver, the IESG, will appoint one SSC member by a
   process of its choosing.  The other three stream approvers (IAB,
   IRSG, and ISE) will collectively appoint the other member by a
   process of their own choosing.  To ensure broad support for
   appointments, each stream appointee must be approved by the other
   stream approvers; that is, the IESG approver must approve the member
   proposed by the IAB, IRSG, and ISE approvers, and vice versa).

   Streams appointees may, but need not, be current participants in the
   streams or current stream leaders.  To promote broad participation,
   current stream chairs are not eligible for appointment to the SSC.
   Each stream approver should widely survey members of their streams
   when making their selection.

A.4.  RSAG Appointees

   The two RSAG appointees may be from the RSAG or from the greater
   community.  One of the two appointees may be a highly respected
   leader from the technical publications world without previous direct



Kowack                   Expires April 29, 2011                [Page 40]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   participation in the community.  The RSAG should seek community
   comment on their prospective candidate(s).

A.5.  SSC Regular Member Qualifications

   All SSC regular members must have:

   o  broad experience and wide respect within the community,

   o  experience interviewing and evaluating prospective hires and with
      interviewing,,

   o  significant experience with editorial practices, and

   o  skill at analyzing and resolving complex issues as members of
      teams.

A.6.  Additional Qualifications for Streams Appointees

   The streams appointees must have solid knowledge of stream editorial
   requirements and typical RFC Editor interactions from within at least
   one stream.

A.7.  Additional Qualifications for RSAG Appointees

   The RSAG appointees must have extensive knowledge of editorial
   practices in general and specifically of the processes of the RFC
   Editor and the duties and challenges of the RSE.  This criterion may
   be ignored if one of the RSAG appointees is a leader in technical
   publishing, per above.

   The vast majority of RSE candidates will come from technical
   publishing, a profession different from that of most members of the
   community.  Community members generally do not have extensive
   experience in search and hiring.  To ensure that qualified candidates
   apply, the SSC will use the services of a professional search firm.
   A search professional may act as SSC HR advisor, or the SSC may
   require a separate HR advisor.

   The RSE and IAOC will locate a professional search firm in
   cooperation with the IAB.  The SSC will have final approval of the
   search professional.  The RSE will support the IAOC in determining
   budget requirements.  The IAOC and IAB will seek financial support
   for a search firm.







Kowack                   Expires April 29, 2011                [Page 41]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


A.8.  Non-Voting Members

   In cooperation with the IAB, the TRSE will make a community call for
   a volunteer HR professional to serve on the SSC.  The SSC have final
   approval for any such selection.  If they a suitable candidate is not
   found, an HR professional will be sought with the assistance of ISOC
   staff; support will be sought from ISOC.

   The TRSE will advise the SSC on the RSE job description and the
   search and selection process, and on other topics on request.  The
   TRSE will draft calls for candidates before the first meeting of the
   SSC and will be available to write or modify documents on request.
   The HR professional will provide guidance on hiring law and on
   standard HR processes, and practices.

A.9.  SSC Assistants and Additional Expert Advisors

   The SSC may engage volunteer help as needed from across the community
   and elsewhere.  The SSC will publish names of volunteers and their
   roles.  The SSC may also seek compensated expert help if required and
   unavailable on a volunteer basis.  Names and roles of experts will be
   made public unless not possible due to confidentiality requirements.

A.10.  SSC Approval of Job Description

   The SSC will have final approval over job description postings, but
   may not diverge from RFC 5620bis.

A.11.  Financial and Legal Preparations

   Before the public call for RSE candidates, in cooperation with the
   IAB and the IAOC the TRSE will locate a suitable compensation
   specialist to be hired by the IAOC.  The specialist will work with
   the TRSE to determine RSE compensation and related matters.  In
   cooperation with the IAB, the TRSE will support the IAOC in
   determining a budget line item.  The goal of the TRSE and IAOC is to
   have this information in place before the first meeting of the SSC.
   The SSC will review these items as soon as they are available and
   have right of approval of the budget items.  SSC approval is
   required, also, to ensure that SSC are able to fulfill their mission.

   The TRSE will publish RSE compensation information to the community
   once it is available.

   There will be a budget for the SSC.  Besides including the search
   firm and compensation specialist fees, the SSC and IAOC will agree on
   an advertising budget, and other items as required by the SSC.




Kowack                   Expires April 29, 2011                [Page 42]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   The SSC will review the IAOC's RSE contractual terms with the IAOC to
   ensure that the process is effective and to maintain alignment
   between candidate and community requirements from start to finish.
   The committee may request changes to contract terms to reduce
   unnecessary barriers to unconventional candidates of otherwise high
   quality suited to this unusual position.

A.12.  SSC Alignment with RSE Job Description

   Hiring is a complex activity and no candidate will be a perfect fit.
   However, the committee may not diverge from the job description and
   5620bis.

A.13.  SSC Call for Candidates

   The call for candidates will describe the application process.  It
   will be distributed worldwide, including at least:

   o  across the community, and

   o  beyond the community:

   o  technical publications offices at universities and research
      institutes,

   o  technical publishers, including journals,

   o  technical publications offices in technology companies,

   o  government technical publications offices, and

   o  other standards bodies, to be defined.

   The SSC will determine where to post notices, including mail lists
   and popular job posting web sites.  The SSC is encouraged to use the
   personal networks of the community to "get the word out" but also
   cautioned to avoid language and postings that could encourage
   unqualified applicants.

A.14.  Applications and Short List

   The SSC will be responsible, with the support of the RSE and the HR
   professional, for the search and hiring process.  The SSC will use
   interviews, reference checks, and other means to select a short list
   of no more than 10 candidates.






Kowack                   Expires April 29, 2011                [Page 43]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


A.15.  Confidentiality

   Aspects of the hiring process must be confidential, out of respect
   for candidates' needs, and by law.  Nevertheless, the SSC will make
   every effort to communicate progress to the community.  It is likely
   that community discussion of candidates will have to be limited to
   individuals or small groups.  Members of the SSC and volunteers who
   participate in these reviews will be privy to confidential material
   and must agree to respect confidentiality.

A.16.  Best and Final

   The SSC will select a final candidate, or, at their discretion, two
   or three finalists.  Before the SSC selects an RSE, the candidate(s)
   will meet with community leaders and primary colleagues of the RSE,
   including:

   o  IAB Chair,

   o  IAOC Chair and IAD,

   o  IETF chair,

   o  IRSG chair,

   o  Independent Submissions Editor, and

   o  Production Center Director.

   These interviews are for thoroughness, and to give each candidate an
   opportunity to meet the people with whom the RSE must work most
   closely -- a critical step for anyone considering the position.
   Interviews will be primarily by phone, but for a single preferred
   candidate may be face-to-face, if necessary.  Interview results will
   be an important input to the SSC's decision.  But these meetings do
   not imply that participants have final approval or veto power over
   the SSC's selection.

A.17.  IAB Process Review

   The SSC will send notice of their selection to the IAB.  Notice will
   include the candidate's qualifications with respect to the RSE job
   description, and a review of the process.  The IAB will review the
   search and selection process for completeness and compliance.  If the
   IAB does not find any exceptions to process, it must approve the
   candidate.  The IAB may not change the selection of the committee.
   If the IAB finds process exceptions, it must not step in and manage
   the search and selection process.  It must publish a report to the



Kowack                   Expires April 29, 2011                [Page 44]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   community about what those exceptions are and call for new search and
   selection activity with new process requirements.

A.18.  IAOC / SSC Joint Negotiation

   The SSC chair will shepherd the selected applicant through the final
   contracting process.  The IAOC will negotiate the contract with the
   selected candidate in close consultation with the SSC chair.  A start
   date for the new RSE will be agreed during negotiations.  Once a
   contract is in place between the IAOC/SSC and the candidate, the IAB
   will be notified and, following standard practice, the contract will
   be forwarded to the Internet Society for signature.  The SSC and IAOC
   will support the IAB in drafting a public announcement.  This will
   complete the RSE selection process.

A.19.  SSC DRAFT SCHEDULE

   The committee will announce a final schedule soon after they are
   appointed, starting with this draft schedule:

   o  5620bis and Job Description agreed by community (target date TBD)

   o  Calls for SSC members (target date TBD)

   o  Announcement of SSC members (target date TBD)

   o  First SSC meeting (target date TBD)

   o  Financials and legal terms agreed (target date TBD)

   o  Final "Call for Candidates" text completed (target 9 November)

   o  SSC Call for Candidates (target 11 November at Beijing IETF)

   o  Close of Application Period (date TBD) [Ed., Holiday lag?]

   o  Vetting of "short list" of < 10 candidates (target date TBD)

   o  Determination of Best and Final List (target date TBD)

   o  Announcement of new RSE (target date TBD)

A.20.  No Suitable Candidate

   The SSC has the option to make no selection if they conclude that no
   suitable candidate has been found.  In this case, they will explain
   this in their report and describe possible remedies.  It will then be
   up to the IAB to determine (1) how to provide for continuity of the



Kowack                   Expires April 29, 2011                [Page 45]

Internet-Draft        RFC Editor Model (Version 2)          October 2010


   series for another fixed interim period, (2) what went wrong with the
   job description or the search and selection process, and (3) what
   sort of new process should be undertaken.


Author's Address

   Glenn Kowack (editor)
   Riveronce

   Email: glenn@riveronce.com








































Kowack                   Expires April 29, 2011                [Page 46]


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