Internet Engineering Task Force A. Baber Internet-Draft IANA Intended status: Standards Track 5 June 2025 Expires: 7 December 2025 Early IANA Registry Creation draft-baber-ianabis-early-registries-00 Abstract This memo describes the requirements for publishing a registry on the IANA website before the IETF Stream document that creates the registry is approved for publication as an RFC. This process can be used when a Working Group needs to coordinate allocations among multiple documents or with an organization outside the IETF. 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 7 December 2025. Copyright Notice Copyright (c) 2025 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Baber Expires 7 December 2025 [Page 1] Internet-Draft Early IANA Registry Creation June 2025 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conditions for Early Registry Creation . . . . . . . . . . . 3 3. Process for Early Registry Creation . . . . . . . . . . . . . 3 3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Follow-Up . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Expiry . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Early Registry Initialization . . . . . . . . . . . . . . . . 5 5. Conditions for Allocation from Early Registries . . . . . . . 6 6. Alternatives to Early Registry Creation . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Protocol specifications documented in RFCs often need to create registries of names or code points for various objects, messages, or other protocol entities so that implementations can interoperate. Registry creation is handled by the Internet Assigned Numbers Authority (IANA) in accordance with processes described in [RFC8126]. Working groups that establish a new registry in one document may find that they need to allocate code points for other documents while the first document is still in development. However, adding those other allocations in the original document may prove impractical or undesireable. Additionally, the working group may need to create a registry that a group outside of the IETF urgently needs ongoing allocations from. Working groups may choose to maintain an informal registry internally until the IESG approves the registry document for publication as an RFC, at which point IANA would create an official registry. However, doing so risks the possibility that some party may not realize that the unofficial registry has been replaced, in which case they might self-assign codepoints that IANA has assigned for another purpose. IANA also has processes in place to ensure that requirements are met, and methods for tracking registration requests, among other advantages as a central coordinator. Baber Expires 7 December 2025 [Page 2] Internet-Draft Early IANA Registry Creation June 2025 This document is therefore proposing a method for creating registries before the IESG approves the document for publication. Creation requires the same approvals described in [RFC7120], the document that defines the early allocation process, and registries are likewise subject to expiration, but can be renewed. Early registry creation, as opposed to early allocation, introduces one new issue: registry maintenance, or early allocation from early registries. Any allocation will require either the [RFC7120] process or Working Group Chair approval, depending on the registration procedure intended for the final RFC-based registry. 2. Conditions for Early Registry Creation The following conditions must hold before IANA can process a request for early registry creation: 1. The registry must be described fully, in accordance with [RFC8126], in enough detail for IANA to be able to create the registry, maintain it, and determine its format and intended location. 2. The Working Group chairs and AD must determine that there is sufficient interest in the community for early (pre-RFC) implementation and deployment, or that the lack of central coordination before document approval could lead to registry maintenance issues. 3. If the registry is to be created primarily for use by an organization outside of the IETF, the Working Group chairs must be satisfied that the relevant parties are aware that the registry will be closed if the document that creates it does not advance. 4. The Working Group chairs must be willing to function as approvers for all requests for allocation from that registry until the document is approved for publication, as described in Section 5. If allocation from the finalized version of the registry will require an RFC, the Working Group chairs and Area Directors (ADs) must be willing to use the [RFC7120] early allocation process to allocate values. 3. Process for Early Registry Creation The processes described below assume that the document in question is the product of an IETF Working Group (WG). If this is not the case, replace "WG chairs" below with "Shepherding AD." Baber Expires 7 December 2025 [Page 3] Internet-Draft Early IANA Registry Creation June 2025 There are three processes associated with early allocation: making the request for registry creation, following up on the request, and, optionally, revoking the registry. 3.1. Request The process for requesting early registry creation is as follows: 1. The authors (editors) of the document submit a request for early creation to the Working Group chairs, specifying which registry should be created and where it should be placed. 2. The WG chairs determine whether the conditions for early registry creation described in Section 2 are met. 3. The WG chairs gauge whether there is consensus within the WG that early registry creation is appropriate for the given document. 4. If steps 2) and 3) are satisfied, the WG chairs request approval from the AD(s). The AD(s) may apply judgment to the request, especially if there is a risk that the registry will not be made permanent. 5. If the ADs approve step 4), the WG chairs contact IANA to request early registry creation. 6. IANA creates the registry in the appropriate location, marking it as "temporary," valid for a period of two years from the creation date. The creation and expiration dates are recorded in the registry and made visible to the public. 3.2. Follow-Up It is the responsibility of the document authors and the Working Group chairs to review changes in the document and determine whether changes to registry content or structure are required before the document is approved for publication. If the document progresses to the point at which IANA normally creates registries, IANA will make any necessary registry updates described by the document's IANA Considerations section and remove the "temporary" designation from the registry description. If the document will not progress, or if the registry is no longer required, the Working Group chairs should inform IANA. Baber Expires 7 December 2025 [Page 4] Internet-Draft Early IANA Registry Creation June 2025 3.3. Expiry As described in Section 3.1, the registry's expiration date is recorded and tracked by IANA. If the registry will expire before the IESG approves the document for publication, IANA will contact the WG chairs and AD to ask whether they wish to renew the registry for an additional two-year period. After the first extension, any further renewal requests must also be approved by the IESG. The renewal request to the IESG must include the reason(s) another renewal is necessary and the WG's plans for the specification. If an extension is not approved, IANA will close the registry and label it accordingly. The WG chairs can also instruct IANA to close the registry at any time. Implementers and deployers need to be aware of this possibility. Note that if the document that created the registry is submitted for review to the IESG, and at the time of submission the registry is valid (not expired), it will not be subject to expiration while the document is under IESG consideration. 4. Early Registry Initialization When early registry creation is approved, IANA will add the registry to the specified registry group. If the group has yet to be created, IANA will create a group, make it available at a new URL, and add a "temporary" designation to the name of the group as well as the registry itself. IANA will initialize the registry with the fields and registrations provided by the document's IANA Considerations section. Any desired registrations not included in the initializing document must be requested separately, after IANA creates the registry. IANA will temporarily substitute "RFC 7120 Early Allocation" or "WG Chair/AD Approval", as described below, for the registration procedures requested by the document. Baber Expires 7 December 2025 [Page 5] Internet-Draft Early IANA Registry Creation June 2025 5. Conditions for Allocation from Early Registries The document's IANA Considerations section must name one or more registration procedures for the registry, as described in [RFC8126]. However, those procedures will not apply until the registry has been finalized (i.e., until the document that creates the registry has been approved for publication). Instead, IANA will apply the following registration procedures: * RFC 7120 Early Allocation: if the projected registration procedure will require an RFC (e.g., "IETF Review", "Standards Action With Expert Review"), entry into the early registry will require the early allocation procedure described in [RFC7120]. When the registry itself is made permanent, these allocations will still be marked "temporary" until their associated documents are approved for publication. If the Working Group or shepherding AD responsible for the registry is not the source of the early allocation request, the requesting chair or AD should consult with the appropriate chairs or AD before contacting IANA. * WG Chair/AD Approval: if the projected registration procedure will not require an RFC (e.g., "First Come First Served"," "Expert Review"), allocations must be approved by a Working Group chair responsible for the registry (or by the shepherding AD, if applicable). Once approved, these allocations do not require renewal. 6. Alternatives to Early Registry Creation Early registry creation is an option, not a requirement, for coordinating future allocations. Internal lists maintained by the Working Group are another option, as long as the maintainer makes the list inaccessible after IANA creates the registry. A more formal, perhaps less risky method is for the authors of the registry-creating document to function as the initial registrar. In this scenario, the authors update their IANA Considerations section with allocations for other in-progress documents, assigning values and naming the appropriate document in the registry's "Reference" field. When their document is approved for publication as an RFC, IANA re-publishes the registry contents, including registrations that refer to other documents. Baber Expires 7 December 2025 [Page 6] Internet-Draft Early IANA Registry Creation June 2025 7. IANA Considerations This document defines early registry creation procedures that will be implemented by IANA. Specifically, IANA will create early registries, manage the resulting allocation requests, track and report expiring early registries, and initiate the early registry renewal process in accordance with this document. 8. Security Considerations As noted in [RFC7120], it is important to keep in mind that denial- of-service attacks on IANA are possible as a result of the processes defined in this memo. IANA may at any time request that the IESG suspend the procedures described in this document. [NOTE: IANA will ask for guidance in describing other potential security issues.] 9. References 9.1. Normative References [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, . 9.2. Informative References [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, . Acknowledgements This document uses text written by Kireeti Kompella, Alex Zinin, and Michelle Cotton for RFC 4020 and RFC 7120. Author's Address Amanda Baber Internet Assigned Numbers Authority PTI/ICANN 12025 Waterfront Drive Los Angeles, 90094 United States of America Baber Expires 7 December 2025 [Page 7] Internet-Draft Early IANA Registry Creation June 2025 Email: amanda.baber@iana.org Baber Expires 7 December 2025 [Page 8]