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

Versions: 00

Network Working Group                                P. Saint-Andre, Ed.
Internet-Draft                                                   Mozilla
Obsoletes: RFC8728 (if approved)                          April 05, 2021
Intended status: Informational
Expires: October 7, 2021

                      RFC Editor Model (Version 3)


   This document describes Version 3 of the RFC Editor model.

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 October 7, 2021.

Copyright Notice

   Copyright (c) 2021 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.

Saint-Andre              Expires October 7, 2021                [Page 1]

Internet-Draft             RFC Editor Model v3                April 2021

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Overview of the Model . . . . . . . . . . . . . . . . . . . .   3
   4.  Ongoing Operation . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Policy Definition . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  Structure and Roles . . . . . . . . . . . . . . . . . . .   4
       5.1.1.  RFC Series Working Group (RSWG) . . . . . . . . . . .   4
       5.1.2.  RFC Series Approval Board (RSAB)  . . . . . . . . . .   5
     5.2.  Process . . . . . . . . . . . . . . . . . . . . . . . . .   6
       5.2.1.  Intent  . . . . . . . . . . . . . . . . . . . . . . .   6
       5.2.2.  Specifics . . . . . . . . . . . . . . . . . . . . . .   6
       5.2.3.  Appeals of RSAB Decisions . . . . . . . . . . . . . .   8
   6.  RFC Series Editor/Advisor (RSEA)  . . . . . . . . . . . . . .   8
     6.1.  RSEA Selection  . . . . . . . . . . . . . . . . . . . . .   8
     6.2.  RSEA Ongoing Performance Evaluation . . . . . . . . . . .   9
   7.  Changes from Version 2 of the RFC Editor Model  . . . . . . .   9
     7.1.  RFC Series Editor . . . . . . . . . . . . . . . . . . . .   9
     7.2.  RFC Series Oversight Committee (RSOC) . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
     9.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   NOTE NOTE NOTE This document is a work in progress.  Although it is
   intended to describe consensus forged in the RFCED-Future Program,
   many aspects are not yet settled; as a result, this document contains
   proposals and conjectures that do not yet have consensus.

   Documents in the Request for Comments (RFC) series have been
   continually published since 1969 [RFC8700].  The processes and
   organizational models for publication of these documents have changed
   significantly over the years.  Most recently, in 2009 [RFC5620]
   defined the RFC Editor Model (Version 1) and in 2012 [RFC6635]
   defined the RFC Editor Model (Version 2), since modified slightly in
   2020 by [RFC8728].

   In order to provide a sustainable basis for continued publication of
   the RFC series, this document describes Version 3 of the RFC Editor
   model, which divides the responsibilities for the RFC series among
   four primary functions: the IETF Administration LLC (IETF LLC), the

Saint-Andre              Expires October 7, 2021                [Page 2]

Internet-Draft             RFC Editor Model v3                April 2021

   RFC Series Working Group (RSWG), the RFC Series Approval Board
   (RSAB), and the RFC Publication Center (RPC).

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Overview of the Model

   Version 2 of the RFC Editor Model [RFC8728] specified a structure
   consisting of the RFC Series Editor, the RFC Production Center, and
   the RFC Publisher, with oversight provided by the RFC Series
   Oversight Committee (RSOC) on behalf of the Internet Architecture
   Board (IAB).

   Discussion within the RFCED-Future Program has led in the direction
   of a more consensus-oriented structure (similar in some respects to
   the structure of technical work within the IETF) that retains roles
   for specialized expertise in document editing and publication.

   Specifically, this document defines a structure in which ultimate
   authority lies with the IETF LLC, which is the corporate home for the
   Internet Engineering Task Force (IETF), the Internet Architecture
   Board (IAB), and the Internet Research Task Force (IRTF).

   The IETF LLC shall exercise oversight regarding ongoing operation of
   the final editorial and publication processes that lead to
   publication of documents in the RFC series.  As in Version 2, these
   processes are the responsibility of the RFC Production Center (RPC)

   The IETF LLC shall also provide a structure for defining policies
   regarding the RFC series.  This document specifies such a structure
   through a new RFC Series Working Group (RSWG), which shall submit its
   policy proposals to a new RFC Series Approval Board (RSAB).

4.  Ongoing Operation

   Continuing publication of RFCs shall be handled by the RFC Production
   Center (RPC) function in accordance with current policies in force or
   future policies defined as specified in the next section of this

Saint-Andre              Expires October 7, 2021                [Page 3]

