1. Introduction
This section preserves the RFC text for the RFC Editor Model, including RSWG, RSAB, RPC, RSCE, IETF LLC, Editorial Stream, appeals, policy implementation, and historical RFC Series properties.
Original RFC Text
1. Introduction
The Request for Comments (RFC) Series is the archival series
dedicated to documenting Internet technical specifications, including
general contributions from the Internet research and engineering
community as well as standards documents. RFCs are available free of
charge to anyone via the Internet. As described in [RFC8700], RFCs
have been published continually since 1969.
RFCs are generated and approved by multiple document streams.
Whereas the stream approving body [RFC8729] for each stream is
responsible for the content of that stream, the RFC Editor function
is responsible for the production and distribution of all RFCs. The
four existing streams are described in [RFC8729]. This document
specifies a fifth stream, the Editorial Stream, for publication of
policies governing the RFC Series as a whole.
The overall framework for the RFC Series and the RFC Editor function
is described in [RFC8729] and is updated by this document, which
defines version 3 of the RFC Editor Model. Under this version,
various responsibilities of the RFC Editor function are performed
alone or in combination by the RFC Series Working Group (RSWG), RFC
Series Advisory Board (RSAB), RFC Production Center (RPC), RFC Series
Consulting Editor (RSCE), and IETF Administration Limited Liability
Company (IETF LLC) [RFC8711], which collectively comprise the RFC
Editor function. The intent is to ensure sustainable maintenance and
support of the RFC Series based on the principles of expert
implementation, clear management and direction, and appropriate
community input [RFC8729].
This document updates [RFC7841] by defining boilerplate text for the
Editorial Stream. This document updates [RFC8729] by replacing the
RFC Editor role with the RSWG, RSAB, and RSCE. This document updates
[RFC8730] by removing the dependency on certain policies specified by
the IAB and RFC Series Editor (RSE). More detailed information about
changes from version 2 of the RFC Editor Model can be found in
Section 9.
1.1. Changes to RFC 9280
This section details the changes made to [RFC9280] by the RSWG
starting in 2022. If you are not interested in how this document was
changed, skip directly to Section 2.
[RFC9280] contained significant changes to the publication model for
RFCs. Those changes created new structures and new processes for the
publication of RFCs. As these structures and processes have been
exercised, the community has found places where they can be improved.
In addition, gaps in some of the processes have been found. This
document updates [RFC9280] based on these findings.
The organization of this RFC is different from typical RFCs in order
to keep the section numbering the same as [RFC9280]. To keep the
section numbering the same, the Introduction section is much longer,
with several subsections that refer to the main body.
The remainder of this introduction is a list of changes to [RFC9280].
Those changes are instantiated in the rest of the document, with
cross-references between the list of changes and the main body.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"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.
1.2. RPC Roles and Responsibilities
[RFC9280] created a new structure for the RFC Editor function. It
established the RFC Series Working Group (RSWG) and the RFC Series
Approval Board (RSAB) and gave new responsibilities to the RFC
Production Center (RPC). Broadly speaking, it says that the RSWG
writes policies for the Editorial Stream, the RSAB approves those
policies, and the RPC implements those policies. However, [RFC9280]
does not specify which group is responsible for defining or building
the specific code and tools that implement the policies agreed upon
in this process. The rest of this section updates [RFC9280] to deal
with this and other related matters.
1.2.1. Tooling and Code Used for Publication of RFCs
Section 2 of [RFC9280] states:
| Policy implementation through publication of RFCs in all of the
| streams that form the RFC Series. This is primarily the
| responsibility of the RFC Production Center (RPC) as contractually
| overseen by the IETF Administration Limited Liability Company
| (IETF LLC) [RFC8711].
The same section also states:
| The RPC implements the policies defined by the Editorial Stream in
| its day-to-day editing and publication of RFCs from all of the
| streams.
[RFC9280] does not define any other group that is responsible for
implementing policies.
Throughout [RFC9280], the RSWG is consistently assigned
responsibility for writing policies (not deciding on
implementations). The RPC is consistently assigned responsibility
for implementing policy decisions, but examples given generally
describe decisions made at the single document level. [RFC9280] does
not cover any specific responsibilities for designing and building
the tools and code used to publish documents.
[RFC9280] mentions tool developers twice. Section 3.1.1.2 of
[RFC9280] encourages "developers of tools used to author or edit RFCs
and Internet-Drafts" to participate in the RSWG. Section 3.2.1 of
[RFC9280] says that "RSAB members should consult with their
constituent stakeholders (e.g., authors, editors, tool developers,
and consumers of RFCs) on an ongoing basis".
Section 4.2 of [RFC9280] mentions a specific implementation when
discussing the working practices of the RPC:
| In the absence of a high-level policy documented in an RFC or in
| the interest of specifying the detail of its implementation of
| such policies, the RPC can document ... Guidelines regarding the
| final structure and layout of published documents. In the context
| of the XML vocabulary [RFC7991], such guidelines could include
| clarifications regarding the preferred XML elements and attributes
| used to capture the semantic content of RFCs.
[RFC7991] is the only editorial implementation-related RFC mentioned
in [RFC9280].
The following is added to Section 4.3 of this document:
| The RPC is responsible for the development of tools and processes
| used to implement Editorial Stream policies, in the absence of an
| RFC with specific requirements. The RPC is responsible for
| detailed technical specifications, for example, specific details
| of text or graphical formats or XML grammar. The RPC may
| designate a team of volunteers and/or employees who implement
| these operational decisions. The RPC is expected to solicit input
| from experts and community members when making implementation
| decisions. The RPC is required to document implementation
| decisions in a publicly available place, preferably with
| rationale.
|
| If the RPC has questions about how to interpret policy in
| Editorial Stream documents, they should ask the RSAB for guidance
| in interpreting that policy per the process described in
| Section 4.4.
1.2.2. Conflict Resolution for Implementation Decisions
Section 4.4 of [RFC9280] provides a pathway for resolution of
conflicts between the RPC and the author(s) of a specific document.
No appeal pathway is given for resolution of issues that may occur
when a conflict arises with an implementation decision that applies
to the entire editorial process (not just one document).
The paragraph below is reflected in Section 4.4 of this document:
| If the RPC is responsible for interpreting policy decisions at
| both the document and editorial process tooling level, conflicts
| on either level will involve interpretation of written policy (or
| the acknowledgment that policy does not exist to cover a given
| situation). In any case, the conflict resolution will now use the
| same path of appeal: to the RSAB.
1.2.3. RFC Consumers
This text is reflected in Section 3.3 of this document:
| The IETF mission statement [RFC3935] is clear that the documents
| it produces are intended to be consumed by anyone who wishes to
| implement an IETF protocol or operational recommendation:
|
| to produce high quality, relevant technical and engineering
| documents that influence the way people design, use, and manage
| the Internet in such a way as to make the Internet work better.
|
| Section 3.2.1 introduces the term "consumers of RFCs", referring
| to them as "constituent stakeholders" who should be considered by
| the RSAB when approving Editorial Stream policy documents.
|
| "Consumers of RFCs" is now defined to mean those people who read
| RFCs to understand, implement, critique, and research the
| protocols, operational practices, and other content as found in
| RFCs.
|
| The policy to be followed by the RFC publication streams and RFC
| Editor in respect to consumers of RFCs is as follows:
|
| * Consumers of RFCs MUST be considered as separate constituent
| stakeholders from IETF/IRTF participants. While IETF/IRTF
| participants and others involved in the development and
| production of RFCs may be consumers of RFCs, the two are
| distinct, overlapping sets.
|
| * The RFC Editor website (https://www.rfc-editor.org) MUST be
| primarily focused on consumers of RFCs.
|
| * Consumers of RFCs MUST NOT be required or expected to become
| IETF/IRTF participants unless they wish to extend, update, or
| modify an RFC.
1.3. Updates to RFC 9720
[RFC9720], "RFC Formats and Versions", updates [RFC9280]. This
document updates [RFC9720].
1.3.1. RFCs May Be Reissued
Section 7.6 of [RFC9280] says:
| Once published, RFC Series documents are not changed.
That sentence is replaced in Section 7.6 of this document with:
| Once published, RFCs may be reissued, but the semantic content of
| publication versions shall be preserved to the greatest extent
| possible, as described in Section 2.2 of [RFC9720].
1.3.2. Consistency Policy
A new policy is added to Section 7 of this document:
| 7.8. Consistency
|
| RFCs are copyedited, formatted, and then published. They may be
| reissued to maintain a consistent presentation.
1.4. Purview of the RSWG and RSAB
Section 3 of [RFC9280] says:
| Policies under the purview of the RSWG and RSAB might include, but
| are not limited to, document formats, processes for publication
| and dissemination of RFCs, and overall management of the RFC
| Series.
The following is added to Section 3 of this document immediately
following that sentence:
| Such policies will not include detailed technical specifications,
| for example, specific details of text or graphical formats or XML
| grammar. Such matters will be decided and documented by the RPC
| along with its other working practices, as discussed in
| Section 4.2, with community consultation as for other tools and
| services supported by the IETF LLC [RFC8711].
1.5. Updates to RFCs 7991 through 7997
All instances of "RFC Editor" or "RFC Series Editor" in [RFC7991],
[RFC7992], [RFC7993], [RFC7994], [RFC7995], [RFC7996] (obsoleted by
[RFC9896]), and [RFC7997] are replaced by "RFC Production Center
(RPC)".
1.6. Rewording to Obsolete RFC 9280
Many parts of [RFC9280] talked about changes to be made. Because
this document obsoletes [RFC9280], these parts were updated to
indicate that the changes were made.