| rfced-future | B. Carpenter |
| Internet-Draft | Univ. of Auckland |
| Intended status: Informational | August 20, 2020 |
| Expires: February 21, 2021 |
Alternative Proposed Model for RFC Editing and Publication
draft-carpenter-rfced-model-00
The 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. It would require significant updates to RFC 8728 and RFC 8729, and minor updates to RFC 2850 and RFC 7841.
Discussion of this document takes place on the RFC Editor Futures mailing list (rfced-future@iab.org).
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 21, 2021.
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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Please note that large portions of this draft have been copied, with permission, from [I-D.thomson-rfced-model]. However, the two proposals are substantively different.
The RFC Editor Model [RFC8728] describes a system that supports the process of editing and publication of RFCs. Its companion document [RFC8729] covers the related organizational roles, including that of the RFC Series Editor (RSE) in person. Both of these documents were issued by the IAB in pursuance of the relevant item in its charter [RFC2850].
The process of RFC editing and publication currently takes inputs in the form of documents that are approved for publication by one of four existing streams (IETF, IRTF, IAB, and Independent Submissions) [RFC7841]. 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 evolve. The current system has evolved out of a relatively simple system, into something like what is described in [RFC8728] 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.
The highest-level abstraction is shown in Figure 1.
+-------------+ +-------------+ | IETF Stream +------->+ +-----> +-------------+ D | | +-------------+ o | | | IRTF Stream +---c--->+ RFC +-----> R +-------------+ u | Editing | F +-------------+ m | and | C | IAB Stream +---e--->+ Publication +-----> s +-------------+ n | | +-------------+ t | | | Independent +---s--->+ +-----> +-------------+ +-------------+
Figure 1: RFC Production Model
In this model, each of the 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). In [RFC8728], two separate functions are identified (RFC Production Center and RFC Publisher) but externally that distinction seems pointless. The entity (or entities) that perform the REP function are contracted to turn approved documents into RFCs.
The 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 [RFC8711].
This results in evolving the basic model as shown in Figure 2.
+------+
| IETF |
| LLC |
+------+
|
| Contract &
| Oversight
v
+-------------+ +-------------+
| IETF Stream +------->+ +----->
+-------------+ D | |
+-------------+ o | |
| IRTF Stream +---c--->+ RFC +-----> R
+-------------+ u | Editing | F
+-------------+ m | and | C
| IAB Stream +---e--->+ Publication +-----> s
+-------------+ n | |
+-------------+ t | |
| Independent +---s--->+ +----->
+-------------+ +-------------+
Figure 2: Oversight and Funding Functions
This shows the IETF LLC having budgetary and contractual oversight over the REP.
The 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 might choose 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 REP. Any appeal or dispute with the actions of this individual or committee would then be taken up with the IETF LLC.
Setting the strategy and policies for REP functions and more detailed requirements for operation of these functions have historically been delegated to the RSE. This document proposes separating these. The goal is to improve the ability of the community (across all streams) to set and evolve policies. Operational details and targets, on the other hand, clearly fall under the LLC.
The strategic requirements of each of the streams change 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 [RFC2418] used in the IETF to the maximum extent possible, given that the community of interest is broader than the IETF.
Concretely, this document proposes forming an RFC Series Advisory Working Group (RSAWG) under the auspices of the Internet Society (ISOC). This would be a group that follows [RFC2418] procedures, with the exception that the oversight and conflict resolution functions performed by the IESG are instead performed by ISOC. In particular, selection of chairs and appeals regarding the execution of the process are directed to the ISOC Board of Trustees to resolve. This is intended to underline the community-wide importance of the RFC Series.
Like any IETF working group, the RSAWG will be open to any interested person. This explicitly includes staff of the REP. However, in addition to at least two chairs appointed by ISOC, it is important that each RFC stream has a named representative in the RSAWG who is able to present the requirements of that stream.
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.
Much of the strategy will be concerned with the technical needs of the streams or with other matters that protocol engineers are competent to discuss. However, some matters will arise that are questions of technical editing, publishing, archiving, etc. Protocol engineers cannot be assumed to have the necessary expertise for these topics. Therefore, an outside RFC Series Advisor (RSA) is needed. More details are given below.
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 Figure 3.
+------+
| ISOC |
+--+---+
|
| Oversight
v
+-----+------+
| RFC Series |
| Advisory |<------- RFC Series Advisor
| WG | (RSA)
+-----+------+
|
| Strategy
v
+--+---+
| IETF |
| LLC |
+--+---+
|
| Contract &
| Oversight
v
+-------------+ +---------+---+
| IETF Stream +------->+ +----->
+-------------+ D | |
+-------------+ o | |
| IRTF Stream +---c--->+ RFC +-----> R
+-------------+ u | Editing | F
+-------------+ m | and | C
| IAB Stream +---e--->+ Publication +-----> s
+-------------+ n | |
+-------------+ t | |
| Independent +---s--->+ +----->
+-------------+ +-------------+
Figure 3: Evolution and Strategy Additions
It 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 RSAWG is to provide a single venue for discussion of changes to REP requirements, processes, and procedures.
The 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 RSAWG. To avoid conflicts of interest, it is expected that stream managers will be active participants - and not chairs - in this group.
One question that arises when considering policy is that of the Style Guide [RFC7322] 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 RSAWG 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 RSAWG 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. This is also a major reason why REP staff might choose to participate directly in the RSAWG.
The nature of the process the RSAWG 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.
Producing 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 Figure 4.
+------+
| ISOC |
+--+---+
|
| Oversight
v
+-----+------+
+-------------+ Participate | RFC Series |
| Community +------------->+ Advisory |<------- RFC Series Advisor
+-----+-------+ | WG | (RSA)
^ +-----+------+
| |
| Provide Tools | Strategy
| v
+-----+-------+ +--+---+
| Tools | Contract(s) | IETF |
| Maintenance +<----------------+ LLC |
+-----+-------+ +--+---+
| |
+--Provide-Tools-------+ | Contract &
| | Oversight
v v
+-------------+ +---+-----+---+
| IETF Stream +------->+ +----->
+-------------+ D | |
+-------------+ o | |
| IRTF Stream +---c--->+ RFC +-----> R
+-------------+ u | Editing | F
+-------------+ m | and | C
| IAB Stream +---e--->+ Publication +-----> s
+-------------+ n | |
+-------------+ t | |
| Independent +---s--->+ +----->
+-------------+ +-------------+
Figure 4: Final Model
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.
This 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 implies that the committee has adequate decision-making processes. The IETF LLC is ultimately responsible and its processes for consultation with and accountability to the broader community will apply to delegated reponsibility.
The choice of leadership for the RSAWG is important with a move to a system that lacks a single figurehead. Two measures are suggested to mitigate the temptation for this leadership to become an effective replacement for the RSE position:
These are suggestions to the ISOC 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 development or 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.
Many documents involve actions for IANA that are processed in parallel with the REP processing. These processes need to be documented, as for example in [RFC6359].
This draft describes a model whereby the existing RFC Series Advisory Group (which serves at the pleasure of the RSE) has no future as it serves a role that does not exist in this model. This group embodies 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.
This person will be a senior professional with deep knowledge of technical publishing.
The RSA will operate by providing expert advice to the RSAWG, and if requested to the REP, on any relevant matters. For example, the RSA might be consulted about proposed changes to the style guide, RFC formatting in general, web presence, copyright matters, or archiving policy.
The RSA is expected to attend and facilitate all RSAWG meetings, and to participate in and facilitate RSAWG on-line discussions.
Further, the RSA is expected to ensure that RSAWG consensus is well documented and communicated to the community, the LLC, and the REP. This may include document authorship.
The RSA is expected to be a thought leader for improvements to the RFC Series, for developing vision and policy documents, and for establishing community consensus for them.
The RSA will operate under a part-time professional services contract with the LLC, with performance review by the LLC in consultation with the RSAWG chairs.
This document describes a structure that appears quite different from current practice. This section addresses significant differences and similarities with the existing system.
This 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 RSAWG. Expert input to the RSAWG will be provided by the RSA.
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 charged with 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.
The Internet Architecture Board loses its responsibility for oversight of the RFC Series. The managerial and administrative aspects are taken over by the LLC, and the strategic aspects by a community process based on the RSAWG.
This is consistent with the disbanding of the RSOC.
This 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.
The proposed structure is motivated by the following principles.
At least the following documents need to be updated.
The new 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 existing 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 RSAWG.
There should be a fifth RFC stream, namely the RFC Editorial Stream, in which relevant documents (such as the two just mentioned, future updates of the Style Guide, and documents defining the RFC format) would be published. This will avoid the current anomaly of such documents being published by the IAB. A corresponding update of [RFC7841] will be needed.
This 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.
Much 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.
This document makes no request of IANA.
Large portions of this draft have been copied, with permission, from [I-D.thomson-rfced-model].
The name of the proposed new RFC stream was coined by Mike St Johns.
This is not new thinking. You might, if you were so inclined, find all of these concepts in emails or documents from other people.
| [RFC2418] | Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, September 1998. |
| [RFC2850] | Internet Architecture Board and B. Carpenter, "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000. |
| [I-D.thomson-rfced-model] | Thomson, M., "A Proposed Model for RFC Editing and Publication", Internet-Draft draft-thomson-rfced-model-01, August 2020. |
| [RFC6359] | Ginoza, S., Cotton, M. and A. Morris, "Datatracker Extensions to Include IANA and RFC Editor Processing Information", RFC 6359, DOI 10.17487/RFC6359, September 2011. |
| [RFC7322] | Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, DOI 10.17487/RFC7322, September 2014. |
| [RFC7841] | Halpern, J., Daigle, L. and O. Kolkman, "RFC Streams, Headers, and Boilerplates", RFC 7841, DOI 10.17487/RFC7841, May 2016. |
| [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. |
| [RFC8728] | Kolkman, O., Halpern, J. and R. Hinden, "RFC Editor Model (Version 2)", RFC 8728, DOI 10.17487/RFC8728, February 2020. |
| [RFC8729] | Housley, R. and L. Daigle, "The RFC Series and RFC Editor", RFC 8729, DOI 10.17487/RFC8729, February 2020. |