RFC 8729

The RFC Series and RFC Editor

📅 published February 2020, from ietf

RFC 8729: The RFC Series and RFC Editor 🎀

Okay bestie, the title block first 💅 This is RFC 8729, titled "The RFC Series and RFC Editor." Russ Housley and Leslie Daigle are the editors, and it comes from the Internet Architecture Board (IAB). It's Informational, so it's published for the record and isn't a Standards Track spec. It's dated February 2020 and has ISSN 2070-1721. It obsoletes RFC 4844, and there's no Updates line, so it doesn't update anything else. 🦋

Abstract ✨

This doc lays out a framework for the RFC Series and an RFC Editor function. The whole point is to bake in organized community involvement and accountability, which the Internet technical community has basically needed as it's grown. That way the RFC Series can keep doing its job 🫶 This document obsoletes RFC 4844.

Status of This Memo 🧐

Quick reality check: this isn't an Internet Standards Track specification. It's published for informational purposes. 📚

This document is a product of the Internet Architecture Board (IAB). It's info the IAB thinks is valuable enough to keep on permanent record, and it represents the consensus of the IAB. Documents the IAB approves for publication are not candidates for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details 🙈

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8729.

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), as they stand on the publication date. Please read those carefully, because they spell out your rights and restrictions for this document. Not skimming the legal stuff is a whole vibe 🧚

Table of Contents 🍓

   1.  Introduction
   2.  RFC Series Mission
   3.  Roles and Responsibilities
     3.1.  RFC Editor
     3.2.  IAB
     3.3.  Operational Oversight
     3.4.  Policy Oversight
   4.  Framework
     4.1.  Document Approval
       4.1.1.  Definition
       4.1.2.  Operational Implementation
       4.1.3.  Process Change
       4.1.4.  Existing Approval Process Documents
     4.2.  Editing, Processing, and Publication of Documents
       4.2.1.  Definition
       4.2.2.  Operational Implementation
       4.2.3.  Process Change
       4.2.4.  Existing Process Documents
     4.3.  Archiving, Indexing, and Accessibility
       4.3.1.  Definition
       4.3.2.  Operational Implementation
       4.3.3.  Process Change
       4.3.4.  Existing Process Documents
     4.4.  Series-Wide Guidelines and Rules
       4.4.1.  Definition
       4.4.2.  Operational Implementation
       4.4.3.  Process Change
       4.4.4.  Existing Process Documents
   5.  RFC Streams
     5.1.  RFC Approval Processes
       5.1.1.  IETF Document Stream
       5.1.2.  IAB Document Stream
       5.1.3.  IRTF Document Stream
       5.1.4.  Independent Submission Stream
     5.2.  RFC Technical Publication Requirements
       5.2.1.  IETF Documents
       5.2.2.  IAB Documents
       5.2.3.  IRTF Documents
       5.2.4.  Independent Submissions
   6.  Security Considerations
   7.  Changes Since RFC 4844
   8.  Informative References
   Appendix A.  A Retrospective of IAB Charters and RFC Editor
     A.1.  1992
     A.2.  1994
     A.3.  2000
   IAB Members at the Time of Approval
   Authors' Addresses

1. Introduction 🌸

The first Request for Comments (RFC) document was published in April of 1969, as part of the effort to design and build what we now know as the Internet. Ever since, the RFC Series has been the archival series for documenting Internet technical specifications. That includes general contributions from the Internet research and engineering community, plus standards documents. Iconic history 👑

As described in the history of the first 30 years of RFCs ([RFC2555]), the RFC Series was created to capture the research and engineering thought behind the design of (what we now know as) the Internet. When the Internet Engineering Task Force (IETF) got formalized to handle discussion and documentation of Internet standards, IETF documents became a big part of the RFC Series. Not the whole thing, though 🫶

The IETF has grown up and celebrated its own 30 years of history, and its requirements for archival publication of its output have changed and gotten more rigorous. The biggest change is that the IETF must be able to define adjustments to its publication processes, based on its own open consensus discussion processes and leadership directions, and then implement them. ✨

Meanwhile, the Internet engineering and research community as a whole has grown and now needs more openness and accountability from every organization that supports it. More than ever, this community needs an RFC Series that is supported, both operationally and in terms of its principles, so there's a balance of:

  • expert implementation;
  • clear management and direction -- for operations and evolution across the whole RFC Series (whether originating in the IETF or not); and
  • appropriate community input into and review of activities.

Honestly, there's been some confusion, and sometimes tension, over where and how to address RFC issues that are particular to contributing groups (e.g., the IETF, the Internet Architecture Board (IAB), or independent individuals). It wasn't always clear where community involvement should happen versus where the RFC Editor is in control. Depending on the issue, there might be more or less involvement from the IAB, the Internet Engineering Steering Group (IESG), or the community at large. There are similar issues with RFC Series-wide issues: where do you discuss and resolve them in a way that's balanced across the whole series? 🙃

For example, there have been discussions about Intellectual Property Rights (IPR) for IETF-generated documents. But it's not clear when or how to pull out the parts of those discussions that matter to the rest of the RFC Series. Discussions about labeling (of RFCs in general, IETF documents in particular, or some combination) generally have to apply to the whole RFC Series or not at all. Without an agreed-on framework for managing the RFC Series, it's really hard to have those talks without getting polarized. Either the IETF is dictating the reality of the rest of the RFC Series, or the RFC Series is putting undue restrictions on IETF documents. Nobody wants that drama 💀

As part of its charter (see Appendix A), the IAB has a responsibility for the RFC Editor. Acknowledging the IETF's needs and the evolving needs of the general Internet engineering and research community, the IAB backs a future for the RFC Series that keeps meeting its original mandate: being the archival series for the technical research and engineering documentation that describes the Internet. 🧚

So this document gives the framework for the RFC Series and an RFC Editor function. The specific goal is making sure the RFC Series is maintained and supported in ways that match its stated purpose and the realities of today's Internet research and engineering community. The framework describes the existing "streams" of RFCs, maps out the existing process documents that already define the implementation, and gives clear direction on how to evolve this framework and its supporting pieces through discussion and future document revisions. 🦋

Specifically, this document gives a short charter for the RFC Series. It describes the roles of the RFC Editor, the IAB, and the IETF Administrative Support Activity (IASA) in a framework for managing the RFC Series. It also talks about the streams of input to the RFC Series from the different constituencies it serves. 💖

2. RFC Series Mission 💅

The RFC Series is the archival series dedicated to documenting Internet technical specifications. That includes general contributions from the Internet research and engineering community, plus standards documents.

RFCs are available free of charge to anyone via the Internet. Free docs for everyone, periodt 🌈

3. Roles and Responsibilities 🎀

This document sets up the framework for supporting the RFC Series mission. So this section goes over the updated roles and responsibilities of the entities that have had involvement, and will keep having involvement, in supporting that mission. 🫶

3.1. RFC Editor 📝

Originally, one single person acted as editor of the RFC Series, and that person was the RFC Editor. The job grew, though, and now it takes an organized group of experts, so there are RFC Editors, or an RFC Editor organization. Down the line, several organizations might work together to do the work the RFC Series needs. To keep things simple, and without trying to predict how the role might get split up among them, this document calls that whole group of experts and organizations the "RFC Editor." 🧁

The RFC Editor is an expert technical editor and series editor, and acts to support the mission of the RFC Series. That makes the RFC Editor the implementer who handles the editorial management of the RFC Series, following the defined processes. The RFC Editor is also expected to be the expert and prime mover in discussions about the policies for editing, publishing, and archiving RFCs. Main character energy for real 👑

3.2. IAB 🌷

In this model, the IAB's job is to make sure the RFC Series mission is being fulfilled properly for the whole community it was created for. The IAB doesn't have comprehensive publishing or editorial expertise as an organization, so its focus is different. The IAB makes sure principles are met, that the right bodies and communities are kept informed and consulted, and that the RFC Editor has what it needs to carry out what's in its mandate. Supportive bestie energy 🫶

It's the IAB's responsibility to approve the appointment of the RFC Editor, and to approve the general policy the RFC Editor follows. 💜

3.3. Operational Oversight ✨

