| RFC 8729 | The RFC Series and RFC Editor | February 2020 |
| Housley & Daigle | Informational | [Page] |
This document describes the framework for an RFC Series and an RFC Editorfunction that incorporate the principles of organized communityinvolvement and accountability that has become necessary as the Internettechnical community has grown, thereby enabling the RFC Series tocontinue to fulfill its mandate. This document obsoletes RFC 4844.¶
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://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) 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.¶
The first Request for Comments (RFC) document was published in Aprilof 1969 as part of the effort to design and buildwhat we now know of as the Internet. Since then, the RFC Serieshas been the archival series dedicated to documentingInternet technical specifications, including both generalcontributions from the Internet research and engineeringcommunity as well as standards documents.¶
As described in the history of the first 30 years of RFCs([RFC2555]), the RFC Series was created for the purposeof capturing the research and engineering thought that underliethe design of (what we now know of as) the Internet. As theInternet Engineering Task Force (IETF) was formalized to carry outthe discussion and documentation of Internet standards, IETF documentshave become a large part (but not the entirety) of the RFC Series.¶
As the IETF has grown up and celebrated its own 30 years of history, its requirements for archival publication of its outputhave changed and become more rigorous. Perhaps most significantly,the IETF must be able to define (based on its own open consensusdiscussion processes and leadership directions) and implementadjustments to its publication processes.¶
At the same time, the Internet engineering and research communityas a whole has grown and come to require more openness and accountabilityin all organizations supporting it. More than ever, this communityneeds an RFC Series that is supported (operationally and in terms ofits principles) such that there is a balance of:¶
In the past, there has been confusion and therefore sometimes tension over where and how to address RFC issues that are particular tocontributing groups (e.g., the IETF, the Internet Architecture Board(IAB), or independent individuals). It was not always clear where there shouldbe community involvement versus RFC Editor control; depending on theissue, there might be more or less involvement from the IAB, theInternet Engineering Steering Group (IESG), or thecommunity at large. There are similar issues with handling RFCSeries-wide issues -- where to discuss and resolve them in a way thatis balanced across the whole series.¶
For example, there have been discussions about Intellectual PropertyRights (IPR) for IETF-generated documents, but it's not clear when orhow to abstract the portions of those discussions that are relevantto the rest of the RFC Series. Discussions of labeling (ofRFCs in general, IETF documents in particular, or some combinationthereof) generally must be applied to the whole RFC Series ornot at all. Without an agreed-on framework for managing the RFC Series, it is difficult to have those discussions in a non-polarized fashion -- either the IETF dictating the reality of the rest of the RFC Series, or the RFC Series imposing undue restrictions on documents from the IETF.¶
As part of its charter (seeAppendix A), the IAB has a responsibility for the RFC Editor. Acknowledging the IETF's needsand the general Internet engineering and research community's evolvingneeds, the IAB supports a future for the RFC Series thatcontinues to meet its original mandate of providing the archivalseries for the technical research and engineering documentation thatdescribes the Internet.¶
With this document, the IAB provides the framework for the RFC Series andan RFC Editor function with the specific purpose of ensuring that the RFCSeries is maintained and supported in ways that are consistent with thestated purpose of the RFC Series and the realities of today's Internetresearch and engineering community. The framework describes the existing"streams" of RFCs, draws a roadmap of existing process documents alreadydefining the implementation, and provides clear direction of how toevolve this framework and its supporting pieces through discussion andfuture document revision.¶
Specifically, this document provides a brief charter for the RFC Series,describes the role of the RFC Editor, the IAB, and the IETFAdministrative Support Activity (IASA) in a framework for managing theRFC Series, and discusses the streams of input to the RFC Series from thevarious constituencies it serves.¶
The RFC Series is the archival series dedicated to documenting Internet technical specifications, including generalcontributions from the Internet research and engineeringcommunity as well as standards documents.¶
RFCs are available free of charge to anyone via the Internet.¶
As this document sets out the framework for supporting theRFC Series mission, this section reviews the updated roles and responsibilities of the entities that have had, and will have, involvement in continued support of the mission.¶
Originally, there was a single person acting as editor of the RFCSeries (the RFC Editor). The task has grown, and the work now requires the organized activity of several experts, so there areRFC Editors, or an RFC Editor organization. In time, there may bemultiple organizations working together to undertake the work requiredby the RFC Series. For simplicity's sake, and without attemptingto predict how the role might be subdivided among them, this document refers to this collection of experts and organizations as the "RFC Editor".¶
The RFC Editor is an expert technical editor and series editor, acting to support the mission of the RFC Series. As such, the RFC Editoris the implementer handling the editorial management of the RFC Series, in accordance with the defined processes. In addition, theRFC Editor is expected to be the expert and prime mover in discussionsabout policies for editing, publishing, and archiving RFCs.¶
In this model, the role of the IAB is to ensure that the RFC Seriesmission is being appropriately fulfilled for the whole community forwhich it was created. The IAB does not, organizationally, havecomprehensive publishing or editorial expertise. Therefore, the role ofthe IAB is focused on ensuring that principles are met, the appropriatebodies and communities are duly informed and consulted, and the RFCEditor has what it needs in order to execute on the material that is intheir mandate.¶
It is the responsibility of the IAB to approve theappointment of the RFC Editor and to approve the generalpolicy followed by the RFC Editor.¶
The IETF Administration Limited Liability Company (IETF LLC), as partof the IETF Administrative Support Activity (IASA), is responsiblefor administrative and financial matters for the IETF, the IAB, andthe Internet Research Task Force (IRTF)[RFC8711]. The IASA is tasked withproviding the funding for the RFC Editor. The IASA, through theIETF Executive Director, provides contractual and financial oversightof the RFC Editor. Additionally, as described inSection 3.1 of [RFC8728], the RFC Series OversightCommittee (RSOC), acting with authority delegated from the IAB, isresponsible for ensuring that the RFC Series is run in a transparentand accountable manner, including design and execution of theRFC Series Editor selection process.¶
The IETF Executive Director works with the IAB to identify suitablepersons or entities to fulfill the mandate of the RFC ProductionCenter and the RFC Publisher roles as defined in[RFC8728].¶
The IETF Executive Director establishes appropriatecontractual agreements with the selected persons or entitiesto carry out the work that will satisfy the technical publication requirementsdefined for the various RFC input streams (seeSection 5.2).The IETF Executive Director may define additional operational requirementsand policies for management purposes to meet the requirements definedby the various communities.¶
The IETF Administration LLC Board approves a budget for operation ofthe RFC Editor activity, and the IETF Executive Director establishes andmanages the necessary operational agreements for the RFC Editor activity.¶
The IAB monitors the effectiveness of the policies in force andtheir implementation to ensure that the RFC Editor activitymeets the editorial management and document publication needsas referenced in this document. In the event of serious non-conformance, the IAB, either on its own initiative or at the request of the IETFAdministration LLC Board, may require the IETF Executive Director to varyor terminate and renegotiate the arrangements for the RFC Editor activity.¶
With the RFC Series mission outlined above, this document describes aframework for supporting¶
based on¶
for which there are¶
Generally speaking, the RFC Editor is responsible for the operational implementation of the RFC Series. As outlinedinSection 3.3, the IETF Executive Director providesthe oversight of this operational role.¶
The process and definition documents are detailed below, includingresponsibility for the individual process documents (maintenance andupdate). The RFC Editor works with the appropriate community to ensurethat the process documents reflect current requirements. The IAB ischarged with the role of verifying that appropriate community input hasbeen sought and that any changes appropriately account for communityrequirements.¶
There are three categories of activity, and a fourth category of series-wide rules and guidelines, described for implementing the RFC Series to support its mission:¶
The RFC Series mission implicitly requires that documents bereviewed and approved for acceptance into the series.¶
Section 5.1 describes the different streams of documentsthat are put to the RFC Editor for publication as RFCs today. Whilethere may be general policies for approval of documents as RFCs (toensure the coherence of the RFC Series), there are also policies definedfor the approval of documents in each stream. Generally speaking, thereis a different approving body for each stream. The current definitionsare catalogued inSection 5.1.¶
Each stream has its own documented approval process. The RFC Editor isresponsible for the approval of documents in one of the streams(Independent Submission stream, seeSection 5.1.4)and works with the other approving bodies to ensure smooth passage ofapproved documents into the next phases, ultimately to publication andarchiving as an RFC.¶
From time to time, it may be necessary to change the approval processesfor any given stream, or even add or remove streams. This may occurwhen the RFC Editor, the IAB, the body responsible for a given stream of documents, or the community determines that there are issues to beresolved in general for RFC approval or for per-stream approval processes.¶
In this framework, the general approach is that the IAB will work withthe RFC Editor and other parties to get community input, and it will verifythat any changes appropriately account for community requirements.¶
The existing documents describing the approval processes for each stream are detailed inSection 5.1.¶
Producing and maintaining a coherent, well-edited document series requires specialized skills and subject matter expertise. This isthe domain of the RFC Editor. Nevertheless, the community servedby the RFC Series and the communities served by the individualstreams of RFCs have requirements that help define the nature of theseries.¶
General and stream-specific requirements for the RFC Series are documentedin community-approved documents (catalogued inSection 5.2below).¶
Any specific interfaces, numbers, or concrete values required to make therequirements operational are the subject of agreements betweenthe IASA and the RFC Editor (e.g., contracts, statements of work, servicelevel agreements, etc).¶
The RFC Editor is responsible for ensuring that editing, processing, andpublication of RFCs are carried out in a way that is consistent with therequirements laid out in the appropriate documents. The RFC Editor workswith the IASA to provide regular reporting and feedback on these operations.¶
From time to time, it may be necessary to change the requirementsfor any given stream, or the RFC Series in general. This may occurwhen the RFC Editor, the IAB, the approval body for a given stream of documents, or the community determines that there are issues to beresolved in general for RFCs or for per-stream requirements.¶
In this model, the general approach is that the IAB will work with theRFC Editor to get community input, and it will approve changes byvalidating appropriate consideration of community requirements.¶
Documents describing existing requirements for the streams aredetailed inSection 5.2.¶
The activities of archiving, indexing, and making accessible the RFCSeries can be informed by specific subject matter expertise in generaldocument series editing. It is also important that they are informed byrequirements from the whole community. As long as the RFC Series is toremain coherent, there should be uniform archiving and indexing of RFCsacross all streams and a common method of accessing the resultingdocuments.¶
In principle, there should be a community consensus document describingthe archiving, indexing, and accessibility requirements for the RFCSeries. In practice, we continue with the archive as built by thecapable RFC Editors since the series' inception.¶
Any specific concrete requirements for the archive, index, andaccessibility operations are the subject of agreements between the IASAand the RFC Editor (e.g., contracts, statements of work, service levelagreements, etc).¶
The RFC Editor is responsible for ensuring that the RFC archive and indexare maintained appropriately and that the resulting documents are madeavailable to anybody wishing to access them via the Internet. The RFCEditor works with the IASA for regular reporting and feedback.¶
Should there be a community move to propose changes to the requirementsfor the RFC archive and index or accessibility, the IAB will work with the RFC Editor to get community input, and it will approve changes by validating appropriate consideration of community requirements.¶
There are no applicable process documents.¶
The RFC Series style and content can be shaped by subject matterexpertise in document series editing. They are also informed byrequirements by the using community. As long as the RFC Series is toremain coherent, there should be uniform style and content for RFCsacross all streams. This includes, but is not limited to, acceptablelanguage, use of references, and copyright rules.¶
In principle, there should be a community consensus document (or set ofdocuments) describing the content requirements for the RFC Series. Inpractice, some do exist, though some need reviewing and more may beneeded over time.¶
The RFC Editor is responsible for ensuring that the RFC Series guidelinesare upheld within the RFC Series.¶
When additions or changes are needed to series-wide definitions,the IAB will work with the RFC Editor and stream stakeholdersto get community input and review. The IAB will approve changes byvalidating appropriate consideration of community requirements.¶
Existing series-wide rules and guidelines documents include:¶
Various contributors provide input to the RFC Series. Thesecontributors come from several different communities, eachwith its own defined process for approving documents thatwill be published by the RFC Editor. This is nothing new;however, over time the various communities and documentrequirements have grown and separated. In order to promoteharmony in discussing the collective set of requirements,it is useful to recognize each in their own space -- and theyare referred to here as "streams".¶
Note that by identifying separate streams, there is no intentionof dividing them or undermining their management as one series. Rather,the opposite is true -- by clarifying the constituent parts, it is easier to make them work together without the friction thatsometimes 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 ofstreams and all policies surrounding general changes to theRFC Series are discussed above inSection 4.¶
Processes for approval of documents (or requirements) for each stream aredefined by the community that defines the stream. The IAB is chargedwith the role of verifying that appropriate community input has beensought and that the changes are consistent with the RFC Series missionand this overall framework.¶
The RFC Editor is expected to publish all documents passed to itafter appropriate review and approval in one of the identifiedstreams.¶
The IETF document stream includes IETF WG documents as well as"individual submissions" sponsored by an IESG area director. Anydocument being published as part of the IETF standards processmust follow this stream -- no other stream can approveStandards-Track RFCs or Best Current Practice (BCP) RFCs.¶
Approval of documents in the IETF stream is defined by¶
Changes to the approval process for this stream are made byupdating the IETF standards process documents.¶
The IAB defines the processes by which it approves documents in itsstream. Consistent with the above, any documents that the IAB wishes topublish as part of the IETF Standards Track (Standards or BCPs) aresubject to the approval processes referred to inSection 5.1.1.¶
The review and approval process for documents in the IABstream is described in¶
The IRTF is chartered as an activity of the IAB. With the approvalof the IAB, the IRTF may publish and update a process forpublication of its own, non-IETF Standards-Track, documents.¶
The review and approval process for documents in the IRTF streamis described in¶
The RFC Series has always served a broader Internet technical community than the IETF. The "Independent Submission" stream isdefined to provide review and (possible) approval of documentsthat are outside the scope of the streams identified above.¶
Generally speaking, approval of documents in this stream fallsunder the purview of the RFC Editor, and the RFC Editor seeksinput to its review from the IESG.¶
The process for reviewing and approving documents in the IndependentSubmission stream is defined by¶
The Internet engineering and research community has not only grown,it has become more diverse, and sometimes more demanding. The IETF,as a standards-developing organization, has publication requirementsthat extend beyond those of an academic journal. The IAB does nothave the same interdependence with IANA assignments as the IETFstream does. Therefore, there is the need to both codify thepublishing requirements of each stream, and endeavor to harmonizethem to the extent that is reasonable.¶
Therefore, it is expected that the community of effort behindeach document stream will outline their technical publication requirements.¶
As part of the RFC Editor oversight, the IAB must agree that therequirements are consistent with and implementable as part of theRFC Editor activity.¶
Although they were developed for the IETF standards process, the IAB hasidentified applicable requirements in[RFC4714] for itsstream. In addition, procedures related to IPR for the IAB stream arecaptured in[RFC5745].¶
If the IAB elects to define other requirements, they should deviateminimally from those (in an effort to keep the collective technicalpublication requirements reasonably managed by one technical publisher).¶
The IRTF has identified applicable requirements in[RFC5743]for its stream.¶
If the IRTF elects to define other requirements, they should deviateminimally from those (in an effort to keep the collective technicalpublication requirements reasonably managed by one technical publisher).¶
Procedures and processes for the Independent Stream are described in[RFC4846] and[RFC8730].¶
Although they were developed for the IETF standards process, the RFCEditor has identified applicable requirements in[RFC4714]for the Independent Submissions stream. In addition, procedures relatedto IPR for the independent submissions stream are captured in[RFC5744].¶
If the RFC Editor elects to define other requirements, they should deviateminimally from those (in an effort to keep the collective technicalpublication requirements reasonably managed by one technical publisher).¶
The processes for the publication of documents must prevent theintroduction of unapproved changes. Since the RFC Editor maintains theindex of publications, sufficient security must be in place to preventthese published documents from being changed by external parties. Thearchive of RFC documents, any source documents needed to recreate the RFCdocuments, and any associated original documents (such as lists oferrata, tools, and, for some early items, non-machine readable originals)need to be secured against failure of the storage medium and othersimilar disasters.¶
Sections3.3,3.4,and4 have been updated to align with the restructuring of theIETF Administrative Support Activity (IASA). Under the new structure, theIETF LLC performs the tasks related to IASA that were previously assigned tothe 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 frameworkprovided in RFC 4884. For example, RFC 4844 said, "... this document sets outa revised framework ...", and it is now more appropriate to say, "... thisdocument sets out the framework ...".¶
With this document, the IAB's role with respect to the RFC Seriesand the RFC Editor is being adjusted to work more directly with theRFC Editor and provide oversight to ensure the RFC Series missionprinciples and communities' input are addressed appropriately.¶
This section provides an overview of the role of the IAB with respectto the RFC Editor as it has been presented in IAB Charter RFCs datingback to 1992. The point of this section is that the IAB's role hashistorically been substantive -- whether it is supposed to be directlyresponsible for the RFC Series' editorial management(circa 1992,Appendix A.1), or appointment ofthe RFC Editor organization and approval of general policy(circa 2000,Appendix A.3).¶
[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.¶
[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.¶
The most recent IAB Charter[RFC2850] says:¶
(d) RFC Series and IANAThe RFC Editor executes editorial management and publication ofthe IETF "Request for Comment" (RFC) document series, which isthe permanent document repository of the IETF. The RFC Seriesconstitutes the archival publication channel for InternetStandards and for other contributions by the Internet researchand engineering community. RFCs are available free of charge toanyone via the Internet. The IAB must approve the appointmentof an organization to act as RFC Editor and the general policyfollowed by the RFC Editor.¶
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:¶