]> The University of Auckland

School of Computer Science The University of Auckland PB 92019 Auckland 1142 New Zealand brian.e.carpenter@gmail.com

Transport RSWG Internet-Draft This document describes policies applicable when the text of an RFC is modified after it has been approved for publication. About This Document Status information for this document may be found at . Discussion of this document takes place on the RSWG Working Group mailing list (), which is archived at .

Introduction It is very common that the text of an RFC needs to altered after a draft has been approved for publication by the relevant approving body for the relevant RFC stream, as defined in . There are three principal causes of such changes:

1. Editorial changes made by RPC staff, for example to correct grammatical errors or to respect the style guide.
2. Changes made after those editorial changes, during final processing before publication, at the request of the authors, document shepherd, or members of the approving body. These are colloquially called "AUTH48" changes for historical reasons. They are currently logged in a publicly archived mailing list.
3. Changes made after initial publication of the RFC, when significant editorial or technical errors have been reported by a reader and then approved by a member of the approving body. These are currently known as "verified errata" and they currently result in the posting of an updated (but unofficial) revised HTML version of the RFC.

Changes made as a result of general changes in RFC format, or of changes to the tools and markup formats used to produce RFCs, are not in scope for this document, as long as they do not alter the wording of the RFC.

Policy Considerations Whether a change is made during editing, during final processing, or to correct an error in the published version, the following principles must be respected:

1. The changed version must be formally approved by a member of the original approving body. Each RFC stream may require a consensus process or further approvals, which the stream will administer itself by an internal process. (This does not preclude informal contact between interested parties and the RPC.)
2. This process must be visible to the community, for example via an on-line discussion forum or a mailing list with a public archive. (This principle does not require announcement emails, but does not forbid them either.)
3. Each stream must provide a dispute resolution mechanism in case community members disagree with the changes made. This explicitly does not concern the RPC; such disputes must be resolved by the stream itself. Disputes with the RPC itself are a separate matter discussed in Section 4.4 of .

Note that these principles apply regardless of whether post-publication changes result in an official republication of the whole RFC, which is a separate issue. Thus they apply to the current "errata" system and to its possible replacement, as well as to the "AUTH48" system.

IANA Considerations No IANA actions are needed.

Security Considerations This document does not directly affect the security of the Internet.

Acknowledgements Useful comments were received from Eliot Lear, and other members of the RSWG.

Informative References 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 specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series. First, policy definition is the joint responsibility of the RFC Series Working Group (RSWG), which produces policy proposals, and the RFC Series Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFC Production Center (RPC) as contractually overseen by the IETF Administration Limited Liability Company (IETF LLC). In addition, various responsibilities of the RFC Editor function are now performed alone or in combination by the RSWG, RSAB, RPC, RFC Series Consulting Editor (RSCE), and IETF LLC. Finally, this document establishes the Editorial Stream for publication of future policy definition documents produced through the processes defined herein. This document obsoletes RFC 8728. This document updates RFCs 7841, 8729, and 8730.

Change Log [RFC Editor: please remove]

Draft-00

• Original version

Draft-01

• Clarifications, references.