Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 8126

Guidelines for Writing an IANA Considerations Section in RFCs

Pages: 47
Best Current Practice: 26
Obsoletes:  5226
Part 3 of 3 – Pages 34 to 47
First   Prev   None

Top   ToC   RFC8126 - Page 34   prevText

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.
Top   ToC   RFC8126 - Page 35

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:
Top   ToC   RFC8126 - Page 36
   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
Top   ToC   RFC8126 - Page 37
   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.
Top   ToC   RFC8126 - Page 38
   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
Top   ToC   RFC8126 - Page 39
   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

   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.
Top   ToC   RFC8126 - Page 40
   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. References

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 2003, <>.
Top   ToC   RFC8126 - Page 41
   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,

   [RFC1591]  Postel, J., "Domain Name System Structure and Delegation",
              RFC 1591, DOI 10.17487/RFC1591, March 1994,

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 2434,
              DOI 10.17487/RFC2434, October 1998,

   [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,

   [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,

   [RFC3228]  Fenner, B., "IANA Considerations for IPv4 Internet Group
              Management Protocol (IGMP)", BCP 57, RFC 3228,
              DOI 10.17487/RFC3228, February 2002,

   [RFC3575]  Aboba, B., "IANA Considerations for RADIUS (Remote
              Authentication Dial In User Service)", RFC 3575,
              DOI 10.17487/RFC3575, July 2003,

   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
              Considered Useful", BCP 82, RFC 3692,
              DOI 10.17487/RFC3692, January 2004,

   [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,

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", BCP 90, RFC 3864,
              DOI 10.17487/RFC3864, September 2004,
Top   ToC   RFC8126 - Page 42
   [RFC3942]  Volz, B., "Reclassifying Dynamic Host Configuration
              Protocol version 4 (DHCPv4) Options", RFC 3942,
              DOI 10.17487/RFC3942, November 2004,

   [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,

   [RFC4025]  Richardson, M., "A Method for Storing IPsec Keying
              Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March
              2005, <>.

   [RFC4044]  McCloghrie, K., "Fibre Channel Management MIB", RFC 4044,
              DOI 10.17487/RFC4044, May 2005,

   [RFC4124]  Le Faucheur, F., Ed., "Protocol Extensions for Support of
              Diffserv-aware MPLS Traffic Engineering", RFC 4124,
              DOI 10.17487/RFC4124, June 2005,

   [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,

   [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,

   [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,

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340,
              DOI 10.17487/RFC4340, March 2006,
Top   ToC   RFC8126 - Page 43
   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422,
              DOI 10.17487/RFC4422, June 2006,

   [RFC4446]  Martini, L., "IANA Allocations for Pseudowire Edge to Edge
              Emulation (PWE3)", BCP 116, RFC 4446,
              DOI 10.17487/RFC4446, April 2006,

   [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, <>.

   [RFC4589]  Schulzrinne, H. and H. Tschofenig, "Location Types
              Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006,

   [RFC4727]  Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
              ICMPv6, UDP, and TCP Headers", RFC 4727,
              DOI 10.17487/RFC4727, November 2006,

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,

   [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,

   [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,

   [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,

   [RFC5795]  Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
              Header Compression (ROHC) Framework", RFC 5795,
              DOI 10.17487/RFC5795, March 2010,
Top   ToC   RFC8126 - Page 44
   [RFC6014]  Hoffman, P., "Cryptographic Algorithm Identifier
              Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014,
              November 2010, <>.

   [RFC6230]  Boulton, C., Melanchuk, T., and S. McGlashan, "Media
              Control Channel Framework", RFC 6230,
              DOI 10.17487/RFC6230, May 2011,

   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
              2011, <>.

   [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, <>.

   [RFC6709]  Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
              Considerations for Protocol Extensions", RFC 6709,
              DOI 10.17487/RFC6709, September 2012,

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,

   [RFC6895]  Eastlake 3rd, D., "Domain Name System (DNS) IANA
              Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
              April 2013, <>.

   [RFC6994]  Touch, J., "Shared Use of Experimental TCP Options",
              RFC 6994, DOI 10.17487/RFC6994, August 2013,

   [RFC7120]  Cotton, M., "Early IANA Allocation of Standards Track Code
              Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
              2014, <>.

   [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,
Top   ToC   RFC8126 - Page 45
   [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,

   [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,

   [RFC8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names
              (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
Top   ToC   RFC8126 - Page 46
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.
Top   ToC   RFC8126 - Page 47

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: URI: Barry Leiba Huawei Technologies Phone: +1 646 827 0648 Email: URI: 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: