Network Working Group A. Farrel Internet-Draft Independent Submissions Editor Intended status: Informational August 14, 2019 Expires: February 15, 2020 How Requests for IANA Action Will be Handled on the Independent Stream draft-ise-iana-policy-01 Abstract The Internet Assigned Numbers Authority (IANA) maintains registries to track codepoints used by protocols such as those defined by the IETF and documented in RFCs developed on the IETF Stream. The Independent Submissions 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 Submissions Stream that request actions from the 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 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 February 15, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Farrel Expires February 15, 2020 [Page 1] Internet-Draft IANA and the Independent Stream August 2019 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. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Allocations from Existing Registries . . . . . . . . . . . . 3 3. Changing Policies of Existing Registries . . . . . . . . . . 3 4. Creating New IANA Registries . . . . . . . . . . . . . . . . 3 5. Assigning Designated Experts . . . . . . . . . . . . . . . . 4 6. Transfer of Control . . . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 8. Security Considerations . . . . . . . . . . . . . . . . . . . 4 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 10. Normative References . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The Internet Assigned Numbers Authority (IANA) maintains registries to track codepoints 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 . 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 Submissions Stream (the Independent Stream) as described in [RFC4846]. The Independent Stream is under the care 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 the IANA. Nothing in this document changes existing IANA registries or their allocation policies, nor does it change any previously documented processes. Farrel Expires February 15, 2020 [Page 2] Internet-Draft IANA and the Independent Stream August 2019 In the event that 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 allocation policy of the registry itself, and usually require documentation from the same stream as 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 new registries are needed to track a new set of codepoints 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 registry. The only exception to this rule is the creation of a sub-registry that is specifically tied to a code point allocated for the same document from an existing registry where the allocation policy for that document is Specification Required, Expert Review, or RFC Required. Furthermore, where there is an appointed DE for the parent registry, that DE must approve the creation of the sub-registry. Farrel Expires February 15, 2020 [Page 3] Internet-Draft IANA and the Independent Stream August 2019 Additionally, the allocation policy for the new sub-registry may only be First Come First Served, RFC Required, Experimental, or Private Use. In particular, no sub-registry may be created that would require IETF action to achieve a future codepoint allocation. See Section 5 for an explanation of why the application of Specification Required and Expert Review are not acceptable policies for any sub- registry created from a document in the Independent Stream. 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 all sub-registries created for Independent Stream documents will not require the review of a DE. That means that no new sub-registry 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 would 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 Farrel Expires February 15, 2020 [Page 4] Internet-Draft IANA and the Independent Stream August 2019 registries contributes to the stability of the protocols themselves. That is a benefit for the security of the Internet and the users of the Internet. 9. Acknowledgements Thanks to Brian Carpenter, Subramanian Moonesamy, Craig Partridge, Michelle Cotton, Andrew Malis, Warren Kumari, Ned Freed, Rich Salz, Michael Richardson, Colin Perkins, and Brian Carpenter for suggestions and advice. 10. Normative References [RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent Submissions to the RFC Editor", RFC 4846, DOI 10.17487/RFC4846, July 2007, . [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, . Author's Address Adrian Farrel Independent Submissions Editor Email: rfc-ise@rfc-editor.org Farrel Expires February 15, 2020 [Page 5]