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.
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.
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. 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. RFC2026], Section 6.5. That is, an initial appeal should be directed to the IESG, followed (if necessary) by an appeal to the IAB.
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. RFC 5226 with references to this document. 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.
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. [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>. [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. 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. 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.
https://www.iana.org/ Barry Leiba Huawei Technologies Phone: +1 646 827 0648 Email: email@example.com 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: firstname.lastname@example.org