Skip to main content

1. Introduction

Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. The Protocol field in the IP header [RFC791] and MIME media types [RFC6838] are two examples of such coordinations.

The IETF selects an IANA Functions Operator (IFO) for protocol parameters defined by the IETF. In the contract between the IETF and the current IFO (ICANN), that entity is referred to as the IANA PROTOCOL PARAMETER SERVICES Operator, or IPPSO. For consistency with past practice, the IFO or IPPSO is referred to in this document as "IANA" [RFC2860].

In this document, we call the range of possible values for such a field a "namespace". The binding or association of a specific value with a particular purpose within a namespace is called an assignment (or, variously: an assigned number, assigned value, code point, protocol constant, or protocol parameter). The act of assignment is called a registration, and it takes place in the context of a registry. The terms "assignment" and "registration" are used interchangeably throughout this document.

To make assignments in a given namespace prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.

Typically, this information is recorded in a dedicated section of the specification with the title "IANA Considerations".

1.1. Keep IANA Considerations for IANA​

The purpose of having a dedicated IANA Considerations section is to provide a single place to collect clear and concise information and instructions for IANA. Technical documentation should reside in other parts of the document; the IANA Considerations should refer to these other sections by reference only (as needed). Using the IANA Considerations section as primary technical documentation both hides it from the target audience of the document and interferes with IANA's review of the actions they need to take.

An ideal IANA Considerations section clearly enumerates and specifies each requested IANA action; includes all information IANA needs, such as the full names of all applicable registries; and includes clear references to elsewhere in the document for other information.

The IANA actions are normally phrased as requests for IANA (such as, "IANA is asked to assign the value TBD1 from the Frobozz Registry..."); the RFC Editor will change those sentences to reflect the actions taken ("IANA has assigned the value 83 from the Frobozz Registry...").

1.2. For Updated Information​

IANA maintains a web page that includes additional clarification information beyond what is provided here, such as minor updates and summary guidance. Document authors should check that page. Any significant updates to the best current practice will have to feed into updates to BCP 26 (this document), which is definitive.

https://iana.org/help/protocol-registration

1.3. A Quick Checklist Upfront​

It's useful to be familiar with this document as a whole. But when you return for quick reference, here are checklists for the most common things you'll need to do and references to help with the less common ones.

In general...

  1. Put all the information that IANA will need to know into the "IANA Considerations" section of your document (see Section 1.1).

  2. Try to keep that section only for information to IANA and to designated expert reviewers; put significant technical information in the appropriate technical sections of the document (see Section 1.1).

  3. Note that the IESG has the authority to resolve issues with IANA registrations. If you have any questions or problems, you should consult your document shepherd and/or working group chair, who may ultimately involve an Area Director (see Section 3.3).

If you are creating a new registry...

  1. Give the registry a descriptive name and provide a brief description of its use (see Section 2.2).

  2. Identify any registry grouping that it should be part of (see Section 2.1).

  3. Clearly specify what information is required in order to register new items (see Section 2.2). Be sure to specify data types, lengths, and valid ranges for fields.

  4. Specify the initial set of items for the registry, if applicable (see Section 2.2).

  5. Make sure the change control policy for the registry is clear to IANA, in case changes to the format or policies need to be made later (see Sections 2.3 and 9.5).

  6. Select a registration policy -- or a set of policies -- to use for future registrations (see Section 4, and especially note Sections 4.11 and 4.12).

  7. If you're using a policy that requires a designated expert (Expert Review or Specification Required), understand Section 5 and provide review guidance to the designated expert (see Section 5.3).

  8. If any items or ranges in your registry need to be reserved for special use or are otherwise unavailable for assignment, see Section 6.

If you are registering into an existing registry...

  1. Clearly identify the registry by its exact name and optionally by its URL (see Section 3.1).

  2. If the registry has multiple ranges from which assignments can be made, make it clear which range is requested (see Section 3.1).

  3. Avoid using specific values for numeric or bit assignments, and let IANA pick a suitable value at registration time (see Section 3.1). This will avoid registration conflicts among multiple documents.

  4. For "reference" fields, use the document that provides the best and most current documentation for the item being registered. Include section numbers to make it easier for readers to locate the relevant documentation (see Sections 3.1 and 7).

  5. Look up (in the registry's reference document) what information is required for the registry and accurately provide all the necessary information (see Section 3.1).

  6. Look up (in the registry's reference document) any special rules or processes there may be for the registry, such as posting to a particular mailing list for comment, and be sure to follow the process (see Section 3.1).

  7. If the registration policy for the registry does not already dictate the change control policy, make sure it's clear to IANA what the change control policy is for the item, in case changes to the registration need to be made later (see Section 9.5).

If you're writing a "bis" document or otherwise making older documents obsolete, see Section 8.

If you need to make an early registration, such as for supporting test implementations during document development, rather than waiting for your document to be finished and approved, see [RFC7120].

If you need to change the format/contents or policies for an existing registry, see Section 2.4.

If you need to update an existing registration, see Section 3.2.

If you need to close down a registry because it is no longer needed, see Section 9.6.