RFC 5226 - Guidelines for Writing an IANA Considerations Section in RFCs Light Dark Auto RFC 5226 Best Current Practice Title Guidelines for Writing an IANA Considerations Section in RFCs Document Document type RFC - Best Current Practice May 2008 View errata Report errata Obsoleted by RFC 8126 Obsoletes RFC 2434 Was draft-narten-iana-considerations-rfc2434bis (individual in gen area) Select version 09 RFC 5226 Compare versions RFC 5226 draft-narten-iana-considerations-rfc2434bis-09 draft-narten-iana-considerations-rfc2434bis-08 draft-narten-iana-considerations-rfc2434bis-07 draft-narten-iana-considerations-rfc2434bis-06 draft-narten-iana-considerations-rfc2434bis-05 draft-narten-iana-considerations-rfc2434bis-04 draft-narten-iana-considerations-rfc2434bis-03 draft-narten-iana-considerations-rfc2434bis-02 draft-narten-iana-considerations-rfc2434bis-01 draft-narten-iana-considerations-rfc2434bis-00 RFC 5226 draft-narten-iana-considerations-rfc2434bis-09 draft-narten-iana-considerations-rfc2434bis-08 draft-narten-iana-considerations-rfc2434bis-07 draft-narten-iana-considerations-rfc2434bis-06 draft-narten-iana-considerations-rfc2434bis-05 draft-narten-iana-considerations-rfc2434bis-04 draft-narten-iana-considerations-rfc2434bis-03 draft-narten-iana-considerations-rfc2434bis-02 draft-narten-iana-considerations-rfc2434bis-01 draft-narten-iana-considerations-rfc2434bis-00 Side-by-side Inline Authors T. Narten , H. Alvestrand Email authors RFC stream Other formats txt html w/errata bibtex Report a bug 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 2008 Table 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 another kind of value. The binding or association of a specific value with a particular purpose within a namespace is called an assigned number (or assigned value, or sometimes a "code point", Narten & Alvestrand Best Current Practice [Page 2] RFC 5226 IANA Considerations Section in RFCs May 2008 "protocol constant", or "protocol parameter"). Each assignment of a value in a namespace is called a registration. In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values should be assigned or when (and how) modifications to existing values can be made. This document provides guidelines to authors on what sort of text should be added to their documents in order to provide IANA clear guidelines, and it reviews issues that should be considered in formulating an appropriate policy for assigning numbers to name spaces. Not all namespaces require centralized administration. In some cases, it is possible to delegate a namespace in such a way that further assignments can be made independently and with no further (central) coordination. In the Domain Name System, for example, IANA only deals with assignments at the higher levels, while subdomains are administered by the organization to which the space has been delegated. As another example, Object Identifiers (OIDs) as defined by the ITU are also delegated [ASSIGNED]; IANA manages the subtree rooted at "iso.org.dod.internet" (1.3.6.1) . When a namespace is delegated, the scope of IANA is limited to the parts of the namespace where IANA has authority. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. For this document, "the specification" as used by RFC 2119 refers to the processing of protocol documents within the IETF standards process. 2. Why Management of a Namespace May Be Necessary One issue to consider in managing a namespace is its size. If the space is small and limited in size, assignments must be made carefully to prevent exhaustion of the space. If the space is essentially unlimited, on the other hand, potential exhaustion will probably not be a practical concern at all. Even when the space is essentially unlimited, however, it is usually desirable to have at least a minimal review prior to assignment in order to: - prevent the hoarding of or unnecessary wasting of values. For example, if the space consists of text strings, it may be desirable to prevent entities from obtaining large sets of strings that correspond to desirable names (e.g., existing company names). Narten & Alvestrand Best Current Practice [Page 3] RFC 5226 IANA Considerations Section in RFCs May 2008 - provide a sanity check that the request actually makes sense and is necessary. Experience has shown that some level of minimal review from a subject matter expert is useful to prevent assignments in cases where the request is malformed or not actually needed (i.e., an existing assignment for an essentially equivalent service already exists). A second consideration is whether it makes sense to delegate the namespace in some manner. This route should be pursued when appropriate, as it lessens the burden on IANA for dealing with assignments. A third, and perhaps most important, consideration concerns potential impact on the interoperability of unreviewed extensions. Proposed protocol extensions generally benefit from community review; indeed, review is often essential to avoid future interoperability problems [PROTOCOL-EXT]. When the namespace is essentially unlimited and there are no potential interoperability issues, assigned numbers can safely be given out to anyone without any subjective review. In such cases, IANA can make assignments directly, provided that IANA is given specific instructions on what types of requests it should grant, and what information must be provided as part of a well-formed request for an assigned number. 3. Designated Experts 3.1. The Motivation for Designated Experts It should be noted that IANA does not create or define assignment policy itself; rather, it carries out policies that have been defined by others and published in RFCs. IANA must be given a set of guidelines that allow it to make allocation decisions with minimal subjectivity and without requiring any technical expertise with respect to the protocols that make use of a registry. In many cases, some review of prospective allocations is appropriate, and the question becomes who should perform the review and what is the purpose of the review. One might think that an IETF working group (WG) familiar with the namespace at hand should be consulted. In practice, however, WGs eventually disband, so they cannot be considered a permanent evaluator. It is also possible for namespaces to be created through individual submission documents, for which no WG is ever formed. Narten & Alvestrand Best Current Practice [Page 4] RFC 5226 IANA Considerations Section in RFCs May 2008 One way to ensure community review of prospective assignments is to have the requester submit a document for publication as an RFC. Such an action helps ensure that the specification is publicly and permanently available, and it allows some review of the specification prior to publication and assignment of the requested code points. This is the preferred way of ensuring review, and is particularly important if any potential interoperability issues can arise. For example, some assignments are not just assignments, but also involve an element of protocol specification. A new option may define fields that need to be parsed and acted on, which (if specified poorly) may not fit cleanly with the architecture of other options or the base protocols on which they are built. In some cases, however, the burden of publishing an RFC in order to get an assignment is excessive. However, it is generally still useful (and sometimes necessary) to discuss proposed additions on a mailing list dedicated to the purpose (e.g., the [email protected] for medi…