| Internet-Draft | Early IANA Registry Creation | February 2026 |
| Baber | Expires 24 August 2026 | [Page] |
This memo describes the requirements for establishing an IANA registry before the IETF Stream document that creates the registry is approved for publication as an RFC. This process can be used when an IETF working group needs to coordinate allocations among multiple documents or with an organization outside the IETF.¶
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 24 August 2026.¶
Copyright (c) 2026 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.¶
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 [I-D.ietf-ianabis-rfc8126bis].¶
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 undesirable.¶
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 coordination resources.¶
This document is therefore proposing methods for creating and maintaining IANA registries before the IESG approves the document for publication.¶
Creation requires the same approval processes described in [I-D.ietf-ianabis-rfc7120bis], the document that defines an early allocation process for IETF stream Internet-Drafts, and early registries are likewise subject to expiration, barring renewal or finalization.¶
Early registry creation also requires a process for obtaining allocations from an early registry. This process will require either approval by a Working Group chair, approval by the sponsoring Area Director (AD), or the IETF stream Internet-Draft process described in [I-D.ietf-ianabis-rfc7120bis], depending on the registration procedure intended for the finalized registry.¶
The following conditions must hold before IANA can process a request for early registry creation:¶
The registry must be described fully, in accordance with [I-D.ietf-ianabis-rfc8126bis], in enough detail for IANA to be able to create the registry, maintain it, and determine its format and location.¶
The Working Group chairs and Area Director (AD) must determine that there is sufficient interest in the community for early implementation and deployment, before the document that creates the registry is approved for publication as an RFC, or that a lack of central coordination before document approval could result in registry maintenance issues.¶
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.¶
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 [I-D.ietf-ianabis-rfc7120bis] early allocation process to allocate values.¶
The processes described below assume that the document in question is the product of an IETF Working Group (WG). If the document is instead sponsored by an AD, replace "WG chairs" below with "sponsoring AD."¶
There are three processes associated with early allocation: making the request for registry creation, following up on the request, and, optionally, revoking the registry.¶
The process for requesting early registry creation is as follows:¶
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.¶
The WG chairs determine whether the conditions for early registry creation described in Section 2 are met.¶
The WG chairs gauge whether there is consensus within the WG that early registry creation is appropriate for the given document.¶
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.¶
If the ADs approve step 4), the WG chairs contact IANA to request early registry creation.¶
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.¶
The document authors and Working Group chairs are responsible for reviewing changes in the document and determining whether changes to registry content or structure are required before the document is approved for publication.¶
%% QUESTION FOR IANABIS: Does the AD need to approve registry structure/procedure changes? We don't ask them to approve changes to registrations, although it could be said that they should check for this when they approve renewals. %%¶
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.¶
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 request that IANA 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.¶
When early registry creation is approved, IANA will initialize the registry with the registrations provided by the document's IANA Considerations section, indicate that the registry is temporary, and temporarily list this document as an additional reference for the registry.¶
Any desired registrations not included in the initializing document must be requested separately, after IANA creates the registry.¶
Until the IESG approves the document for publication, IANA will maintain the registry in accordance with one or more of the registration procedures described below.¶
The document's IANA Considerations section must name one or more registration procedures for the registry, as described in [I-D.ietf-ianabis-rfc8126bis]. 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 one or more of the "WG Chair Approval," "Sponsoring AD Approval," and "Early Allocation" procedures described below.¶
If the projected registration procedure will not require an RFC (e.g., "First Come First Served", "Expert Review"), and the Internet-Draft that created the registry is the product of a working group, allocations must be approved by a Working Group chair responsible for the document. Once approved, these allocations do not require renewal.¶
If the projected registration procedure is "Specification Required," this procedure will apply under the circumstances described in Section 5.5.¶
Identical to the "WG Chair Approval" procedure, but in this case the sponsoring AD serves as the approver for AD-sponsored documents.¶
If the projected registration procedure will require an RFC (e.g., "IETF Review", "Standards Action"), entry into the early registry will be limited to IETF stream Internet-Drafts that qualify for the early allocation procedure described in [I-D.ietf-ianabis-rfc7120bis].¶
IANA will process requests in accordance with that document's Section 2.2, with WG chair and AD approval taking the place of any expert approval that would be required by a procedure like "Standards Action With Expert Review." When the registry itself is made permanent, these allocations will continue to be identified as temporary until their associated documents are also approved for publication.¶
If the Working Group or sponsoring AD responsible for the registry is not the source of the early allocation request, the requesting chair or AD should consult with the chairs or sponsoring AD for the registry before contacting IANA.¶
%% QUESTION FOR IANABIS: if a different WG needs to request an early allocation, should approval from the registry's WG chair be required or recommended? %%¶
If the projected registration procedure is "Specification Required," this procedure will apply under the circumstances described in Section 5.5.¶
If the projected registration procedure changes while the document is still in development, and the new procedure would call for a different temporary registration procedure (for example, if the projected procedure changes from "Expert Review" to "IETF Review"), IANA must be notified of the change. IANA will not track changes to documents that create early registries.¶
If the finalized registry will use the "Specification Required" policy, IANA will need to know whether Internet-Drafts will be be considered eligible for permanent registration once the registry is finalized.¶
If the specification is "Specification Required," and the document states that Internet-Drafts will be eligible for permanent registration, as described in [I-D.ietf-ianabis-rfc8126bis], the "WG Chair Approval" (or "Sponsoring AD Approval") procedure will apply to all registration requests.¶
If the projected registration procedure is "Specification Required," but the document does not declare Internet-Drafts eligible for permanent registration, the early registry will require two separate registration procedures: 1) the time-limited "Early Allocation" procedure available to IETF stream Internet-Drafts, and 2) permanent "WG Chair Approval" (or "Sponsoring AD Approval", as appropriate) registration for all specifications not published as Internet-Drafts. Registration would not be available to Internet-Drafts from outside the IETF stream.¶
If an organization outside the IETF needs code points from an early registry in order to publish a standard, WG Chairs and sponsoring ADs can choose to use the process described in [I-D.ietf-ianabis-rfc7120bis], if they consider it appropriate.¶
Early registry creation is an option for coordinating future allocations. It is not a requirement.¶
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 approach 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.¶
%% QUESTION FOR IANABIS: Should the paragraph below be removed? %%¶
However, if the new registry will require RFC publication for registration, it may not be possible to publish the document that creates the registry until all of the references within the registry can also be published as RFCs.¶
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.¶
As noted in [I-D.ietf-ianabis-rfc7120bis], 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.¶
%% ACTION FOR IANABIS: IANA needs the WG to supply other security considerations for early registry creation (if any). %%¶
This document uses text written by Kireeti Kompella, Alex Zinin, and Michelle Cotton for RFC 4020 and RFC 7120.¶
Thanks to Kim Davies, Sabrina Tanamal, and John Scudder for their reviews and recommendations.¶