RFC 8126 - Guidelines for Writing an IANA Considerations Section in RFCs

RFC 8126 - Guidelines for Writing an IANA Considerations Section in RFCs Light Dark Auto RFC 8126 Best Current Practice Title Guidelines for Writing an IANA Considerations Section in RFCs Document Document type RFC - Best Current Practice June 2017 View errata Report errata Updated by RFC 9907 Obsoletes RFC 5226 Was draft-leiba-cotton-iana-5226bis (individual) Select version 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 RFC 8126 Compare versions RFC 8126 draft-leiba-cotton-iana-5226bis-20 draft-leiba-cotton-iana-5226bis-19 draft-leiba-cotton-iana-5226bis-18 draft-leiba-cotton-iana-5226bis-17 draft-leiba-cotton-iana-5226bis-16 draft-leiba-cotton-iana-5226bis-15 draft-leiba-cotton-iana-5226bis-14 draft-leiba-cotton-iana-5226bis-13 draft-leiba-cotton-iana-5226bis-12 draft-leiba-cotton-iana-5226bis-11 draft-leiba-cotton-iana-5226bis-10 draft-leiba-cotton-iana-5226bis-09 draft-leiba-cotton-iana-5226bis-08 draft-leiba-cotton-iana-5226bis-07 draft-leiba-cotton-iana-5226bis-06 draft-leiba-cotton-iana-5226bis-05 draft-leiba-cotton-iana-5226bis-04 draft-leiba-cotton-iana-5226bis-03 draft-leiba-cotton-iana-5226bis-02 draft-leiba-cotton-iana-5226bis-01 draft-leiba-cotton-iana-5226bis-00 RFC 8126 draft-leiba-cotton-iana-5226bis-20 draft-leiba-cotton-iana-5226bis-19 draft-leiba-cotton-iana-5226bis-18 draft-leiba-cotton-iana-5226bis-17 draft-leiba-cotton-iana-5226bis-16 draft-leiba-cotton-iana-5226bis-15 draft-leiba-cotton-iana-5226bis-14 draft-leiba-cotton-iana-5226bis-13 draft-leiba-cotton-iana-5226bis-12 draft-leiba-cotton-iana-5226bis-11 draft-leiba-cotton-iana-5226bis-10 draft-leiba-cotton-iana-5226bis-09 draft-leiba-cotton-iana-5226bis-08 draft-leiba-cotton-iana-5226bis-07 draft-leiba-cotton-iana-5226bis-06 draft-leiba-cotton-iana-5226bis-05 draft-leiba-cotton-iana-5226bis-04 draft-leiba-cotton-iana-5226bis-03 draft-leiba-cotton-iana-5226bis-02 draft-leiba-cotton-iana-5226bis-01 draft-leiba-cotton-iana-5226bis-00 Side-by-side Inline Authors M. Cotton , B. Leiba , T. Narten Email authors RFC stream Other formats txt html bibtex Report a bug Internet Engineering Task Force (IETF) M. Cotton Request for Comments: 8126 PTI BCP: 26 B. Leiba Obsoletes: 5226 Huawei Technologies Category: Best Current Practice T. Narten ISSN: 2070-1721 IBM Corporation June 2017 Guidelines for Writing an IANA Considerations Section in RFCs Abstract Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8126. Cotton, et al. Best Current Practice [Page 1] RFC 8126 IANA Considerations Section in RFCs June 2017 Copyright Notice Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Keep IANA Considerations for IANA . . . . . . . . . . . . 4 1.2. For Updated Information . . . . . . . . . . . . . . . . . 5 1.3. A Quick Checklist Upfront . . . . . . . . . . . . . . . . 5 2. Creating and Revising Registries . . . . . . . . . . . . . . 7 2.1. Organization of Registries . . . . . . . . . . . . . . . 8 2.2. Documentation Requirements for Registries . . . . . . . . 8 2.3. Specifying Change Control for a Registry . . . . . . . . 11 2.4. Revising Existing Registries . . . . . . . . . . . . . . 11 3. Registering New Values in an Existing Registry . . . . . . . 12 3.1. Documentation Requirements for Registrations . . . . . . 12 3.2. Updating Existing Registrations . . . . . . . . . . . . . 14 3.3. Overriding Registration Procedures . . . . . . . . . . . 14 3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 15 4. Choosing a Registration Policy and Well-Known Policies . . . 15 4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . 18 4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 19 4.4. First Come First Served . . . . . . . . . . . . . . . . . 19 4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 20 4.6. Specification Required . . . . . . . . . . . . . . . . . 21 4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . 22 4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 22 4.9. Standards Action . . . . . . . . . . . . . . . . . . . . 23 4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 23 4.11. Using the Well-Known Registration Policies . . . . . . . 24 4.12. Using Multiple Policies in Combination . . . . . . . . . 26 4.13. Provisional Registrations . . . . . . . . . . . . . . . . 26 Cotton, et al. Best Current Practice [Page 2] RFC 8126 IANA Considerations Section in RFCs June 2017 5. Designated Experts . . . . . . . . . . . . . . . . . . . . . 27 5.1. The Motivation for Designated Experts . . . . . . . . . . 27 5.2. The Role of the Designated Expert . . . . . . . . . . . . 27 5.2.1. Managing Designated Experts in the IETF . . . . . . . 29 5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 29 5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 31 6. Well-Known Registration Status Terminology . . . . . . . . . 31 7. Documentation References in IANA Registries . . . . . . . . . 32 8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 33 9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . 34 9.1. When There Are No IANA Actions . . . . . . . . . . . . . 34 9.2. Namespaces Lacking Documented Guidance . . . . . . . . . 35 9.3. After-the-Fact Registrations . . . . . . . . . . . . . . 35 9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . 35 9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 36 9.6. Closing or Obsoleting a Registry/Registrations . . . . . 37 10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 37 12. Security Considerations . . . . . . . . . . . . . . . . . . . 37 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . 38 14.1. 2016: Changes in This Document Relative to RFC 5226 . . 38 14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 39 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 15.1. Normative References . . . . . . . . . . . . . . . . . . 40 15.2. Informative References . . . . . . . . . . . . . . . . . 40 Acknowledgments for This Document (2017) . . . . . . . . . . . . 46 Acknowledgments from the Second Edition (2008) . . . . . . . . . 46 Acknowledgments from the First Edition (1998) . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Cotton, et al. Best Current Practice [Page 3] RFC 8126 IANA Considerations Section in RFCs June 2017 1. Introduction Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. The Protocol field in the IP header [RFC791] and MIME media types [RFC6838] are two examples of such coordinations. The IETF selects an IANA Functions Operator (IFO) for protocol parameters defined by the IETF. In the contract between the IETF and the current IFO (ICANN), that entity is referred to as the IANA PROTOCOL PARAMETER SERVICES Operator, or IPPSO. For consistency with past practice, the IFO or IPPSO is referred to in this document as "IANA" [RFC2860]. In this document, we call the range of possible values for such a field a "namespace". The binding or association of a specific value with a particular purpose within a namespace is called an assignment (or, variously: an assigned number, assigned value, code point, protocol constant, or protocol parameter). The act of assignment is called a registration, and it takes place in the context of a registry. The terms "assignment" and "registration" are used interchangeably throughout this document. To make assignments in a given namespace prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. Typically, this information is recorded in a dedicated section of the specification with the title "IANA Considerations". 1.1. Keep IANA Considerations for IANA The purpose of having a dedicated IANA Considerations section is to provide a single place to collect clear and concise information and instructions for IANA. Technical documentation should reside in other parts of the document; the IANA Considerations should refer to these other sections by reference only (as needed). Using the IANA Considerations section as primary technical documentation both hides it from the target audience of the document and interferes with IANA's review of the actions they need to take. Cotton, et al. Best Current Practice [Page 4] RFC 8126 IANA Considerations Section in RFCs June 2017 An ideal IANA Considerations section clearly enumerates and specifies each requested IANA action; includes all information IANA needs, such as the full names of all applicable registries; and includes clear references to elsewhere in the document for other information. The IANA actions are normally phrased as requests for IANA (such as, "IANA is asked to assign the value TBD1 from the Frobozz Registry..."); the RFC Editor will change those sentences to reflect the actions taken ("IANA has assigned the value 83 from the Frobozz Registry..."). 1.2. For Updated Information IANA maintains a web page that includes additional clarification information beyond what is provided here, such as minor updates and summary guidance. Document authors should check that page. Any significant updates to the best current practice will have to f…