Guidelines for Writing an IANA Considerations Section in RFCs
RFC 8126

Document Type RFC - Best Current Practice (June 2017; No errata)
Obsoletes RFC 5226
Last updated 2017-06-20
Stream IETF
Formats plain text pdf html bibtex
Yang Validation 0 errors, 0 warnings.
Reviews
Stream WG state (None)
Document shepherd Tony Hansen
Shepherd write-up Show (last changed 2014-09-24)
IESG IESG state RFC 8126 (Best Current Practice)
Consensus Boilerplate Yes
Telechat date
Responsible AD Terry Manderson
Send notices to (None)
IANA IANA review state Version Changed - Review Needed
IANA action state RFC-Ed-Ack
Internet Engineering Task Force (IETF)                         M. Cotton
Request for Comments: 8126                                           PTI
BCP: 26                                                         B. Leiba
Obsoletes: 5226                                      Huawei Technologies
Category: Best Current Practice                                T. Narten
ISSN: 2070-1721                                          IBM Corporation
                                                               June 2017

     Guidelines for Writing an IANA Considerations Section in RFCs

Abstract

   Many protocols make use of points of extensibility that use constants
   to identify various protocol parameters.  To ensure that the values
   in these fields do not have conflicting uses and to promote
   interoperability, their allocations are often coordinated by a
   central record keeper.  For IETF protocols, that role is filled by
   the Internet Assigned Numbers Authority (IANA).

   To make assignments in a given registry prudently, guidance
   describing the conditions under which new values should be assigned,
   as well as when and how modifications to existing values can be made,
   is needed.  This document defines a framework for the documentation
   of these guidelines by specification authors, in order to assure that
   the provided guidance for the IANA Considerations is clear and
   addresses the various issues that are likely in the operation of a
   registry.

   This is the third edition of this document; it obsoletes RFC 5226.

Status of This Memo

   This memo documents an Internet Best Current Practice.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   BCPs is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc8126.

Cotton, et al.            Best Current Practice                 [Page 1]
RFC 8126           IANA Considerations Section in RFCs         June 2017

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Keep IANA Considerations for IANA . . . . . . . . . . . .   4
     1.2.  For Updated Information . . . . . . . . . . . . . . . . .   5
     1.3.  A Quick Checklist Upfront . . . . . . . . . . . . . . . .   5
   2.  Creating and Revising Registries  . . . . . . . . . . . . . .   7
     2.1.  Organization of Registries  . . . . . . . . . . . . . . .   8
     2.2.  Documentation Requirements for Registries . . . . . . . .   8
     2.3.  Specifying Change Control for a Registry  . . . . . . . .  11
     2.4.  Revising Existing Registries  . . . . . . . . . . . . . .  11
   3.  Registering New Values in an Existing Registry  . . . . . . .  12
     3.1.  Documentation Requirements for Registrations  . . . . . .  12
     3.2.  Updating Existing Registrations . . . . . . . . . . . . .  14
     3.3.  Overriding Registration Procedures  . . . . . . . . . . .  14
     3.4.  Early Allocations . . . . . . . . . . . . . . . . . . . .  15
   4.  Choosing a Registration Policy and Well-Known Policies  . . .  15
     4.1.  Private Use . . . . . . . . . . . . . . . . . . . . . . .  18
     4.2.  Experimental Use  . . . . . . . . . . . . . . . . . . . .  18
     4.3.  Hierarchical Allocation . . . . . . . . . . . . . . . . .  19
     4.4.  First Come First Served . . . . . . . . . . . . . . . . .  19
     4.5.  Expert Review . . . . . . . . . . . . . . . . . . . . . .  20
     4.6.  Specification Required  . . . . . . . . . . . . . . . . .  21
     4.7.  RFC Required  . . . . . . . . . . . . . . . . . . . . . .  22
     4.8.  IETF Review . . . . . . . . . . . . . . . . . . . . . . .  22
     4.9.  Standards Action  . . . . . . . . . . . . . . . . . . . .  23
     4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . .  23
     4.11. Using the Well-Known Registration Policies  . . . . . . .  24
Show full document text