< draft-narten-iana-considerations-rfc2434bis-07.txt   draft-narten-iana-considerations-rfc2434bis-08.txt >
INTERNET-DRAFT Thomas Narten INTERNET-DRAFT Thomas Narten
IBM IBM
<draft-narten-iana-considerations-rfc2434bis-07.txt> Harald Alvestrand <draft-narten-iana-considerations-rfc2434bis-08.txt> Harald Alvestrand
Obsoletes: 2434 Google Obsoletes (if approved): 2434 Google
July 9, 2007 Expires: April 4, 2007 October 4, 2007
Intended Status: BCP
Guidelines for Writing an IANA Considerations Section in RFCs Guidelines for Writing an IANA Considerations Section in RFCs
<draft-narten-iana-considerations-rfc2434bis-07.txt> <draft-narten-iana-considerations-rfc2434bis-08.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 3, line 20 skipping to change at page 3, line 20
2. Why Management of a Name Space May be Necessary.......... 5 2. Why Management of a Name Space May be Necessary.......... 5
3. Designated Experts....................................... 5 3. Designated Experts....................................... 5
3.1. The Motivation For Designated Experts............... 5 3.1. The Motivation For Designated Experts............... 5
3.2. The Role of the Designated Expert................... 7 3.2. The Role of the Designated Expert................... 7
3.3. Designated Expert Reviews........................... 7 3.3. Designated Expert Reviews........................... 7
4. Creating A Registry...................................... 9 4. Creating A Registry...................................... 9
4.1. Well-Known IANA Policy Definitions.................. 9 4.1. Well-Known IANA Policy Definitions.................. 9
4.2. What To Put In Documents That Create A Registry..... 12 4.2. What To Put In Documents That Create A Registry..... 13
4.3. Updating IANA Guidelines For Existing Registries.... 14 4.3. Updating IANA Guidelines For Existing Registries.... 15
5. Registering New Values In An Existing Registry........... 14 5. Registering New Values In An Existing Registry........... 15
5.1. What to Put In Documents When Registering Values.... 14 5.1. What to Put In Documents When Registering Values.... 15
5.2. Updating Registrations.............................. 15 5.2. Updating Registrations.............................. 17
5.3. Overriding Registration Procedures.................. 16 5.3. Overriding Registration Procedures.................. 18
6. Miscellaneous Issues..................................... 17 6. Miscellaneous Issues..................................... 18
6.1. When There Are No IANA Actions...................... 17 6.1. When There Are No IANA Actions...................... 18
6.2. Namespaces Lacking Documented Guidance.............. 18 6.2. Namespaces Lacking Documented Guidance.............. 19
6.3. After-The-Fact Registrations........................ 18 6.3. After-The-Fact Registrations........................ 19
6.4. Reclaiming Assigned Values.......................... 18 6.4. Reclaiming Assigned Values.......................... 20
7. Appeals.................................................. 19 7. Appeals.................................................. 20
8. Mailing Lists............................................ 19 8. Mailing Lists............................................ 20
9. Security Considerations.................................. 19 9. Security Considerations.................................. 21
10. Changes Relative to RFC 2434............................ 20 10. Changes Relative to RFC 2434............................ 21
10.1. Changes Relative to -00............................ 21
10.2. Changes Relative to -02............................ 21
11. IANA Considerations..................................... 21 11. IANA Considerations..................................... 22
12. Acknowledgments......................................... 21 12. Acknowledgments......................................... 22
13. Normative References.................................... 21 13. Normative References.................................... 23
14. Informative References.................................. 22 14. Informative References.................................. 23
15. Authors' Addresses...................................... 24 15. Authors' Addresses...................................... 26
1. Introduction 1. Introduction
Many protocols make use of fields that contain constants and other 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 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 MIME media types [MIME-REG]). Even after a protocol has been defined
been defined and deployment has begun, new values may need to be and deployment has begun, new values may need to be assigned (e.g., a
assigned (e.g., a new option type in DHCP [DHCP-OPTIONS] or a new new option type in DHCP [DHCP-OPTIONS] or a new encryption or
encryption or authentication transform for IPsec [IPSEC]). To ensure authentication transform for IPsec [IPSEC]). To ensure that such
that such fields have consistent values and interpretations in fields have consistent values and interpretations in different
different implementations, their assignment must be administered by a implementations, their assignment must be administered by a central
central authority. For IETF protocols, that role is provided by the authority. For IETF protocols, that role is provided by the Internet
Internet Assigned Numbers Authority (IANA) [IANA-MOU]. Assigned Numbers Authority (IANA) [IANA-MOU].
In this document, we call the set of possible values for such a field In this document, we call the set of possible values for such a field
a "name space"; its actual value may be a text string, a number or a "name space"; its actual value may be a text string, a number or
another kind of value. The binding or association of a specific value another kind of value. The binding or association of a specific value
with a particular purpose within a name space is called an assigned with a particular purpose within a name space is called an assigned
number (or assigned value, or sometimes a "code point", "protocol number (or assigned value, or sometimes a "code point", "protocol
constant", or "protocol parameter"). Each assignment of a value in a constant", or "protocol parameter"). Each assignment of a value in a
name space is called a registration. name space is called a registration.
In order for IANA to manage a given name space prudently, it needs In order for IANA to manage a given name space prudently, it needs
skipping to change at page 4, line 47 skipping to change at page 4, line 47
further assignments can be made independently and with no further further assignments can be made independently and with no further
(central) coordination. In the Domain Name System, for example, the (central) coordination. In the Domain Name System, for example, the
IANA only deals with assignments at the higher-levels, while IANA only deals with assignments at the higher-levels, while
subdomains are administered by the organization to which the space subdomains are administered by the organization to which the space
has been delegated. As another example, Object Identifiers (OIDs) as has been delegated. As another example, Object Identifiers (OIDs) as
defined by the ITU are also delegated [ASSIGNED]; IANA manages the defined by the ITU are also delegated [ASSIGNED]; IANA manages the
subtree rooted at "iso.org.dod.internet" (1.3.6.1) . When a name subtree rooted at "iso.org.dod.internet" (1.3.6.1) . When a name
space is delegated, the scope of IANA is limited to the parts of the space is delegated, the scope of IANA is limited to the parts of the
namespace where IANA has authority. namespace where IANA has authority.
This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
negatives, in the way described in RFC 2119 [KEYWORDS]. In this case, "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"the specification" as used by RFC 2119 refers to the processing of document are to be interpreted as described in RFC 2119 [KEYWORDS].
protocol documents within the IETF standards process. For this document, "the specification" as used by RFC 2119 refers to
the processing of protocol documents within the IETF standards
process.
2. Why Management of a Name Space May be Necessary 2. Why Management of a Name Space May be Necessary
One issue to consider in managing a name space is its size. If the One issue to consider in managing a name space is its size. If the
space is small and limited in size, assignments must be made space is small and limited in size, assignments must be made
carefully to prevent exhaustion of the space. If the space is carefully to prevent exhaustion of the space. If the space is
essentially unlimited, on the other hand, potential exhaustion will essentially unlimited, on the other hand, potential exhaustion will
probably not be a practical concern at all. Even when the space is probably not be a practical concern at all. Even when the space is
essentially unlimited, however, it is usually desirable to have at essentially unlimited, however, it is usually desirable to have at
least a minimal review prior to assignment in order to: least a minimal review prior to assignment in order to:
skipping to change at page 9, line 17 skipping to change at page 9, line 17
- the extension would conflict with one under active development by - the extension would conflict with one under active development by
the IETF, and having both would harm rather than foster the IETF, and having both would harm rather than foster
interoperability. interoperability.
4. Creating A Registry 4. Creating A Registry
Creating a registry involves describing the name spaces to be Creating a registry involves describing the name spaces to be
created, an initial set of assignments (if appropriate) and created, an initial set of assignments (if appropriate) and
guidelines on how future assignments are to be made. guidelines on how future assignments are to be made.
Once a registry has been created, IANA records assignments that have
been made. The following labels describe the status of an individual
(or range) of assignments:
Private Use: Private use only (not assigned), as described in
Section 4.1
Experimental: Available for experimental use as described in
[EXPERIMENTATION]. IANA does not record specific assignments for
any particular use.
Unassigned: Unused and available for assignment via documented
procedures.
Reserved: Not to be assigned. Reserved values are held for special
uses, such as to extend the name space when it become exhausted.
Reserved values are not available for general assignment.
4.1. Well-Known IANA Policy Definitions 4.1. Well-Known IANA Policy Definitions
The following are some defined policies, some of which are in use The following are some defined policies, some of which are in use
today. These cover a range of typical policies that have been used to today. These cover a range of typical policies that have been used to
date to describe the procedure for assigning new values in a name date to describe the procedure for assigning new values in a name
space. It is not required that documents use these terms; the actual space. It is not required that documents use these terms; the actual
requirement is that the instructions to IANA are clear and requirement is that the instructions to IANA are clear and
unambiguous. However, use of these terms is RECOMMENDED where unambiguous. However, use of these terms is RECOMMENDED where
possible, since their meaning is widely understood. possible, since their meaning is widely understood.
Private Use - For private or local use only, with the type and Private Use - For private or local use only, with the type and
purpose defined by the local site. No attempt is made to purpose defined by the local site. No attempt is made to
prevent multiple sites from using the same value in prevent multiple sites from using the same value in
different (and incompatible) ways. There is no need for different (and incompatible) ways. There is no need for
IANA to review such assignments (since IANA does not record IANA to review such assignments (since IANA does not record
them) and assignments are not generally useful for broad them) and assignments are not generally useful for broad
interoperability. interoperability. It is the responsibility of the sites
making use of the Private Use range to ensure that no
conflicts occur (within the intended scope of use).
Examples: Site-specific options in DHCP [DHCP-OPTIONS] have Examples: Site-specific options in DHCP [DHCP-IANA], Fibre
significance only within a single site, "X-foo:" header Channel Port Type Registry [RFC4044], Exchange Types in the
lines in email messages. IKEv2 header [RFC4306].
Experimental Use - Similar to private or local use only, with the Experimental Use - Similar to private or local use only, with the
purpose being to facilitate experimentation. See purpose being to facilitate experimentation. See
[EXPERIMENTATION] for details. [EXPERIMENTATION] for details.
Example: Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6,
UDP, and TCP Headers [RFC4727].
Hierarchical allocation - Delegated managers can assign values Hierarchical allocation - Delegated managers can assign values
provided they have been given control over that part of the provided they have been given control over that part of the
name space. IANA controls the higher levels of the name space. IANA controls the higher levels of the
namespace according to one of the other policies. namespace according to one of the other policies.
Examples: DNS names, Object Identifiers, IP addresses Examples: DNS names, Object Identifiers, IP addresses.
First Come First Served - Assignments are made to anyone on a First Come First Served - Assignments are made to anyone on a
first come, first served basis. There is no substantive first come, first served basis. There is no substantive
review of the request, other than to ensure that it is review of the request, other than to ensure that it is
well-formed and doesn't duplicate an existing assignment. well-formed and doesn't duplicate an existing assignment.
However, requests must include a minimal amount of clerical However, requests must include a minimal amount of clerical
information, such as a a point of contact (including an information, such as a a point of contact (including an
email address) and a brief description of how the value email address) and a brief description of how the value
will be used. Additional information specific to the type will be used. Additional information specific to the type
of value requested may also need to be provided, as defined of value requested may also need to be provided, as defined
by the name space. For numbers, the exact value is by the name space. For numbers, the exact value is
generally assigned by IANA; with names, specific text generally assigned by IANA; with names, specific text
strings can usually be requested. strings can usually be requested.
Examples: vnd. (vendor assigned) MIME types [MIME-REG]. Examples: SASL mechanism names [RFC4422], LDAP Protocol
Mechanisms and LDAP Syntax [RFC4520].
Expert Review (or Designated Expert) - approval by a Designated Expert Review (or Designated Expert) - approval by a Designated
Expert is required. The required documentation and review Expert is required. The required documentation and review
criteria for use by the Designated Expert should be criteria for use by the Designated Expert should be
provided when defining the registry. For example, see provided when defining the registry. For example, see
Sections 6 and 7.2 in [RFC3748]. Sections 6 and 7.2 in [RFC3748].
Examples: EAP Method Types [RFC3748], HTTP Digest AKA
algorithm versions [RFC4169], URI schemes [RFC4395],
GEOPRIV Location Types [RFC4589].
Specification required - Values and their meaning must be Specification required - Values and their meaning must be
documented in an RFC or other permanent and readily documented in an RFC or other permanent and readily
available public specification, in sufficient detail so available public specification, in sufficient detail so
that interoperability between independent implementations that interoperability between independent implementations
is possible. When used, Specification Required also implies is possible. When used, Specification Required also implies
usage of a Designated Expert, who will review the public usage of a Designated Expert, who will review the public
specification and evaluate whether it is sufficiently clear specification and evaluate whether it is sufficiently clear
to allow interoperable implementations. The intention to allow interoperable implementations. The intention
behind "permanent and readily available" is that a document behind "permanent and readily available" is that a document
can be reasonably be expected to easily be found long after can be reasonably be expected to easily be found long after
IANA assignment of the requested value. Publication of an IANA assignment of the requested value. Publication of an
RFC is the ideal means of achieving this requirement. RFC is the ideal means of achieving this requirement. For
RFC publication, the normal RFC review process is expected
to provide the necessary review for interoperability,
though the Designated Expert may be a particularly well-
qualified person to perform such a review.
Examples: SCSP [SCSP]. Examples: Diffserv-aware TE Bandwidth Constraints Model
Identifiers [RFC4124], TLS ClientCertificateType
identifiers [RFC4346], ROHC Profile Identifiers [RFC4995].
RFC Required - RFC publication (either as IETF Submission or as an RFC Required - RFC publication (either as IETF Submission or as an
RFC Editor submission [RFC3932]) suffices. Unless otherwise RFC Editor submission [RFC3932]) suffices. Unless otherwise
specified, any type of RFC is sufficient (e.g., specified, any type of RFC is sufficient (e.g.,
Informational, Experimental, Standards Track, etc.) Informational, Experimental, Standards Track, etc.)
IETF Review - (Formerly called "IETF Consensus" in [IANA- IETF Review - (Formerly called "IETF Consensus" in [IANA-
CONSIDERATIONS]) New values are assigned only through RFCs CONSIDERATIONS]) New values are assigned only through RFCs
that have been shepherded through the IESG as AD-Sponsored that have been shepherded through the IESG as AD-Sponsored
IETF (or WG) Documents [RFC3932,RFC3978]. The intention is IETF (or WG) Documents [RFC3932,RFC3978]. The intention is
skipping to change at page 11, line 11 skipping to change at page 11, line 46
by the IESG and appropriate IETF WGs (or experts, if by the IESG and appropriate IETF WGs (or experts, if
suitable working groups no longer exist) to ensure that the suitable working groups no longer exist) to ensure that the
proposed assignment will not negatively impact proposed assignment will not negatively impact
interoperability or otherwise extend IETF protocols in an interoperability or otherwise extend IETF protocols in an
inappropriate or damaging manner. inappropriate or damaging manner.
To ensure adequate community review, such documents are To ensure adequate community review, such documents are
shepherded through the IESG as AD-sponsored documents with shepherded through the IESG as AD-sponsored documents with
an IETF Last Call. an IETF Last Call.
Examples: SMTP extensions [SMTP-EXT], BGP Subsequent Examples: IPSECKEY Algorithm Types [RFC4025], Accounting-
Address Family Identifiers [BGP4-EXT]. Auth-Method AVP values in DIAMETER [RFC4005], TLS Handshake
Hello Extensions [RFC4366].
Standards Action - Values are assigned only for Standards Track Standards Action - Values are assigned only for Standards Track
RFCs approved by the IESG. RFCs approved by the IESG.
Examples: MIME top level types [MIME-REG]. Examples: BGP message types [RFC4271], Mobile Node
Identifier option types [RFC4283], DCCP Packet Types
[RFC4340].
IESG Approval - New assignments may be approved by the IESG. IESG Approval - New assignments may be approved by the IESG.
Although there is no requirement that the request be Although there is no requirement that the request be
documented in an RFC, the IESG has discretion to request documented in an RFC, the IESG has discretion to request
documents or other supporting materials on a case-by-case documents or other supporting materials on a case-by-case
basis. basis.
IESG Approval is not intended to be used often or as a IESG Approval is not intended to be used often or as a
"common case;" indeed, it has seldom been used in practice "common case;" indeed, it has seldom been used in practice
during the period RFC 2434 was in effect. Rather, it is during the period RFC 2434 was in effect. Rather, it is
skipping to change at page 11, line 51 skipping to change at page 12, line 41
- The IESG can (and should) reject a request if another - The IESG can (and should) reject a request if another
path is available that is more appropriate and there is path is available that is more appropriate and there is
no compelling reason to bypass normal community review. no compelling reason to bypass normal community review.
- before approving a request, the community should be - before approving a request, the community should be
consulted, via a "call for comments" that provides as consulted, via a "call for comments" that provides as
much information as is reasonably possible about the much information as is reasonably possible about the
request. request.
Examples: IPv4 Multicast address assignments [RFC3171], IPv4 IGMP
Type and Code values [RFC3228], Mobile IPv6 Mobility Header Type and
Option values [RFC3775].
It should be noted that it often makes sense to partition a name It should be noted that it often makes sense to partition a name
space into multiple categories, with assignments within each category space into multiple categories, with assignments within each category
handled differently. For example, many protocols now partition name handled differently. For example, many protocols now partition name
spaces into two (or even more) parts, where one range is reserved for spaces into two (or even more) parts, where one range is reserved for
Private or Experimental Use, while other ranges are reserved for Private or Experimental Use, while other ranges are reserved for
globally unique assignments assigned following some review process. globally unique assignments assigned following some review process.
Dividing a name space into ranges makes it possible to have different Dividing a name space into ranges makes it possible to have different
policies in place for different ranges. policies in place for different ranges.
4.2. What To Put In Documents That Create A Registry 4.2. What To Put In Documents That Create A Registry
skipping to change at page 12, line 28 skipping to change at page 13, line 21
almost all cases, having an explicit "IANA Considerations" section is almost all cases, having an explicit "IANA Considerations" section is
appropriate. The following and later sections define what is needed appropriate. The following and later sections define what is needed
for the different types of IANA actions. for the different types of IANA actions.
Documents that create a new name space (or modify the definition of Documents that create a new name space (or modify the definition of
an existing space) and that expect IANA to play a role in maintaining an existing space) and that expect IANA to play a role in maintaining
that space (e.g., serving as a repository for registered values) MUST that space (e.g., serving as a repository for registered values) MUST
provide clear instructions on details of the name space. In provide clear instructions on details of the name space. In
particular, instructions MUST include: particular, instructions MUST include:
1) The name of the registry being created and/or maintained. The 1) The name of the registry (or sub-registry) being created and/or
name will appear on the IANA web page and will be referred to in maintained. The name will appear on the IANA web page and will
future documents that need to allocate a value from the new be referred to in future documents that need to allocate a value
space. The full name (and abbreviation, if appropriate) should from the new space. The full name (and abbreviation, if
be provided. It is highly desirable that the chosen name not be appropriate) should be provided. It is highly desirable that the
easily confusable with the name of another registry. chosen name not be easily confusable with the name of another
registry. When creating a sub-registry, the registry that it is
a part of should be clearly identified. When referring to an
already existing registry, providing a URL to precisely identify
the registry is helpful. All such URLs, however, will be removed
from the RFC prior to final publication. For example, documents
could contain: [TO BE REMOVED: This registration should take
place at the following location:
http://www.iana.org/assignments/foobar-registry]
2) What information must be provided as part of a request in order 2) What information must be provided as part of a request in order
to assign a new value. This information may include the need to to assign a new value. This information may include the need to
document relevant security considerations, if any. document relevant security considerations, if any.
3) The review process that will apply to all future requests for a 3) The review process that will apply to all future requests for a
value from the namespace. value from the namespace.
Note: When a Designated Expert is used, documents MUST NOT name Note: When a Designated Expert is used, documents MUST NOT name
the Designated Expert in the document itself; instead, the name the Designated Expert in the document itself; instead, the name
skipping to change at page 13, line 10 skipping to change at page 14, line 9
If the request should also be reviewed on a specific public If the request should also be reviewed on a specific public
mailing list (such as the ietf-types@iana.org for media types), mailing list (such as the ietf-types@iana.org for media types),
that mailing address should be specified. Note, however, that that mailing address should be specified. Note, however, that
when mailing lists are specified, the requirement for a when mailing lists are specified, the requirement for a
Designated Expert MUST also be specified (see Section 3). Designated Expert MUST also be specified (see Section 3).
If IANA is expected to make assignments without requiring an If IANA is expected to make assignments without requiring an
outside review, sufficient guidance MUST be provided so that the outside review, sufficient guidance MUST be provided so that the
requests can be evaluated with minimal subjectivity. requests can be evaluated with minimal subjectivity.
4) The size and format of registry entries. When creating a new 4) The size, format and syntax of registry entries. When creating a
name/number space, authors must specify the size of the registry new name/number space, authors must describe any technical
or sub-registry as well as the exact format for recording requirements on registry (and sub-registry) values (e.g., valid
registry values. For number assignments, one should specify ranges for integers, length limitations on strings, etc.) as
well as the exact format that registry values should be
displayed in. For number assignments, one should specify
whether values are to be recorded in decimal, hexadecimal or whether values are to be recorded in decimal, hexadecimal or
some other format. For strings, the encoding format should be some other format. For strings, the encoding format should be
specified (e.g., ASCII, UTF8, etc.) Authors should also clear specified (e.g., ASCII, UTF8, etc.) Authors should also clearly
specify what fields to record in the registry. specify what fields to record in the registry.
5) Initial assignments and reservations. Clear instructions should 5) Initial assignments and reservations. Clear instructions should
be provided to identify any initial assignments or be provided to identify any initial assignments or
registrations. In addition, any ranges that are to be reserved registrations. In addition, any ranges that are to be reserved
for "Private Use", "Reserved", "Unassigned", etc. should be for "Private Use", "Reserved", "Unassigned", etc. should be
clearly indicated. clearly indicated.
When specifying the process for making future assignments, it is When specifying the process for making future assignments, it is
quite acceptable to pick one (or more) of the example policies listed quite acceptable to pick one (or more) of the example policies listed
skipping to change at page 13, line 40 skipping to change at page 14, line 41
above policies and include additional guidelines for what kind of above policies and include additional guidelines for what kind of
considerations should be taken into account by the review process. considerations should be taken into account by the review process.
For example, RADIUS [RFC3575] specifies the use of a Designated For example, RADIUS [RFC3575] specifies the use of a Designated
Expert, but includes specific additional criteria the Designated Expert, but includes specific additional criteria the Designated
Expert should follow. Expert should follow.
For example, a document could say something like: For example, a document could say something like:
This document defines a new DHCP option, entitled "FooBar" (see This document defines a new DHCP option, entitled "FooBar" (see
Section y), assigned a value of TBD1 from the DCHP Option space Section y), assigned a value of TBD1 from the DCHP Option space
[RFCXXX]. The FooBar option also defines an 8-bit FooType field, [to be removed upon publication:
for which IANA is to create and maintain a registry entitled http://www.iana.org/assignments/bootp-dhcp-parameters] [DHCP-
"FooType values". Initial values for the DHCP FooBar FooType OPTIONS,DHCP-IANA]:
registry are given below; future assignments are to be made
through Expert Review [IANA-CONSIDERATIONS]. Assignments consist
of a DHCP FooBar FooType name and its associated value.
DHCP FooBar FooType Name Value Definition Data
------------------------ ---------- Tag Name Length Meaning
Frobnitz 1 See Section y.1 ---- ---- ------ -------
NitzFrob 2 See Section y.2 TBD1 FooBar N FooBar server
For examples of documents that provide good and detailed guidance to The FooBar option also defines an 8-bit FooType field, for which
IANA on the issue of assigning numbers, consult [MIME-LANG, RFC3757, IANA is to create and maintain a new sub-registry entitled
RFC3749, RFC3575, RFC3968]. "FooType values" under the FooBar option. Initial values for the
DHCP FooBar FooType registry are given below; future assignments
are to be made through Expert Review [IANA-CONSIDERATIONS].
Assignments consist of a DHCP FooBar FooType name and its
associated value.
Value DHCP FooBar FooType Name Definition
---- ------------------------ ----------
0 Reserved
1 Frobnitz See Section y.1
2 NitzFrob See Section y.2
3-254 Unassigned
255 Reserved
For examples of documents that provide detailed guidance to IANA on
the issue of assigning numbers, consult [RFC2929, RFC3575, RFC3968,
RFC4520].
4.3. Updating IANA Guidelines For Existing Registries 4.3. Updating IANA Guidelines For Existing Registries
Updating the registration process for an already existing (i.e., Updating the registration process for an already existing (i.e.,
previously created) name space (whether created explicitly or previously created) name space (whether created explicitly or
implicitly) follows a process similar to that used when creating a implicitly) follows a process similar to that used when creating a
new namespace. That is, a document is produced that makes reference new namespace. That is, a document is produced that makes reference
to the existing namespace and then provides detailed guidelines for to the existing namespace and then provides detailed guidelines for
handling assignments in each individual name space. Such documents handling assignments in each individual name space. Such documents
are normally processed as BCPs [IETF-PROCESS]. are normally processed as BCPs [IETF-PROCESS].
skipping to change at page 14, line 35 skipping to change at page 15, line 47
Often, documents request an assignment from an already existing name Often, documents request an assignment from an already existing name
space (i.e., one created by a previously-published RFC). In such space (i.e., one created by a previously-published RFC). In such
cases: cases:
- Documents should clearly identify the name space in which each - Documents should clearly identify the name space in which each
value is to be registered. If the registration goes into a sub- value is to be registered. If the registration goes into a sub-
registry, the author should clearly describe where the assignment registry, the author should clearly describe where the assignment
or registration should go. It is helpful to use the exact name or registration should go. It is helpful to use the exact name
space name as listed on the IANA web page (and defining RFC), and space name as listed on the IANA web page (and defining RFC), and
cite the RFC where the name space is defined. (Note: There is no cite the RFC where the name space is defined.
need to mention what the assignment policy for new assignments is,
as that should be clear from the references.) Note 1: There is no need to mention what the assignment policy for
new assignments is, as that should be clear from the references.
Note 2: When referring to an existing registry, providing a URL to
precisely identify the registry is helpful. All such URLs,
however, will be removed from the RFC prior to final publication.
For example, documents could contain: [TO BE REMOVED: This
registration should take place at the following location:
http://www.iana.org/assignments/foobar-registry]
- Each value requested should be given a unique reference. When the - Each value requested should be given a unique reference. When the
value is numeric, use the notation: TBD1, TBD2, etc. Throughout value is numeric, use the notation: TBD1, TBD2, etc. Throughout
the document where an actual IANA-assigned value should be filled the document where an actual IANA-assigned value should be filled
in, use the "TBDx" notation. This helps ensure that the final RFC in, use the "TBDx" notation. This helps ensure that the final RFC
has the correct assigned values inserted in in all of the relevant has the correct assigned values inserted in in all of the relevant
places where the value is expected to appear in the final places where the value is expected to appear in the final
document. For values that are text strings, a specific name can be document. For values that are text strings, a specific name can be
suggested. IANA will normally assign the name, unless it conflicts suggested. IANA will normally assign the name, unless it conflicts
with a name already in use. with a name already in use.
skipping to change at page 15, line 28 skipping to change at page 16, line 48
basis, e.g., codes are always assigned sequentially unless there basis, e.g., codes are always assigned sequentially unless there
is a strong reason for making an exception. Nothing in this is a strong reason for making an exception. Nothing in this
document is intended to change those policies or prevent their document is intended to change those policies or prevent their
future application. future application.
- The IANA Considerations section should summarize all of the IANA - The IANA Considerations section should summarize all of the IANA
actions, with pointers to the relevant sections elsewhere in the actions, with pointers to the relevant sections elsewhere in the
document as appropriate. When multiple values are requested, it is document as appropriate. When multiple values are requested, it is
generally helpful to include a summary table. It is also helpful generally helpful to include a summary table. It is also helpful
for this table to be in the same format as it should appear on the for this table to be in the same format as it should appear on the
IANA web site. IANA web site. For example:
Value Description Reference
-------- ------------------- ---------
tbd1 Foobar [RFCXXXX]
Note: in cases where authors feel that including the full table is Note: in cases where authors feel that including the full table is
too verbose or repetitive, authors should still include the table, too verbose or repetitive, authors should still include the table,
but may include a note asking the table be removed prior to but may include a note asking the table be removed prior to
publication of the final RFC. publication of the final RFC.
As an example, the following text could be used to request assignment As an example, the following text could be used to request assignment
of a DHCPv6 option number: of a DHCPv6 option number:
IANA has assigned an option code value of TBD1 to the DNS IANA has assigned an option code value of TBD1 to the DNS
Recursive Name Server option and an option code value of TBD2 to Recursive Name Server option and an option code value of TBD2 to
the Domain Search List option from the DHCP option code space the Domain Search List option from the DHCP option code space
defined in section 24.3 of RFC 3315. defined in section 24.3 of RFC 3315.
5.2. Updating Registrations 5.2. Updating Registrations
Registrations are a request to assign a new value, including the Registrations are a request to assign a new value, including the
related information needed to evaluate and document the request. Even related information needed to evaluate and document the request. Even
after a number has been assigned, some types of registrations contain after a number has been assigned, some types of registrations contain
additional information that may need to be updated over time. For additional information that may need to be updated over time. For
example, MIME types, character sets, language tags, etc. typically example, MIME media types, character sets, language tags, etc.
include more information than just the registered value itself. typically include more information than just the registered value
itself. Example information can include point of contact information,
Example information can include point of contact information,
security issues, pointers to updates, literature references, etc. In security issues, pointers to updates, literature references, etc. In
such cases, the document defining the namespace must clearly state such cases, the document defining the namespace must clearly state
who is responsible for maintaining and updating a registration. In who is responsible for maintaining and updating a registration. In
different cases, it may be appropriate to specify one or more of the different cases, it may be appropriate to specify one or more of the
following: following:
- Let the author update the registration, subject to the same - Let the author update the registration, subject to the same
constraints and review as with new registrations. constraints and review as with new registrations.
- Allow some mechanism to attach comments to the registration, for - Allow some mechanism to attach comments to the registration, for
skipping to change at page 18, line 27 skipping to change at page 19, line 49
6.3. After-The-Fact Registrations 6.3. After-The-Fact Registrations
Occasionally, IANA becomes aware that an unassigned value from a Occasionally, IANA becomes aware that an unassigned value from a
managed name space is in use on the Internet, or that an assigned managed name space is in use on the Internet, or that an assigned
value is being used for a different purpose than originally value is being used for a different purpose than originally
registered. IANA will not condone such misuse, i.e., procedures of registered. IANA will not condone such misuse, i.e., procedures of
the type described in this document MUST be applied to such cases. In the type described in this document MUST be applied to such cases. In
the absence of specifications to the contrary, values may only be the absence of specifications to the contrary, values may only be
reassigned for a different purpose with the consent of the original reassigned for a different purpose with the consent of the original
assignee (when possible) and with due consideration of the impact of assignee (when possible) and with due consideration of the impact of
such a reassignment. such a reassignment. In cases of likely controversy, consultation
with the IESG is advised.
6.4. Reclaiming Assigned Values 6.4. Reclaiming Assigned Values
Reclaiming previously-assigned values for reuse is tricky, because Reclaiming previously-assigned values for reuse is tricky, because
doing so can lead to interoperability problems with deployed systems doing so can lead to interoperability problems with deployed systems
still using the assigned values. Moreover, it can be extremely still using the assigned values. Moreover, it can be extremely
difficult to determine the extent of deployment of systems making use difficult to determine the extent of deployment of systems making use
of a particular value. However, in cases where the name space is of a particular value. However, in cases where the name space is
running out of unassigned values and additional ones are needed, it running out of unassigned values and additional ones are needed, it
may be desirable to attempt to reclaim unused values. When reclaiming may be desirable to attempt to reclaim unused values. When reclaiming
skipping to change at page 19, line 42 skipping to change at page 21, line 23
Experts and mail list participants too. Experts and mail list participants too.
Information concerning possible security vulnerabilities of a Information concerning possible security vulnerabilities of a
protocol may change over time. Likewise, security vulnerabilities protocol may change over time. Likewise, security vulnerabilities
related to how an assigned number is used (e.g., if it identifies a related to how an assigned number is used (e.g., if it identifies a
protocol) may change as well. As new vulnerabilities are discovered, protocol) may change as well. As new vulnerabilities are discovered,
information about such vulnerabilities may need to be attached to information about such vulnerabilities may need to be attached to
existing registrations, so that users are not mislead as to the true existing registrations, so that users are not mislead as to the true
security issues surrounding the use of a registered number. security issues surrounding the use of a registered number.
An analysis of security issues is required for all parameters (data An analysis of security issues is generally required for all
types, operation codes, keywords, etc.) used in IETF protocols or protocols that make use of parameters (data types, operation codes,
registered by IANA. All descriptions of security issues must be as keywords, etc.) used in IETF protocols or registered by IANA. Such
accurate as possible regardless of level of registration. In security considerations are usually included in the protocol document
particular, a statement that there are "no security issues associated [RFC3552]. It is the responsibility of the IANA Considerations
with this type" must not be given when it would be more accurate to associated with a particular registry to specify what (if any)
state that "the security issues associated with this type have not security considerations must be provided when assigning new values,
been assessed". and the process for reviewing such claims.
It is the responsibility of the IANA Considerations associated with a
particular registry to specify what (if any) security considerations
must be provided when assigning new values.
10. Changes Relative to RFC 2434 10. Changes Relative to RFC 2434
Changes include: Changes include:
- Major reordering of text to group the "creation of registries" - Major reordering of text to expand descriptions and to better
text in same section, etc. 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 thier needs.
- Numerous editorial changes to improve readability. - Numerous editorial changes to improve readability.
- Change "IETF Consensus" term to "IETF Review" and added more - Changed the term "IETF Consensus" to "IETF Review" and added more
clarifications. (History has shown that people see the words "IETF clarifications. History has shown that people see the words "IETF
Consensus" and know what that means; in contrast, the term has a Consensus" (without consulting the actual definition) are quick to
specific definition within this document.) make incorrect assumptions about what the term means in the
context of IANA Considerations.
- Added "RFC Required" to list of defined policies. - Added "RFC Required" to list of defined policies.
- Much more explicit directions and examples of "what to put in - Much more explicit directions and examples of "what to put in
RFCs". RFCs".
- "Specification Required" now implies use of Designated Expert to - "Specification Required" now implies use of Designated Expert to
evaluate specs for sufficient clarity. evaluate specs for sufficient clarity.
- Significantly changed the wording in Section 3. Main purpose is to - Significantly changed the wording in Section 3. Main purpose is to
make clear that Expert Reviewers are accountable to the community, make clear that Expert Reviewers are accountable to the community,
and to provide some guidance for review criteria in the default and to provide some guidance for review criteria in the default
case. case.
- removed wording: "By virtue of the IAB's role as overseer of IANA - Changed wording to remove any special appeals path. The normal
administration [RFC 1602], the IAB's decision is final [IETF- RFC2026 appeals path is used.
PROCESS]." This document now makes no changes to existing appeal
mechanisms relative to RFC 2026.
- Added section about reclaiming unused value. - Added section about reclaiming unused value.
- Added a section on after-the-fact registrations. - Added a section on after-the-fact registrations.
- no doubt other things... - Added section indicating that mailing lists used to evaluate
possible assignments (e.g., by a designated expert) are subject to
[RFC Editor: please remove the "changes relative to individual normal IETF rules.
drafts" below upon publication.]
10.1. Changes Relative to -00
- Revised Section 5.3 to try and make it even more clear.
10.2. Changes Relative to -02
- Significantly changed the wording in Section 3. Main purpose is
to make clear the Expert Reviewers are accountable to the com-
munity, and to provide some guidance for review criteria in the
default case.
- removed wording: "By virtue of the IAB's role as overseer of
IANA administration [RFC 1602], the IAB's decision is final
[IETF-PROCESS]." This document now makes no changes to existing
appeal mechanisms relative to RFC 2026.
11. IANA Considerations 11. IANA Considerations
This document is all about IANA Considerations. This document is all about IANA Considerations, but has no IANA
actions.
12. Acknowledgments 12. Acknowledgments
This document has benefited from specific feedback from Marcelo This document has benefited from specific feedback from Jari Arkko,
Bagnulo Braun, Brian Carpenter, Barbara Denny, Spencer Dawkins, Paul Marcelo Bagnulo Braun, Brian Carpenter, Michelle Cotton, Barbara
Hoffman, John Klensin, Allison Mankin, Mark Townsley and Bert Wijnen. Denny, Spencer Dawkins, Miguel Garcia, Paul Hoffman, Russ Housley,
John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus
Westerland and Bert Wijnen.
The original acknowledgments section in RFC 2434 was: The original acknowledgments section in RFC 2434 was:
Jon Postel and Joyce Reynolds provided a detailed explanation on what Jon Postel and Joyce Reynolds provided a detailed explanation on what
IANA needs in order to manage assignments efficiently, and patiently IANA needs in order to manage assignments efficiently, and patiently
provided comments on multiple versions of this document. Brian provided comments on multiple versions of this document. Brian
Carpenter provided helpful comments on earlier versions of the Carpenter provided helpful comments on earlier versions of the
document. One paragraph in the Security Considerations section was document. One paragraph in the Security Considerations section was
borrowed from [MIME-REG]. borrowed from [MIME-REG].
13. Normative References 13. Normative References
14. Informative References
[ASSIGNED] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
RFC 1700, October 1994. See also: Requirement Levels", BCP 14, RFC 2119, March 1997.
http://www.iana.org/numbers.html
[BGP4-EXT] Bates. T., Chandra, R., Katz, D. and Y. Rekhter, 14. Informative References
"Multiprotocol Extensions for BGP-4", RFC 2283,
February 1998. [ASSIGNED] "Assigned Numbers: RFC 1700 is Replaced by an On-line
Database," J. Reynolds, Ed., RFC 3232, January
2002.
[DHCP-OPTIONS] Alexander, S. and R. Droms, "DHCP Options and BOOTP [DHCP-OPTIONS] Alexander, S. and R. Droms, "DHCP Options and BOOTP
Vendor Extensions", RFC 2132, March 1997. Vendor Extensions", RFC 2132, March 1997.
[DHCP-IANA] Procedures and IANA Guidelines for Definition of New DHCP
Options and Message Types. R. Droms, RFC 2939,
September 2000.
[EXPERIMENTATION] "Assigning Experimental and Testing Numbers [EXPERIMENTATION] "Assigning Experimental and Testing Numbers
Considered Useful". T. Narten, RFC 3692, January Considered Useful". T. Narten, RFC 3692, January
2004. 2004.
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP Writing an IANA Considerations Section in RFCs", BCP
26, RFC 2434, October 1998. 26, RFC 2434, October 1998.
[IANA-MOU] Memorandum of Understanding Concerning the Technical Work [IANA-MOU] Memorandum of Understanding Concerning the Technical Work
of the Internet Assigned Numbers Authority. B. of the Internet Assigned Numbers Authority. B.
skipping to change at page 22, line 38 skipping to change at page 23, line 44
2000. 2000.
[IETF-PROCESS] Bradner, S., "The Internet Standards Process -- [IETF-PROCESS] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996. Revision 3", BCP 9, RFC 2026, October 1996.
[IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IPSEC] S. Kent, K. Seo., "Security Architecture for the Internet [IPSEC] S. Kent, K. Seo., "Security Architecture for the Internet
Protocol", RFC 4301, December 2005. Protocol", RFC 4301, December 2005.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [MIME-REG] "Media Type Specifications and Registration Procedures".
Requirement Levels", BCP 14, RFC 2119, March 1997. N. Freed, J. Klensin. December 2005, RFC 4288.
[MIME-LANG] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and
Continuations", RFC 2184, August 1997.
[MIME-REG] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Internet Mail Extension (MIME) Part Four:
Registration Procedures", RFC 2048, November 1996.
[SCSP] Luciani, J., Armitage, G. and J. Halpern, "Server Cache
Synchronization Protocol (SCSP)", RFC 2334, April
1998.
[SMTP-EXT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
Crocker, "SMTP Service Extensions", RFC 1869,
November 1995.
[PROTOCOL-EXT] "Procedures for protocol extensions and variations", [PROTOCOL-EXT] "Design Considerations for Protocol Extensions",
draft-carpenter-protocol-extensions-01.txt draft-carpenter-extension-recs-02.txt (Work in
Progress).
[RFC2929] Domain Name System (DNS) IANA Considerations. D. Eastlake [RFC2929] Domain Name System (DNS) IANA Considerations. D. Eastlake
3rd, E. Brunner-Williams, B. Manning. September 3rd, E. Brunner-Williams, B. Manning. September
2000. 2000.
[RFC3171] "IANA Guidelines for IPv4 Multicast Address Assignments".
Z. Albanna, K. Almeroth, D. Meyer, M. Schipper.
August 2001.
[RFC3228] IANA Considerations for IPv4 Internet Group Management [RFC3228] IANA Considerations for IPv4 Internet Group Management
Protocol (IGMP). B. Fenner. February 2002. Protocol (IGMP). B. Fenner. February 2002.
[RFC3552] Guidelines for Writing RFC Text on Security Considerations.
E. Rescorla, B. Korver. July 2003.
[RFC3575] IANA Considerations for RADIUS (Remote Authentication Dial [RFC3575] IANA Considerations for RADIUS (Remote Authentication Dial
In User Service). B. Aboba. RFC 3575, July 2003. In User Service). B. Aboba. RFC 3575, July 2003.
[RFC3748] Extensible Authentication Protocol (EAP), B. Aboba, L. [RFC3748] Extensible Authentication Protocol (EAP), B. Aboba, L.
Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz,
Ed., RFC 3748, June, 2004. Ed., RFC 3748, June, 2004.
[RFC3978] IETF Rights in Contributions. S. Bradner, Ed.. March 2005. [RFC3978] IETF Rights in Contributions. S. Bradner, Ed.. March 2005.
[RFC3575] IANA Considerations for RADIUS (Remote Authentication Dial [RFC3775] "Mobility Support in IPv6," D. Johnson, C. Perkins, J.
In User Service). B. Aboba. July 2003. Arkko. June 2004.
[RFC3748] Extensible Authentication Protocol (EAP). B. Aboba, L.
Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz,
Ed.. June 2004.
[RFC3932] The IESG and RFC Editor Documents: Procedures. H. [RFC3932] The IESG and RFC Editor Documents: Procedures. H.
Alvestrand. October 2004. Alvestrand. October 2004.
[RFC3942] "Reclassifying Dynamic Host Configuration Protocol version [RFC3942] "Reclassifying Dynamic Host Configuration Protocol version
4 (DHCPv4) Options", B. Volz. RFC 3942, November 4 (DHCPv4) Options", B. Volz. RFC 3942, November
2004 2004
[RFC3968] "The Internet Assigned Number Authority (IANA) Header Field [RFC3968] "The Internet Assigned Number Authority (IANA) Header Field
Parameter Registry for the Session Initiation Parameter Registry for the Session Initiation
Protocol (SIP)," G. Camarillo. RFC 3968, December Protocol (SIP)," G. Camarillo. RFC 3968, December
2004. 2004.
[RFC4005] "Diameter Network Access Server Application," P. Calhoun,
G. Zorn, D. Spence, D. Mitton. August 2005.
[RFC4025] "A Method for Storing IPsec Keying Material in DNS," M.
Richardson. March 2005.
[RFC4044] "Fibre Channel Management MIB", K. McCloghrie. May 2005.
[RFC4124] "Protocol Extensions for Support of Diffserv-aware MPLS
Traffic Engineering," F. Le Faucheur, Ed.. June
2005.
[RFC4169] "Hypertext Transfer Protocol (HTTP) Digest Authentication
Using Authentication and Key Agreement (AKA)
Version-2". V. Torvinen, J. Arkko, M. Naslund.
November 2005.
[RFC4271] "A Border Gateway Protocol 4 (BGP-4)," Y. Rekhter, Ed., T.
Li, Ed., S. Hares, Ed.. January 2006.
[RFC4283] "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)," A.
Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury.
November 2005.
[RFC4306] "Internet Key Exchange (IKEv2) Protocol", C. Kaufman, Ed.
December 2005
[RFC4340] "Datagram Congestion Control Protocol (DCCP)," E. Kohler,
M. Handley, S. Floyd. March 2006
[RFC4366] "Transport Layer Security (TLS) Extensions," S. Blake-
Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T.
Wright. April 2006.
[RFC4346] "The Transport Layer Security (TLS) Protocol Version 1.1,"
T. Dierks, E. Rescorla. April 2006.
[RFC4395] "Guidelines and Registration Procedures for New URI
Schemes," T. Hansen, T. Hardie, L. Masinter.
February 2006.
[RFC4422] "Simple Authentication and Security Layer (SASL)". A.
Melnikov, Ed., K. Zeilenga, Ed.. June 2006.
[RFC4520] "Internet Assigned Numbers Authority (IANA) Considerations
for the Lightweight Directory Access Protocol
(LDAP)," K. Zeilenga. June 2006.
[RFC4589] "Location Types Registry," H. Schulzrinne, H. Tschofenig.
July 2006.
[RFC4727] "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP,
and TCP Headers". B. Fenner. November 2006.
[RFC4995] "The RObust Header Compression (ROHC) Framework," L-E.
Jonsson, G. Pelletier, K. Sandlund. July 2007.
15. Authors' Addresses 15. Authors' Addresses
Thomas Narten Thomas Narten
IBM Corporation IBM Corporation
3039 Cornwallis Ave. 3039 Cornwallis Ave.
PO Box 12195 - BRQA/502 PO Box 12195 - BRQA/502
Research Triangle Park, NC 27709-2195 Research Triangle Park, NC 27709-2195
Phone: 919-254-7798 Phone: 919-254-7798
EMail: narten@us.ibm.com EMail: narten@us.ibm.com
 End of changes. 55 change blocks. 
161 lines changed or deleted 270 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/