Mozilla

stpeter@jabber.org

Internet Internet-Draft This document describes Version 3 of the RFC Editor model.

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 . The processes and organizational models for publication of these documents have changed significantly over the years. Most recently, in 2009 defined the RFC Editor Model (Version 1) and in 2012 defined the RFC Editor Model (Version 2), since modified slightly in 2020 by . 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 RFC Series Working Group (RSWG), the RFC Series Approval Board (RSAB), and the RFC Publication Center (RPC).

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 when, and only when, they appear in all capitals, as shown here.

Version 2 of the RFC Editor Model 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) function. 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).

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

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.

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 . 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 ) that are consistent with . The RSWG shall conform itself to an anti-harassment policy consistent with and . 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 process.

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: The IETF Chair, representing the IETF stream The IAB Chair, representing the IAB stream The IRTF Chair, representing the IRTF stream The Independent Submissions Editor 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, etc.). 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.

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 ). 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 goal.

The following process shall be used to formulate or modify processes related to the RFC series: A individual participant in the RSWG generates a proposal in the form of an Internet-Draft. 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. The RSWG shall then further develop the proposal. Members of the RSAB are expected to participate in discussion relating to such proposals. 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. 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. 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”. Should substantial changes be made, additional community calls for comment should be issued, and again comments considered. Once all comments have been been addressed, the RSWG chairs will submit the proposal to the RSAB for its consideration. 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: The proposal represents a serious problem for the group a particular member represents. 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. If a CONCERN exists, discussion will take place within the RSWG. Again, all RSAB members MUST participate. 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. 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. Otherwise, it is returned to the RSWG. In the case of a tie, the proposal is approved. 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 are these documents published? Is a new stream (e.g., the “Editorial Stream”) needed?

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.

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: Provide expert advice regarding policy proposals within the RSWG. Serve as a voting member on the RSAB (see OPEN ISSUE above). 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.

The RSEA will be selected by a committee formed by the Executive Director of the IETF LLC, taking into account the role definition and any detailed job description defined by the relevant parties (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 years.

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: Was the RSEA an active participant in RSWG/RSAB discussions and meetings? Did the RSEA provide useful advice to the RSWG and RPC? Did the RSEA exercise good judgment in RSAB decision making? Was the RSEA effective in advising the community on policy direction? 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.

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.

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.

This document has no actions for IANA.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the guidelines and procedures for formation and operation of IETF working groups. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. IAB The RFC Editor performs a number of functions that may be carried out by various persons or entities. The RFC Editor model presented in this document divides the responsibilities for the RFC Series into four functions: The RFC Series Editor, the Independent Submission Editor, the RFC Production Center, and the RFC Publisher. It also introduces the RFC Series Advisory Group and an (optional) Independent Submission Stream Editorial Board. The model outlined here is intended to increase flexibility and operational support options, provide for the orderly succession of the RFC Editor, and ensure the continuity of the RFC series, while maintaining RFC quality and timely processing, ensuring document accessibility, reducing costs, and increasing cost transparency. This memo provides information for the Internet community. IAB The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFC Series Editor, the RFC Production Center, and the RFC Publisher. Internet Architecture Board (IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administrative Oversight Committee (IAOC) and the RSOC. This document reflects the experience gained with "RFC Editor Model (Version 1)", documented in RFC 5620, and obsoletes that document. This document is not an Internet Standards Track specification; it is published for informational purposes. This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work.This document is an updated version of the guidelines for conduct originally published in RFC 3184. The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a "majority rule" philosophy. This is why we engage in rituals like "humming" instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day without consideration of minority concerns. This document explains some features of rough consensus, what is not rough consensus, how we have gotten away from it, how we might think about it differently, and the things we can do in order to really achieve rough consensus.Note: This document is quite consciously being put forward as Informational. It does not propose to change any IETF processes and is therefore not a BCP. It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus. IETF Participants must not engage in harassment while at IETF meetings, virtual meetings, or social events or while participating in mailing lists. This document lays out procedures for managing and enforcing this policy.This document updates RFC 2418 by defining new working group guidelines and procedures. This document updates RFC 7437 by allowing the Ombudsteam to form a recall petition without further signatories. The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026. This document also obsoletes RFCs 3979 and 4879. This RFC marks the fiftieth anniversary for the RFC Series. It includes both retrospective material from individuals involved at key inflection points as well as a review of the current state of affairs. It concludes with thoughts on possibilities for the next fifty years for the Series. This document updates the perspectives offered in RFCs 2555 and 5540. The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFC Series Editor, the RFC Production Center, and the RFC Publisher. Internet Architecture Board (IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administration Limited Liability Company and the RSOC. This document reflects the experience gained with "RFC Editor Model (Version 1)", documented in RFC 5620; and obsoletes RFC 6635 to replace all references to the IETF Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 Model. This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate. This document obsoletes RFC 4844. This document describes the function and responsibilities of the RFC Independent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC Production Center and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF Administration Limited Liability Company (LLC).This version obsoletes RFC 6548 to replace all references to the Internet Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 structure. This document provides a set of guidelines for working groups that choose to use GitHub for their work.

Portions of this document were borrowed from , , , 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.)