Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+SearchTech-invite World Map Symbol

RFC 8126


Guidelines for Writing an IANA Considerations Section in RFCs

Part 3 of 3, p. 34 to 47
Prev Section


prevText      Top      ToC       Page 34 
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      Up      ToC       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

   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

Top      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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

   Barry Leiba
   Huawei Technologies

   Phone: +1 646 827 0648

   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