9. Miscellaneous Issues
9.1. When There Are No IANA Actions
Before an Internet-Draft can be published as an RFC, IANA needs to
know what actions (if any) it needs to perform. Experience has shown
that it is not always immediately obvious whether a document has no
IANA actions, without reviewing the document in some detail. In
order to make it clear to IANA that it has no actions to perform (and
that the author has consciously made such a determination), such
documents should, after the authors confirm that this is the case,
include an IANA Considerations section that states:
This document has no IANA actions.
IANA prefers that these "empty" IANA Considerations sections be left
in the document for the record: it makes it clear later on that the
document explicitly said that no IANA actions were needed (and that
it wasn't just omitted). This is a change from the prior practice of
requesting that such sections be removed by the RFC Editor, and
authors are asked to accommodate this change.
9.2. Namespaces Lacking Documented Guidance
For all existing RFCs that either explicitly or implicitly rely on
IANA to make assignments without specifying a precise assignment
policy, IANA will work with the IESG to decide what policy is
appropriate. Changes to existing policies can always be initiated
through the normal IETF consensus process, or through the IESG when
All future RFCs that either explicitly or implicitly rely on IANA to
register or otherwise administer namespace assignments must provide
guidelines for administration of the namespace.
9.3. After-the-Fact Registrations
Occasionally, the IETF becomes aware that an unassigned value from a
namespace is in use on the Internet or that an assigned value is
being used for a different purpose than it was registered for. The
IETF does not condone such misuse; procedures of the type described
in this document need to be applied to such cases, and it might not
always be possible to formally assign the desired value. In the
absence of specifications to the contrary, values may only be
reassigned for a different purpose with the consent of the original
assignee (when possible) and with due consideration of the impact of
such a reassignment. In cases of likely controversy, consultation
with the IESG is advised.
This is part of the reason for the advice in Section 3.1 about using
placeholder values, such as "TBD1", during document development:
problems are often caused by the open use of unregistered values
after results from well-meant, early implementations, where the
implementations retained the use of developmental code points that
never proceeded to a final IANA assignment.
9.4. Reclaiming Assigned Values
Reclaiming previously assigned values for reuse is tricky, because
doing so can lead to interoperability problems with deployed systems
still using the assigned values. Moreover, it can be extremely
difficult to determine the extent of deployment of systems making use
of a particular value. However, in cases where the namespace is
running out of unassigned values and additional ones are needed, it
may be desirable to attempt to reclaim unused values. When
reclaiming unused values, the following (at a minimum) should be
o Attempts should be made to contact the original party to which a
value is assigned, to determine if the value was ever used, and if
so, the extent of deployment. (In some cases, products were never
shipped or have long ceased being used. In other cases, it may be
known that a value was never actually used at all.)
o Reassignments should not normally be made without the concurrence
of the original requester. Reclamation under such conditions
should only take place where there is strong evidence that a value
is not widely used, and the need to reclaim the value outweighs
the cost of a hostile reclamation. IESG Approval is needed in
o It may be appropriate to write up the proposed action and solicit
comments from relevant user communities. In some cases, it may be
appropriate to write an RFC that goes through a formal IETF
process (including IETF Last Call) as was done when DHCP reclaimed
some of its "Private Use" options [RFC3942].
o It may be useful to differentiate between revocation, release, and
transfer. Revocation occurs when IANA removes an assignment,
release occurs when the assignee initiates that removal, and
transfer occurs when either revocation or release is coupled with
immediate reassignment. It may be useful to specify procedures
for each of these or to explicitly prohibit combinations that are
9.5. Contact Person vs Assignee or Owner
Many registries include designation of a technical or administrative
contact associated with each entry. Often, this is recorded as
contact information for an individual. It is unclear, though, what
role the individual has with respect to the registration: is this
item registered on behalf of the individual, the company the
individual worked for, or perhaps another organization the individual
was acting for?
This matters because some time later, when the individual has changed
jobs or roles, and perhaps can no longer be contacted, someone might
want to update the registration. IANA has no way to know what
company, organization, or individual should be allowed to take the
registration over. For registrations rooted in RFCs, the stream
owner (such as the IESG or the IAB) can make an overriding decision.
But in other cases, there is no recourse.
Registries can include, in addition to a "Contact" field, an
"Assignee" or "Owner" field (also referred to as "Change Controller")
that can be used to address this situation, giving IANA clear
guidance as to the actual owner of the registration. This is
strongly advised, especially for registries that do not require RFCs
to manage their information (e.g., registries with policies such as
First Come First Served (Section 4.4), Expert Review (Section 4.5),
and Specification Required (Section 4.6)). Alternatively,
organizations can put an organizational role into the "Contact" field
in order to make their ownership clear.
9.6. Closing or Obsoleting a Registry/Registrations
Sometimes there is a request to "close" a registry to further
registrations. When a registry is closed, no further registrations
will be accepted. The information in the registry will still be
valid and registrations already in the registry can still be updated.
A closed registry can also be marked as "obsolete", as an indication
that the information in the registry is no longer in current use.
Specific entries in a registry can be marked as "obsolete" (no longer
in use) or "deprecated" (use is not recommended).
Such changes to registries and registered values are subject to
normal change controls (see Section 2.3). Any closure, obsolescence,
or deprecation serves to annotate the registry involved; the
information in the registry remains there for informational and
Appeals of protocol parameter registration decisions can be made
using the normal IETF appeals process as described in [RFC2026],
Section 6.5. That is, an initial appeal should be directed to the
IESG, followed (if necessary) by an appeal to the IAB.
11. Mailing Lists
All IETF mailing lists associated with evaluating or discussing
assignment requests as described in this document are subject to
whatever rules of conduct and methods of list management are
currently defined by best current practices or by IESG decision.
12. Security Considerations
Information that creates or updates a registration needs to be
authenticated and authorized. IANA updates registries according to
instructions in published RFCs and from the IESG. It may also accept
clarifications from document authors, relevant working group chairs,
designated experts, and mail list participants.
Information concerning possible security vulnerabilities of a
protocol may change over time. Likewise, security vulnerabilities
related to how an assigned number is used may change as well. As new
vulnerabilities are discovered, information about such
vulnerabilities may need to be attached to existing registrations so
that users are not misled as to the true security issues surrounding
the use of a registered number.
Security needs to be considered as part of the selection of a
registration policy. For some protocols, registration of certain
parameters will have security implications, and registration policies
for the relevant registries must ensure that requests get appropriate
review with those security implications in mind.
An analysis of security issues is generally required for all
protocols that make use of parameters (data types, operation codes,
keywords, etc.) documented in IETF protocols or registered by IANA.
Such security considerations are usually included in the protocol
document [BCP72]. It is the responsibility of the IANA
considerations associated with a particular registry to specify
whether value-specific security considerations must be provided when
assigning new values and the process for reviewing such claims.
13. IANA Considerations
Sitewide, IANA has replaced references to RFC 5226 with references to
14. Changes Relative to Earlier Editions of BCP 26
14.1. 2016: Changes in This Document Relative to RFC 5226
o Removed RFC 2119 key words, boilerplate, and reference, preferring
plain English -- this is not a protocol specification.
o Added Section 1.1, Keep IANA Considerations for IANA
o Added Section 1.2, For Updated Information
o Added Section 2.1, Organization of Registries
o Added best practice for selecting an appropriate policy into
o Added Section 4.12, Using Multiple Policies in Combination
o Added Section 2.3, Specifying Change Control for a Registry
o Added Section 3.4, Early Allocations
o Moved each well-known policy into a separate subsection of
o Added Section 5.4, Expert Reviews and the Document Lifecycle
o Added Section 7, Documentation References in IANA Registries
o Added Section 8, What to Do in "bis" Documents
o Added Section 9.5, Contact Person vs Assignee or Owner
o Added Section 9.6, Closing or Obsoleting a Registry/Registrations
Clarifications and such:
o Some reorganization -- moved text around for clarity and easier
o Made clarifications about identification of IANA registries and
use of URLs for them.
o Clarified the distinction between "Unassigned" and "Reserved".
o Made some clarifications in "Expert Review" about instructions to
the designated expert.
o Made some clarifications in "Specification Required" about how to
declare this policy.
o Assorted minor clarifications and editorial changes throughout.
14.2. 2008: Changes in RFC 5226 Relative to RFC 2434
o Major reordering of text to expand descriptions and to better
group topics such as "updating registries" vs. "creating new
registries", in order to make it easier for authors to find the
text most applicable to their needs.
o Numerous editorial changes to improve readability.
o Changed the term "IETF Consensus" to "IETF Review" and added more
clarifications. History has shown that people see the words "IETF
Consensus" (without consulting the actual definition) and are
quick to make incorrect assumptions about what the term means in
the context of IANA Considerations.
o Added "RFC Required" to list of defined policies.
o Much more explicit directions and examples of "what to put in
o "Specification Required" now implies use of a designated expert to
evaluate specs for sufficient clarity.
o Added a section describing provisional registrations.
o Significantly changed the wording in the "Designated Experts"
section. Main purpose is to make clear that Expert Reviewers are
accountable to the community, and to provide some guidance for
review criteria in the default case.
o Changed wording to remove any special appeals path. The normal
RFC 2026 appeals path is used.
o Added a section about reclaiming unused values.
o Added a section on after-the-fact registrations.
o Added a section indicating that mailing lists used to evaluate
possible assignments (such as by a designated expert) are subject
to normal IETF rules.
15.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
15.2. Informative References
[BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
Acknowledgments for This Document (2017)
Thomas Narten and Harald Tveit Alvestrand edited the two earlier
editions of this document (RFCs 2434 and 5226), and Thomas continues
his role in this third edition. Much of the text from RFC 5226
remains in this edition.
Thank you to Amanda Baber and Pearl Liang for their multiple reviews
and suggestions for making this document as thorough as possible.
This document has benefited from thorough review and comments by many
people, including Benoit Claise, Alissa Cooper, Adrian Farrel,
Stephen Farrell, Tony Hansen, John Klensin, Kathleen Moriarty, Mark
Nottingham, Pete Resnick, and Joe Touch.
Special thanks to Mark Nottingham for reorganizing some of the text
for better organization and readability, to Tony Hansen for acting as
document shepherd, and to Brian Haberman and Terry Manderson for
acting as sponsoring ADs.
Acknowledgments from the Second Edition (2008)
The original acknowledgments section in RFC 5226 was:
This document has benefited from specific feedback from Jari Arkko,
Marcelo Bagnulo Braun, Brian Carpenter, Michelle Cotton, Spencer
Dawkins, Barbara Denny, Miguel Garcia, Paul Hoffman, Russ Housley,
John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus
Westerlund, and Bert Wijnen.
Acknowledgments from the First Edition (1998)
The original acknowledgments section in RFC 2434 was:
Jon Postel and Joyce Reynolds provided a detailed explanation on what
IANA needs in order to manage assignments efficiently, and patiently
provided comments on multiple versions of this document. Brian
Carpenter provided helpful comments on earlier versions of the
document. One paragraph in the Security Considerations section was
borrowed from RFC 4288.
PTI, an affiliate of ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
United States of America
Phone: +1 646 827 0648
3039 Cornwallis Ave., PO Box 12195 - BRQA/502
Research Triangle Park, NC 27709-2195
United States of America
Phone: +1 919 254 7798