< draft-leiba-cotton-iana-5226bis-02.txt   draft-leiba-cotton-iana-5226bis-03.txt >
Network Working Group M. Cotton Network Working Group M. Cotton
Internet-Draft ICANN Internet-Draft ICANN
BCP: 26 B. Leiba BCP: 26 B. Leiba
Obsoletes: 5226 (if approved) Huawei Technologies Obsoletes: 5226 (if approved) Huawei Technologies
Intended status: Best Current Practice T. Narten Intended status: Best Current Practice T. Narten
Expires: September 28, 2013 IBM Corporation Expires: January 31, 2014 IBM Corporation
March 29, 2013 August 01, 2013
Guidelines for Writing an IANA Considerations Section in RFCs Guidelines for Writing an IANA Considerations Section in RFCs
draft-leiba-cotton-iana-5226bis-02 draft-leiba-cotton-iana-5226bis-03
Abstract Abstract
Many protocols make use of points of extensibility that use constants Many protocols make use of points of extensibility that use constants
to identify various protocol parameters. To ensure that the values to identify various protocol parameters. To ensure that the values
used in these fields do not have conflicting uses, and to promote used in these fields do not have conflicting uses, and to promote
interoperability, their allocation is often coordinated by a central interoperability, their allocation is often coordinated by a central
authority. For IETF protocols, that role is filled by the Internet authority. For IETF protocols, that role is filled by the Internet
Assigned Numbers Authority (IANA). Assigned Numbers Authority (IANA).
To manage a given namespace prudently, IANA needs guidance describing To make assignments in a given namespace prudently, IANA needs
the conditions under which new values should be assigned, as well as guidance describing the conditions under which new values should be
when and how modifications to existing values can be made. This assigned, as well as when and how modifications to existing values
document defines a framework for the documentation of these can be made. This document defines a framework for the documentation
guidelines by specification authors, in order to assure that the of these guidelines by specification authors, in order to assure that
guidance given to IANA is clear and addresses the various issues that the guidance given to IANA is clear and addresses the various issues
are likely in the operation of a registry. that are likely in the operation of a registry.
This is the third edition, and obsoletes RFC 5226. This is the third edition, and obsoletes RFC 5226.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 31, 2014.
This Internet-Draft will expire on September 28, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/ Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology Used In This Document . . . . . . . . . . . . 3 1.1. Terminology Used In This Document . . . . . . . . . . . . 3
2. Creating and Revising Registries . . . . . . . . . . . . . . . 3 2. Creating and Revising Registries . . . . . . . . . . . . . . . 4
2.1. Documentation Requirements for Registries . . . . . . . . 4 2.1. Documentation Requirements for Registries . . . . . . . . 4
2.2. Defining an Appropriate Registry Policy . . . . . . . . . 6 2.2. Defining an Appropriate Registry Policy . . . . . . . . . 6
2.2.1. Using the Well-Known Registration Policies . . . . . . 8 2.2.1. Using the Well-Known Registration Policies . . . . . . 8
2.2.2. Using Multiple Policies in Combination . . . . . . . . 9 2.2.2. Using Multiple Policies in Combination . . . . . . . . 9
2.3. Revising Existing Registries . . . . . . . . . . . . . . . 10 2.3. Revising Existing Registries . . . . . . . . . . . . . . . 10
3. Registering New Values in an Existing Registry . . . . . . . . 10 3. Registering New Values in an Existing Registry . . . . . . . . 10
3.1. Documentation Requirements for Registrations . . . . . . . 10 3.1. Documentation Requirements for Registrations . . . . . . . 10
3.2. Updating Existing Registrations . . . . . . . . . . . . . 12 3.2. Updating Existing Registrations . . . . . . . . . . . . . 12
3.3. Overriding Registration Procedures . . . . . . . . . . . . 12 3.3. Overriding Registration Procedures . . . . . . . . . . . . 12
4. Well-Known Registration Policies . . . . . . . . . . . . . . . 13 4. Well-Known Registration Policies . . . . . . . . . . . . . . . 13
skipping to change at page 2, line 54 skipping to change at page 3, line 6
6. Well-Known Registration Status Terminology . . . . . . . . . . 21 6. Well-Known Registration Status Terminology . . . . . . . . . . 21
7. Documentation References in IANA Registries . . . . . . . . . 22 7. Documentation References in IANA Registries . . . . . . . . . 22
8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 22 8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 22
9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 23 9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 23
9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 23 9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 23
9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 24 9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 24
9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 24 9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 24
9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 25 9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 25
9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 25 9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 25
9.6. Closing or Obsoleting a Registry . . . . . . . . . . . . . 26 9.6. Closing or Obsoleting a Registry . . . . . . . . . . . . . 26
9.7. BCP 78/79 Issues in Registries . . . . . . . . . . . . . . 26
10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 26 11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 26
12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26
13. To-Do List; resolve and remove before requesting publication . 27 13. To-Do List; resolve and remove before requesting publication . 27
14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 27 14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 27
14.1. 2013: Changes in This Document Relative to RFC 5226 . . . 27 14.1. 2013: Changes in This Document Relative to RFC 5226 . . . 27
14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 28 14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 28
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
15.1. Acknowledgments for This Document (2013) . . . . . . . . 28 15.1. Acknowledgments for This Document (2013) . . . . . . . . 28
15.2. Acknowledgments from the second edition (2008) . . . . . 29 15.2. Acknowledgments from the second edition (2008) . . . . . 29
skipping to change at page 3, line 24 skipping to change at page 3, line 29
16.2. Informative References . . . . . . . . . . . . . . . . . 29 16.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Many protocols make use of points of extensibility that use constants Many protocols make use of points of extensibility that use constants
to identify various protocol parameters. To ensure that the values to identify various protocol parameters. To ensure that the values
used in these fields do not have conflicting uses, and to promote used in these fields do not have conflicting uses, and to promote
interoperability, their allocation is often coordinated by a central interoperability, their allocation is often coordinated by a central
authority. For IETF protocols, that role is filled by the Internet authority. For IETF protocols, that role is filled by the Internet
Assigned Numbers Authority (IANA) [RFC2860]. Assigned Numbers Authority (IANA) [RFC2860]. IANA services are
currently provided by the International Corporation for Assigned
Names and Numbers (ICANN).
The Protocol field in the IP header [RFC0791] and MIME media types The Protocol field in the IP header [RFC0791] and MIME media types
[RFC4288] are two examples of such coordinations. [RFC4288] are two examples of such coordinations.
In this document, we call the range of possible values for such a In this document, we call the range of possible values for such a
field a "namespace". The binding or association of a specific value field a "namespace". The binding or association of a specific value
with a particular purpose within a namespace is called an assignment with a particular purpose within a namespace is called an assignment
(or, variously: an assigned number, assigned value, "code point", (or, variously: an assigned number, assigned value, "code point",
"protocol constant", or "protocol parameter"). The act of assignment "protocol constant", or "protocol parameter"). The act of assignment
is called a registration, and it takes place in the context of a is called a registration, and it takes place in the context of a
registry. registry. The terms "assignment" and "registration" are used
interchangably throughout this document.
To manage a given namespace prudently, IANA needs guidance describing To make assignments in a given namespace prudently, IANA needs
the conditions under which new values should be assigned, as well as guidance describing the conditions under which new values should be
when and how modifications to existing values can be made. This assigned, as well as when and how modifications to existing values
document defines a framework for the documentation of these can be made. This document defines a framework for the documentation
guidelines by specification authors, in order to assure that the of these guidelines by specification authors, in order to assure that
guidance given to IANA is clear and addresses the various issues that the guidance given to IANA is clear and addresses the various issues
are likely in the operation of a registry. that are likely in the operation of a registry.
Typically, this information is recorded in a dedicated section of the Typically, this information is recorded in a dedicated section of the
specification with the title "IANA Considerations". specification with the title "IANA Considerations".
1.1. Terminology Used In This Document 1.1. Terminology Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
For this document, "the specification" as used by RFC 2119 refers to For this document, "the specification" as used by RFC 2119 refers to
the processing of protocol documents within the IETF standards the processing of protocol documents within the IETF standards
process. process.
2. Creating and Revising Registries 2. Creating and Revising Registries
Defining a registry involves describing the namespace(s) to be Defining a registry involves describing the namespace(s) to be
created, listing an initial set of assignments (if appropriate), and created, listing an initial set of assignments (if appropriate), and
documenting guidelines on how future assignments are to be made. documenting guidelines on how future assignments are to be made.
Before defining a registry, however, consider delegating the Before defining a registry, however, consider delegating the
namespace in some manner. This route should be pursued when namespace in some manner. This route should be pursued when
appropriate, as it lessens the burden on IANA for dealing with appropriate, as it lessens the burden on IANA for dealing with
assignments. assignments.
In particular, not all namespaces require a registry; in some cases, In particular, not all namespaces require a registry; in some cases,
skipping to change at page 6, line 42 skipping to change at page 6, line 42
3-254 Unassigned 3-254 Unassigned
255 Reserved 255 Reserved
--------------------------------------------------------------- ---------------------------------------------------------------
For examples of documents that establish registries, consult For examples of documents that establish registries, consult
[RFC6195], [RFC3575], [RFC3968], and [RFC4520]. [RFC6195], [RFC3575], [RFC3968], and [RFC4520].
2.2. Defining an Appropriate Registry Policy 2.2. Defining an Appropriate Registry Policy
There are several issues to consider when defining the policy for the There are several issues to consider when defining the policy for the
management of a registry. new assignments in a registry.
If the registry's namespace is limited, assignments will need to be If the registry's namespace is limited, assignments will need to be
made carefully to prevent exhaustion. made carefully to prevent exhaustion.
Even when the space is essentially unlimited, however, it is usually Even when the space is essentially unlimited, however, it is usually
desirable to have at least a minimal review prior to assignment in desirable to have at least a minimal review prior to assignment in
order to: order to:
o prevent the hoarding of or unnecessary wasting of values. For o prevent the hoarding of or unnecessary wasting of values. For
example, if the space consists of text strings, it may be example, if the space consists of text strings, it may be
skipping to change at page 10, line 27 skipping to change at page 10, line 27
2.3. Revising Existing Registries 2.3. Revising Existing Registries
Updating the registration process for an already existing (previously Updating the registration process for an already existing (previously
created) namespace (whether created explicitly or implicitly) follows created) namespace (whether created explicitly or implicitly) follows
a process similar to that used when creating a new namespace. That a process similar to that used when creating a new namespace. That
is, a document is produced that makes reference to the existing is, a document is produced that makes reference to the existing
namespace and then provides detailed guidelines for handling namespace and then provides detailed guidelines for handling
assignments in each individual namespace. Such documents are assignments in each individual namespace. Such documents are
normally processed as Best Current Practices (BCPs) [RFC2026]. normally processed as Best Current Practices (BCPs) [RFC2026].
Example documents that updated the guidelines for managing (then) Example documents that updated the guidelines for assignments in pre-
pre-existing registries include: [RFC6195], [RFC3228], and [RFC3575]. existing registries include: [RFC6195], [RFC3228], and [RFC3575].
3. Registering New Values in an Existing Registry 3. Registering New Values in an Existing Registry
3.1. Documentation Requirements for Registrations 3.1. Documentation Requirements for Registrations
Often, documents request an assignment from an already existing Often, documents request an assignment from an already existing
namespace (one created by a previously published document). namespace (one created by a previously published document).
Such documents should clearly identify the namespace in which each Such documents should clearly identify the namespace 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-
skipping to change at page 14, line 21 skipping to change at page 14, line 21
the intended scope of use). the intended scope of use).
Examples: Examples:
Site-specific options in DHCP [RFC2939] Site-specific options in DHCP [RFC2939]
Fibre Channel Port Type Registry [RFC4044] Fibre Channel Port Type Registry [RFC4044]
TLS ClientCertificateType Identifiers 224-255 [RFC5246] TLS ClientCertificateType Identifiers 224-255 [RFC5246]
4.2. Experimental Use 4.2. Experimental Use
Similar to private or local use only, with the purpose being to Experimental Use is similar to Private Use only, but with the purpose
facilitate experimentation. See [RFC3692] for details. being to facilitate experimentation. See [RFC3692] for details.
Example: Example:
Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP
Headers [RFC4727] Headers [RFC4727]
4.3. Hierarchical Allocation 4.3. Hierarchical Allocation
Delegated managers can assign values provided they have been given With Hierarchical Allocation, delegated administrators are given
control over that part of the namespace. IANA controls the higher control over part of the namespace, and can assign values in that
levels of the namespace according to one of the other policies. part of the namespace. IANA makes allocations in the higher levels
of the namespace according to one of the other policies.
Examples: Examples:
DNS names DNS names
Object Identifiers Object Identifiers
IP addresses IP addresses
4.4. First Come First Served 4.4. First Come First Served
Assignments are made to anyone on a first come, first served basis. For the First Come First Served policy, assignments are made to
There is no substantive review of the request, other than to ensure anyone on a first come, first served basis. There is no substantive
that it is well-formed and doesn't duplicate an existing assignment. review of the request, other than to ensure that it is well-formed
However, requests must include a minimal amount of clerical and doesn't duplicate an existing assignment. However, requests must
information, such as a point of contact (including an email address) include a minimal amount of clerical information, such as a point of
contact (including an email address, and sometimes a postal address)
and a brief description of how the value will be used. Additional and a brief description of how the value will be used. Additional
information specific to the type of value requested may also need to information specific to the type of value requested may also need to
be provided, as defined by the namespace. For numbers, the exact be provided, as defined by the namespace. For numbers, the exact
value is generally assigned by IANA; with names, specific text value is generally assigned by IANA; with names, specific text
strings can usually be requested. strings can usually be requested.
Examples: Examples:
SASL mechanism names [RFC4422] SASL mechanism names [RFC4422]
LDAP Protocol Mechanisms and LDAP Syntax [RFC4520] LDAP Protocol Mechanisms and LDAP Syntax [RFC4520]
4.5. Expert Review 4.5. Expert Review
(Sometimes also called "Designated Expert" in earlier editions of (Also called "Designated Expert" in earlier editions of this
this document.) Review and approval by a designated expert is document.) For the Expert Review policy, review and approval by a
required. The required documentation and review criteria for use by designated expert (see Section 5) is required. The required
the designated expert should be provided when defining the registry. documentation and review criteria for use by the designated expert
For example, see Sections 6 and 7.2 in [RFC3748]. should be provided when defining the registry. For example, see
Sections 6 and 7.2 in [RFC3748].
It is particularly important, when using a designated expert, to give It is particularly important, when using a designated expert, to give
clear guidance to the expert, laying out criteria for performing an clear guidance to the expert, laying out criteria for performing an
evaluation and reasons for rejecting a request. When specifying a evaluation and reasons for rejecting a request. When specifying a
policy that involves a designated expert, the IANA Considerations policy that involves a designated expert, the IANA Considerations
SHOULD contain such guidance. It is also a good idea to include, SHOULD contain such guidance. It is also a good idea to include,
when possible, a sense of whether many registrations are expected when possible, a sense of whether many registrations are expected
over time, or if the registry is expected to be updated infrequently over time, or if the registry is expected to be updated infrequently
or in exceptional circumstances only. or in exceptional circumstances only.
Examples: Examples:
EAP Method Types [RFC3748] EAP Method Types [RFC3748]
HTTP Digest AKA algorithm versions [RFC4169] HTTP Digest AKA algorithm versions [RFC4169]
URI schemes [RFC4395] URI schemes [RFC4395]
GEOPRIV Location Types [RFC4589] GEOPRIV Location Types [RFC4589]
4.6. Specification Required 4.6. Specification Required
Review and approval by a Designated Expert is required, (as in For the Specification Required policy, review and approval by a
Section 4.5) and the values and their meanings must be documented in designated expert (see Section 5) is required, and the values and
a permanent and readily available public specification, in sufficient their meanings must be documented in a permanent and readily
detail so that interoperability between independent implementations available public specification, in sufficient detail so that
is possible. The Designated Expert will review the public interoperability between independent implementations is possible.
specification and evaluate whether it is sufficiently clear to allow The designated expert will review the public specification and
interoperable implementations. The intention behind "permanent and evaluate whether it is sufficiently clear to allow interoperable
readily available" is that a document can reasonably be expected to implementations. The intention behind "permanent and readily
be findable and retrievable long after IANA assignment of the available" is that a document can reasonably be expected to be
requested value. Publication of an RFC is an ideal means of findable and retrievable long after IANA assignment of the requested
achieving this requirement, but Specification Required is intended to value. Publication of an RFC is an ideal means of achieving this
also cover the case of a document published outside of the RFC path. requirement, but Specification Required is intended to also cover the
For RFC publication, the normal RFC review process is expected to case of a document published outside of the RFC path. For RFC
provide the necessary review for interoperability, though the publication, the normal RFC review process is expected to provide the
designated expert may be a particularly well-qualified person to necessary review for interoperability, though the designated expert
perform such a review. may be a particularly well-qualified person to perform such a review.
When specifying this policy, just use the term "Specification When specifying this policy, just use the term "Specification
Required". Some specifications have chosen to refer to it as "Expert Required". Some specifications have chosen to refer to it as "Expert
Review with Specification Required", and that only causes confusion. Review with Specification Required", and that only causes confusion.
Examples: Examples:
Diffserv-aware TE Bandwidth Constraints Model Identifiers Diffserv-aware TE Bandwidth Constraints Model Identifiers
[RFC4124] [RFC4124]
TLS ClientCertificateType Identifiers 64-223 [RFC5246] TLS ClientCertificateType Identifiers 64-223 [RFC5246]
ROHC Profile Identifiers [RFC5795] ROHC Profile Identifiers [RFC5795]
4.7. RFC Required 4.7. RFC Required
RFC publication suffices, as an IETF submission or in any other With the RFC Required policy, the registration request, along with
stream (currently an RFC Editor Independent Submission [RFC5742] or associated documentation, must be published in an RFC. The RFC need
an RFC in the IRTF or IAB Stream). Unless otherwise specified, any not be in the IETF stream, but may be in any RFC stream (currently an
RFC may be in the IETF, IRTF, or IAB stream, or an RFC Editor
Independent Submission [RFC5742]). Unless otherwise specified, any
type of RFC is sufficient (currently Standards Track, BCP, type of RFC is sufficient (currently Standards Track, BCP,
Informational, Experimental, Historic). Informational, Experimental, or Historic).
4.8. IETF Review 4.8. IETF Review
(Formerly called "IETF Consensus" in the first edition of this (Formerly called "IETF Consensus" in the first edition of this
document.) New values are assigned only through RFCs in the IETF document.) With the IETF Review policy, new values are assigned only
Stream -- those that have been shepherded through the IESG as AD- through RFCs in the IETF Stream -- those that have been shepherded
Sponsored or IETF working group Documents [RFC2026] [RFC5378]. The through the IESG as AD-Sponsored or IETF working group Documents
intention is that the document and proposed assignment will be [RFC2026] [RFC5378].
reviewed by the IESG and appropriate IETF working groups (or experts,
if suitable working groups no longer exist) to ensure that the
proposed assignment will not negatively impact interoperability or
otherwise extend IETF protocols in an inappropriate or damaging
manner.
To ensure adequate community review, such documents are shepherded The intent is that the document and proposed assignment will be
through the IESG as AD-sponsored or working group documents with an reviewed by the IETF community (including appropriate IETF working
IETF Last Call. groups, directorates, and other experts) and by the IESG, to ensure
that the proposed assignment will not negatively affect
interoperability or otherwise extend IETF protocols in an
inappropriate or damaging manner. To ensure adequate community
review, such documents will always undergo an IETF Last Call.
Examples: Examples:
IPSECKEY Algorithm Types [RFC4025] IPSECKEY Algorithm Types [RFC4025]
Accounting-Auth-Method AVP values in DIAMETER [RFC4005] Accounting-Auth-Method AVP values in DIAMETER [RFC4005]
TLS Extension Types [RFC5246] TLS Extension Types [RFC5246]
4.9. Standards Action 4.9. Standards Action
Values are assigned only for Standards Track RFCs approved by the For the Standards Action policy, values are assigned only through
IESG. Standards Track RFCs approved by the IESG.
Examples: Examples:
BGP message types [RFC4271] BGP message types [RFC4271]
Mobile Node Identifier option types [RFC4283] Mobile Node Identifier option types [RFC4283]
TLS ClientCertificateType Identifiers 0-63 [RFC5246] TLS ClientCertificateType Identifiers 0-63 [RFC5246]
DCCP Packet Types [RFC4340] DCCP Packet Types [RFC4340]
4.10. IESG Approval 4.10. IESG Approval
skipping to change at page 18, line 48 skipping to change at page 18, line 48
requests for an assignment to the expert for evaluation, and the requests for an assignment to the expert for evaluation, and the
expert (after performing the evaluation) informs IANA as to whether expert (after performing the evaluation) informs IANA as to whether
or not to make the assignment or registration. or not to make the assignment or registration.
It will often be useful to use a designated expert only some of the It will often be useful to use a designated expert only some of the
time, as a supplement to other processes. For more discussion of time, as a supplement to other processes. For more discussion of
that topic, see Section 2.2.2. that topic, see Section 2.2.2.
5.2. The Role of the Designated Expert 5.2. The Role of the Designated Expert
The designated expert is responsible for initiating and coordinating The designated expert is responsible for coordinating the appropriate
the appropriate review of an assignment request. The review may be review of an assignment request. The review may be wide or narrow,
wide or narrow, depending on the situation and the judgment of the depending on the situation and the judgment of the designated expert.
designated expert. This may involve consultation with a set of This may involve consultation with a set of technology experts,
technology experts, discussion on a public mailing list, consultation discussion on a public mailing list, consultation with a working
with a working group (or its mailing list if the working group has group (or its mailing list if the working group has disbanded), etc.
disbanded), etc. Ideally, the designated expert follows specific Ideally, the designated expert follows specific review criteria as
review criteria as documented with the protocol that creates or uses documented with the protocol that creates or uses the namespace. See
the namespace. See the IANA Considerations sections of [RFC3748] and the IANA Considerations sections of [RFC3748] and [RFC3575] for
[RFC3575] for specific examples. specific examples.
Designated experts are expected to be able to defend their decisions Designated experts are expected to be able to defend their decisions
to the IETF community, and the evaluation process is not intended to to the IETF community, and the evaluation process is not intended to
be secretive or bestow unquestioned power on the expert. Experts are be secretive or bestow unquestioned power on the expert. Experts are
expected to apply applicable documented review or vetting procedures, expected to apply applicable documented review or vetting procedures,
or in the absence of documented criteria, follow generally accepted or in the absence of documented criteria, follow generally accepted
norms such as those in Section 5.3. norms such as those in Section 5.3.
Section 3.2 discusses disputes and appeals in more detail. Section 3.2 discusses disputes and appeals in more detail.
skipping to change at page 21, line 40 skipping to change at page 21, line 40
It is possible, through carelessness, accident, inattentiveness, or It is possible, through carelessness, accident, inattentiveness, or
even willful disregard, that changes might be made after the even willful disregard, that changes might be made after the
designated expert's review and approval that would, if the document designated expert's review and approval that would, if the document
were re-reviewed, cause the expert not to approve the registration. were re-reviewed, cause the expert not to approve the registration.
It is up to the IESG, with the token held by the responsible Area It is up to the IESG, with the token held by the responsible Area
Director, to be alert to such situations and to recognize that such Director, to be alert to such situations and to recognize that such
changes need to be checked. changes need to be checked.
6. Well-Known Registration Status Terminology 6. Well-Known Registration Status Terminology
The following labels describe the status of an individual (or range) The following labels describe the status of an assignment or range of
of assignments: assignments:
Private Use: Private use only (not assigned), as described in Private Use: Private use only (not assigned), as described in
Section 4.1. Section 4.1.
Experimental: Available for general experimental use as described Experimental: Available for general experimental use as described
in [RFC3692]. IANA does not record specific assignments for in [RFC3692]. IANA does not record specific assignments for
any particular use. any particular use.
Unassigned: Not currently assigned, and available for assignment Unassigned: Not currently assigned, and available for assignment
via documented procedures. While it's generally clear that via documented procedures. While it's generally clear that
skipping to change at page 24, line 4 skipping to change at page 23, line 49
If information for registered items has been or is being moved to If information for registered items has been or is being moved to
other documents, then, of course, the registration information should other documents, then, of course, the registration information should
be changed to point to those other documents. In no case is it be changed to point to those other documents. In no case is it
reasonable to leave documentation pointers to the obsoleted document reasonable to leave documentation pointers to the obsoleted document
for any registries or registered items that are still in current use. for any registries or registered items that are still in current use.
9. Miscellaneous Issues 9. Miscellaneous Issues
9.1. When There Are No IANA Actions 9.1. When There Are No IANA Actions
Before an Internet-Draft can be published as an RFC, IANA needs to 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 know what actions (if any) it needs to perform. Experience has shown
that it is not always immediately obvious whether a document has no that it is not always immediately obvious whether a document has no
IANA actions, without reviewing the document in some detail. In 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 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 that the author has consciously made such a determination), such
documents should include an IANA Considerations section that states: documents should include an IANA Considerations section that states:
This document has no IANA actions. This document has no IANA actions.
This statement, or an equivalent, must only be inserted after the This statement, or an equivalent, must only be inserted after the
working group or individual submitter has carefully verified it to be working group or individual submitter has carefully verified it to be
true. Using such wording as a matter of "boilerplate" or without true. Using such wording as a matter of "boilerplate" or without
careful consideration can lead to incomplete or incorrect IANA careful consideration can lead to incomplete or incorrect IANA
actions being performed. actions being performed.
If a specification makes use of values from a namespace that is not If a specification makes use of values from a namespace in which
managed by IANA, it may be useful to note this fact, with wording assignments are not made by IANA, it may be useful to note this fact,
such as this: with wording such as this:
The values of the Foobar parameter are assigned by the Barfoo The values of the Foobar parameter are assigned by the Barfoo
registry on behalf of the Rabfoo Forum. Therefore, this document registry on behalf of the Rabfoo Forum. Therefore, this document
has no IANA actions. has no IANA actions.
In some cases, the absence of IANA-assigned values may be considered In some cases, the absence of IANA-assigned values may be considered
valuable information for future readers; in other cases, it may be valuable information for future readers; in other cases, it may be
considered of no value once the document has been approved, and may considered of no value once the document has been approved, and may
be removed before archival publication. This choice should be made be removed before archival publication. This choice should be made
clear in the draft, for example, by including a sentence such as clear in the draft, for example, by including a sentence such as
[RFC Editor: please remove this section prior to publication.] [RFC Editor: please remove this section prior to publication.]
or or
[RFC Editor: please do not remove this section.] [RFC Editor: please do not remove this section.]
9.2. Namespaces Lacking Documented Guidance 9.2. Namespaces Lacking Documented Guidance
For all existing RFCs that either explicitly or implicitly rely on For all existing RFCs that either explicitly or implicitly rely on
IANA to evaluate assignments without specifying a precise evaluation IANA to make assignments without specifying a precise assignment
policy, IANA (in consultation with the IESG) will continue to decide policy, IANA (in consultation with the IESG) will continue to decide
what policy is appropriate. Changes to existing policies can always what policy is appropriate. Changes to existing policies can always
be initiated through the normal IETF consensus process. be initiated through the normal IETF consensus process.
All future RFCs that either explicitly or implicitly rely on IANA to All future RFCs that either explicitly or implicitly rely on IANA to
register or otherwise manage namespace assignments MUST provide register or otherwise administer namespace assignments MUST provide
guidelines for managing the namespace. guidelines for administration of the namespace.
9.3. After-the-Fact Registrations 9.3. After-the-Fact Registrations
Occasionally, IANA becomes aware that an unassigned value from a
managed namespace is in use on the Internet or that an assigned value Occasionally, the IETF becomes aware that an unassigned value from a
is being used for a different purpose than originally registered. namespace is in use on the Internet or that an assigned value is
IANA will not condone such misuse; procedures of the type described 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 MUST be applied to such cases. In the absence of in this document MUST be applied to such cases. In the absence of
specifications to the contrary, values may only be reassigned for a specifications to the contrary, values may only be reassigned for a
different purpose with the consent of the original assignee (when different purpose with the consent of the original assignee (when
possible) and with due consideration of the impact of such a possible) and with due consideration of the impact of such a
reassignment. In cases of likely controversy, consultation with the reassignment. In cases of likely controversy, consultation with the
IESG is advised. IESG is advised.
9.4. Reclaiming Assigned Values 9.4. Reclaiming Assigned Values
Reclaiming previously assigned values for reuse is tricky, because Reclaiming previously assigned values for reuse is tricky, because
skipping to change at page 26, line 4 skipping to change at page 25, line 47
9.5. Contact Person vs Assignee or Owner 9.5. Contact Person vs Assignee or Owner
Many registries include designation of a technical or administrative Many registries include designation of a technical or administrative
contact associated with each entry. Often, this is recorded as contact associated with each entry. Often, this is recorded as
contact information for an individual. It is unclear, though, what contact information for an individual. It is unclear, though, what
role the individual has with respect to the registration: is this role the individual has with respect to the registration: is this
item registered on behalf of the individual, the company the item registered on behalf of the individual, the company the
individual worked for, or perhaps another organization the individual individual worked for, or perhaps another organization the individual
was acting for? was acting for?
This matters because some time later, when the individual has changed This matters because some time later, when the individual has changed
jobs or roles, and perhaps can no longer be contacted, someone might jobs or roles, and perhaps can no longer be contacted, someone might
want to update the registration. IANA has no way to know what want to update the registration. IANA has no way to know what
company, organization, or individual should be allowed to take the company, organization, or individual should be allowed to take the
registration over. For registrations rooted in RFCs, the stream registration over. For registrations rooted in RFCs, the stream
owner (such as the IESG or the IAB) can make an overriding decision. owner (such as the IESG or the IAB) can make an overriding decision.
But in other cases, there is no recourse. But in other cases, there is no recourse.
Registries can include, in addition to a "Contact" field, an Registries can include, in addition to a "Contact" field, an
"Assignee" or "Owner" field that can be used to address this "Assignee" or "Owner" field that can be used to address this
situation, giving IANA clear guidance as to the actual owner of the situation, giving IANA clear guidance as to the actual owner of the
registration. Alternatively, organizations can put an organizational registration. Alternatively, organizations can put an organizational
role into the "Contact" field in order to make their ownership clear. role into the "Contact" field in order to make their ownership clear.
9.6. Closing or Obsoleting a Registry 9.6. Closing or Obsoleting a Registry
[[This section needs to be resolved before publication.]] [[This section needs to be resolved before publication.]]
9.7. BCP 78/79 Issues in Registries Sometimes there is a request to "close" a registry. Registries can
only be marked as closed, obsoleted or historical through publication
[[This section needs to be resolved before publication, but I'm not of an RFC. o Closing a registry When closing a registry, no further
sure anything's needed here after all. ]] registrations will be accepted. The information in the registry will
still be valid and if needed, registrations already in the registry
can be updated. o Making a registry Historical When a registry is
made Historical???? o Obsoleting a registry This means the
information in the registry is no longer used or applicable???
Whether the registry is closed, obsoleted or made historical, the
information will remain in the registry for informational purposes
unless specifically requested to be removed. all registrations
cancelled and existing values deprecated/ inoperative? values no
longer accessible to public view?
10. Appeals 10. Appeals
Appeals of registration decisions made by IANA can be made using the Appeals of protocol parameter registration decisions can be made
normal IETF appeals process as described in Section 6.5 of [RFC2026]. using the normal IETF appeals process as described in [RFC2026],
Specifically, appeals should be directed to the IESG, followed (if Section 6.5. That is, an initial appeal should be directed to the
necessary) by an appeal to the IAB, etc. IESG, followed (if necessary) by an appeal to the IAB.
11. Mailing Lists 11. Mailing Lists
All IETF mailing lists associated with evaluating or discussing All IETF mailing lists associated with evaluating or discussing
assignment requests as described in this document are subject to assignment requests as described in this document are subject to
whatever rules of conduct and methods of list management are whatever rules of conduct and methods of list management are
currently defined by Best Current Practices or by IESG decision. currently defined by Best Current Practices or by IESG decision.
12. Security Considerations 12. Security Considerations
skipping to change at page 27, line 45 skipping to change at page 27, line 45
o Added Section 2.2.2, Using Multiple Policies in Combination. o Added Section 2.2.2, Using Multiple Policies in Combination.
o Added Section 7, Documentation References in IANA Registries o Added Section 7, Documentation References in IANA Registries
o Added Section 8, What to Do in "bis" Documents 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.5, Contact Person vs Assignee or Owner
o Added Section 9.6, Closing or Obsoleting a Registry o Added Section 9.6, Closing or Obsoleting a Registry
o Added Section 9.7, BCP 78/79 Issues in Registries
Clarifications and such: Clarifications and such:
o Some reorganization -- moved text around for clarity and easier o Some reorganization -- moved text around for clarity and easier
reading. reading.
o Made clarifications about identification of IANA registries and o Made clarifications about identification of IANA registries and
use of URLs for them. use of URLs for them.
o Clarified the distinction between "Unassigned" and "Reserved". o Clarified the distinction between "Unassigned" and "Reserved".
skipping to change at page 29, line 9 skipping to change at page 29, line 9
to normal IETF rules. to normal IETF rules.
15. Acknowledgments 15. Acknowledgments
15.1. Acknowledgments for This Document (2013) 15.1. Acknowledgments for This Document (2013)
Thomas Narten and Harald Tveit Alvestrand edited the two earlier Thomas Narten and Harald Tveit Alvestrand edited the two earlier
editions of this document (RFCs 2434 and 5226), and Thomas continues editions of this document (RFCs 2434 and 5226), and Thomas continues
his role in this third edition. Much of the text from RFC 5226 his role in this third edition. Much of the text from RFC 5226
remains in this edition. remains in this edition.
Special thanks to Mark Nottingham for thoroughly reviewing the This document has benefited from thorough review and comments by John
document and reorganizing the text for better organization and Klensin and Mark Nottingham.
readability.
Special thanks to Mark Nottingham for reorganizing some of the text
for better organization and readability.
15.2. Acknowledgments from the second edition (2008) 15.2. Acknowledgments from the second edition (2008)
The original acknowledgments section in RFC 5226 was: The original acknowledgments section in RFC 5226 was:
This document has benefited from specific feedback from Jari Arkko, This document has benefited from specific feedback from Jari Arkko,
Marcelo Bagnulo Braun, Brian Carpenter, Michelle Cotton, Spencer Marcelo Bagnulo Braun, Brian Carpenter, Michelle Cotton, Spencer
Dawkins, Barbara Denny, Miguel Garcia, Paul Hoffman, Russ Housley, Dawkins, Barbara Denny, Miguel Garcia, Paul Hoffman, Russ Housley,
John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus
Westerlund, and Bert Wijnen. Westerlund, and Bert Wijnen.
skipping to change at page 32, line 25 skipping to change at page 32, line 25
[RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support [RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011. in IPv6", RFC 6275, July 2011.
[RFC6709] Carpenter, B., Aboba, B. and S. Cheshire, "Design [RFC6709] Carpenter, B., Aboba, B. and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709, Considerations for Protocol Extensions", RFC 6709,
September 2012. September 2012.
Authors' Addresses Authors' Addresses
Michelle Cotton, Manager, IANA Services Michelle Cotton
Internet Corporation for Assigned Names and Numbers Internet Corporation for Assigned Names and Numbers
12025 Waterfront Drive, Suite 300 12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536 Los Angeles, CA 90094-2536
US US
Phone: +1 310 301 5812 Phone: +1 310 823 9358
Email: michelle.cotton@icann.org Email: michelle.cotton@icann.org
URI: http://www.icann.org/
Barry Leiba Barry Leiba
Huawei Technologies Huawei Technologies
Phone: +1 646 827 0648 Phone: +1 646 827 0648
Email: barryleiba@computer.org Email: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/ URI: http://internetmessagingtechnology.org/
Thomas Narten Thomas Narten
IBM Corporation IBM Corporation
 End of changes. 38 change blocks. 
113 lines changed or deleted 131 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/