Internet-Draft             RFC Editor Model v3                April 2021

   This document does not specify the exact relationship between the
   IETF LLC and the RPC function; for example, the RPC function could be
   provided by a separate corporate entity under contract to the IETF
   LLC, it could be performed by employees of the IETF LLC, or the IETF
   LLC could work with independent contractors for some or all aspects
   of the RPC function.  The exact relationship is a matter for the IETF
   LLC and its Executive Director to determine.

   The IETF LLC has authority over negotiating performance targets for
   the RPC and also has responsibility for 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 RPC
   can request that the IETF LLC look into 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.

5.  Policy Definition

   Policies governing the RFC series as a whole shall be defined in the
   open through proposals that are generated by and discussed within the
   RFC Series Working Group (RSWG) and then approved by the RFC Series
   Approval Board (RSAB).

   Policies under the purview of the RSWG and RSAB might include but are
   not necessarily limited to document formats, tooling, processes for
   publication and dissemination of RFCs, and overall management of the
   RFC series.

5.1.  Structure and Roles

5.1.1.  RFC Series Working Group (RSWG)

   The RFC Series Working Group (RSWG) shall formulate proposals
   regarding policies governing the RFC series.  The intent is that the
   RSWG operate in a way similar to working groups in the IETF and
   research groups in the IRTF.  Therefore, all RSWG meetings shall be
   open to any participant, subject to intellectual property policies
   which must be consistent with those of the IETF [RFC8179].  At the
   initial formation of the RSWG, all discussions shall take place on an
   open mailing list, and anyone is welcome to participate in
   discussions on that list.  The RSWG may decide by rough consensus to
   use additional forms of communication (e.g., GitHub as specified in
   [RFC8874]) that are consistent with [RFC2418].  The RSWG shall
   conform itself to an anti-harassment policy consistent with [RFC7154]
   and [RFC7776].

Saint-Andre              Expires October 7, 2021                [Page 4]

Internet-Draft             RFC Editor Model v3                April 2021

   The IETF Chair and the Independent Submissions Editor shall each
   appoint and oversee a co-chair of the RSWG.

   All interested parties are welcome to participate in the RSWG.  This
   includes participants in the IETF and IRTF, IAB and IESG members, RFC
   authors, individuals who use RFCs in procurement decisions, and the
   like.  The IETF LLC Board members, staff, and the Executive Director
   are invited to participate as community members in the RSWG to the
   extent permitted by any relevant IETF LLC policies.  Members of the
   RSAB are also expected to participate actively in the RSWG so that
   they are fully aware of proposals early in the policy definition

