Independent IANA: How Requests for IANA Action Will Be Handled on the Independent Stream
Rules for IANA registries in documents outside the main IETF track.
Farrel, A., "How Requests for IANA Action Will Be Handled on the Independent Stream", RFC 8726, DOI 10.17487/RFC8726, November 2020, <https://www.rfc-editor.org/info/rfc8726>.
@misc{rfc8726,
series = {Request for Comments},
number = 8726,
howpublished = {RFC 8726},
publisher = {RFC Editor},
doi = {10.17487/RFC8726},
url = {https://www.rfc-editor.org/info/rfc8726},
author = {A. Farrel},
title = {{How Requests for IANA Action Will Be Handled on the Independent Stream}},
pagetotal = 6,
year = 2020,
month = nov,
} RFC text
Contents
Independent Submission A. Farrel Request for Comments: 8726 Independent Submissions Editor Category: Informational November 2020 ISSN: 2070-1721 How Requests for IANA Action Will Be Handled on the Independent Stream Abstract The Internet Assigned Numbers Authority (IANA) maintains registries to track code points used by protocols such as those defined by the IETF and documented in RFCs developed on the IETF Stream. The Independent Submission Stream is another source of documents that can be published as RFCs. This stream is under the care of the Independent Submissions Editor (ISE). This document complements RFC 4846 by providing a description of how the ISE currently handles documents in the Independent Submission Stream that request actions from IANA. Nothing in this document changes existing IANA registries or their allocation policies, nor does it change any previously documented processes. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see 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 https://www.rfc-editor.org/info/rfc8726. 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. Table of Contents 1. Introduction 2. Allocations from Existing Registries 3. Changing Policies of Existing Registries 4. Creating New IANA Registries 5. Assigning Designated Experts 6. Transfer of Control 7. IANA Considerations 8. Security Considerations 9. References 9.1. Normative References 9.2. Informative References Acknowledgements Author's Address 1. Introduction The Internet Assigned Numbers Authority (IANA) maintains registries to track code points used by protocols such as those defined by the IETF and documented in RFCs developed on the IETF Stream. A full list of registries and code points can be found at https://www.iana.org/protocols. Requests may be made to IANA for actions to create registries or to allocate code points from existing registries. Procedures for these operations are described in [RFC8126]. Many requests for IANA action are included in documents that are progressed for publication as RFCs. RFCs may be sourced from within the IETF (on the IETF Stream) but may also be sourced from other streams, including the Independent Submission Stream (the Independent Stream), as described in [RFC4846]. The Independent Stream is under the care of the Independent Submissions Editor (ISE). This document complements [RFC4846] by providing a description of how the ISE currently handles documents in the Independent Stream that request actions from IANA. Nothing in this document changes existing IANA registries or their allocation policies, nor does it change any previously documented processes. If a case arises that is not precisely covered by this document, the ISE may discuss a solution with the interested parties, including IANA, the IESG, the stream managers for other streams, and the authors of an Independent Submission that requests IANA action. 2. Allocations from Existing Registries Each IANA registry is governed by an allocation policy -- the rules that IANA applies to determine which code points can be allocated and under what circumstances. These policies are described in [RFC8126]. Documents proceeding from the Independent Stream will always follow the assignment policies defined for the registries from which they request allocations. Similarly, all code point assignments are subject to the oversight of any designated expert (DE) appointed for the registry. It should be noted that documents on the Independent Stream can never result in Standards Track RFCs and Independent Stream documents are never subject to IETF review. Thus, a registry whose policy is "IETF Review" or "Standards Action" [RFC8126] is not available to Independent Stream documents. 3. Changing Policies of Existing Registries From time to time, a decision is made to change the allocation policy for a registry. Such changes are normally only made using the allocation policy of the registry itself and usually require documentation from the same stream that created the registry. Independent Stream RFCs will not seek to change the allocation policies of any registries except those created by documents from the Independent Stream. The list of such registries is itself very limited (see Section 4). 4. Creating New IANA Registries Sometimes registries are needed to track a new set of code points for a new protocol or an extension to an existing protocol. In general, documents on the Independent Stream cannot request the creation of a new IANA registry. The only exception to this rule is when a document to be published in the Independent Submission Stream requests the allocation of a code point from an existing registry with the allocation policy Specification Required, Expert Review, RFC Required, or First Come First Served. Then the document to be published may also need to create a registry that is tied to that specific code point and is used for interpreting a sub-code. Consider, for example, the "Uniform Resource Identifier (URI) Schemes" registry [URL-URIschemes]. From time to time, a URI scheme may need a registry of associated parameters; for example, consider the tel URI scheme that has a register of parameters called the "tel URI Parameters" [URL-telURI]. Such examples are rare and only exist to support the allocation from the base registry. In such cases, where there is an appointed DE for the existing base registry, the assignment of the individual code point from the existing base registry and the creation of the new registry can only happen if the DE approves both actions. There are several further constraints on the new registry: * The allocation policy for the new registry may only be First Come First Served, RFC Required, Experimental, or Private Use. In particular, no registry may be created that would require IETF action to achieve a future code point allocation. See Section 5 for an explanation of why the application of Specification Required and Expert Review are not acceptable policies for any registry created from a document in the Independent Stream. * If the allocation policy for the new registry is First Come First Served, the document must contain a brief statement and explanation of the expected arrival rate of new registrations over time. * The new registry must contain a clear statement of the escalation process for any issues that arise with the registry. A model for this statement is as follows: | This registry was created by [RFCXXXX], which was published on the | Independent Submission Stream. Any issues that arise with the | management of this registry will be resolved by IANA in | consultation with the Independent Submissions Editor. * The IESG will be invited to provide its opinions about the advisability of the creation of any new registries during its conflict review of the document [RFC5742], and the ISE will give full consideration to such opinions. Authors of Independent Submission Stream documents should consider the most appropriate venue to host such registries, taking into account where the expertise for managing and reviewing registry assignments may be found. In some cases, this may mean that registries are hosted by organizations other than IANA. 5. Assigning Designated Experts Some IANA allocation policies (specifically, Specification Required and Expert Review) utilize the review of a DE. The procedures applicable to the appointment and actions of a DE are described in Section 5 of [RFC8126]. When a DE is appointed, the position must be maintained and supported by whoever designated the DE in the first place. That is, someone must appoint replacement DEs if necessary, and someone must provide a backstop in case the appointed DEs are unresponsive. The ISE will not appoint a DE. That means that no subregistry created for Independent Stream documents will require the review of a DE. That means that no new subregistry can be created that uses the Specification Required or Expert Review policies. 6. Transfer of Control Very rarely, it may be desirable to transfer "ownership" of an IANA registry from the Independent Stream to the IETF Stream. This might happen, for example, if a protocol was originally documented in the Independent Stream but has been adopted for work and standardization in the IETF. Such a transfer may require an IETF Stream RFC to act as the base reference for the registry and will require discussion and agreement with the ISE. Ownership of a registry will not be transferred from the IETF Stream to the Independent Stream. 7. IANA Considerations This document is all about IANA actions but makes no request for IANA action. 8. Security Considerations There are no direct security considerations arising from this document. It may be noted that some IANA registries relate to security protocols, and the stability and proper management of those registries contribute to the stability of the protocols themselves. That is a benefit for the security of the Internet and the users of the Internet. 9. References 9.1. Normative References [RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent Submissions to the RFC Editor", RFC 4846, DOI 10.17487/RFC4846, July 2007, <https://www.rfc-editor.org/info/rfc4846>. [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for Handling of Independent and IRTF Stream Submissions", BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009, <https://www.rfc-editor.org/info/rfc5742>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. 9.2. Informative References [URL-telURI] "tel URI Parameters", <https://www.iana.org/assignments/tel-uri-parameters>. [URL-URIschemes] "Uniform Resource Identifier (URI) Schemes", <https://www.iana.org/assignments/uri-schemes>. Acknowledgements Thanks to Brian Carpenter, Subramanian Moonesamy, Craig Partridge, Michelle Cotton, Andrew Malis, Warren Kumari, Ned Freed, Rich Salz, Michael Richardson, Colin Perkins, Stephen Farrell, Barry Leiba, and Benjamin Kaduk for suggestions and advice. Author's Address Adrian Farrel Independent Submissions Editor Email: rfc-ise@rfc-editor.org
AI ELI5
On this page
§1Introduction
The IETF publishes RFCs through several different streams. The main stream follows the IETF Standards Process, with extensive review and consensus. The Independent Submission Stream, managed by the Independent Submissions Editor (ISE), publishes valuable but independently authored documents that do not go through IETF review.
When documents in either stream request IANA actions—assignments from existing registries or creation of new registries—the rules are different. This RFC, complementing RFC 4846 which describes Independent Stream publication, spells out exactly what IANA requests Independent Stream documents can and cannot make.
Some documents are published as RFCs but not through the normal IETF approval process. This explains what kinds of IANA registry requests those independent documents are allowed to make.
§2Allocations from Existing Registries
Independent Stream documents can request code points from existing IANA registries, but only if the registry's allocation policy permits it. The registry policies are defined in RFC 8126. Policies like "First Come First Served" and "Expert Review" are open to Independent Stream documents. However, policies requiring "IETF Review" or "Standards Action" are off-limits to Independent Stream documents because those policies by definition require IETF participation.
All requests must still follow the allocation policy of the registry—if the policy requires expert review, the designated expert must approve the request. This ensures consistency and quality across all streams.
Independent Stream documents can ask for numbers from existing lists, as long as the list's rules allow it. But some lists are only for IETF documents, and Independent Stream documents cannot use those.
§3Creating New IANA Registries
Creating a new IANA registry is generally forbidden for Independent Stream documents. The only exception is when a document requests a code point from an existing registry with an open allocation policy (Specification Required, Expert Review, RFC Required, or First Come First Served), and that code point requires a sub-registry to interpret a sub-code. For example, a new URI scheme registered in the "URI Schemes" registry might need a companion registry for parameters specific to that scheme.
Even in this narrow case, the new registry must follow strict rules. Its allocation policy can only be First Come First Served, RFC Required, Experimental, or Private Use—no policy that would require future IETF action. The document must explain the expected rate of new registrations if the policy is First Come First Served. It must also contain an escalation process for issues, and the IESG is invited to comment on advisability during conflict review.
Independent Stream documents usually cannot create new official registries. The rare exception is when they register a code point and that code point needs its own small sub-registry, and only with specific rules attached.
§4Designated Experts and Support
Some IANA registries require Designated Expert review, where an expert vetted by the IETF checks each new assignment. The ISE will not appoint Designated Experts for Independent Stream registries. This means that no new sub-registry created by an Independent Stream document can use the "Specification Required" or "Expert Review" policies—because those require expert appointments that the ISE will not maintain.
This rule exists to prevent the IETF from inheriting the burden of maintaining expert review infrastructure for registries started outside the IETF process.
If a registry needs an expert to check new entries, only IETF documents can create it, because the IETF will maintain the expert. Independent Stream documents cannot create registries that need expert review.
§5Status and Context
RFC 8726 was published in November 2020 by Adrian Farrel as Independent Submissions Editor. It codifies and clarifies practices the ISE had already been following. The RFC makes plain to authors and the community the constraints on Independent Stream registry work, preventing surprises or conflicts downstream.
This document puts into writing the rules the Independent Submissions Editor already follows when approving IANA registry requests.