Guidelines for Writing an IANA Considerations Section in RFCs
RFC 5226

 
Document
Type RFC - Best Current Practice (May 2008; Errata)
Obsoletes RFC 2434
Also known as BCP 26
Was draft-narten-iana-considerations-rfc2434bis (individual in gen area)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream
WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG
IESG state RFC 5226 (Best Current Practice)
Telechat date
Responsible AD Russ Housley
Send notices to narten@us.ibm.com, harald@alvestrand.no

Email authors IPR References Referenced by Nits Search lists

Network Working Group                                          T. Narten
Request for Comments: 5226                                           IBM
BCP: 26                                                    H. Alvestrand
Obsoletes: 2434                                                   Google
Category: Best Current Practice                                 May 2008

     Guidelines for Writing an IANA Considerations Section in RFCs

Status of This Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Abstract

   Many protocols make use of identifiers consisting of constants and
   other well-known values.  Even after a protocol has been defined and
   deployment has begun, new values may need to be assigned (e.g., for a
   new option type in DHCP, or a new encryption or authentication
   transform for IPsec).  To ensure that such quantities have consistent
   values and interpretations across all implementations, their
   assignment must be administered by a central authority.  For IETF
   protocols, that role is provided by the Internet Assigned Numbers
   Authority (IANA).

   In order for IANA to manage a given namespace prudently, it needs
   guidelines describing the conditions under which new values can be
   assigned or when modifications to existing values can be made.  If
   IANA is expected to play a role in the management of a namespace,
   IANA must be given clear and concise instructions describing that
   role.  This document discusses issues that should be considered in
   formulating a policy for assigning values to a namespace and provides
   guidelines for authors on the specific text that must be included in
   documents that place demands on IANA.

   This document obsoletes RFC 2434.

Narten & Alvestrand      Best Current Practice                  [Page 1]
RFC 5226          IANA Considerations Section in RFCs           May 2008

Table of Contents

   1. Introduction ....................................................2
   2. Why Management of a Namespace May Be Necessary ..................3
   3. Designated Experts ..............................................4
      3.1. The Motivation for Designated Experts ......................4
      3.2. The Role of the Designated Expert ..........................5
      3.3. Designated Expert Reviews ..................................7
   4. Creating a Registry .............................................8
      4.1. Well-Known IANA Policy Definitions .........................9
      4.2. What to Put in Documents That Create a Registry ...........12
      4.3. Updating IANA Guidelines for Existing Registries ..........15
   5. Registering New Values in an Existing Registry .................15
      5.1. What to Put in Documents When Registering Values ..........15
      5.2. Updating Registrations ....................................17
      5.3. Overriding Registration Procedures ........................17
   6. Miscellaneous Issues ...........................................18
      6.1. When There Are No IANA Actions ............................18
      6.2. Namespaces Lacking Documented Guidance ....................19
      6.3. After-the-Fact Registrations ..............................19
      6.4. Reclaiming Assigned Values ................................19
   7. Appeals ........................................................20
   8. Mailing Lists ..................................................20
   9. Security Considerations ........................................20
   10. Changes Relative to RFC 2434 ..................................21
   11. Acknowledgments ...............................................22
   12. References ....................................................22
      12.1. Normative References .....................................22
      12.2. Informative References ...................................22

1.  Introduction

   Many protocols make use of fields that contain constants and other
   well-known values (e.g., the Protocol field in the IP header [IP] or
   MIME media types [MIME-REG]).  Even after a protocol has been defined
   and deployment has begun, new values may need to be assigned (e.g., a
   new option type in DHCP [DHCP-OPTIONS] or a new encryption or
   authentication transform for IPsec [IPSEC]).  To ensure that such
   fields have consistent values and interpretations in different
   implementations, their assignment must be administered by a central
   authority.  For IETF protocols, that role is provided by the Internet
   Assigned Numbers Authority (IANA) [IANA-MOU].

   In this document, we call the set of possible values for such a field
   a "namespace"; its actual value may be a text string, a number, or
Show full document text