RFC Editor Model Proposal: Executive Summary
draft-crocker-rfc5620bis-execsum

Abstract

The RFC Editor publishes the Internet's archival series of technical documents. Its activities are divided into a number of components, including the RFC Series Editor (RSE) whose responsibilities demands a very high level of technical, editorial, and managerial expertise. This Summary describes a proposal that is the result of nearly one year's effort to clarify the activities of the RFC Editor and the RSE, according to established approaches to management and oversight of a publication service, but tailored for the style of the Internet technical community, and with careful attention to the need for stable operations. [RFC5620bis]

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

Copyright Notice

Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents 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.   Introduction
• 2.   RFC Editor Model
  • 2.1   Executive
  • 2.2   Operations
  • 2.3   Streams
• 3.   Considerations
  • 3.1   IANA Considerations
  • 3.2   Security Considerations
• 4.   References
  • 4.1   Normative References
  • 4.2   Informative References
• Author's Address
• A.   Re-Establishing an RFC Editor Stream
• B.   Resolution of Disagreements
  • B.1   Disagreements between RFC Editor Components and Model Participants
  • B.2   Resolution of Inter-Stream Conflicts
• C.   RSE Search and Selection Process

• Figure 1: RFC Editor Structure

1. Introduction

This Summary describes a proposal that is the result of nearly one year's effort to clarify the activities of the RFC Editor and the RSE, according to established approaches to management and oversight of a publication service, but tailored for the style of the Internet technical community, and with careful attention to the need for stable operations. [RFC5620bis]

The RFC Series is the Internet technical community's official medium, for communicating its work, to itself and to the rest of the world. In use since 1969, the now over 6,000 RFCs constitute one of the most extensive and influential technical series in history. Without openly available RFCs, the Internet could not have been built, operated, nor continued its remarkable advance. The RFC Editor is the community-defined and supported function that accepts documents from the community, makes textual edits to them for clarity and formal correctness, and publishes and archives those documents as RFCs for free access by everyone.

[RFC5620] first defined the components and processes of the present-day RFC Editor. These included the RFC Series Editor (RSE) as its leading component. The recent attempt to hire a new RSE proved problematic and resulted in an transitional project to propose refinements to the RFC Editor model and especially to clarify and enhance the role of the RSE.

• 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 being proposed to the existing version of the RFC Editor Model. Although modest, these changes are fundamental to the on-going success of the RFC Editor's service to the Internet community.

• The first clarification is that the overall leadership and management of RFC Editor functions must be by the RFC Series Editor -- the subject matter and managerial expert.

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

• The Internet technical community has requirements, processes, and traditional that must continue to be supported.
• The line between the responsibilities of the RSE and the IETF Administration and Oversight Committee (IAOC) must be clarified.

The changes being proposed frame the details of the RSE by combining a description of RFC Editor leadership as it would be practiced in a typical not-for-profit organization, and then applying these Internet community-driven practices:

• Seeking community input appropriately and widely
• Encouraging volunteer initiative and contribution
• Practicing supervision according to specified procedures

The proposal calls for collaboration between the RSE and the IAOC:

• The RSE is responsible for regular editorial activities and management, including long-term editorial planning.
• The IAOC retains its leadership of legal and financial matters.

This is analogous to the partnership between line management and finance found in most modern corporations.

Additional changes being proposed include:

• Explicit independence of the Independent Submission Stream and Independent Submission Editor (ISE) is reinforced by moving RSE reviews of the ISE to an independent committee.
• The role of the RSE Advisory Group (RSAG) is marginally expanded to ensure that the RSE follows community will and to provide counsel to the IAB when the RSE is either unavailable or the subject of a discussion.
• An updated RSE search and selection process is rooted in community participation, qualified and expert participants and advisors, and carefully-described roles to ensure a successful result.

Without aiming to do so, most of the changes in the updated model naturally return the RFC Editor to the style and perspective used during the first 40 years of its life, but adapted to today's structure and operation of the technical community. The proposal is based on the conclusion that this time-proven arrangement is the best way, to serve the requirements of the Internet technical community.

The changes being proposed from the existing, documented model and service are intentionally small, although substantive. Principally the lines of reporting are more explicit, as are the details of responsibility and authority.

2. RFC Editor Model

As shown in Figure 1 the RFC Editor model divides the responsibilities for the RFC Series into the following types of components:

Executive:

The RFC Series Editor ('RSE') and RFC Series Advisory Group (RSAG) provide strategic oversight to RFC Editor operations and enhancement, and they resolve unusual problems, questions and concerns as they arise. Oversight of the Executive functions is provided by the IAB and the IAOC.

Streams:

Documents are submitted to the RFC Editor through a variety of "streams", each of which has its own content and approval processes. The current streams are: IETF, IRTF, IAB and Independent.

Operations:

The RFC Production Center (RFC PC) handles daily activities of the RFC Editor, specifically processing documents from submission to publishing. The RFC Publisher (RFC Pub) is the public archive of RFCs.

                                  +-------+  +-------+
                                  |       |  |       |
                                  |  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   |   |   r   |  .  |  &  |
|           |   |             | . |   n   |   |       |  .  |  R  |
|   IRTF    +--->    IRSG     +--->       |   |       |  .  |  e  |
|           |   |             | . |   C   |   |       |  .  |  a  |
+-----------+   +-------------+ . |   e   |   |       |  .  |  d  |
+-----------+   +-------------+ . |   n   |   |       |  .  |  e  |
|           |   |             | . |   t   |   |       |  .  |  r  |
|   IETF    +--->    IESG     +--->   e   |   |       |  .  |  s  |
|           |   |             | . |   r   |   |       |  .  |     |
+-----------+   +-------------+ . +-------+   +-------+  .  +-----+
                                .                        .
                                +........................+

