RFC 8126
Guidelines for Writing an IANA Considerations Section in RFCs
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 appropriate. 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 considered:
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
this case.
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
not desired.
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 historic purposes.10. Appeals
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 this document.14. Changes Relative to Earlier Editions of BCP 26
14.1. 2016: Changes in This Document Relative to RFC 5226
Significant additions: 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 Section 4. 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 Section 4. 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 reading. 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
Changes include: 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
RFCs".
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. References
15.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<http://www.rfc-editor.org/info/rfc2026>.
15.2. Informative References
[BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
2003, <http://www.rfc-editor.org/info/bcp72>.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>. [RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, DOI 10.17487/RFC1591, March 1994, <http://www.rfc-editor.org/info/rfc1591>. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, DOI 10.17487/RFC2434, October 1998, <http://www.rfc-editor.org/info/rfc2434>. [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, DOI 10.17487/RFC2860, June 2000, <http://www.rfc-editor.org/info/rfc2860>. [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, DOI 10.17487/RFC2939, September 2000, <http://www.rfc-editor.org/info/rfc2939>. [RFC3228] Fenner, B., "IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)", BCP 57, RFC 3228, DOI 10.17487/RFC3228, February 2002, <http://www.rfc-editor.org/info/rfc3228>. [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, DOI 10.17487/RFC3575, July 2003, <http://www.rfc-editor.org/info/rfc3575>. [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, <http://www.rfc-editor.org/info/rfc3692>. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <http://www.rfc-editor.org/info/rfc3748>. [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <http://www.rfc-editor.org/info/rfc3864>.
[RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options", RFC 3942, DOI 10.17487/RFC3942, November 2004, <http://www.rfc-editor.org/info/rfc3942>. [RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, DOI 10.17487/RFC3968, December 2004, <http://www.rfc-editor.org/info/rfc3968>. [RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March 2005, <http://www.rfc-editor.org/info/rfc4025>. [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, DOI 10.17487/RFC4044, May 2005, <http://www.rfc-editor.org/info/rfc4044>. [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, DOI 10.17487/RFC4124, June 2005, <http://www.rfc-editor.org/info/rfc4124>. [RFC4169] Torvinen, V., Arkko, J., and M. Naslund, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2", RFC 4169, DOI 10.17487/RFC4169, November 2005, <http://www.rfc-editor.org/info/rfc4169>. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, DOI 10.17487/RFC4283, November 2005, <http://www.rfc-editor.org/info/rfc4283>. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <http://www.rfc-editor.org/info/rfc4340>.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, <http://www.rfc-editor.org/info/rfc4422>. [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, DOI 10.17487/RFC4446, April 2006, <http://www.rfc-editor.org/info/rfc4446>. [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, DOI 10.17487/RFC4520, June 2006, <http://www.rfc-editor.org/info/rfc4520>. [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006, <http://www.rfc-editor.org/info/rfc4589>. [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, DOI 10.17487/RFC4727, November 2006, <http://www.rfc-editor.org/info/rfc4727>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>. [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, DOI 10.17487/RFC5378, November 2008, <http://www.rfc-editor.org/info/rfc5378>. [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for Handling of Independent and IRTF Stream Submissions", BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009, <http://www.rfc-editor.org/info/rfc5742>. [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, DOI 10.17487/RFC5771, March 2010, <http://www.rfc-editor.org/info/rfc5771>. [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, DOI 10.17487/RFC5795, March 2010, <http://www.rfc-editor.org/info/rfc5795>.
[RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014, November 2010, <http://www.rfc-editor.org/info/rfc6014>. [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media Control Channel Framework", RFC 6230, DOI 10.17487/RFC6230, May 2011, <http://www.rfc-editor.org/info/rfc6230>. [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, <http://www.rfc-editor.org/info/rfc6275>. [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>. [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, DOI 10.17487/RFC6709, September 2012, <http://www.rfc-editor.org/info/rfc6709>. [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>. [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <http://www.rfc-editor.org/info/rfc6895>. [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, DOI 10.17487/RFC6994, August 2013, <http://www.rfc-editor.org/info/rfc6994>. [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <http://www.rfc-editor.org/info/rfc7120>. [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 7564, DOI 10.17487/RFC7564, May 2015, <http://www.rfc-editor.org/info/rfc7564>.
[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <http://www.rfc-editor.org/info/rfc7595>. [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <http://www.rfc-editor.org/info/rfc7752>. [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, <http://www.rfc-editor.org/info/rfc8141>.
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.
Authors' Addresses
Michelle Cotton PTI, an affiliate of ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 United States of America Phone: +1-424-254-5300 Email: michelle.cotton@iana.org URI: https://www.iana.org/ Barry Leiba Huawei Technologies Phone: +1 646 827 0648 Email: barryleiba@computer.org URI: http://internetmessagingtechnology.org/ Thomas Narten IBM Corporation 3039 Cornwallis Ave., PO Box 12195 - BRQA/502 Research Triangle Park, NC 27709-2195 United States of America Phone: +1 919 254 7798 Email: narten@us.ibm.com