The IETF Administration Limited Liability Company (IETF LLC) is part of the IETF Administrative Support Activity (IASA) 🏢, and it handles the admin and money stuff for the IETF, the IAB, and the Internet Research Task Force (IRTF) [RFC8711]. The IASA is in charge of funding the RFC Editor 💰. Through the IETF Executive Director, the IASA also provides contractual and financial oversight of the RFC Editor 📋. Then there's the RFC Series Oversight Committee (RSOC) 👀, which acts with authority delegated from the IAB, as described in Section 3.1 of [RFC8728]. Its job is making sure the RFC Series is run in a transparent and accountable manner, and that includes designing and running the RFC Series Editor selection process 🗳️.

The IETF Executive Director works with the IAB to find suitable persons or entities for the RFC Production Center and RFC Publisher roles, as defined in [RFC8728] 🔍.

The IETF Executive Director sets up contractual agreements with the selected persons or entities so they can do the work that meets the technical publication requirements for the various RFC input streams (see Section 5.2) 🤝. The IETF Executive Director may also define extra operational requirements and policies for management purposes, so the requirements from the different communities get met 💼.

The IETF Administration LLC Board approves the budget for running the RFC Editor activity, and the IETF Executive Director sets up and manages the operational agreements for it 📊. Budget and paperwork, bestie, it's all connected 🎀.

3.4. Policy Oversight 👑

The IAB keeps an eye on whether the policies in force are working and being carried out properly 👀. The goal is making sure the RFC Editor activity covers the editorial management and publication needs referenced in this document 📚. If there's serious non-conformance, the IAB can step in, either on its own initiative or when the IETF Administration LLC Board asks. It may then require the IETF Executive Director to vary or terminate and renegotiate the arrangements for the RFC Editor activity 🚨. Accountability era, periodt 💅.

4. Framework 🧩

With the RFC Series mission outlined above, this document lays out a framework for supporting:

  • the operational implementation of the RFC Series,

based on:

  • public process and definition documents,

for which there are:

  • clear responsibilities and mechanisms for update and change.

Generally speaking, the RFC Editor is responsible for the operational implementation of the RFC Series 🛠️. As outlined in Section 3.3, the IETF Executive Director provides oversight of this operational role 👑.

The process and definition documents are detailed below, including who is responsible for each individual process document (maintenance and update) 📝. The RFC Editor works with the appropriate community to make sure the process documents reflect current requirements 🔄. The IAB is charged with verifying that appropriate community input has been sought, and that any changes properly account for community requirements ✅.

There are three categories of activity, plus a fourth category of series-wide rules and guidelines. They're all there for implementing the RFC Series so it can support its mission 🌈:

  • Approval of documents.
  • Editing, processing, and publication of documents.
  • Archiving and indexing the documents and making them accessible.
  • Series rules and guidelines.

4.1. Document Approval 🦋

The RFC Series mission implicitly requires that documents be reviewed and approved for acceptance into the series 🔎.

4.1.1. Definition

Section 5.1 describes the different streams of documents that are put to the RFC Editor for publication as RFCs today 🌊. There may be general policies for approving documents as RFCs (to keep the RFC Series coherent), and there are also policies defined for approving documents in each stream 🧵. Generally speaking, there is a different approving body for each stream. The current definitions are catalogued in Section 5.1 📚.

4.1.2. Operational Implementation

Each stream has its own documented approval process 📜. The RFC Editor is responsible for approving documents in one of the streams (Independent Submission stream, see Section 5.1.4) 🙌. It also works with the other approving bodies to make sure approved documents pass smoothly into the next phases, all the way to publication and archiving as an RFC 🚀.

4.1.3. Process Change

From time to time, it may be necessary to change the approval processes for any given stream, or even to add or remove streams 🔀. This can happen when the RFC Editor, the IAB, the body responsible for a given stream, or the community decides there are issues to be resolved, either for RFC approval in general or for per-stream approval processes 🧐.

In this framework, the general approach is that the IAB works with the RFC Editor and other parties to get community input, and it verifies that any changes properly account for community requirements 🫶.

4.1.4. Existing Approval Process Documents

The existing documents describing the approval processes for each stream are detailed in Section 5.1 📖.

4.2. Editing, Processing, and Publication of Documents ✏️

Producing and maintaining a coherent, well-edited document series takes specialized skills and subject matter expertise 🧠. That's the domain of the RFC Editor. Still, the community served by the RFC Series, and the communities served by the individual streams of RFCs, have requirements that help define what the series is like 💖.

