A Proposed Model for RFC Editing and PublicationMozillamt@lowentropy.net
IAB
rfced-futureInternet-DraftThe finishing process for a document that is approved for publication as an RFC
currently involves a somewhat detailed and lengthy process. The system that
executes that process involves a number of different actors, each bringing
competency with different aspects of the overall process. Ensuring that this
process functions smoothly is critical to the mission of the organizations that
publish documents in the RFC series.This document proposes a framework for that system that aims to provide clear
delineations of accountability and responsibility for each of the actors in this
system.Discussion VenuesDiscussion of this document takes place on the
RFC Editor Futures program mailing list (rfced-future@iab.org),
which is archived at https://mailarchive.ietf.org/arch/browse/rfced-future/.Source for this draft and an issue tracker can be found at
https://github.com/martinthomson/rfced-model.IntroductionThe RFC Editor Model describes a system that supports the
process of editing and publication of RFCs.The process of RFC editing and publication takes inputs in the form of
documents that are approved for publication by one of four streams (IETF, IRTF,
IAB, and Independent Submissions). The output is an RFC.Generally speaking, this system is successful if RFCs are produced at a rate
approximating the rate that documents are approved for publication. In addition
to managing throughput, the overall latency should be minimized and the quality
of documents should be sufficient to serve the ends of the consumers of those
documents.In practice, the demands placed on the editing and publication process mean that
this function is quite involved. Furthermore, the exact goals that this system
serves continually evolves. The current system has evolved out of a relatively
simple system, into something like what is described in with multiple
discrete roles and somewhat complex interactions between each.The goal of this document is to ensure that the RFC series can continue to serve
as a venue for the publication of documents that are relevant to the Internet.
To that end, it aims to define a system for administering the editing and
publication process.This aims to be a lightweight system that uses community engagement and
transparency as the primary mechanisms for ensuring accountability. This system
avoids vesting control in an individual or body with closed membership,
preferring open processes for critical strategic functions.This document starts out by building from a simple (even simplistic) model of
the system, then builds that out incrementally. The goal is to progressively
expand on the relevance of the model in addressing different problems that have
been identified as important, or to draw in each of the relevant actors in the
system and to attribute responsibilities (and associated authority) to each.Conventions and DefinitionsThe 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.Abstract ModelThe highest-level abstraction is shown in .In this model, each of the four document streams produce documents that are
approved for publication according to the processes of those streams. Each
stream is an independent client of a single entity that provides services in
support of publishing documents as RFCs. These services have numerous facets,
but the core services are copy editing of documents, the preparation of
documents for publication, and the publication of documents.At a high level, each of the streams is an independent customer of the function
of RFC Editing and Publication (REP). Informally, the entity (or entities) that
perform the REP function are contracted to turn approved documents into RFCs.Funding and OversightThe entity that performs the REP function holds contracts with the IETF LLC, who
also provides payment for those contracted services. This means that the REP
function is ultimately answerable to the IETF LLC with respect to performance.Currently, the IETF LLC delegates some of its authority to another body. This
allows the IETF LLC to rely on the expertise of volunteers from the community in
performing oversight. The IETF LLC currently delegates this function to the RFC
Series Oversight Committee (RSOC) via the IAB. This indirection has caused some
problems and this document proposes that oversight be a function that the IETF
LLC be responsible for, either directly or through a delegation process that is
managed by the IETF LLC.The IETF LLC therefore has authority over negotiating performance targets for
the REP and the responsibility of 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 REP can
request that the IETF LLC investigate 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 .This results in evolving the basic model as shown in .This shows the IETF LLC having budgetary and contractual oversight over the
REP.IETF LLC Delegation of Oversight FunctionThe current organization tasks the RSOC with responsibility for oversight. This
has lead to numerous questions about the extent of authority delegated to the
RSOC and the responsibilities of various entities that the RSOC is tasked with
interacting with.This document avoids these questions by placing this authority directly with
the IETF LLC. However, the oversight function is one that the IETF LLC is
expected to delegate, either to an individual or committee.Any delegation would ideally result in the creation of a a document governing
how the delegation was structured. This is not that document, but this assumes
that the person or persons who are given oversight responsibility would be
responsible for managing contract and performance for the RSEP. Any appeal or
dispute with the actions of this individual or committee would then be taken up
with the IETF LLC.Evolution and Setting PoliciesSetting the policies that set targets for REP performance and more detailed
requirements for operation of their functions has historically been delegated to
the RSE. This document proposes separating that function. The goal is to
improve the ability of the community (across all streams) to set and evolve
policies.The requirements of each of the streams changes over time. The goal is to find
a system that allows the community to develop consensus around the strategic
direction for the evolution of the RFC Series.In terms of structure of this effort, the community has a set of well-understood
and tested systems for developing consensus. Therefore, this document proposes
that strategic goals for the RFC Series are developed using the working group
process used in the IETF.Concretely, this proposes forming a RFC Series Evolution program of the IAB that
uses the auspices of an IAB program, one that closely follows the model proposed
in . This results in a group that follows
procedures, with the exception that the functions performed by
the IESG are instead performed by the IAB. In particular, selection of chairs
and appeals regarding the execution of the process are directed to the IAB to
resolve.It is important that this group adopt code of conduct, anti-harrassment, and
other policies. Again, existing IETF processes - collectively referred to in
the Note Well - are well-suited to this task.Any strategic direction that is produced by this process will be documented in
RFCs. These will need to be framed as high-level goals and priorities rather
than strict requirements. It will be up to the IETF LLC - or their delegate -
to negotiate with the REP function about the execution for any changes. In
negotiating the execution of strategy, the IETF LLC is expected to factor in
relevant factors such as cost, legal constraints, or schedule.The IETF LLC is also responsible for ensuring that the plans for implementation
of strategic goals is published and available to the community.This results in the model shown in .Individual InteractionsIt is important to recognize that the interface to the REP function is most
often through individual authors (or chairs, document shepherds, and area
directors) and individual REP staff.In those interactions, those individuals might find problems with processes or
might be motivated to make suggestions for improvement. The goal of the RFC
Series Evolution program is to provide a single venue for discussion of changes
to REP requirements, processes, and procedures.The Needs of Different StreamsThe singular group responsible for evolution of the RFC Series as a whole is
a simplification that is made to reduce contention in setting strategic goals.
It is important to note that the needs of different streams can be different.Several factors motivate a single group that sets strategy. Historically, the
IETF stream is responsible for a large proportion of the documents in the
series. That is unlikely to change and experience has shown that other streams
are - for the most part - willing to accept that strategic direction is largely
dictated by the needs of the most prolific user of the REP service.It is important that each stream retain control over the content of documents
that are published on that stream. Streams currently appoint a stream manager
who is allocated authority over content on that stream and responsibility to
manage any problems that might arise in handling documents produced by that
stream. This document proposes that this aspect of the role continue.Stream managers are also involved in discussion of changes to REP processes and
they contribute to the development of strategic direction for the RFC series.
Rather than deal with issues of REP processes directly, stream managers are
expected to initiate discussion or make proposals to the RFC Series Evolution
program. To avoid conflicts of interest, it is expected that stream managers
will be active participants - and not chairs - in this program.Style GuideOne question that arises when considering policy is that of the Style Guide
and supporting material. These materials are critical to the
process of editing and therefore require that they be owned and maintained.The current process requires that the RFC Series Editor produce and maintain
this material. This document proposes that the RFC Series Evolution program
become responsible for ownership of this material.However, it is recognized that the REP service will likely be the ones to
encounter the need to make updates to material. The RFC Series Evolution
program will need clear processes for reporting problems. As problems of this
nature often arise during document processing, they can require expedient
solutions. To that end, the process should allow for the REP service to make
and record decisions.The nature of the process the RFC Series Evolution program uses might change
over time. Any changes need to be clearly communicated and changes negotiated
with the REP. This negotiation is to be facilitated by the IETF LLC or their
delegate.ToolingProducing an RFC relies heavily on tools that help automate many aspects of the
process. Using tools contributes to consistency and better performance of the
REP function.In one version of this model, the tools that are used by the REP function are
the responsibility of the function. However, the larger system benefits from a
degree of consistency between the tools used by each stream to produce documents
and the tools used in the editing and publication stage. In practice, these
tools are shared and a great deal of benefit is derived from that arrangement.A number of different organizational arrangements could be conceived of for
arranging this situation. For instance, the REP could be tasked with producing
and maintaining tools that it is required to also make available to the
community of people that produce documents. The current arrangement is that the
REP develops some of its own tools, but it also depends on tools that are
maintained by the IETF LLC.Reflecting that arrangement, we have the final composition of functions as
shown in .This arrangement means that any dependencies the REP might have for tools need
to be coordinated via the entity responsible for managing the maintenance of
tooling. The IETF LLC is ultimately responsible for ensuring that the tools
maintenance function has processes for managing the requirements of the REP. As
with the REP oversight functions, this might also be delegated at the discretion
of the IETF LLC.If meeting new requirements set by the IETF LLC require new or modified tooling,
it is the responsibility of the REP to formulate requests regarding to tools to
the Tools Maintenance function.Any problems arising from this arrangement will be raised with the IETF LLC as
they pertain to meeting operational goals.Management of Individual FunctionsThis model does not specify strong requirements on the management of any of the
functions it describes. It is expected that each function identified here will
be managed in a manner appropriate to the function that it serves.Any choice by the IETF LLC to delegate oversight responsibility to a committee
might require that the committee will need decision-making processes. The IETF
LLC is ultimately responsible for ensuring that these processes are appropriate
and effective. The IETF LLC processes regarding consultation with and
accountability to the broader IETF community are deemed sufficient.The choice of leadership for the RFC Series Evolution program could become more
important with a move to a system that lacks a single figurehead. Two measures
are suggested to mitigate the potential for this position to become a function
replacement for the RSE position:
The IAB should appoint at least two co-chairs. This is already good practice
for working groups as it provides redundancy in case of absence or conflict of
interest.
The IAB should seek new chairs at regular intervals and seek to limit the
period over which any one individual might hold a leadership position in the
program.
These are suggestions to the IAB only, not hard requirements.If the function of the REP is contracted to a single entity, it would be the
responsibility of that entity to provide appropriate management. That
management would be expected to manage the workload involved in providing core
REP functions like editing and publication, arranging and planning for changes
in response to upcoming requirements, and reporting on status and performance.For the tools maintenance function, contracting of tools development and
maintenance currently involves multiple entities. Therefore, it might be
necessary for the IETF LLC to contract for a role to manage coordination of
tools maintenance. Arranging for appropriate management, along with systems for
establishing accountability to the community, enabling community contributions,
and dealing with dispute or contention is left to the IETF LLC.Other Involved EntitiesMany documents involve actions for IANA that are processed as part of the REP
processing. These processes need to be captured and documented.This draft describes a model whereby the RFC Series Advisory Group and the RFC
Series Editorial Board have no future as these are functions that serve the a
role that does not exist in this model. These august bodies embody a great deal
of collected wisdom regarding the RFC Series. It is this author's earnest hope
that these individuals will continue to lend their efforts in the form of
contributions to the development of strategy.This draft proposes that the RFC Series Oversight Committee (RSOC) be
disbanded. Many of the functions provided by the RSOC are now an IETF LLC
responsibility in this model. If the IETF LLC decides to form a committee, the
experience of RSOC procedures and former personnel might be used as a resource.It might be necessary on occasion to seek the guidance of experts in fields in
which the community does not feel is well represented. Requirements discussed
thus far include archival, publishing, and legal expertise, though this is not a
definitive set. Consulting or contracting for specialized expertise can be
performed on behalf of the RFC Series Evolution program by the IETF LLC, after
consultation and discussion in the program.Changes from Version 2This document describes a structure that appears quite different from current
practice. This section addresses significant differences and similarities with
the existing system.No RFC Series EditorThis proposal does not describe a role for a RFC Series Editor.The functions previously served by this individual are devolved into several
pieces. The REP function is expanded to cover both RFC Production Center (RPC)
and RFC Publisher as well as the operational management responsibilities
formerly adopted by the RFC Series Editor.The responsibility for managing the evolution of the series is delegated to a
consensus-based group rather than being vested in an individual. Previous RFC
Series Editors achieved much of the strategic and evolutionary functions of
their role by building community consensus, so this aspect of the role is
essentially transferred to the chairs of the RFC Series Evolution program.Any responsibility for execution of RFC Series strategy that might have been
the responsibility of a RFC Series Editor has been distributed: the IETF LLC is
responsible for turning strategy into requests; the REP is responsible for
executing these requests. As the RPC (or publisher) was previously ultimately
responsible for execution of any strategy, the functional difference is
minimal.Moving away from a model where a single individual is involved in setting
direction for the RFC Series is significant. This proposal vests that control
in a consensus-based body instead, which means that decisive action is likely no
longer a feature of this system. As the emphasis of the group is on longer-term
strategy, this is not anticipated to be a practical problem. This further
assumes that the required rate of change matches that of the recent past in that
changes to the operation of the series will be not be extensive or rapid.Preserved Aspects of Current PracticeThis document does not disrupt critical functions involved in RFC editing and
publication. There is general agreement that the continued publication of RFCs
remains an important goal. Disruptive changes to this part of the system would
be counterproductive.This proposal combines the RFC Production Center and RFC Publisher functions.
These have been conjoined in practice for many years already and so this merely
formalizes a standing arrangement.Motivating PrinciplesThe proposed structure is motivated by the following principles:
Community ownership:
The community at large owns the outcomes of this process and so it needs to
own the process too.
Open participation:
The principle of open participation in standardization has been critical to
success in the IETF. That provides a template for participation and governance
of this process.
Transparency:
Transparency is the most important part of ensuring that actors are
accountable. Avoiding decisions made in closed forums - or by individuals -
ensures that the community is best able to understand and contribute to the
operation of the system.
Divestiture of responsibility:
The title of RFC Series Editor has in the past been held by individuals with a
remarkably broad set of skills. Rather than dictate that an individual with the
diverse traits be selected, this design distributes that responsibility. This
allows for more flexibility and specialization.
Documentation RequirementsThis model depends on the production of a document (or set of documents) that
outlines the initial set of requirements for the operation of the REP. Much of
this already exists in the form of previous service agreements and
the expectation is that these documents can be adapted. These documents will
become the resposibility of the IETF LLC.Over time, some of the material from service agreements and contract are
expected to move to strategic documents maintained by the RFC Series Evolution
program.The RFC Series Evolution program will be responsible for maintaining this
document, along with other documents that describe the RFC Series, such as
, , and . Continuing
publication of these documents on the IAB represents no change to existing
practice.Errors and OmissionsThis is a draft. At this stage, it is intended to just show the general outline
of the model. As details are filled in, everything here is liable to change.
There are likely many errors, omissions, and inconsistencies.There are lots of small details in that are still likely relevant and
would need to be tweaked to fit within the proposed structure.Security ConsiderationsMuch of the success of systems like this can be attributed to the dilligent work
of individuals who strive to resolve issues collaboratively. Generally
speaking, it is good to assume that this will continue. However, this document
does attempt to establish where authority lies for any particular decision in
case of lapses or disagreements.This document aims to provide some measure of security against failure of any
single person to execute their function in good faith. That doesn't mean that a
malicious actor operating in any of the critical roles could not choose to be
extremely disruptive. In addition to some expectation of reasonableness, this
system defines entities (often bodies) to whom each actor is answerable or who
are empowered to resolve disputes.IANA ConsiderationsThis document makes no request of IANA.ReferencesNormative ReferencesRFC Editor Model (Version 2)IABThe 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.Key words for use in RFCs to Indicate Requirement LevelsIn 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.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 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.IETF Working Group Guidelines and ProceduresThis 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.Informative ReferencesRFC Production Center Services AgreementStructure of the IETF Administrative Support Activity, Version 2.0The IETF Administrative Support Activity (IASA) was originally established in 2005. In the years since then, the needs of the IETF evolved in ways that required changes to its administrative structure. The purpose of this RFC is to document and describe the IETF Administrative Support Activity, version 2.0 (IASA 2.0). It defines the roles and responsibilities of the IETF Administration LLC Board (IETF LLC Board), the IETF Executive Director, and the Internet Society in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IETF LLC Board.This document obsoletes RFC 4071, RFC 4333, and RFC 7691.RFC Series Model ProcessThe RFC Series has come to a crossroads where questions must be answered regarding how the Series should be managed, the role of the RFC Series Editor, and the oversight of the RFC Editor function. This draft offers a proposal to form a new IAB program called the RFC Editor Future Development Program. This proposal is based on the discussions held during three virtual meetings in September and October 2019, as well as the RSEME session at IETF 106, and requests a new, open IAB program that will drive consensus around any changes to the RFC Editor model. The program will require extensive community engagement and outreach to a broad set of stakeholder communities.RFC Style GuideThis document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 2223, "Instructions to RFC Authors".RFC Editor Model (Version 2)IABThe 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.RFC Streams, Headers, and BoilerplatesRFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document obsoletes RFC 5741, moving detailed content to an IAB web page and preparing for more flexible output formats.AcknowledgmentsThis is not new thinking. You might, if you were so inclined, find all of these
concepts in emails or documents from other people.