Network Working Group T. Narten
Request for Comments: 5226 IBM
BCP: 26 H. Alvestrand
Obsoletes: 2434 Google
Category: Best Current Practice May 2008
Guidelines for Writing an IANA Considerations Section in RFCs
Status of This Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Abstract
Many protocols make use of identifiers consisting of constants and
other well-known values. Even after a protocol has been defined and
deployment has begun, new values may need to be assigned (e.g., for a
new option type in DHCP, or a new encryption or authentication
transform for IPsec). To ensure that such quantities have consistent
values and interpretations across all implementations, their
assignment must be administered by a central authority. For IETF
protocols, that role is provided by the Internet Assigned Numbers
Authority (IANA).
In order for IANA to manage a given namespace prudently, it needs
guidelines describing the conditions under which new values can be
assigned or when modifications to existing values can be made. If
IANA is expected to play a role in the management of a namespace,
IANA must be given clear and concise instructions describing that
role. This document discusses issues that should be considered in
formulating a policy for assigning values to a namespace and provides
guidelines for authors on the specific text that must be included in
documents that place demands on IANA.
This document obsoletes RFC 2434.
Narten & Alvestrand Best Current Practice [Page 1]RFC 5226 IANA Considerations Section in RFCs May 2008Table of Contents
1. Introduction ....................................................2
2. Why Management of a Namespace May Be Necessary ..................3
3. Designated Experts ..............................................4
3.1. The Motivation for Designated Experts ......................4
3.2. The Role of the Designated Expert ..........................5
3.3. Designated Expert Reviews ..................................7
4. Creating a Registry .............................................8
4.1. Well-Known IANA Policy Definitions .........................9
4.2. What to Put in Documents That Create a Registry ...........12
4.3. Updating IANA Guidelines for Existing Registries ..........15
5. Registering New Values in an Existing Registry .................15
5.1. What to Put in Documents When Registering Values ..........15
5.2. Updating Registrations ....................................17
5.3. Overriding Registration Procedures ........................17
6. Miscellaneous Issues ...........................................18
6.1. When There Are No IANA Actions ............................18
6.2. Namespaces Lacking Documented Guidance ....................19
6.3. After-the-Fact Registrations ..............................19
6.4. Reclaiming Assigned Values ................................19
7. Appeals ........................................................20
8. Mailing Lists ..................................................20
9. Security Considerations ........................................20
10. Changes Relative to RFC 2434 ..................................21
11. Acknowledgments ...............................................22
12. References ....................................................22
12.1. Normative References .....................................22
12.2. Informative References ...................................22
1. Introduction
Many protocols make use of fields that contain constants and other
well-known values (e.g., the Protocol field in the IP header [IP] or
MIME media types [MIME-REG]). Even after a protocol has been defined
and deployment has begun, new values may need to be assigned (e.g., a
new option type in DHCP [DHCP-OPTIONS] or a new encryption or
authentication transform for IPsec [IPSEC]). To ensure that such
fields have consistent values and interpretations in different
implementations, their assignment must be administered by a central
authority. For IETF protocols, that role is provided by the Internet
Assigned Numbers Authority (IANA) [IANA-MOU].
In this document, we call the set of possible values for such a field
a "namespace"; its actual value may be a text string, a number, or