RSWG B. E. Carpenter Internet-Draft Univ. of Auckland Intended status: Informational 12 February 2024 Expires: 15 August 2024 Policy Considerations for Changes to RFCs draft-carpenter-rswg-rfc-changes-00 Abstract This document describes policies applicable when the text of an RFC is modified after it has been approved for publication. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-carpenter-rswg-rfc-changes/. Discussion of this document takes place on the RSWG Working Group mailing list (mailto:rswg@rfc-editor.org), which is archived at https://mailarchive.ietf.org/arch/browse/rswg/. 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/. 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 15 August 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Carpenter Expires 15 August 2024 [Page 1] Internet-Draft RFC Change Policy February 2024 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Policy Considerations . . . . . . . . . . . . . . . . . . . . 2 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 Appendix A. Change Log [RFC Editor: please remove] . . . . . . . 3 A.1. Draft-00 . . . . . . . . . . . . . . . . . . . . . . . . 3 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction It is very common that the text of an RFC needs to altered after a draft has been approved for publication. 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. 3. Changes made after initial publication of the RFC, when significant editorial or technical errors have been reported and 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) revision version of the RFC. 2. 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: Carpenter Expires 15 August 2024 [Page 2] Internet-Draft RFC Change Policy February 2024 1. The changed version must be formally approved by a member of the original approving body. Each 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 forum. (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; disputes must be resolved by the stream itself. 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. 3. IANA Considerations No IANA actions are needed. 4. Security Considerations This document does not directly affect the security of the Internet. 5. Acknowledgements Useful comments were received from [TBD] ... Appendix A. Change Log [RFC Editor: please remove] A.1. Draft-00 * Original version Author's Address Brian E. Carpenter The University of Auckland School of Computer Science The University of Auckland PB 92019 Auckland 1142 New Zealand Carpenter Expires 15 August 2024 [Page 3] Internet-Draft RFC Change Policy February 2024 Email: brian.e.carpenter@gmail.com Carpenter Expires 15 August 2024 [Page 4]