Internet DRAFT - draft-carpenter-rfced-model

draft-carpenter-rfced-model







rfced-future                                                B. Carpenter
Internet-Draft                                         Univ. of Auckland
Intended status: Informational                           August 20, 2020
Expires: February 21, 2021


       Alternative Proposed Model for RFC Editing and Publication
                     draft-carpenter-rfced-model-00

Abstract

   The finishing process for a document that is approved for publication
   as an RFC currently involves a somewhat detailed and lengthy process.
   The system that executes that process involves a number of different
   actors, each bringing competency with different aspects of the
   overall process.  Ensuring that this process functions smoothly is
   critical to the mission of the organizations that publish documents
   in the RFC series.

   This document proposes a framework for that system that aims to
   provide clear delineations of accountability and responsibility for
   each of the actors in this system.  It would require significant
   updates to RFC 8728 and RFC 8729, and minor updates to RFC 2850 and
   RFC 7841.

   Discussion of this document takes place on the RFC Editor Futures
   mailing list (rfced-future@iab.org).

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 https://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 February 21, 2021.







Carpenter               Expires February 21, 2021               [Page 1]

Internet-Draft        Alternative RFC Editing Model          August 2020


Copyright Notice

   Copyright (c) 2020 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
   (https://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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Abstract Model  . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Funding and Oversight . . . . . . . . . . . . . . . . . . . .   4
     3.1.  IETF LLC Delegation of Oversight Function . . . . . . . .   5
   4.  Evolution and Setting Policies  . . . . . . . . . . . . . . .   6
     4.1.  Individual Interactions . . . . . . . . . . . . . . . . .   8
     4.2.  The Needs of Different Streams  . . . . . . . . . . . . .   9
     4.3.  Style Guide . . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Tooling . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  Management of Individual Functions  . . . . . . . . . . . . .  12
   7.  Other Involved Entities . . . . . . . . . . . . . . . . . . .  13
   8.  Role of the RFC Series Advisor  . . . . . . . . . . . . . . .  13
   9.  Changes from Version 2 of the RFC Model . . . . . . . . . . .  14
     9.1.  No RFC Series Editor  . . . . . . . . . . . . . . . . . .  14
     9.2.  No IAB Responsibility . . . . . . . . . . . . . . . . . .  14
     9.3.  Preserved Aspects of Current Practice . . . . . . . . . .  15
     9.4.  Motivating Principles . . . . . . . . . . . . . . . . . .  15
   10. Documentation Requirements  . . . . . . . . . . . . . . . . .  15
     10.1.  New RFC Stream . . . . . . . . . . . . . . . . . . . . .  17
   11. Errors and Omissions  . . . . . . . . . . . . . . . . . . . .  17
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  18
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  18
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  18
     15.2.  Informative References . . . . . . . . . . . . . . . . .  19
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  19







Carpenter               Expires February 21, 2021               [Page 2]

Internet-Draft        Alternative RFC Editing Model          August 2020


1.  Introduction

   Please note that large portions of this draft have been copied, with
   permission, from [I-D.thomson-rfced-model].  However, the two
   proposals are substantively different.

   The RFC Editor Model [RFC8728] describes a system that supports the
   process of editing and publication of RFCs.  Its companion document
   [RFC8729] covers the related organizational roles, including that of
   the RFC Series Editor (RSE) in person.  Both of these documents were
   issued by the IAB in pursuance of the relevant item in its charter
   [RFC2850].

   The process of RFC editing and publication currently takes inputs in
   the form of documents that are approved for publication by one of
   four existing streams (IETF, IRTF, IAB, and Independent Submissions)
   [RFC7841].  The output is an RFC.

   Generally speaking, this system is successful if RFCs are produced at
   a rate approximating the rate that documents are approved for
   publication.  In addition to managing throughput, the overall latency
   should be minimized and the quality of documents should be sufficient
   to serve the ends of the consumers of those documents.

   In practice, the demands placed on the editing and publication
   process mean that this function is quite involved.  Furthermore, the
   exact goals that this system serves continually evolve.  The current
   system has evolved out of a relatively simple system, into something
   like what is described in [RFC8728] with multiple discrete roles and
   somewhat complex interactions between each.

   The goal of this document is to ensure that the RFC series can
   continue to serve as a venue for the publication of documents that
   are relevant to the Internet.  To that end, it aims to define a
   system for administering the editing and publication process.

   This aims to be a lightweight system that uses community engagement
   and transparency as the primary mechanisms for ensuring
   accountability.  This system avoids vesting control in an individual
   or body with closed membership, preferring open processes for
   critical strategic functions.

   This document starts out by building from a simple (even simplistic)
   model of the system, then builds that out incrementally.  The goal is
   to progressively expand on the relevance of the model in addressing
   different problems that have been identified as important, or to draw
   in each of the relevant actors in the system and to attribute
   responsibilities (and associated authority) to each.



Carpenter               Expires February 21, 2021               [Page 3]

Internet-Draft        Alternative RFC Editing Model          August 2020


2.  Abstract Model

   The highest-level abstraction is shown in Figure 1.

     +-------------+        +-------------+
     | IETF Stream +------->+             +----->
     +-------------+   D    |             |
     +-------------+   o    |             |
     | IRTF Stream +---c--->+ RFC         +-----> R
     +-------------+   u    | Editing     |       F
     +-------------+   m    | and         |       C
     | IAB Stream  +---e--->+ Publication +-----> s
     +-------------+   n    |             |
     +-------------+   t    |             |
     | Independent +---s--->+             +----->
     +-------------+        +-------------+

                      Figure 1: RFC Production Model

   In this model, each of the document streams produce documents that
   are approved for publication according to the processes of those
   streams.  Each stream is an independent client of a single entity
   that provides services in support of publishing documents as RFCs.
   These services have numerous facets, but the core services are copy
   editing of documents, the preparation of documents for publication,
   and the publication of documents.

   At a high level, each of the streams is an independent customer of
   the function of RFC Editing and Publication (REP).  In [RFC8728], two
   separate functions are identified (RFC Production Center and RFC
   Publisher) but externally that distinction seems pointless.  The
   entity (or entities) that perform the REP function are contracted to
   turn approved documents into RFCs.

3.  Funding and Oversight

   The entity that performs the REP function holds contracts with the
   IETF LLC, who also provides payment for those contracted services.
   This means that the REP function is ultimately answerable to the IETF
   LLC with respect to performance.

   Currently, the IETF LLC delegates some of its authority to another
   body.  This allows the IETF LLC to rely on the expertise of
   volunteers from the community in performing oversight.  The IETF LLC
   currently delegates this function to the RFC Series Oversight
   Committee (RSOC) via the IAB.  This indirection has caused some
   problems and this document proposes that oversight be a function that




Carpenter               Expires February 21, 2021               [Page 4]

Internet-Draft        Alternative RFC Editing Model          August 2020


   the IETF LLC be responsible for, either directly or through a
   delegation process that is managed by the IETF LLC.

   The IETF LLC therefore has authority over negotiating performance
   targets for the REP and the responsibility of ensuring that those
   targets are adhered to.  The IETF LLC is empowered to appoint a
   manager or to convene a committee that is responsible for this
   oversight function.

   Community members who have concerns about the performance of the REP
   can request that the IETF LLC investigate the matter.  If the IETF
   LLC opts to delegate the oversight function, concerns can be raised
   with the IETF LLC.  The IETF LLC is ultimately responsible to the
   community via the mechanisms outlined in its charter [RFC8711].

   This results in evolving the basic model as shown in Figure 2.

                                 +------+
                                 | IETF |
                                 | LLC  |
                                 +------+
                                    |
                                    | Contract &
                                    | Oversight
                                    v
   +-------------+        +-------------+
   | IETF Stream +------->+             +----->
   +-------------+   D    |             |
   +-------------+   o    |             |
   | IRTF Stream +---c--->+ RFC         +-----> R
   +-------------+   u    | Editing     |       F
   +-------------+   m    | and         |       C
   | IAB Stream  +---e--->+ Publication +-----> s
   +-------------+   n    |             |
   +-------------+   t    |             |
   | Independent +---s--->+             +----->
   +-------------+        +-------------+

                 Figure 2: Oversight and Funding Functions

   This shows the IETF LLC having budgetary and contractual oversight
   over the REP.

3.1.  IETF LLC Delegation of Oversight Function

   The current organization tasks the RSOC with responsibility for
   oversight.  This has lead to numerous questions about the extent of




Carpenter               Expires February 21, 2021               [Page 5]

Internet-Draft        Alternative RFC Editing Model          August 2020


   authority delegated to the RSOC and the responsibilities of various
   entities that the RSOC is tasked with interacting with.

   This document avoids these questions by placing this authority
   directly with the IETF LLC.  However, the oversight function is one
   that the IETF LLC might choose to delegate, either to an individual
   or committee.

   Any delegation would ideally result in the creation of a a document
   governing how the delegation was structured.  This is not that
   document, but this assumes that the person or persons who are given
   oversight responsibility would be responsible for managing contract
   and performance for the REP.  Any appeal or dispute with the actions
   of this individual or committee would then be taken up with the IETF
   LLC.

4.  Evolution and Setting Policies

   Setting the strategy and policies for REP functions and more detailed
   requirements for operation of these functions have historically been
   delegated to the RSE.  This document proposes separating these.  The
   goal is to improve the ability of the community (across all streams)
   to set and evolve policies.  Operational details and targets, on the
   other hand, clearly fall under the LLC.

   The strategic requirements of each of the streams change over time.
   The goal is to find a system that allows the community to develop
   consensus around the strategic direction for the evolution of the RFC
   Series.

   In terms of structure of this effort, the community has a set of
   well-understood and tested systems for developing consensus.
   Therefore, this document proposes that strategic goals for the RFC
   Series are developed using the working group process [RFC2418] used
   in the IETF to the maximum extent possible, given that the community
   of interest is broader than the IETF.

   Concretely, this document proposes forming an RFC Series Advisory
   Working Group (RSAWG) under the auspices of the Internet Society
   (ISOC).  This would be a group that follows [RFC2418] procedures,
   with the exception that the oversight and conflict resolution
   functions performed by the IESG are instead performed by ISOC.  In
   particular, selection of chairs and appeals regarding the execution
   of the process are directed to the ISOC Board of Trustees to resolve.
   This is intended to underline the community-wide importance of the
   RFC Series.





Carpenter               Expires February 21, 2021               [Page 6]

Internet-Draft        Alternative RFC Editing Model          August 2020


   Like any IETF working group, the RSAWG will be open to any interested
   person.  This explicitly includes staff of the REP.  However, in
   addition to at least two chairs appointed by ISOC, it is important
   that each RFC stream has a named representative in the RSAWG who is
   able to present the requirements of that stream.

   It is important that this group adopt code of conduct, anti-
   harrassment, and other policies.  Again, existing IETF processes -
   collectively referred to in the Note Well - are well-suited to this
   task.

   Much of the strategy will be concerned with the technical needs of
   the streams or with other matters that protocol engineers are
   competent to discuss.  However, some matters will arise that are
   questions of technical editing, publishing, archiving, etc.  Protocol
   engineers cannot be assumed to have the necessary expertise for these
   topics.  Therefore, an outside RFC Series Advisor (RSA) is needed.
   More details are given below.

   Any strategic direction that is produced by this process will be
   documented in RFCs.  These will need to be framed as high-level goals
   and priorities rather than strict requirements.  It will be up to the
   IETF LLC - or their delegate - to negotiate with the REP function
   about the execution for any changes.  In negotiating the execution of
   strategy, the IETF LLC is expected to factor in relevant factors such
   as cost, legal constraints, or schedule.

   The IETF LLC is also responsible for ensuring that the plans for
   implementation of strategic goals is published and available to the
   community.

   This results in the model shown in Figure 3.



















Carpenter               Expires February 21, 2021               [Page 7]

Internet-Draft        Alternative RFC Editing Model          August 2020


                                 +------+
                                 | ISOC |
                                 +--+---+
                                    |
                                    | Oversight
                                    v
                              +-----+------+
                              | RFC Series |
                              | Advisory   |<------- RFC Series Advisor
                              | WG         |         (RSA)
                              +-----+------+
                                    |
                                    | Strategy
                                    v
                                 +--+---+
                                 | IETF |
                                 | LLC  |
                                 +--+---+
                                    |
                                    | Contract &
                                    | Oversight
                                    v
   +-------------+        +---------+---+
   | IETF Stream +------->+             +----->
   +-------------+   D    |             |
   +-------------+   o    |             |
   | IRTF Stream +---c--->+ RFC         +-----> R
   +-------------+   u    | Editing     |       F
   +-------------+   m    | and         |       C
   | IAB Stream  +---e--->+ Publication +-----> s
   +-------------+   n    |             |
   +-------------+   t    |             |
   | Independent +---s--->+             +----->
   +-------------+        +-------------+

                Figure 3: Evolution and Strategy Additions

4.1.  Individual Interactions

   It is important to recognize that the interface to the REP function
   is most often through individual authors (or chairs, document
   shepherds, and area directors) and individual REP staff.

   In those interactions, those individuals might find problems with
   processes or might be motivated to make suggestions for improvement.
   The goal of the RSAWG is to provide a single venue for discussion of
   changes to REP requirements, processes, and procedures.




Carpenter               Expires February 21, 2021               [Page 8]

Internet-Draft        Alternative RFC Editing Model          August 2020


4.2.  The Needs of Different Streams

   The singular group responsible for evolution of the RFC Series as a
   whole is a simplification that is made to reduce contention in
   setting strategic goals.  It is important to note that the needs of
   different streams can be different.

   Several factors motivate a single group that sets strategy.
   Historically, the IETF stream is responsible for a large proportion
   of the documents in the series.  That is unlikely to change and
   experience has shown that other streams are - for the most part -
   willing to accept that strategic direction is largely dictated by the
   needs of the most prolific user of the REP service.

   It is important that each stream retain control over the content of
   documents that are published on that stream.  Streams currently
   appoint a stream manager who is allocated authority over content on
   that stream and responsibility to manage any problems that might
   arise in handling documents produced by that stream.  This document
   proposes that this aspect of the role continue.

   Stream managers are also involved in discussion of changes to REP
   processes and they contribute to the development of strategic
   direction for the RFC series.  Rather than deal with issues of REP
   processes directly, stream managers are expected to initiate
   discussion or make proposals to the RSAWG.  To avoid conflicts of
   interest, it is expected that stream managers will be active
   participants - and not chairs - in this group.

4.3.  Style Guide

   One question that arises when considering policy is that of the Style
   Guide [RFC7322] and supporting material.  These materials are
   critical to the process of editing and therefore require that they be
   owned and maintained.

   The current process requires that the RFC Series Editor produce and
   maintain this material.  This document proposes that the RSAWG become
   responsible for ownership of this material.

   However, it is recognized that the REP service will likely be the
   ones to encounter the need to make updates to material.  The RSAWG
   will need clear processes for reporting problems.  As problems of
   this nature often arise during document processing, they can require
   expedient solutions.  To that end, the process should allow for the
   REP service to make and record decisions.  This is also a major
   reason why REP staff might choose to participate directly in the
   RSAWG.



Carpenter               Expires February 21, 2021               [Page 9]

Internet-Draft        Alternative RFC Editing Model          August 2020


   The nature of the process the RSAWG uses might change over time.  Any
   changes need to be clearly communicated and changes negotiated with
   the REP.  This negotiation is to be facilitated by the IETF LLC or
   their delegate.

5.  Tooling

   Producing an RFC relies heavily on tools that help automate many
   aspects of the process.  Using tools contributes to consistency and
   better performance of the REP function.

   In one version of this model, the tools that are used by the REP
   function are the responsibility of the function.  However, the larger
   system benefits from a degree of consistency between the tools used
   by each stream to produce documents and the tools used in the editing
   and publication stage.  In practice, these tools are shared and a
   great deal of benefit is derived from that arrangement.

   A number of different organizational arrangements could be conceived
   of for arranging this situation.  For instance, the REP could be
   tasked with producing and maintaining tools that it is required to
   also make available to the community of people that produce
   documents.  The current arrangement is that the REP develops some of
   its own tools, but it also depends on tools that are maintained by
   the IETF LLC.

   Reflecting that arrangement, we have the final composition of
   functions as shown in Figure 4.























Carpenter               Expires February 21, 2021              [Page 10]

Internet-Draft        Alternative RFC Editing Model          August 2020


                                  +------+
                                  | ISOC |
                                  +--+---+
                                     |
                                     | Oversight
                                     v
                               +-----+------+
  +-------------+ Participate  | RFC Series |
  |  Community  +------------->+ Advisory   |<------- RFC Series Advisor
  +-----+-------+              | WG         |         (RSA)
        ^                      +-----+------+
        |                            |
        | Provide Tools              | Strategy
        |                            v
  +-----+-------+                 +--+---+
  |    Tools    |     Contract(s) | IETF |
  | Maintenance +<----------------+ LLC  |
  +-----+-------+                 +--+---+
        |                            |
        +--Provide-Tools-------+     | Contract &
                               |     | Oversight
                               v     v
    +-------------+        +---+-----+---+
    | IETF Stream +------->+             +----->
    +-------------+   D    |             |
    +-------------+   o    |             |
    | IRTF Stream +---c--->+ RFC         +-----> R
    +-------------+   u    | Editing     |       F
    +-------------+   m    | and         |       C
    | IAB Stream  +---e--->+ Publication +-----> s
    +-------------+   n    |             |
    +-------------+   t    |             |
    | Independent +---s--->+             +----->
    +-------------+        +-------------+

                           Figure 4: Final Model

   This arrangement means that any dependencies the REP might have for
   tools need to be coordinated via the entity responsible for managing
   the maintenance of tooling.  The IETF LLC is ultimately responsible
   for ensuring that the tools maintenance function has processes for
   managing the requirements of the REP.  As with the REP oversight
   functions, this might also be delegated at the discretion of the IETF
   LLC.

   If meeting new requirements set by the IETF LLC require new or
   modified tooling, it is the responsibility of the REP to formulate
   requests regarding to tools to the Tools Maintenance function.



Carpenter               Expires February 21, 2021              [Page 11]

Internet-Draft        Alternative RFC Editing Model          August 2020


   Any problems arising from this arrangement will be raised with the
   IETF LLC as they pertain to meeting operational goals.

6.  Management of Individual Functions

   This model does not specify strong requirements on the management of
   any of the functions it describes.  It is expected that each function
   identified here will be managed in a manner appropriate to the
   function that it serves.

   Any choice by the IETF LLC to delegate oversight responsibility to a
   committee implies that the committee has adequate decision-making
   processes.  The IETF LLC is ultimately responsible and its processes
   for consultation with and accountability to the broader community
   will apply to delegated reponsibility.

   The choice of leadership for the RSAWG is important with a move to a
   system that lacks a single figurehead.  Two measures are suggested to
   mitigate the temptation for this leadership to become an effective
   replacement for the RSE position:

   o  The ISOC should appoint at least two co-chairs.  This is generally
      good practice for working groups as it provides redundancy in case
      of absence or conflict of interest.

   o  The ISOC should seek new chairs at regular intervals and seek to
      limit the period over which any one individual might hold a
      leadership position.

   These are suggestions to the ISOC only, not hard requirements.

   If the function of the REP is contracted to a single entity, it would
   be the responsibility of that entity to provide appropriate
   management.  That management would be expected to manage the workload
   involved in providing core REP functions like editing and
   publication, arranging and planning for changes in response to
   upcoming requirements, and reporting on status and performance.

   For the tools maintenance function, contracting of tools development
   and maintenance currently involves multiple entities.  Therefore, it
   might be necessary for the IETF LLC to contract for a role to manage
   coordination of tools development or maintenance.  Arranging for
   appropriate management, along with systems for establishing
   accountability to the community, enabling community contributions,
   and dealing with dispute or contention is left to the IETF LLC.






Carpenter               Expires February 21, 2021              [Page 12]

Internet-Draft        Alternative RFC Editing Model          August 2020


7.  Other Involved Entities

   Many documents involve actions for IANA that are processed in
   parallel with the REP processing.  These processes need to be
   documented, as for example in [RFC6359].

   This draft describes a model whereby the existing RFC Series Advisory
   Group (which serves at the pleasure of the RSE) has no future as it
   serves a role that does not exist in this model.  This group embodies
   a great deal of collected wisdom regarding the RFC Series.  It is
   this author's earnest hope that these individuals will continue to
   lend their efforts in the form of contributions to the development of
   strategy.

   This draft proposes that the RFC Series Oversight Committee (RSOC) be
   disbanded.  Many of the functions provided by the RSOC are now an
   IETF LLC responsibility in this model.  If the IETF LLC decides to
   form a committee, the experience of RSOC procedures and former
   personnel might be used as a resource.

8.  Role of the RFC Series Advisor

   This person will be a senior professional with deep knowledge of
   technical publishing.

   The RSA will operate by providing expert advice to the RSAWG, and if
   requested to the REP, on any relevant matters.  For example, the RSA
   might be consulted about proposed changes to the style guide, RFC
   formatting in general, web presence, copyright matters, or archiving
   policy.

   The RSA is expected to attend and facilitate all RSAWG meetings, and
   to participate in and facilitate RSAWG on-line discussions.

   Further, the RSA is expected to ensure that RSAWG consensus is well
   documented and communicated to the community, the LLC, and the REP.
   This may include document authorship.

   The RSA is expected to be a thought leader for improvements to the
   RFC Series, for developing vision and policy documents, and for
   establishing community consensus for them.

   The RSA will operate under a part-time professional services contract
   with the LLC, with performance review by the LLC in consultation with
   the RSAWG chairs.






Carpenter               Expires February 21, 2021              [Page 13]

Internet-Draft        Alternative RFC Editing Model          August 2020


9.  Changes from Version 2 of the RFC Model

   This document describes a structure that appears quite different from
   current practice.  This section addresses significant differences and
   similarities with the existing system.

9.1.  No RFC Series Editor

   This proposal does not describe a role for a RFC Series Editor.

   The functions previously served by this individual are devolved into
   several pieces.  The REP function is expanded to cover both RFC
   Production Center (RPC) and RFC Publisher as well as the operational
   management responsibilities formerly adopted by the RFC Series
   Editor.

   The responsibility for managing the evolution of the series is
   delegated to a consensus-based group rather than being vested in an
   individual.  Previous RFC Series Editors achieved much of the
   strategic and evolutionary functions of their role by building
   community consensus, so this aspect of the role is essentially
   transferred to the chairs of the RSAWG.  Expert input to the RSAWG
   will be provided by the RSA.

   Any responsibility for execution of RFC Series strategy that might
   have been the responsibility of a RFC Series Editor has been
   distributed: the IETF LLC is responsible for turning strategy into
   requests; the REP is responsible for executing these requests.  As
   the RPC (or publisher) was previously ultimately responsible for
   execution of any strategy, the functional difference is minimal.

   Moving away from a model where a single individual is charged with
   setting direction for the RFC Series is significant.  This proposal
   vests that control in a consensus-based body instead, which means
   that decisive action is likely no longer a feature of this system.
   As the emphasis of the group is on longer-term strategy, this is not
   anticipated to be a practical problem.  This further assumes that the
   required rate of change matches that of the recent past in that
   changes to the operation of the series will be not be extensive or
   rapid.

9.2.  No IAB Responsibility

   The Internet Architecture Board loses its responsibility for
   oversight of the RFC Series.  The managerial and administrative
   aspects are taken over by the LLC, and the strategic aspects by a
   community process based on the RSAWG.




Carpenter               Expires February 21, 2021              [Page 14]

Internet-Draft        Alternative RFC Editing Model          August 2020


   This is consistent with the disbanding of the RSOC.

9.3.  Preserved Aspects of Current Practice

   This document does not disrupt critical functions involved in RFC
   editing and publication.  There is general agreement that the
   continued publication of RFCs remains an important goal.  Disruptive
   changes to this part of the system would be counterproductive.

   This proposal combines the RFC Production Center and RFC Publisher
   functions.  These have been conjoined in practice for many years
   already and so this merely formalizes a standing arrangement.

9.4.  Motivating Principles

   The proposed structure is motivated by the following principles.

   o  Community ownership.  The community at large owns the outcomes of
      this process and so it needs to own the process too.

   o  Open participation.  The principle of open participation in
      standardization has been critical to success in the IETF.  That
      provides a template for participation and governance of this
      process in a wider context.

   o  Transparency.  Transparency is the most important part of ensuring
      that actors are accountable.  Avoiding decisions made in closed
      forums - or by individuals - ensures that the community is best
      able to understand and contribute to the operation of the system.

   o  Divestiture of responsibility.  The title of RFC Series Editor has
      in the past been held by individuals with a remarkably broad set
      of skills.  Rather than dictate that an individual with such
      diverse traits be found and selected, this design distributes that
      responsibility.  This allows for more flexibility and
      specialization.  Publishing expertise is not set aside, but will
      be provided instead by the RFC Series Advisor.

   o  Reducing the IAB's non-technical responsibilities to allow it to
      focus even more on the technical architecture of the Internet.

10.  Documentation Requirements

   At least the following documents need to be updated.

   o  The IAB Charter [RFC2850].  The IAB's responsibility for the RFC
      Editor and RFC Series is removed.




Carpenter               Expires February 21, 2021              [Page 15]

Internet-Draft        Alternative RFC Editing Model          August 2020


   o  The RFC Editor Model (Version 2) [RFC8728].  Numerous changes are
      needed as a direct consequence of the model described above.  More
      fundamentally, the model (or the following document) needs to set
      out basic principles of the RFC Series, such as:

      *  The RFC Series is the archival series that documents Internet
         technical specifications, descriptions, and commentaries,
         including general contributions from the Internet research and
         engineering community, as well as standards documents.  It also
         includes some organisational documents from the same community.

         +  "Archival" means that the documents must be available for
            the indefinite future in a form that is trusted by all
            parties.  In particular there must be no doubt as to the
            precise original text and diagrams, regardless of the format
            in which the documents are stored or displayed.  Errors or
            omissions detected after publication, and subsequent
            modifications or extensions of the document content, do not
            change the archived document itself.

      *  All RFCs are available free of charge to anyone via the
         Internet.  They may be freely translated in their entirety into
         any language.

      *  Request for Comments means Request for Comments.  There is an
         inherent modesty in calling our documents "requests for
         comments".  We get things wrong, we want comments, we want
         errata, we want operational feedback, and we want to go round
         that loop again.  This property is a useful counter-balance to
         any occurrence of groupthink in the community.

      *  RFCs come from various streams, i.e. originating organisations.

         +  Each stream has its own policy on change control, copyright,
            and patents, with the IETF Trust generally acting as a
            repository for intellectual property rights that are not
            retained by the authors.

         +  Each stream has full control of the technical content of its
            documents.The RFC Editor team has control of editorial
            matters, subject to review by the relevant stream and the
            document authors.  In particular, a badly written document
            may be returned to its stream for improvements if an
            abnormal amount of copy-editing is required.If an individual
            member of the RFC Editor team has personal comments on the
            technical content of a draft RFC, they must be handled in
            person, using the appropriate mechanism of the stream
            concerned, not as an RFC Editor matter.



Carpenter               Expires February 21, 2021              [Page 16]

Internet-Draft        Alternative RFC Editing Model          August 2020


         +  If the RFC Editor team believes that a draft RFC contains a
            serious technical flaw, which the stream declines to change,
            the RFC Editor cannot block the document indefinitely.  Note
            that there is more discussion of such disagreements in
            Section 4.3 of [RFC8728].

         +  New streams may in principle be created, subject to
            community agreement and guidelines to be defined.

         +  Defunct streams may be closed, subject to community
            agreement.

      *  The RFC Series is community property and must operate on behalf
         of the community as a whole.  By making the RSAWG an open
         group, the whole community is welcome to participate in its
         strategy formation.

   o  The RFC Series and RFC Editor [RFC8729].  This document also needs
      a major update.  Possibly it should be rolled into the previous
      one.  In any case, it needs to be refactored to account for the
      abolition of the Editor as a notional person rather than as a
      function (the REP) and the addition of the RSAWG and the RSA.

   The new model depends on the production of a document (or set of
   documents) that outlines the initial set of requirements for the
   operation of the REP.  Much of this already exists in the form of
   existing service agreements and the expectation is that these
   documents can be adapted.  These documents will become the
   resposibility of the IETF LLC.

   Over time, some of the material from service agreements and contract
   are expected to move to strategic documents maintained by the RSAWG.

10.1.  New RFC Stream

   There should be a fifth RFC stream, namely the RFC Editorial Stream,
   in which relevant documents (such as the two just mentioned, future
   updates of the Style Guide, and documents defining the RFC format)
   would be published.  This will avoid the current anomaly of such
   documents being published by the IAB.  A corresponding update of
   [RFC7841] will be needed.

11.  Errors and Omissions

   This is a draft.  At this stage, it is intended to just show the
   general outline of the model.  As details are filled in, everything
   here is liable to change.  There are likely many errors, omissions,
   and inconsistencies.



Carpenter               Expires February 21, 2021              [Page 17]

Internet-Draft        Alternative RFC Editing Model          August 2020


12.  Security Considerations

   Much of the success of systems like this can be attributed to the
   dilligent work of individuals who strive to resolve issues
   collaboratively.  Generally speaking, it is good to assume that this
   will continue.  However, this document does attempt to establish
   where authority lies for any particular decision in case of lapses or
   disagreements.

   This document aims to provide some measure of security against
   failure of any single person to execute their function in good faith.
   That doesn't mean that a malicious actor operating in any of the
   critical roles could not choose to be extremely disruptive.  In
   addition to some expectation of reasonableness, this system defines
   entities (often bodies) to whom each actor is answerable or who are
   empowered to resolve disputes.

13.  IANA Considerations

   This document makes no request of IANA.

14.  Acknowledgments

   Large portions of this draft have been copied, with permission, from
   [I-D.thomson-rfced-model].

   The name of the proposed new RFC stream was coined by Mike St Johns.

   This is not new thinking.  You might, if you were so inclined, find
   all of these concepts in emails or documents from other people.

15.  References

15.1.  Normative References

   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
              Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418,
              September 1998, <https://www.rfc-editor.org/info/rfc2418>.

   [RFC2850]  Internet Architecture Board and B. Carpenter, Ed.,
              "Charter of the Internet Architecture Board (IAB)",
              BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000,
              <https://www.rfc-editor.org/info/rfc2850>.








Carpenter               Expires February 21, 2021              [Page 18]

Internet-Draft        Alternative RFC Editing Model          August 2020


15.2.  Informative References

   [I-D.thomson-rfced-model]
              Thomson, M., "A Proposed Model for RFC Editing and
              Publication", draft-thomson-rfced-model-01 (work in
              progress), August 2020.

   [RFC6359]  Ginoza, S., Cotton, M., and A. Morris, "Datatracker
              Extensions to Include IANA and RFC Editor Processing
              Information", RFC 6359, DOI 10.17487/RFC6359, September
              2011, <https://www.rfc-editor.org/info/rfc6359>.

   [RFC7322]  Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
              DOI 10.17487/RFC7322, September 2014,
              <https://www.rfc-editor.org/info/rfc7322>.

   [RFC7841]  Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed.,
              "RFC Streams, Headers, and Boilerplates", RFC 7841,
              DOI 10.17487/RFC7841, May 2016,
              <https://www.rfc-editor.org/info/rfc7841>.

   [RFC8711]  Haberman, B., Hall, J., and J. Livingood, "Structure of
              the IETF Administrative Support Activity, Version 2.0",
              BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020,
              <https://www.rfc-editor.org/info/rfc8711>.

   [RFC8728]  Kolkman, O., Ed., Halpern, J., Ed., and R. Hinden, Ed.,
              "RFC Editor Model (Version 2)", RFC 8728,
              DOI 10.17487/RFC8728, February 2020,
              <https://www.rfc-editor.org/info/rfc8728>.

   [RFC8729]  Housley, R., Ed. and L. Daigle, Ed., "The RFC Series and
              RFC Editor", RFC 8729, DOI 10.17487/RFC8729, February
              2020, <https://www.rfc-editor.org/info/rfc8729>.

Author's Address

   Brian E. Carpenter
   The University of Auckland
   School of Computer Science
   PB 92019
   Auckland  1142
   New Zealand

   Email: brian.e.carpenter@gmail.com






Carpenter               Expires February 21, 2021              [Page 19]