4.2.1. Definition

General and stream-specific requirements for the RFC Series are documented in community-approved documents (catalogued in Section 5.2 below) 🗂️.

Any specific interfaces, numbers, or concrete values needed to make the requirements operational are the subject of agreements between the IASA and the RFC Editor (for example, contracts, statements of work, service level agreements, and so on) 📑.

4.2.2. Operational Implementation

The RFC Editor is responsible for making sure that editing, processing, and publication of RFCs are carried out in a way that's consistent with the requirements laid out in the appropriate documents ✨. The RFC Editor works with the IASA to provide regular reporting and feedback on these operations 📈.

4.2.3. Process Change

From time to time, it may be necessary to change the requirements for any given stream, or for the RFC Series in general 🔁. This can happen when the RFC Editor, the IAB, the approval body for a given stream, or the community decides there are issues to be resolved, either for RFCs in general or for per-stream requirements 🫠.

In this model, the general approach is that the IAB works with the RFC Editor to get community input, and it approves changes by validating appropriate consideration of community requirements 💅.

4.2.4. Existing Process Documents

Documents describing existing requirements for the streams are detailed in Section 5.2 📚.

4.3. Archiving, Indexing, and Accessibility 🗄️

Archiving, indexing, and making the RFC Series accessible can be informed by specific subject matter expertise in general document series editing 🧑‍🏫. It's also important that they're informed by requirements from the whole community 🌍. As long as the RFC Series is to stay coherent, there should be uniform archiving and indexing of RFCs across all streams, plus a common method of accessing the resulting documents 🔗.

4.3.1. Definition

In principle, there should be a community consensus document describing the archiving, indexing, and accessibility requirements for the RFC Series 📃. In practice, we continue with the archive as built by the capable RFC Editors since the series' inception 🏛️.

Any specific concrete requirements for the archive, index, and accessibility operations are the subject of agreements between the IASA and the RFC Editor (for example, contracts, statements of work, service level agreements, and so on) 🤝.

4.3.2. Operational Implementation

The RFC Editor is responsible for making sure that the RFC archive and index are maintained appropriately, and that the resulting documents are made available to anybody who wants to access them via the Internet 🌐. The RFC Editor works with the IASA for regular reporting and feedback 📊.

4.3.3. Process Change

Should there be a community move to propose changes to the requirements for the RFC archive, the index, or accessibility, the IAB works with the RFC Editor to get community input, and it approves changes by validating appropriate consideration of community requirements 🙏.

4.3.4. Existing Process Documents

There are no applicable process documents 🤷‍♀️.

4.4. Series-Wide Guidelines and Rules 🎀

The RFC Series style and content can be shaped by subject matter expertise in document series editing ✍️. They're also informed by requirements from the using community 👥. As long as the RFC Series is to stay coherent, there should be uniform style and content for RFCs across all streams. That includes, but isn't limited to, acceptable language, use of references, and copyright rules ⚖️.

4.4.1. Definition

In principle, there should be a community consensus document (or set of documents) describing the content requirements for the RFC Series 🧾. In practice, some do exist, though some need reviewing, and more may be needed over time ⏳.

4.4.2. Operational Implementation

The RFC Editor is responsible for making sure the RFC Series guidelines are upheld within the RFC Series 🛡️.

4.4.3. Process Change

When additions or changes are needed to series-wide definitions, the IAB works with the RFC Editor and stream stakeholders to get community input and review 🗣️. The IAB approves changes by validating appropriate consideration of community requirements 💜.

4.4.4. Existing Process Documents

Existing series-wide rules and guidelines documents include:

5. RFC Streams 🌊

Various contributors provide input to the RFC Series 🙌. These contributors come from several different communities, and each has its own defined process for approving documents that will be published by the RFC Editor 🧑‍🤝‍🧑. This is nothing new. However, over time the various communities and document requirements have grown and separated 🌱. To promote harmony when discussing the collective set of requirements, it's useful to recognize each one in its own space, and they're referred to here as "streams" 🫧.

Note that by identifying separate streams, there is no intention of dividing them or undermining their management as one series 🚫💔. It's actually the opposite! By clarifying the constituent parts, it's easier to make them work together without the friction that sometimes arises when discussing various requirements 💞.

