Internet DRAFT - draft-thomson-rfced-model
draft-thomson-rfced-model
rfced-future M. Thomson
Internet-Draft Mozilla
Updates: 4844, 6635 (if approved) 10 August 2020
Intended status: Informational
Expires: 11 February 2021
A Proposed Model for RFC Editing and Publication
draft-thomson-rfced-model-01
Abstract
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.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion 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/
(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
(https://github.com/martinthomson/rfced-model).
Status of This Memo
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/.
Thomson Expires 11 February 2021 [Page 1]
Internet-Draft RFC Editor Model August 2020
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 11 February 2021.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Abstract Model . . . . . . . . . . . . . . . . . . . . . . . 4
4. Funding and Oversight . . . . . . . . . . . . . . . . . . . . 4
4.1. IETF LLC Delegation of Oversight Function . . . . . . . . 5
5. Evolution and Setting Policies . . . . . . . . . . . . . . . 6
5.1. Individual Interactions . . . . . . . . . . . . . . . . . 8
5.2. The Needs of Different Streams . . . . . . . . . . . . . 8
5.3. Style Guide . . . . . . . . . . . . . . . . . . . . . . . 8
6. Tooling . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Management of Individual Functions . . . . . . . . . . . . . 11
8. Other Involved Entities . . . . . . . . . . . . . . . . . . . 12
9. Changes from Version 2 . . . . . . . . . . . . . . . . . . . 12
9.1. No RFC Series Editor . . . . . . . . . . . . . . . . . . 12
9.2. Preserved Aspects of Current Practice . . . . . . . . . . 13
9.3. Motivating Principles . . . . . . . . . . . . . . . . . . 13
10. Documentation Requirements . . . . . . . . . . . . . . . . . 14
11. Errors and Omissions . . . . . . . . . . . . . . . . . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . . 14
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
14.1. Normative References . . . . . . . . . . . . . . . . . . 15
14.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
Thomson Expires 11 February 2021 [Page 2]
Internet-Draft RFC Editor Model August 2020
1. Introduction
The RFC Editor Model [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 [MODEL] 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.
2. Conventions and Definitions
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.
Thomson Expires 11 February 2021 [Page 3]
Internet-Draft RFC Editor Model August 2020
3. Abstract Model
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: Simplified RFC Production Model
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.
4. Funding and Oversight
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.
Thomson Expires 11 February 2021 [Page 4]
Internet-Draft RFC Editor Model August 2020
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 [LLC].
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.
4.1. IETF LLC Delegation of Oversight Function
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.
Thomson Expires 11 February 2021 [Page 5]
Internet-Draft RFC Editor Model August 2020
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.
5. Evolution and Setting Policies
Setting 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 [WG] 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 [RSEME]. This results in a group that
follows [WG] 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
Thomson Expires 11 February 2021 [Page 6]
Internet-Draft RFC Editor Model August 2020
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.
+------+
| IAB |
+--+---+
|
| Oversight
v
+-----+------+
| RFC Series |
| Evolution |
| Program |
+-----+------+
|
| 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
Thomson Expires 11 February 2021 [Page 7]
Internet-Draft RFC Editor Model August 2020
5.1. Individual Interactions
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 RFC Series Evolution program is to provide a single
venue for discussion of changes to REP requirements, processes, and
procedures.
5.2. The Needs of Different Streams
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 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.
5.3. Style Guide
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.
Thomson Expires 11 February 2021 [Page 8]
Internet-Draft RFC Editor Model August 2020
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.
6. Tooling
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.
Thomson Expires 11 February 2021 [Page 9]
Internet-Draft RFC Editor Model August 2020
+------+
| IAB |
+--+---+
|
| Oversight
v
+-----+------+
+-------------+ Participate | RFC Series |
| Community +------------->+ Evolution |
+-----+-------+ | Program |
^ +-----+------+
| |
| 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.
Thomson Expires 11 February 2021 [Page 10]
Internet-Draft RFC Editor Model August 2020
Any problems arising from this arrangement will be raised with the
IETF LLC as they pertain to meeting operational goals.
7. Management of Individual Functions
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 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.
Thomson Expires 11 February 2021 [Page 11]
Internet-Draft RFC Editor Model August 2020
8. Other Involved Entities
Many 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.
9. Changes from Version 2
This document describes a structure that appears quite different from
current practice. This section addresses significant differences and
similarities with the existing system.
9.1. No RFC Series Editor
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.
Thomson Expires 11 February 2021 [Page 12]
Internet-Draft RFC Editor Model August 2020
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.
9.2. Preserved Aspects of Current Practice
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.
9.3. Motivating Principles
The 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
Thomson Expires 11 February 2021 [Page 13]
Internet-Draft RFC Editor Model August 2020
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.
10. Documentation Requirements
This 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 [RPC-SA] 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 [MODEL], [RFC-SERIES], and [BOILERPLATE]. Continuing
publication of these documents on the IAB represents no change to
existing practice.
11. Errors and Omissions
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.
There are lots of small details in [MODEL] that are still likely
relevant and would need to be tweaked to fit within the proposed
structure.
12. Security Considerations
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.
Thomson Expires 11 February 2021 [Page 14]
Internet-Draft RFC Editor Model August 2020
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.
13. IANA Considerations
This document makes no request of IANA.
14. References
14.1. Normative References
[MODEL] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor
Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June
2012, <https://www.rfc-editor.org/info/rfc6635>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[WG] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418,
September 1998, <https://www.rfc-editor.org/info/rfc2418>.
14.2. Informative References
[BOILERPLATE]
Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed.,
"RFC Streams, Headers, and Boilerplates", RFC 7841,
DOI 10.17487/RFC7841, May 2016,
<https://www.rfc-editor.org/info/rfc7841>.
[LLC] 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,
<https://www.rfc-editor.org/info/rfc8711>.
Thomson Expires 11 February 2021 [Page 15]
Internet-Draft RFC Editor Model August 2020
[RFC-SERIES]
Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor
Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June
2012, <https://www.rfc-editor.org/info/rfc6635>.
[RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
DOI 10.17487/RFC7322, September 2014,
<https://www.rfc-editor.org/info/rfc7322>.
[RPC-SA] IAOC, ., "RFC Production Center Services Agreement", 1
January 2016, <https://iaoc.ietf.org/documents/ISOC-AMS-
RPC-1Jan2016-Agreement-V1-Executed-PUBLIC.pdf>.
[RSEME] Flanagan, H., "RFC Series Model Process", Work in
Progress, Internet-Draft, draft-flanagan-rseme-03, 19
November 2019, <http://www.ietf.org/internet-drafts/draft-
flanagan-rseme-03.txt>.
Acknowledgments
This is not new thinking. You might, if you were so inclined, find
all of these concepts in emails or documents from other people.
Author's Address
Martin Thomson
Mozilla
Email: mt@lowentropy.net
Thomson Expires 11 February 2021 [Page 16]
