Early IANA Registry Creation
draft-ietf-ianabis-early-registries-01

Internet Engineering Task Force                                 A. Baber
Internet-Draft                                                      IANA
Intended status: Standards Track                             4 June 2026
Expires: 6 December 2026

                      Early IANA Registry Creation
                 draft-ietf-ianabis-early-registries-01

Abstract

   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.

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 6 December 2026.

Copyright Notice

   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.

Baber                    Expires 6 December 2026                [Page 1]
Internet-Draft        Early IANA Registry Creation             June 2026

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conditions for Early Registry Creation  . . . . . . . . . . .   3
   3.  Process for Early Registry Creation . . . . . . . . . . . . .   4
     3.1.  Request . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Follow-Up . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Expiry  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Early Registry Initialization . . . . . . . . . . . . . . . .   5
   5.  Conditions for Allocation from Early Registries . . . . . . .   6
     5.1.  WG Chair Approval . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Sponsoring AD Approval  . . . . . . . . . . . . . . . . .   6
     5.3.  Early Allocation (draft-ietf-ianabis-rfc7120bis)  . . . .   6
     5.4.  Updating Registration Procedures  . . . . . . . . . . . .   7
     5.5.  Temporary Procedures for "Specification Required"
           Registries  . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Alternatives to Early Registry Creation . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

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
   [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

Baber                    Expires 6 December 2026                [Page 2]
Internet-Draft        Early IANA Registry Creation             June 2026

   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.

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
       [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.

   2.  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.

   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.

Baber                    Expires 6 December 2026                [Page 3]
Internet-Draft        Early IANA Registry Creation             June 2026

       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.

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 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.

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.

Baber                    Expires 6 December 2026                [Page 4]
Internet-Draft        Early IANA Registry Creation             June 2026

3.2.  Follow-Up

   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.

   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.

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 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.

4.  Early Registry Initialization

   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.

Baber                    Expires 6 December 2026                [Page 5]
Internet-Draft        Early IANA Registry Creation             June 2026

   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.

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
   [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.

5.1.  WG Chair Approval

   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.

5.2.  Sponsoring AD Approval

   Identical to the "WG Chair Approval" procedure, but in this case the
   sponsoring AD serves as the approver for AD-sponsored documents.

5.3.  Early Allocation (draft-ietf-ianabis-rfc7120bis)

   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

Baber                    Expires 6 December 2026                [Page 6]
Internet-Draft        Early IANA Registry Creation             June 2026

   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.

5.4.  Updating Registration Procedures

   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.

5.5.  Temporary Procedures for "Specification Required" 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.

Baber                    Expires 6 December 2026                [Page 7]
Internet-Draft        Early IANA Registry Creation             June 2026

   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.

6.  Alternatives to Early Registry Creation

   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.

   Before deciding to use one Internet-Draft to record other drafts'
   registrations, authors and WGs should consider the following:

   *  If the registry is recording a registration for another draft, the
      registration must be requested in the other draft's IANA
      Considerations section.

   *  The registry should be updated when registrations are changed,
      deleted, or transferred to other documents.  However, the parties
      responsible for those registrations may not always notify the
      registry maintainer.

   *  If the registry will require RFC publication, each registration
      must refer to either the registering document or another document
      already approved for publication as an RFC, if only as an
      additional reference.  However, referring to the registering
      document when the registration is wholly specified by another RFC
      or Internet-Draft is often discouraged.  For this reason, we
      strongly recommend limiting this registry-creation approach to
      First Served and Expert Review registries (and Specification
      Required registries, if the document declares Internet-Drafts
      eligible for permanent registration).

Baber                    Expires 6 December 2026                [Page 8]
Internet-Draft        Early IANA Registry Creation             June 2026

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

   If early registry creation introduces security or other concerns,
   IANA may ask the IESG to suspend the procedure at any time.

   %% QUESTION FOR IANABIS: should any specific security considerations
   be documented here? %%

9.  References

9.1.  Normative References

   [I-D.ietf-ianabis-rfc8126bis]
              Baber, A. and S. Tanamal, "Guidelines for Writing an IANA
              Considerations Section in RFCs", Work in Progress,
              Internet-Draft, draft-ietf-ianabis-rfc8126bis-01, 21
              February 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-ianabis-rfc8126bis-01>.

9.2.  Informative References

   [I-D.ietf-ianabis-rfc7120bis]
              Baber, A. and S. Tanamal, "Early IANA Code Point
              Allocation", Work in Progress, Internet-Draft, draft-ietf-
              ianabis-rfc7120bis-01, 12 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ianabis-
              rfc7120bis-01>.

Acknowledgements

   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.

Author's Address

Baber                    Expires 6 December 2026                [Page 9]
Internet-Draft        Early IANA Registry Creation             June 2026

   Amanda Baber
   Internet Assigned Numbers Authority
   PTI/ICANN
   12025 Waterfront Drive
   Los Angeles,  90094
   United States of America
   Email: amanda.baber@iana.org

Baber                    Expires 6 December 2026               [Page 10]