The subsections below identify the streams that exist today. There is no immediate expectation of new streams being created, and it is preferable that new streams NOT be created 🙅‍♀️. Creation of streams and all policies surrounding general changes to the RFC Series are discussed above in Section 4 🔙.

5.1. RFC Approval Processes 💅

Okay so, every stream's approval process gets defined by the community that runs that stream 🫶. The IAB is the one checking that the right community input was actually asked for, and that the changes fit the RFC Series mission and this whole framework 👑.

The RFC Editor is expected to publish every document handed over after proper review and approval in one of the identified streams ✨.

5.1.1. IETF Document Stream 🎀

The IETF document stream covers IETF WG documents, plus "individual submissions" sponsored by an IESG area director 💖. Any document being published as part of the IETF standards process must follow this stream -- no other stream can approve Standards-Track RFCs or Best Current Practice (BCP) RFCs 🔥. It's the only lane for those, no cap.

Approval of documents in the IETF stream is defined by

  • the IETF standards process [RFC2026] (and its successors).
  • the IESG process for sponsoring individual submissions [SPONSOR].

Changes to the approval process for this stream are made by updating the IETF standards process documents 💜.

5.1.2. IAB Document Stream 🌸

The IAB defines the processes by which it approves documents in its stream. Consistent with the above, any documents the IAB wants to publish as part of the IETF Standards Track (Standards or BCPs) are subject to the approval processes referred to in Section 5.1.1 🧚.

The review and approval process for documents in the IAB stream is described in

  • the IAB process for review and approval of its documents [RFC4845].

5.1.3. IRTF Document Stream 🌈

The IRTF is chartered as an activity of the IAB. With the approval of the IAB, the IRTF may publish and update a process for publication of its own, non-IETF Standards-Track, documents 🦋.

The review and approval process for documents in the IRTF stream is described in

  • IRTF Research Group RFCs [RFC5743].

5.1.4. Independent Submission Stream 🍓

The RFC Series has always served a broader Internet technical community than the IETF, bestie 🥹. The "Independent Submission" stream exists to provide review and (possible) approval of documents that are outside the scope of the streams above ✨.

Generally speaking, approval of documents in this stream falls under the purview of the RFC Editor, and the RFC Editor seeks input to its review from the IESG 💅.

The process for reviewing and approving documents in the Independent Submission stream is defined by

  • Procedures for Rights Handling in the RFC Independent Submission Stream [RFC5744],
  • Independent Submission Editor Model [RFC8730],
  • Independent Submissions to the RFC Editor [RFC4846],
  • The IESG and RFC Editor Documents: Procedures [RFC5742].

5.2. RFC Technical Publication Requirements 🛠️

The Internet engineering and research community has not only grown, it's gotten more diverse, and sometimes more demanding 😭. The IETF, as a standards-developing organization, has publication requirements that go way beyond those of an academic journal. The IAB doesn't have the same interdependence with IANA assignments that the IETF stream does 🙈. So there's a need to both codify the publishing requirements of each stream, and try to harmonize them as much as is reasonable.

So it's expected that the community behind each document stream will outline their technical publication requirements 📝.

As part of the RFC Editor oversight, the IAB must agree that the requirements are consistent with and implementable as part of the RFC Editor activity 👑.

5.2.1. IETF Documents 💜

The requirements for this stream are defined in [RFC4714].

5.2.2. IAB Documents 🦋

Although they were developed for the IETF standards process, the IAB has identified applicable requirements in [RFC4714] for its stream. On top of that, procedures related to IPR for the IAB stream are captured in [RFC5745] ✨.

If the IAB elects to define other requirements, they should deviate minimally from those (in an effort to keep the collective technical publication requirements reasonably managed by one technical publisher) 🫶.

5.2.3. IRTF Documents 🌸

The IRTF has identified applicable requirements in [RFC5743] for its stream 🌈.

If the IRTF elects to define other requirements, they should deviate minimally from those (in an effort to keep the collective technical publication requirements reasonably managed by one technical publisher) 🧚.

5.2.4. Independent Submissions 🍓

Procedures and processes for the Independent Stream are described in [RFC4846] and [RFC8730] 💅.

