< draft-leiba-cotton-iana-5226bis-08.txt   draft-leiba-cotton-iana-5226bis-09.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: April 02, 2015 IBM Corporation Expires: May 11, 2015 IBM Corporation
October 01, 2014 November 09, 2014
Guidelines for Writing an IANA Considerations Section in RFCs Guidelines for Writing an IANA Considerations Section in RFCs
draft-leiba-cotton-iana-5226bis-08 draft-leiba-cotton-iana-5226bis-09
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).
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 April 02, 2015. This Internet-Draft will expire on May 11, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 32 skipping to change at page 2, line 32
2.2. Documentation Requirements for Registries . . . . . . . . 6 2.2. Documentation Requirements for Registries . . . . . . . . 6
2.3. Defining an Appropriate Registry Policy . . . . . . . . . 8 2.3. Defining an Appropriate Registry Policy . . . . . . . . . 8
2.3.1. Using the Well-Known Registration Policies . . . . . . 10 2.3.1. Using the Well-Known Registration Policies . . . . . . 10
2.3.2. Using Multiple Policies in Combination . . . . . . . . 11 2.3.2. Using Multiple Policies in Combination . . . . . . . . 11
2.3.3. Specifying Change Control for a Registry . . . . . . . 12 2.3.3. Specifying Change Control for a Registry . . . . . . . 12
2.4. Revising Existing Registries . . . . . . . . . . . . . . . 12 2.4. Revising Existing Registries . . . . . . . . . . . . . . . 12
3. Registering New Values in an Existing Registry . . . . . . . . 13 3. Registering New Values in an Existing Registry . . . . . . . . 13
3.1. Documentation Requirements for Registrations . . . . . . . 13 3.1. Documentation Requirements for Registrations . . . . . . . 13
3.2. Updating Existing Registrations . . . . . . . . . . . . . 14 3.2. Updating Existing Registrations . . . . . . . . . . . . . 14
3.3. Overriding Registration Procedures . . . . . . . . . . . . 15 3.3. Overriding Registration Procedures . . . . . . . . . . . . 15
3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 15 3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 16
4. Well-Known Registration Policies . . . . . . . . . . . . . . . 16 4. Well-Known Registration Policies . . . . . . . . . . . . . . . 16
4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . . 17 4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . . 17
4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 17 4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 17
4.4. First Come First Served . . . . . . . . . . . . . . . . . 17 4.4. First Come First Served . . . . . . . . . . . . . . . . . 18
4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 18 4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 18
4.6. Specification Required . . . . . . . . . . . . . . . . . . 19 4.6. Specification Required . . . . . . . . . . . . . . . . . . 19
4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . . 19 4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . . 20
4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 19 4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 20
4.9. Standards Action . . . . . . . . . . . . . . . . . . . . . 20 4.9. Standards Action . . . . . . . . . . . . . . . . . . . . . 20
4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 20 4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 21
5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 21 5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 21
5.1. The Motivation for Designated Experts . . . . . . . . . . 21 5.1. The Motivation for Designated Experts . . . . . . . . . . 21
5.2. The Role of the Designated Expert . . . . . . . . . . . . 22 5.2. The Role of the Designated Expert . . . . . . . . . . . . 22
5.2.1. Managing Designated Experts in the IETF . . . . . . . 23 5.2.1. Managing Designated Experts in the IETF . . . . . . . 23
5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 23 5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 24
5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 25 5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 25
6. Well-Known Registration Status Terminology . . . . . . . . . . 25 6. Well-Known Registration Status Terminology . . . . . . . . . . 26
7. Documentation References in IANA Registries . . . . . . . . . 26 7. Documentation References in IANA Registries . . . . . . . . . 26
8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 26 8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 27
9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 27 9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 28
9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 27 9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 28
9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 28 9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 29
9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 28 9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 29
9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 29 9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 29
9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 29 9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 30
9.6. Closing or Obsoleting a Registry . . . . . . . . . . . . . 30 9.6. Closing or Obsoleting a Registry . . . . . . . . . . . . . 30
10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 30 11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 31
12. Security Considerations . . . . . . . . . . . . . . . . . . . 30 12. Security Considerations . . . . . . . . . . . . . . . . . . . 31
13. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 31 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
13.1. 2014: Changes in This Document Relative to RFC 5226 . . . 31 14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 31
13.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 32 14.1. 2014: Changes in This Document Relative to RFC 5226 . . . 32
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 32
14.1. Acknowledgments for This Document (2014) . . . . . . . . 33 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
14.2. Acknowledgments from the second edition (2008) . . . . . 33 15.1. Acknowledgments for This Document (2014) . . . . . . . . 33
14.3. Acknowledgments from the first edition (1998) . . . . . . 33 15.2. Acknowledgments from the second edition (2008) . . . . . 34
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 15.3. Acknowledgments from the first edition (1998) . . . . . . 34
15.1. Normative References . . . . . . . . . . . . . . . . . . 34 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
15.2. Informative References . . . . . . . . . . . . . . . . . 34 16.1. Normative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 16.2. Informative References . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
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]. IANA services are Assigned Numbers Authority (IANA) [RFC2860]. IANA services are
currently provided by the International Corporation for Assigned currently provided by the Internet Corporation for Assigned Names and
Names and Numbers (ICANN). 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 is protocol constant, or protocol parameter). The act of assignment is
called a registration, and it takes place in the context of a called a registration, and it takes place in the context of a
skipping to change at page 4, line 34 skipping to change at page 4, line 37
each requested IANA action; includes all information IANA needs, such each requested IANA action; includes all information IANA needs, such
as the full names of all applicable registries; and includes clear as the full names of all applicable registries; and includes clear
references to elsewhere in the document for other information. references to elsewhere in the document for other information.
1.2. For More Information 1.2. For More Information
IANA maintains a web page that includes current important information IANA maintains a web page that includes current important information
from IANA. Document authors should check that page for additional from IANA. Document authors should check that page for additional
information, beyond what is provided here. information, beyond what is provided here.
<http://www.iana.org/important-information>. <http://iana.org/help/protocol-registration>.
[[***** The URI above is not yet ready. IANA is setting it up.
*****]]
1.3. Terminology Used In This Document 1.3. 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.
skipping to change at page 9, line 45 skipping to change at page 9, line 44
While it is sometimes necessary to restrict what gets registered While it is sometimes necessary to restrict what gets registered
(e.g., for limited resources such as bits in a byte, or for items for (e.g., for limited resources such as bits in a byte, or for items for
which unsupported values can be damaging to protocol operation), in which unsupported values can be damaging to protocol operation), in
many cases having what's in use represented in the registry is more many cases having what's in use represented in the registry is more
important. Overly strict review criteria and excessive cost (in time important. Overly strict review criteria and excessive cost (in time
and effort) discourage people from even attempting to make a and effort) discourage people from even attempting to make a
registration. If a registry fails to reflect the protocol elements registration. If a registry fails to reflect the protocol elements
actually in use, it can adversely affect deployment of protocols on actually in use, it can adversely affect deployment of protocols on
the Internet, and the registry itself is devalued. the Internet, and the registry itself is devalued.
In particular, when a registry policy that requires involvement of In particular, working groups will sometimes write in policies such
Working Groups, directorates, or other bodies to be actively involved as Standards Action when they develop documents. Later, someone will
and to support the effort, requests frequently run into concerns that come to the working group (or to the relevant community, if the
"it's not worth doing a Standards-Track RFC for something this working group has since closed) with a simple request to register a
trivial," when, in fact, that requirement was created by the Working new item, and will be met with a feeling that it's not worth doing a
Group in the first place, by placing the bar that high. Standards-Track RFC for something so trivial. In such cases, it was
a mistake for the working group to have set the bar that high.
Indeed, publishing any RFC is costly, and a Standards Track RFC is Indeed, publishing any RFC is costly, and a Standards Track RFC is
especially so, requiring a great deal of community time for review especially so, requiring a great deal of community time for review
and discussion, IETF-wide last call, involvement of the entire IESG and discussion, IETF-wide last call, involvement of the entire IESG
as well as concentrated time and review from the sponsoring AD, as well as concentrated time and review from the sponsoring AD,
review and action by IANA, and RFC-Editor processing. review and action by IANA, and RFC-Editor processing.
Therefore, Working Groups and other document developers should use Therefore, working groups and other document developers should use
care in selecting appropriate registration policies when their care in selecting appropriate registration policies when their
documents create registries. They should select the least strict documents create registries. They should select the least strict
policy that suits a registry's needs, and look for specific policy that suits a registry's needs, and look for specific
justification for policies that require significant community justification for policies that require significant community
involvement (Specification Required, in terms of the well-known involvement (those stricter than Specification Required, in terms of
policies). the well-known policies).
2.3.1. Using the Well-Known Registration Policies 2.3.1. Using the Well-Known Registration Policies
This document defines a number of registration policies in Section 4. This document defines a number of registration policies in Section 4.
Because they benefit from both community experience and wide Because they benefit from both community experience and wide
understanding, their use is encouraged when appropriate. understanding, their use is encouraged when appropriate.
It is also acceptable to cite one of the well-known policies and It is also acceptable to cite one of the well-known policies and
include additional guidelines for what kind of considerations should include additional guidelines for what kind of considerations should
be taken into account by the review process. be taken into account by the review process.
skipping to change at page 10, line 36 skipping to change at page 10, line 35
Expert should follow. Expert should follow.
The well-known policies from "First Come First Served" to "Standards The well-known policies from "First Come First Served" to "Standards
Action" specify a range of policies in increasing order of strictness Action" specify a range of policies in increasing order of strictness
(using the numbering from the full list in Section 4): (using the numbering from the full list in Section 4):
4. First Come First Served 4. First Come First Served
No review, minimal documentation. No review, minimal documentation.
5. Expert Review 5. Expert Review
Expert review, sufficient documentation for review. Expert review with sufficient documentation for review.
6. Specification Required 6. Specification Required
Expert review, significant, stable public documentation. Expert review with significant, stable public documentation.
7. RFC Required 7. RFC Required
Any RFC publication, IETF or a non-IETF Stream. Any RFC publication, IETF or a non-IETF Stream.
8. IETF Review 8. IETF Review
RFC publication, IETF Stream only, but need not be Standards RFC publication, IETF Stream only, but need not be Standards
Track. Track.
9. Standards Action 9. Standards Action
RFC publication, IETF Stream, Standards Track only. RFC publication, IETF Stream, Standards Track only.
skipping to change at page 12, line 11 skipping to change at page 12, line 4
requests come through RFCs or that requests in RFCs go through review requests come through RFCs or that requests in RFCs go through review
by the designated expert, even though they already have IETF review by the designated expert, even though they already have IETF review
and consensus. and consensus.
This can be documented in the IANA Considerations section when the This can be documented in the IANA Considerations section when the
registry is created: registry is created:
IANA is asked to create the registry "Fruit Access Flags" as a IANA is asked to create the registry "Fruit Access Flags" as a
sub-registry of "Fruit Parameters". New registrations will be sub-registry of "Fruit Parameters". New registrations will be
permitted through either the IETF Review policy or the permitted through either the IETF Review policy or the
Specification Required policy [BCP26]. Specification Required policy [BCP26]. The latter should be used
for registrations requested by SDOs outside the IETF.
Such combinations will commonly use one of {Standards Action, IETF Such combinations will commonly use one of {Standards Action, IETF
Review, RFC Required} in combination with one of {Specification Review, RFC Required} in combination with one of {Specification
Required, Expert Review}. Required, Expert Review}. Guidance should be provided about when
each policy is appropriate, as in the example above.
2.3.3. Specifying Change Control for a Registry 2.3.3. Specifying Change Control for a Registry
Registry definitions and registrations within registries often need Registry definitions and registrations within registries often need
to be changed after they are created. The process of making such to be changed after they are created. The process of making such
changes is complicated when it is unclear who is authorized to make changes is complicated when it is unclear who is authorized to make
the changes. For registries created by RFCs in the IETF stream, the changes. For registries created by RFCs in the IETF stream,
change control for the registry lies by default with the IETF, via change control for the registry lies by default with the IETF, via
the IESG. The same is true for value registrations made in IETF- the IESG. The same is true for value registrations made in IETF-
stream RFCs. stream RFCs.
skipping to change at page 15, line 51 skipping to change at page 16, line 7
In order to allow assignments in such cases, the IESG is granted In order to allow assignments in such cases, the IESG is granted
authority to override registration procedures and approve assignments authority to override registration procedures and approve assignments
on a case-by-case basis. on a case-by-case basis.
The intention here is not to overrule properly documented procedures, The intention here is not to overrule properly documented procedures,
or to obviate the need for protocols to properly document their IANA or to obviate the need for protocols to properly document their IANA
considerations. Rather, it is to permit assignments in specific considerations. Rather, it is to permit assignments in specific
cases where it is obvious that the assignment should just be made, cases where it is obvious that the assignment should just be made,
but updating the IANA process beforehand is too onerous. but updating the IANA process beforehand is too onerous.
When the IESG is required to take action as described in this When the IESG is required to take action as described above, it is a
section, it is a strong indicator that the applicable registration strong indicator that the applicable registration procedures should
procedures should be updated, possibly in parallel with the work that be updated, possibly in parallel with the work that instigated it.
instigated it.
IANA always has the discretion to ask the IESG for advice or
intervention when they feel it is needed, such as in cases where
policies or procedures are unclear to them, where they encounter
issues or questions they are unable to resolve, or where registration
requests or patterns of requests appear to be unusual or abusive.
3.4. Early Allocations 3.4. Early Allocations
IANA normally takes its actions when a document is approved for IANA normally takes its actions when a document is approved for
publication. There are times, though, when early allocation of a publication. There are times, though, when early allocation of a
value is important for the development of a technology: for example, value is important for the development of a technology: for example,
when early implementations are created while the document is still when early implementations are created while the document is still
under development. under development.
IANA has a mechanism for handling such early allocations in some IANA has a mechanism for handling such early allocations in some
cases. See [RFC7120] for details. cases. See [RFC7120] for details.
4. Well-Known Registration Policies 4. Well-Known Registration Policies
skipping to change at page 18, line 4 skipping to change at page 18, line 13
part of the namespace. IANA makes allocations in the higher levels part of the namespace. IANA makes allocations in the higher levels
of the namespace according to one of the other policies. 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
For the First Come First Served policy, assignments are made to For the First Come First Served policy, assignments are made to
anyone on a first come, first served basis. There is no substantive anyone on a first come, first served basis. There is no substantive
review of the request, other than to ensure that it is well-formed review of the request, other than to ensure that it is well-formed
and doesn't duplicate an existing assignment. However, requests must and doesn't duplicate an existing assignment. However, requests must
include a minimal amount of clerical information, such as a point of include a minimal amount of clerical information, such as a point of
contact (including an email address, and sometimes a postal address) 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.
When creating a new registry with First Come First Served as the When creating a new registry with First Come First Served as the
registration policy, in addition to the contact person field or registration policy, in addition to the contact person field or
reference, the registry should contain a field for change controller. reference, the registry should contain a field for change controller.
Having a change controller for each entry for these types of Having a change controller for each entry for these types of
registrations makes authorization of future modifications more clear. registrations makes authorization of future modifications more clear.
See Section 2.3.3 See Section 2.3.3. It is important that changes to the registration
of a First Come First Served code point retain compatibility with the
current usage of that code point, and so changes need to be made with
care.
It is also important to understand that First Come First Served
really has no filtering. Essentially, any request is accepted. A
working group or any other entity that is developing protocol based
on a First Come First Served code point has to be extremely careful
that the protocol retains wire compatibility with current use of the
code point. Once that is no longer true, the new work needs to
change to a different code point (and register that use at the
appropriate time).
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
(Also called "Designated Expert" in earlier editions of this (Also called "Designated Expert" in earlier editions of this
document.) For the Expert Review policy, review and approval by a document.) For the Expert Review policy, review and approval by a
skipping to change at page 23, line 16 skipping to change at page 23, line 43
registries. Sometimes those experts work together in evaluating a registries. Sometimes those experts work together in evaluating a
request, while in other cases additional experts serve as backups. request, while in other cases additional experts serve as backups.
In cases of disagreement among those experts, it is the In cases of disagreement among those experts, it is the
responsibility of those experts to make a single clear recommendation responsibility of those experts to make a single clear recommendation
to IANA. It is not appropriate for IANA to resolve disputes among to IANA. It is not appropriate for IANA to resolve disputes among
experts. In extreme situations, such as deadlock, the designating experts. In extreme situations, such as deadlock, the designating
body may need to step in to resolve the problem. body may need to step in to resolve the problem.
This document defines the designated expert mechanism with respect to This document defines the designated expert mechanism with respect to
documents in the IETF stream only. Documents in other streams may documents in the IETF stream only. Documents in other streams may
only use a registration policy that requires a designated expert if use a registration policy that requires a designated expert only if
those streams (or those documents) specify how designated experts are those streams (or those documents) specify how designated experts are
appointed and managed. What is described below, with management by appointed and managed. What is described below, with management by
the IESG, is only appropriate for the IETF stream. the IESG, is only appropriate for the IETF stream.
5.2.1. Managing Designated Experts in the IETF 5.2.1. Managing Designated Experts in the IETF
Designated experts for registries created by the IETF are appointed Designated experts for registries created by the IETF are appointed
by the IESG, normally upon recommendation by the relevant Area by the IESG, normally upon recommendation by the relevant Area
Director. They may be appointed at the time a document creating or Director. They may be appointed at the time a document creating or
updating a namespace is approved by the IESG, or subsequently, when updating a namespace is approved by the IESG, or subsequently, when
skipping to change at page 31, line 27 skipping to change at page 31, line 50
An analysis of security issues is generally required for all An analysis of security issues is generally required for all
protocols that make use of parameters (data types, operation codes, protocols that make use of parameters (data types, operation codes,
keywords, etc.) used in IETF protocols or registered by IANA. Such keywords, etc.) used in IETF protocols or registered by IANA. Such
security considerations are usually included in the protocol document security considerations are usually included in the protocol document
[RFC3552]. It is the responsibility of the IANA considerations [RFC3552]. It is the responsibility of the IANA considerations
associated with a particular registry to specify what (if any) associated with a particular registry to specify what (if any)
security considerations must be provided when assigning new values, security considerations must be provided when assigning new values,
and the process for reviewing such claims. and the process for reviewing such claims.
13. Changes Relative to Earlier Editions of BCP 26 13. IANA Considerations
13.1. 2014: Changes in This Document Relative to RFC 5226 In accordance with Section 9.1:
This document has no IANA actions.
14. Changes Relative to Earlier Editions of BCP 26
14.1. 2014: Changes in This Document Relative to RFC 5226
Significant additions: Significant additions:
o Added Section 1.1, Keep IANA Considerations for IANA o Added Section 1.1, Keep IANA Considerations for IANA
o Added Section 1.2, For More Information o Added Section 1.2, For More Information
o Added Section 2.1, Hierarchical Registry Structure o Added Section 2.1, Hierarchical Registry Structure
o Added Section 2.3, Best Practice for Selecting an Appropriate o Added Section 2.3, Best Practice for Selecting an Appropriate
skipping to change at page 32, line 26 skipping to change at page 32, line 54
o Clarified the distinction between "Unassigned" and "Reserved". o Clarified the distinction between "Unassigned" and "Reserved".
o Made some clarifications in "Expert Review" about instructions to o Made some clarifications in "Expert Review" about instructions to
the designated expert. the designated expert.
o Made some clarifications in "Specification Required" about how to o Made some clarifications in "Specification Required" about how to
declare this policy. declare this policy.
o Assorted minor clarifications and editorial changes throughout. o Assorted minor clarifications and editorial changes throughout.
13.2. 2008: Changes in RFC 5226 Relative to RFC 2434 14.2. 2008: Changes in RFC 5226 Relative to RFC 2434
Changes include: Changes include:
o Major reordering of text to expand descriptions and to better o Major reordering of text to expand descriptions and to better
group topics such as "updating registries" vs. "creating new group topics such as "updating registries" vs. "creating new
registries", in order to make it easier for authors to find the registries", in order to make it easier for authors to find the
text most applicable to their needs. text most applicable to their needs.
o Numerous editorial changes to improve readability. o Numerous editorial changes to improve readability.
skipping to change at page 33, line 16 skipping to change at page 33, line 42
RFC 2026 appeals path is used. RFC 2026 appeals path is used.
o Added a section about reclaiming unused values. o Added a section about reclaiming unused values.
o Added a section on after-the-fact registrations. o Added a section on after-the-fact registrations.
o Added a section indicating that mailing lists used to evaluate o Added a section indicating that mailing lists used to evaluate
possible assignments (such as by a Designated Expert) are subject possible assignments (such as by a Designated Expert) are subject
to normal IETF rules. to normal IETF rules.
14. Acknowledgments 15. Acknowledgments
14.1. Acknowledgments for This Document (2014) 15.1. Acknowledgments for This Document (2014)
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.
Thank you to Amanda Baber and Pearl Liang for their multiple reviews Thank you to Amanda Baber and Pearl Liang for their multiple reviews
and suggestions for making this document as thorough as possible. and suggestions for making this document as thorough as possible.
This document has benefited from thorough review and comments by Tony This document has benefited from thorough review and comments by Tony
Hansen, John Klensin, and Mark Nottingham. Hansen, John Klensin, and Mark Nottingham.
Special thanks to Mark Nottingham for reorganizing some of the text Special thanks to Mark Nottingham for reorganizing some of the text
for better organization and readability, and to Tony Hansen for for better organization and readability, and to Tony Hansen for
acting as document shepherd. acting as document shepherd.
14.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.
14.3. Acknowledgments from the first edition (1998) 15.3. Acknowledgments from the first edition (1998)
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 [RFC4288]. borrowed from [RFC4288].
15. References 16. References
15.1. Normative References
16.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
15.2. Informative References 16.2. Informative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981. 1981.
[RFC2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of [RFC2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, June 2000. Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition
of New DHCP Options and Message Types", BCP 43, RFC 2939, of New DHCP Options and Message Types", BCP 43, RFC 2939,
 End of changes. 35 change blocks. 
66 lines changed or deleted 92 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/