diff options
Diffstat (limited to 'doc/rfc/rfc8726.txt')
| -rw-r--r-- | doc/rfc/rfc8726.txt | 281 |
1 files changed, 281 insertions, 0 deletions
diff --git a/doc/rfc/rfc8726.txt b/doc/rfc/rfc8726.txt new file mode 100644 index 0000000..bda95d4 --- /dev/null +++ b/doc/rfc/rfc8726.txt @@ -0,0 +1,281 @@ + + + + +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 |