Although they were developed for the IETF standards process, the RFC Editor has identified applicable requirements in [RFC4714] for the Independent Submissions stream. Also, procedures related to IPR for the independent submissions stream are captured in [RFC5744] 🎀.

If the RFC Editor elects to define other requirements, they should deviate minimally from those (in an effort to keep the collective technical publication requirements reasonably managed by one technical publisher) 💖.

6. Security Considerations 🚨

Okay, this section is SERIOUS, bestie 😭💀 The processes for publishing documents must prevent the introduction of unapproved changes. Since the RFC Editor maintains the index of publications, sufficient security must be in place to stop these published documents from being changed by external 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 💀. Back them up, no excuses.

7. Changes Since RFC 4844 🦋

Sections 3.3, 3.4, and 4 have been updated to line up with the restructuring of the IETF Administrative Support Activity (IASA) ✨. Under the new structure, the IETF LLC does the IASA tasks that used to belong to the IETF Administrative Director and to the Internet Society 👑.

Many references were updated to point to the most recent documents 📚.

Minor editorial changes were made to reflect 10 years of using the framework provided in RFC 4884 🌈. For example, RFC 4844 said, "... this document sets out a revised framework ...", and now it's more appropriate to say, "... this document sets out the framework ..." 💅.

8. Informative References 📚

[RFC1358]  Chapin, L., "Charter of the Internet Architecture Board
           (IAB)", RFC 1358, DOI 10.17487/RFC1358, August 1992,
           <https://www.rfc-editor.org/info/rfc1358>.

[RFC1601]  Huitema, C., "Charter of the Internet Architecture Board
           (IAB)", RFC 1601, DOI 10.17487/RFC1601, March 1994,
           <https://www.rfc-editor.org/info/rfc1601>.

[RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
           3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
           <https://www.rfc-editor.org/info/rfc2026>.

[RFC2555]  Editor, RFC. and et. al., "30 Years of RFCs", RFC 2555,
           DOI 10.17487/RFC2555, April 1999,
           <https://www.rfc-editor.org/info/rfc2555>.

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

[RFC3967]  Bush, R. and T. Narten, "Clarifying when Standards Track
           Documents may Refer Normatively to Documents at a Lower
           Level", BCP 97, RFC 3967, DOI 10.17487/RFC3967, December
           2004, <https://www.rfc-editor.org/info/rfc3967>.

[RFC4714]  Mankin, A. and S. Hayes, "Requirements for IETF Technical
           Publication Service", RFC 4714, DOI 10.17487/RFC4714,
           October 2006, <https://www.rfc-editor.org/info/rfc4714>.

[RFC4845]  Daigle, L., Ed. and Internet Architecture Board, "Process
           for Publication of IAB RFCs", RFC 4845,
           DOI 10.17487/RFC4845, July 2007,
           <https://www.rfc-editor.org/info/rfc4845>.

[RFC4846]  Klensin, J., Ed. and D. Thaler, Ed., "Independent
           Submissions to the RFC Editor", RFC 4846,
           DOI 10.17487/RFC4846, July 2007,
           <https://www.rfc-editor.org/info/rfc4846>.

[RFC4897]  Klensin, J. and S. Hartman, "Handling Normative References
           to Standards-Track Documents", BCP 97, RFC 4897,
           DOI 10.17487/RFC4897, June 2007,
           <https://www.rfc-editor.org/info/rfc4897>.

[RFC5378]  Bradner, S., Ed. and J. Contreras, Ed., "Rights
           Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
           DOI 10.17487/RFC5378, November 2008,
           <https://www.rfc-editor.org/info/rfc5378>.

[RFC5742]  Alvestrand, H. and R. Housley, "IESG Procedures for
           Handling of Independent and IRTF Stream Submissions",
           BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009,
           <https://www.rfc-editor.org/info/rfc5742>.

[RFC5743]  Falk, A., "Definition of an Internet Research Task Force
           (IRTF) Document Stream", RFC 5743, DOI 10.17487/RFC5743,
           December 2009, <https://www.rfc-editor.org/info/rfc5743>.

[RFC5744]  Braden, R. and J. Halpern, "Procedures for Rights Handling
           in the RFC Independent Submission Stream", RFC 5744,
           DOI 10.17487/RFC5744, December 2009,
           <https://www.rfc-editor.org/info/rfc5744>.

[RFC5745]  Malis, A., Ed. and IAB, "Procedures for Rights Handling in
           the RFC IAB Stream", RFC 5745, DOI 10.17487/RFC5745,
           December 2009, <https://www.rfc-editor.org/info/rfc5745>.

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

[RFC7997]  Flanagan, H., Ed., "The Use of Non-ASCII Characters in
           RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016,
           <https://www.rfc-editor.org/info/rfc7997>.

[RFC8067]  Leiba, B., "Updating When Standards Track Documents May
           Refer Normatively to Documents at a Lower Level", BCP 97,
           RFC 8067, DOI 10.17487/RFC8067, January 2017,
           <https://www.rfc-editor.org/info/rfc8067>.

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

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

[SPONSOR]  IESG, "Guidance on Area Director Sponsoring of Documents",
           IESG Statement, March 2007,
           <http://www.ietf.org/iesg/statement/ad-sponsoring-
           docs.html>.

Appendix A. A Retrospective of IAB Charters and RFC Editor 🎀

With this document, the IAB's role with respect to the RFC Series and the RFC Editor is getting a glow-up 💅 It's becoming more hands-on with the RFC Editor, and the IAB will provide oversight so the RFC Series mission principles and the communities' input actually get addressed properly 🫶

This appendix is a little history lesson on what the IAB's role with the RFC Editor looked like in IAB Charter RFCs going all the way back to 1992 ✨ The big takeaway is that the IAB has always had a substantive role. Sometimes it was directly in charge of the RFC Series' editorial management (around 1992, see Appendix A.1), and sometimes it was in charge of appointing the RFC Editor organization and approving general policy (around 2000, see Appendix A.3) 🌸

A.1. 1992

[RFC1358] says:

[The IAB's] responsibilities shall include:
[...]
    (2)  The editorial management and publication of the Request
         for Comments (RFC) document series, which constitutes the
         archival publication series for Internet Standards and
         related contributions by the Internet research and
         engineering community.

A.2. 1994

[RFC1601] says:

[The IAB's] responsibilities under this charter include:

(d) RFC Series and IANA

   The IAB is responsible for editorial management and publication
   of the Request for Comments (RFC) document series, and for
   administration of the various Internet assigned numbers.

Which it elaborates as:

2.4 RFC Series and Assigned Numbers

   The RFC Series constitutes the archival publication channel
   for Internet Standards and for other contributions by the
   Internet research and engineering community.  The IAB
   shall select an RFC Editor, who shall be responsible for
   the editorial management and publication of the RFC Series.

A.3. 2000

The most recent IAB Charter [RFC2850] says:

(d) RFC Series and IANA

The RFC Editor executes editorial management and publication of
the IETF "Request for Comment" (RFC) document series, which is
the permanent document repository of the IETF.  The RFC Series
constitutes the archival publication channel for Internet
Standards and for other contributions by the Internet research
and engineering community.  RFCs are available free of charge to
anyone via the Internet.  The IAB must approve the appointment
of an organization to act as RFC Editor and the general policy
followed by the RFC Editor.

IAB Members at the Time of Approval

The IAB members at the time of approval of RFC 4844 were:

  • Bernard Aboba
  • Loa Andersson
  • Brian Carpenter
  • Leslie Daigle
  • Elwyn Davies
  • Kevin Fall
  • Olaf Kolkman
  • Kurtis Lindqvist
  • David Meyer
  • David Oran
  • Eric Rescorla
  • Dave Thaler
  • Lixia Zhang

The IAB members at the time of approval of this document were:

  • Jari Arkko
  • Alissa Cooper
  • Stephen Farrell
  • Wes Hardaker
  • Ted Hardie
  • Christian Huitema
  • Zhenbin Li
  • Erik Nordmark
  • Mark Nottingham
  • Melinda Shore
  • Jeff Tantsura
  • Martin Thomson
  • Brian Trammell

Authors' Addresses 🦋

Russ Housley (editor)

Email: housley@vigilsec.com

Leslie L. Daigle (editor)

Email: ldaigle@thinkingcat.com

📦 where this page comes from