Guidelines for Writing an IANA Considerations Section in RFCs
RFC 2434
| Document | Type |
RFC - Best Current Practice
(October 1998; No errata)
Obsoleted by RFC 5226
Updated by RFC 3692
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 2434 (Best Current Practice) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
Network Working Group T. Narten
Request for Comments: 2434 IBM
BCP: 26 H. Alvestrand
Category: Best Current Practice Maxware
October 1998
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.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
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
algorithm for IPSec). To insure that such quantities 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).
In order for the IANA to manage a given name space prudently, it
needs guidelines describing the conditions under which new values can
be assigned. If the IANA is expected to play a role in the management
of a name space, the 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 name space and provides guidelines to document authors on
the specific text that must be included in documents that place
demands on the IANA.
Narten & Alvestrand Best Current Practice [Page 1]
RFC 2434 Guidelines for IANA Considerations October 1998
Table of Contents
Status of this Memo.......................................... 1
1. Introduction............................................. 2
2. Issues To Consider....................................... 3
3. Registration maintenance................................. 6
4. What To Put In Documents................................. 7
5. Applicability to Past and Future RFCs.................... 8
6. Security Considerations.................................. 8
7. Acknowledgments.......................................... 9
8. References............................................... 9
9. Authors' Addresses....................................... 10
10. Full Copyright Statement................................. 11
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 types in mail messages [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] or a new encryption
or authentication algorithm for IPSec [IPSEC]). To insure 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).
In this document, we call the set of possible values for such a field
a "name space"; its actual content may be a name, a number or another
kind of value. The assignment of a specific value to a name space is
called an assigned number (or assigned value). Each assignment of a
number in a name space is called a registration.
In order for the IANA to manage a given name space prudently, it
needs guidelines describing the conditions under which new values
should be assigned. This document provides guidelines to authors on
what sort of text should be added to their documents, and reviews
issues that should be considered in formulating an appropriate policy
for assigning numbers to name spaces.
Not all name spaces require centralized administration. In some
cases, it is possible to delegate a name space in such a way that
further assignments can be made independently and with no further
(central) coordination. In the Domain Name System, for example, the
IANA only deals with assignments at the higher-levels, while
subdomains are administered by the organization to which the space
has been delegated. As another example, Object Identifiers (OIDs) as
defined by the ITU are also delegated [ASSIGNED]. When a name space
Show full document text