Figure 1: RFC Editor Structure

2.1 Executive

2.1.1 RFC Series Editor

2.1.1.1 Responsibilities

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

• Maintain RFC series continuity"
• Maintain RFC Series quality
• Represent the RFC Series to the technical community
• Represent and promote the RFC Series to the outside world
• Identify and lead community discussions concerning RFC Series issues

Duties of the RSE include:

• Oversight of day-to-day RFC Editor operations
• Reviewing Operations processes, structures, performance, and making changes to them
• Analyzing customer requirements and strategic opportunities
• Developing long-term goals and plans, including budgeting
• Interacting with and supporting peers and colleagues
• Reporting upwards and to constituents
• Representing their area in the marketplace

2.1.1.2 Professional Qualifications

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

• Experience as a senior manager and subject matter expert in technical writing, technical publications and technical series development. This should include executive management experience suitable to the requirements outlined here, and coordinating the overall RFC Editor process
• Experience with complex organizations with substantial group processes. Skilled at participating in, managing, and getting value from, group processes. Understanding and appreciation of delegation is required. Experience with and understanding of the IETF and RFC process is desirable
• Good understanding of the English language and technical terminology related to the Internet.
• Excellent communication and skills
• Independent worker
• Experience as an RFC author is desirable

2.1.2 RFC Series Advisory Group (RSAG)

The RSAG provides expert, informed guidance in matters affecting the RFC Series' operation and development. It provides advice principally to the RSE and aids in RSE and RFC Editor connection to and alignment with the community.

RSAG full (non-liaison) members are all at-large members; they do not represent a particular RFC stream or any organizations. They are selected by the RSE 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. In addition to full members, each RFC stream approver will appoint a liaison to the RSAG to provide context specific to their stream.

2.2 Operations

2.2.1 RFC Production Center

RFC Production is performed by a paid contractor. Under the direction of the RSE, their responsibilities include:

• Editing inputs from all RFC streams to comply with the RFC Style Manual
• Creating records of edits performed on documents
• Identifying where editorial changes might have technical impact and seeking necessary clarification
• Engaging in dialogue with authors, document shepherds, IANA, and/or stream-dependent contacts when clarification is needed
• Creating records of dialogue with document authors
• Requesting advice from the RFC Series Editor as needed
• Offering suggestions to the RFC Series Editor as needed
• Providing sufficient resources to support RFC Series Editor reviews of RFC Publisher performance, and external reviews of the RFC Editor initiated by the IAB or IAOC.
• Coordinating with IANA to perform protocol parameter registry actions
• Assigning RFC numbers
• 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
• Forwarding ready-to-publish documents to the RFC Publisher
• Forwarding records of edits and author dialogue to the RFC Publisher so these can be preserved
• Liaising with various streams as requested by the RSE.

2.2.2 RFC Publisher

The RFC Publisher comprises the publicly-accessible computing resources where RFCs and related information are archived and the promotion of its availability. Included are the management services required to support and maintain that capability. These activities are under general supervision of the RSE.

RFC Publisher responsibilities include:

• Announcing and providing on-line access to RFCs.
• Providing on-line system to submit RFC Errata.
• Providing on-line access to approved RFC Errata.
• Providing backups.
• Providing storage and preservation of records.
• Authenticating RFCs for legal proceedings.

2.3 Streams

The current streams are: IETF, IRTF, IAB and Independent. Their depiction in Figure 1 distinguishes between the sources of documents and the approvers of documents.

Details about the streams are provided in [RFC5742], [RFC5743].

3. Considerations

3.1 IANA Considerations

This document entails no IANA considerations

3.2 Security Considerations

This document entails no Security considerations.

4. References

4.1 Normative References

4.2 Informative References

A. Re-Establishing an RFC Editor Stream

Before publication of [RFC4844], the RFC Editor could produce RFC Editor-related documents whenever they felt it necessary, without approval from other entities. [RFC4844] eliminated this capability. The stream should be re-instituted to distinguish RFC Editor-related policy, structure and process documents from other RFCs.

B. Resolution of Disagreements

B.1 Disagreements between RFC Editor Components and Model Participants

If there is a continuing disagreement between participants and/or functions of the RFC Editor, they should ask the RSE to undertake a formal review. 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. 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 she should forward that to the IAOC.

B.2 Resolution of Inter-Stream Conflicts

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. The RFC Series Editor will resolve inter-stream conflicts. The IAB may review the decision of the RSE for process correctness. The community may revisit the decision of the RSE through the normal process of community consensus and documentation in a new RFC.

C. 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 7-member RSE Search and Selection (SSC) committee will consist of five regular (voting) members:

• The IETF stream approver, the IESG, will appoint one of the members.
• The other three stream approvers (IAB, IRSG, and ISE) will collectively appoint the other member by a process of their own choosing.
• RSAG regular members (that is, not liaisons) will appoint two regular members,
• [ed., TBD] will appoint one regular member,

plus two non-voting advisors:

• A volunteer Human Resources (HR) professional from the computing or networking industry, and NOTE: Is this a permanent position?']
• The Transitional RFC Series Editor

Upon completion of the selection process, the IAB will review the SSC process, in a manner similar to the review provided for a Nomcom process.