5.1.2.  RFC Series Approval Board (RSAB)

   The RFC Series Approval Board (RSAB) shall act as the approving body
   for proposals generated within the RSWG.  The sole function of RSAB
   is to review policy proposals generated by the RSWG; it shall have no
   independent authority to formulate policy on its own.

   The voting members of the RSAB shall be as follows:

   o  The IETF Chair, representing the IETF stream

   o  The IAB Chair, representing the IAB stream

   o  The IRTF Chair, representing the IRTF stream

   o  The Independent Submissions Editor [RFC8730]

   o  The RFC Series Editor/Advisor

   OPEN ISSUE: Discussion continues within the RFCED-Future Program
   regarding the number of members on the RSAB (e.g., whether each
   stream shall have one representative, whether streams that generate
   more RFCs such as the IETF stream shall have more member, etc.) as
   well as the individuals who are voting members (e.g., IETF Chair or
   someone appointed by the IETF Chair, the RFC Series Editor/Advisor,

   The RSAB shall choose a chair from among its members using a method
   to be determined by the RSAB.  The RSAB is expected to operate via
   email and through any necessary tooling.  THE RSAB shall keep a
   public record of its proceedings, including minutes of all meetings
   and a record of all decisions.

Saint-Andre              Expires October 7, 2021                [Page 5]

Internet-Draft             RFC Editor Model v3                April 2021

5.2.  Process

5.2.1.  Intent

   The intent is to provide an open forum by which policies related to
   the RFC series are defined and evolved.  The general expectation is
   that all interested parties will participate in the RSWG, and that
   only under extreme circumstances should RSAB members need to hold
   "CONCERN" positions as described below.

   Because policy issues can be difficult and contentious, RSWG
   participants and RSAB members are strongly encouraged to work
   together in a spirit of good faith and mutual understanding to
   achieve rough consensus (see [RFC7282]).  In particular, RSWG members
   are encouraged to take RSAB concerns seriously, and RSAB members are
   encouraged to clearly express their concerns early in the process and
   to be responsive to the community.  All parties are encouraged to
   respect the value of each stream and the long term health and
   viability of the RFC series.

   This process is intended to be one of continuous consultation.  RSAB
   members should consult with their constituent stakeholders (e.g.,
   authors, editors, tool developers, and consumers of RFCs) on an
   ongoing basis, so that when the time comes to consider a proposal,
   there should be no surprises.  Appointing bodies are expected to
   establish whatever processes they deem appropriate to facilitate this

5.2.2.  Specifics

   The following process shall be used to formulate or modify processes
   related to the RFC series:

   1.  A individual participant in the RSWG generates a proposal in the
       form of an Internet-Draft.

   2.  If there is sufficient interest in the proposal, RSWG may adopt
       the proposal as a draft proposal of the RSWG, much the same way a
       working group of the IETF or IRTF would.

   3.  The RSWG shall then further develop the proposal.  Members of the
       RSAB are expected to participate in discussion relating to such

   4.  At some point, if the RSWG chairs believe there may be rough
       consensus for the proposal to advance, they will issue a working
       group last call.

Saint-Andre              Expires October 7, 2021                [Page 6]

Internet-Draft             RFC Editor Model v3                April 2021

   5.  After a suitable period of time, the RSWG chairs will determine
       whether rough consensus for the proposal exists.  If comments
       have been received and substantial changes have been made, it is
       expected that additional last calls may be necessary.

   6.  Once consensus is established in the RSWG, the chairs shall issue
       a community call for comments.  Should substantial comments be
       received, the RSWG will again consider those comments and make
       revisions as they see fit.  At this same time, the RSAB will
       consider the proposal.  OPEN ISSUE: specify what counts as a
       "community call for consensus".

   7.  Should substantial changes be made, additional community calls
       for comment should be issued, and again comments considered.

   8.  Once all comments have been been addressed, the RSWG chairs will
       submit the proposal to the RSAB for its consideration.

   9.  Within a reasonable period of time, the RSAB will then poll on
       the proposal.  Positions may be as follows: * "YES": the proposal
       should be approved * "CONCERN": the proposal raises substantial
       concerns that must be addressed.  * "RECUSE": the person holding
       the position has a conflict of interest.

   Anyone holding a "CONCERN" position MUST explain their concern to the
   community in detail.  The explanation may or may not be actionable.

   A CONCERN may be made for two reasons:

   o  The proposal represents a serious problem for the group a
      particular member represents.

   o  The member believes that the proposal would cause serious harm to
      the overall series, including harm to the long term health and
      viability of the series.

   No CONCERN should ever come as a surprise to the RSWG.

   1.  If a CONCERN exists, discussion will take place within the RSWG.
       Again, all RSAB members MUST participate.

   2.  If all CONCERN positions are addressed, then the proposal is
       approved.  Again, if substantial changes have been made, an
       additional call for community input should be made.

   3.  If, after a suitable period of time, any CONCERN positions
       remain, a formal vote of the RSAB is taken.  If a majority of
       RSAB members vote to approve, the proposal is approved.

Saint-Andre              Expires October 7, 2021                [Page 7]

Internet-Draft             RFC Editor Model v3                April 2021

       Otherwise, it is returned to the RSWG.  In the case of a tie, the
       proposal is approved.

   4.  When a proposal is approved, a notification is sent to the
       community, and the document enters the queue for publication as
       an RFC.

   OPEN ISSUE: In which stream [RFC8729] are these documents published?
   Is a new stream (e.g., the "Editorial Stream") needed?

5.2.3.  Appeals of RSAB Decisions

   Appeals of RSAB decisions may only be made based on process failures,
   and not on the substance of a proposal.  These appeals SHALL be made
   to the ISOC Board of Trustees within thirty days of the RSAB
   decision.  The ISOC Board of Trusteers MAY decide only whether a
   process failure occurred, and what if any corrective action should
   take place.

6.  RFC Series Editor/Advisor (RSEA)

   OPEN ISSUE: Discussion continues within the RFCED-Future Program
   regarding the roles and responsibilities of an expert in technical
   publication processes.  To retain flexibility (e.g., as to whether
   this individual plays more of an advisory role or more of a singular
   leadership role), this document temporarily refers to the individual
   as the "RFC Series Editor/Advisor" ("RSEA").

   The RFC Series Editor/Advisor (RSEA) shall be a senior professional
   with deep knowledge of technical publishing.

   The primary responsibilities of the RSEA are as follows:

   o  Provide expert advice regarding policy proposals within the RSWG.

   o  Serve as a voting member on the RSAB (see OPEN ISSUE above).

   o  If requested, provide expert advice to the RPC and IETF LLC.

   Matters on which the RSEA might be consulted could include proposed
   changes to the RFC style guide, RFC formatting in general, web
   presence, copyright matters, and archiving policy.

6.1.  RSEA Selection

   The RSEA will be selected by a committee formed by the Executive
   Director of the IETF LLC, taking into account the role definition [1]
   and any detailed job description defined by the relevant parties

Saint-Andre              Expires October 7, 2021                [Page 8]

Internet-Draft             RFC Editor Model v3                April 2021

   (e.g., the Executive Director, other RSAB members, or RSWG chairs).
   The search committee may ask others to take part in the selection
   process in confidence.  The initial length of service shall be for
   one year, but then further extensions will be for three to five

6.2.  RSEA Ongoing Performance Evaluation

   Periodically, the Executive Director will send out to the community a
   call for input on the performance of the RSEA.  The evaluation will
   be based on criteria specified in the role definition.  Criteria
   could include matters such as the following:

   o  Was the RSEA an active participant in RSWG/RSAB discussions and

   o  Did the RSEA provide useful advice to the RSWG and RPC?

   o  Did the RSEA exercise good judgment in RSAB decision making?

   o  Was the RSEA effective in advising the community on policy

   The Executive Director will review the feedback, consulting with
   stream manager representatives, and then produce a recommendation to
   the IETF LLC Board.  The LLC will then make a decision, taking into
   account the Executive Director's recommendation.

   Whether the RSEA role is structured as a contractual or employee
   relationship is a matter for the IETF LLC and its Executive Director
   to determine.

7.  Changes from Version 2 of the RFC Editor Model

7.1.  RFC Series Editor

   The RSWG and RSAB together provide a public process by which policies
   for the RFC series can be defined.  It is expected that these bodies
   will therefore cover some of the responsibilities of the RFC Series
   Editor under Version 2.

7.2.  RFC Series Oversight Committee (RSOC)

   In practice, the relationships and lines of authority and
   responsibility between the IAB, RSOC, and RSE have proved unwieldy
   and somewhat opaque.  To overcome some of these issues, this document
   dispenses with the RSOC.

Saint-Andre              Expires October 7, 2021                [Page 9]

Internet-Draft             RFC Editor Model v3                April 2021

8.  IANA Considerations

   This document has no actions for IANA.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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

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

   [RFC6635]  Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor
              Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June
              2012, <https://www.rfc-editor.org/info/rfc6635>.

   [RFC7154]  Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54,
              RFC 7154, DOI 10.17487/RFC7154, March 2014,

   [RFC7282]  Resnick, P., "On Consensus and Humming in the IETF",
              RFC 7282, DOI 10.17487/RFC7282, June 2014,

   [RFC7776]  Resnick, P. and A. Farrel, "IETF Anti-Harassment
              Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March
              2016, <https://www.rfc-editor.org/info/rfc7776>.

   [RFC8179]  Bradner, S. and J. Contreras, "Intellectual Property
              Rights in IETF Technology", BCP 79, RFC 8179,
              DOI 10.17487/RFC8179, May 2017,

Saint-Andre              Expires October 7, 2021               [Page 10]

Internet-Draft             RFC Editor Model v3                April 2021

   [RFC8700]  Flanagan, H., Ed., "Fifty Years of RFCs", RFC 8700,
              DOI 10.17487/RFC8700, December 2019,

   [RFC8728]  Kolkman, O., Ed., Halpern, J., Ed., and R. Hinden, Ed.,
              "RFC Editor Model (Version 2)", RFC 8728,
              DOI 10.17487/RFC8728, February 2020,

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

   [RFC8730]  Brownlee, N., Ed. and B. Hinden, Ed., "Independent
              Submission Editor Model", RFC 8730, DOI 10.17487/RFC8730,
              February 2020, <https://www.rfc-editor.org/info/rfc8730>.

   [RFC8874]  Thomson, M. and B. Stark, "Working Group GitHub Usage
              Guidance", RFC 8874, DOI 10.17487/RFC8874, August 2020,

9.3.  URIs

   [1] https://github.com/intarchboard/program-rfced-future/blob/master/


   Portions of this document were borrowed from [RFC5620], [RFC6635],
   [RFC8728], and earlier proposals within the RFCED-Future Program by
   Martin Thomson, Brian Carpenter, and Michael StJohns.  Thanks also
   for proposed text from Eliot Lear, Brian Rosen, and other
   participants yet to be mentioned.  (TODO: make this complete.)

Author's Address

   Peter Saint-Andre (editor)

   Email: stpeter@jabber.org

Saint-Andre              Expires October 7, 2021               [Page 11]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/