< draft-leiba-cotton-iana-5226bis-00.txt   draft-leiba-cotton-iana-5226bis-01.txt >
Network Working Group M. Cotton Network Working Group M. Cotton
Internet-Draft Internet Assigned Numbers Internet-Draft Internet Assigned Numbers
Obsoletes: 5226 (if approved) Authority (IANA) Obsoletes: 5226 (if approved) Authority (IANA)
Intended status: BCP B. Leiba Intended status: BCP B. Leiba
Expires: February 2, 2013 Huawei Technologies Expires: April 5, 2013 Huawei Technologies
T. Narten T. Narten
IBM Corporation IBM Corporation
August 1, 2012 October 2, 2012
Guidelines for Writing an IANA Considerations Section in RFCs Guidelines for Writing an IANA Considerations Section in RFCs
draft-leiba-cotton-iana-5226bis-00 draft-leiba-cotton-iana-5226bis-01
Abstract Abstract
Many protocols make use of identifiers consisting of constants and Many protocols make use of identifiers consisting of constants and
other well-known values. Even after a protocol has been defined and other well-known values. Even after a protocol has been defined and
deployment has begun, new values may need to be assigned (such as for deployment has begun, new values may need to be assigned (such as for
a new option type in DHCP, or a new encryption or authentication a new option type in DHCP, or a new encryption or authentication
transform for IPsec). To ensure that such quantities have consistent transform for IPsec). To ensure that such quantities have consistent
values and interpretations across all implementations, their values and interpretations across all implementations, their
assignment must be administered by a central authority. For IETF assignment must be administered by a central authority. For IETF
skipping to change at page 2, line 8 skipping to change at page 2, line 8
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 February 2, 2013. This Internet-Draft will expire on April 5, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 18 skipping to change at page 3, line 18
1.1. Terminology Used In This Document . . . . . . . . . . . . 5 1.1. Terminology Used In This Document . . . . . . . . . . . . 5
2. Why Management of a Namespace May Be Necessary . . . . . . . . 6 2. Why Management of a Namespace May Be Necessary . . . . . . . . 6
3. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 7 3. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 7
3.1. The Motivation for Designated Experts . . . . . . . . . . 7 3.1. The Motivation for Designated Experts . . . . . . . . . . 7
3.2. The Role of the Designated Expert . . . . . . . . . . . . 8 3.2. The Role of the Designated Expert . . . . . . . . . . . . 8
3.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 9 3.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 9
3.4. Expert Reviews and the Document Lifecycle . . . . . . . . 10 3.4. Expert Reviews and the Document Lifecycle . . . . . . . . 10
4. Creating a Registry . . . . . . . . . . . . . . . . . . . . . 11 4. Creating a Registry . . . . . . . . . . . . . . . . . . . . . 11
4.1. Well-Known IANA Policy Definitions . . . . . . . . . . . . 11 4.1. Well-Known IANA Policy Definitions . . . . . . . . . . . . 11
4.1.1. Policy: Private Use . . . . . . . . . . . . . . . . . 12 4.1.1. Policy: Private Use . . . . . . . . . . . . . . . . . 12
4.1.2. Policy: Experimental Use . . . . . . . . . . . . . . . 12 4.1.2. Policy: Experimental Use . . . . . . . . . . . . . . . 13
4.1.3. Policy: Hierarchical Allocation . . . . . . . . . . . 13 4.1.3. Policy: Hierarchical Allocation . . . . . . . . . . . 13
4.1.4. Policy: First Come First Served . . . . . . . . . . . 13 4.1.4. Policy: First Come First Served . . . . . . . . . . . 13
4.1.5. Policy: Expert Review . . . . . . . . . . . . . . . . 13 4.1.5. Policy: Expert Review . . . . . . . . . . . . . . . . 13
4.1.6. Policy: Specification Required . . . . . . . . . . . . 14 4.1.6. Policy: Specification Required . . . . . . . . . . . . 14
4.1.7. Policy: RFC Required . . . . . . . . . . . . . . . . . 14 4.1.7. Policy: RFC Required . . . . . . . . . . . . . . . . . 14
4.1.8. Policy: IETF Review . . . . . . . . . . . . . . . . . 14 4.1.8. Policy: IETF Review . . . . . . . . . . . . . . . . . 15
4.1.9. Policy: Standards Action . . . . . . . . . . . . . . . 15 4.1.9. Policy: Standards Action . . . . . . . . . . . . . . . 15
4.1.10. Policy: IESG Approval . . . . . . . . . . . . . . . . 15 4.1.10. Policy: IESG Approval . . . . . . . . . . . . . . . . 15
4.2. Best Practice for Selecting an Appropriate Policy . . . . 16 4.2. Best Practice for Selecting an Appropriate Policy . . . . 16
4.3. What to Put in Documents That Create a Registry . . . . . 19 4.3. Using Multiple Policies in Combination . . . . . . . . . . 19
4.4. Updating IANA Guidelines for Existing Registries . . . . . 21 4.4. What to Put in Documents That Create a Registry . . . . . 19
5. Registering New Values in an Existing Registry . . . . . . . . 22 4.5. Updating IANA Guidelines for Existing Registries . . . . . 22
5.1. What to Put in Documents When Registering Values . . . . . 22 5. Registering New Values in an Existing Registry . . . . . . . . 23
5.2. Updating Registrations . . . . . . . . . . . . . . . . . . 23 5.1. What to Put in Documents When Registering Values . . . . . 23
5.3. Overriding Registration Procedures . . . . . . . . . . . . 24 5.2. Updating Registrations . . . . . . . . . . . . . . . . . . 24
6. Documentation References in IANA Registries . . . . . . . . . 25 5.3. Overriding Registration Procedures . . . . . . . . . . . . 25
7. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 25 6. Documentation References in IANA Registries . . . . . . . . . 26
8. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 26 7. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 26
8.1. When There Are No IANA Actions . . . . . . . . . . . . . . 26 8. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 27
8.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 27 8.1. When There Are No IANA Actions . . . . . . . . . . . . . . 27
8.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 27 8.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 28
8.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 28 8.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 28
8.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 28 8.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 29
8.6. BCP 78/79 Issues in Registries . . . . . . . . . . . . . . 29 8.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 29
9. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.6. Closing or Obsoleting a Registry . . . . . . . . . . . . . 30
10. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 29 8.7. BCP 78/79 Issues in Registries . . . . . . . . . . . . . . 30
11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
12. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 30 10. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. 2012: Changes in This Document Relative to RFC 5226 . . . 30 11. Security Considerations . . . . . . . . . . . . . . . . . . . 30
12.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . . 31 12. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 31
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 12.1. 2012: Changes in This Document Relative to RFC 5226 . . . 31
13.1. Acknowledgments for This Document (2012) . . . . . . . . . 31 12.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . . 32
13.2. Acknowledgments from the second edition (2008) . . . . . . 32 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
13.3. Acknowledgments from the first edition (1998) . . . . . . 32 13.1. Acknowledgments for This Document (2012) . . . . . . . . . 33
13.2. Acknowledgments from the second edition (2008) . . . . . . 33
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 13.3. Acknowledgments from the first edition (1998) . . . . . . 33
14.1. Normative References . . . . . . . . . . . . . . . . . . . 32 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.2. Informative References . . . . . . . . . . . . . . . . . . 32 14.1. Normative References . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 14.2. Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
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 (such as the Protocol field in the IP header well-known values (such as the Protocol field in the IP header
[RFC0791] and MIME media types [RFC4288]). Even after a protocol has [RFC0791] and MIME media types [RFC4288]). Even after a protocol has
been defined and deployment has begun, new values may need to be been defined and deployment has begun, new values may need to be
assigned (such as a new option type in DHCP [RFC2132] or a new assigned (such as a new option type in DHCP [RFC2132] or a new
encryption or authentication transform for IPsec [RFC4301]). To encryption or authentication transform for IPsec [RFC4301]). To
ensure that such fields have consistent values and interpretations in ensure that such fields have consistent values and interpretations in
skipping to change at page 6, line 39 skipping to change at page 6, line 39
A second consideration is whether it makes sense to delegate the A second consideration is whether it makes sense to delegate 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.
A third, and perhaps most important, consideration concerns potential A third, and perhaps most important, consideration concerns potential
impact on the interoperability of unreviewed extensions. Proposed impact on the interoperability of unreviewed extensions. Proposed
protocol extensions generally benefit from community review; indeed, protocol extensions generally benefit from community review; indeed,
review is often essential to avoid future interoperability problems review is often essential to avoid future interoperability problems
[I-D.iab-extension-recs]. [RFC6709].
When the namespace is essentially unlimited and there are no When the namespace is essentially unlimited and there are no
potential interoperability issues, assigned numbers can safely be potential interoperability issues, assigned numbers can safely be
given out to anyone without any subjective review. In such cases, given out to anyone without any subjective review. In such cases,
IANA can make assignments directly, provided that IANA is given IANA can make assignments directly, provided that IANA is given
specific instructions on what types of requests it should grant, and specific instructions on what types of requests it should grant, and
what information must be provided as part of a well-formed request what information must be provided as part of a well-formed request
for an assigned number. for an assigned number.
3. Designated Experts 3. Designated Experts
skipping to change at page 8, line 17 skipping to change at page 8, line 17
who is responsible for carrying out an appropriate evaluation and who is responsible for carrying out an appropriate evaluation and
returning a recommendation to IANA. returning a recommendation to IANA.
It should be noted that a key motivation for having designated It should be noted that a key motivation for having designated
experts is for the IETF to provide IANA with a subject matter expert experts is for the IETF to provide IANA with a subject matter expert
to whom the evaluation process can be delegated. IANA forwards to whom the evaluation process can be delegated. IANA forwards
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
time, as a supplement to other processes. For more discussion of
that topic, see Section 4.3.
3.2. The Role of the Designated Expert 3.2. The Role of the Designated Expert
The designated expert is responsible for initiating and coordinating The designated expert is responsible for initiating and coordinating
the appropriate review of an assignment request. The review may be the appropriate review of an assignment request. The review may be
wide or narrow, depending on the situation and the judgment of the wide or narrow, depending on the situation and the judgment of the
designated expert. This may involve consultation with a set of designated expert. This may involve consultation with a set of
technology experts, discussion on a public mailing list, consultation technology experts, discussion on a public mailing list, consultation
with a working group (or its mailing list if the working group has with a working group (or its mailing list if the working group has
disbanded), etc. Ideally, the designated expert follows specific disbanded), etc. Ideally, the designated expert follows specific
review criteria as documented with the protocol that creates or uses review criteria as documented with the protocol that creates or uses
skipping to change at page 12, line 25 skipping to change at page 12, line 25
It should be noted that it often makes sense to partition a namespace It should be noted that it often makes sense to partition a namespace
into multiple categories, with assignments within each category into multiple categories, with assignments within each category
handled differently. Many protocols now partition namespaces into handled differently. Many protocols now partition namespaces into
two or more parts, with one range reserved for Private or two or more parts, with one range reserved for Private or
Experimental Use while other ranges are reserved for globally unique Experimental Use while other ranges are reserved for globally unique
assignments assigned following some review process. Dividing a assignments assigned following some review process. Dividing a
namespace into ranges makes it possible to have different policies in namespace into ranges makes it possible to have different policies in
place for different ranges and different use cases. place for different ranges and different use cases.
Similarly, it will often be useful to specify multiple policies in
parallel, with each policy being used under different circumstances.
For more discussion of that topic, see Section 4.3.
Examples: Examples:
LDAP [RFC4520] LDAP [RFC4520]
TLS ClientCertificateType Identifiers [RFC5246] (as detailed in TLS ClientCertificateType Identifiers [RFC5246] (as detailed in
the subsections below) the subsections below)
Pseudowire Edge to Edge Emulation (PWE3) [RFC4446] Pseudowire Edge to Edge Emulation (PWE3) [RFC4446]
4.1.1. Policy: Private Use 4.1.1. Policy: Private Use
For private or local use only, with the type and purpose defined by For private or local use only, with the type and purpose defined by
the local site. No attempt is made to prevent multiple sites from the local site. No attempt is made to prevent multiple sites from
skipping to change at page 13, line 39 skipping to change at page 13, line 45
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.1.5. Policy: Expert Review 4.1.5. Policy: Expert Review
(Sometimes also called "Designated Expert" in earlier editions of (Sometimes also called "Designated Expert" in earlier editions of
this document.) Approval by a designated expert is required. The this document.) Review and approval by a designated expert is
required documentation and review criteria for use by the designated required. The required documentation and review criteria for use by
expert should be provided when defining the registry. For example, the designated expert should be provided when defining the registry.
see Sections 6 and 7.2 in [RFC3748]. 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.1.6. Policy: Specification Required 4.1.6. Policy: Specification Required
Values and their meanings must be documented in a permanent and Review and approval by a Designated Expert is required, (as in
readily available public specification, in sufficient detail so that Section 4.1.5) and the values and their meanings must be documented
interoperability between independent implementations is possible. in a permanent and readily available public specification, in
When used, Specification Required also implies use of a Designated sufficient detail so that interoperability between independent
Expert (see Section 4.1.5), who will review the public specification implementations is possible. The Designated Expert will review the
and evaluate whether it is sufficiently clear to allow interoperable public specification and evaluate whether it is sufficiently clear to
implementations. The intention behind "permanent and readily allow interoperable implementations. The intention behind "permanent
available" is that a document can reasonably be expected to be and readily available" is that a document can reasonably be expected
findable and retrievable long after IANA assignment of the requested to be findable and retrievable long after IANA assignment of the
value. Publication of an RFC is an ideal means of achieving this requested value. Publication of an RFC is an ideal means of
requirement, but Specification Required is intended to also cover the achieving this requirement, but Specification Required is intended to
case of a document published outside of the RFC path. For RFC also cover the case of a document published outside of the RFC path.
publication, the normal RFC review process is expected to provide the For RFC publication, the normal RFC review process is expected to
necessary review for interoperability, though the designated expert provide the necessary review for interoperability, though the
may be a particularly well-qualified person to perform such a review. designated expert 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]
skipping to change at page 17, line 52 skipping to change at page 18, line 10
o Registries for which thorough community review is necessary to o Registries for which thorough community review is necessary to
avoid extending or modifying the protocol in ways that could be avoid extending or modifying the protocol in ways that could be
damaging. One example is in defining new command codes, as damaging. One example is in defining new command codes, as
opposed to options that use existing command codes: the former opposed to options that use existing command codes: the former
might require a strict policy, where a more relaxed policy could might require a strict policy, where a more relaxed policy could
be adequate for the latter. Another example is in defining things be adequate for the latter. Another example is in defining things
that change the semantics of existing operations. that change the semantics of existing operations.
There will be other cases, as well, of course; much assessment and There will be other cases, as well, of course; much assessment and
judgment is needed. It's not the intent here to put limits on the judgment is needed. And it will sometimes be the case that using
applicability of particular registration policies, but to recommend multiple policies in combination is appropriate (see Section 4.3).
laxity, rather than strictness, in general, and to encourage document It's not the intent here to put limits on the applicability of
developers to think carefully about each registry before deciding on particular registration policies, but to recommend laxity, rather
policies. than strictness, in general, and to encourage document developers to
think carefully about each registry before deciding on policies.
The description in Section 4.1.10 of "IESG Approval" suggests that The description in Section 4.1.10 of "IESG Approval" suggests that
the IESG "can (and should) reject a request if another path for the IESG "can (and should) reject a request if another path for
registration is available that is more appropriate and there is no registration is available that is more appropriate and there is no
compelling reason not to use that path." The IESG should give compelling reason not to use that path." The IESG should give
similar consideration to any registration policy more stringent than similar consideration to any registration policy more stringent than
Specification Required, asking for justification and ensuring that Specification Required, asking for justification and ensuring that
more relaxed policies have been considered, and the strict policy is more relaxed policies have been considered, and the strict policy is
the right one. This is a situation that will -- and should -- the right one. This is a situation that will -- and should --
involve a substantive discussion between the IESG and the working involve a substantive discussion between the IESG and the working
skipping to change at page 19, line 5 skipping to change at page 19, line 9
thought, consideration, assessment, and judgment in choosing the thought, consideration, assessment, and judgment in choosing the
right policy for each registry. right policy for each registry.
The recommendations in this section apply whether the well-defined The recommendations in this section apply whether the well-defined
policy names defined herein are used, or whether the document policy names defined herein are used, or whether the document
contains other policy definitions. The point, again, is not to limit contains other policy definitions. The point, again, is not to limit
registration policies, but to ensure that the policies selected are registration policies, but to ensure that the policies selected are
appropriate, and that proper consideration has been given to the appropriate, and that proper consideration has been given to the
level of strictness required by them. level of strictness required by them.
4.3. What to Put in Documents That Create a Registry 4.3. Using Multiple Policies in Combination
It is often desirable to allow registrations through the normal IETF
process, and to also provide a mechanism for registration outside the
process. Thus, a particular registry might want to use a policy such
as "RFC Required" or "IETF Review" sometimes, with a designated
expert checking a "Specification Required" policy at other times.
Such combinations are frequently appropriate, and are encouraged.
The alternative to using a combination requires either that all
requests come through RFCs or that requests in RFCs go through review
by the designated expert, despite the review and consensus that RFCs
represent.
For example, if it is felt that IETF consensus will provide good
review for a particular registry, but we expect frequent
registrations from other SDOs and we do not want those other
organizations always to be required to go through the IETF RFC
process, we might put the following in the IANA Considerations
section when we create the registry:
IANA is asked to create the registry "Fruit Access Flags" as a
sub-registry of "Fruit Parameters". New registrations will be
permitted through either the IETF Review policy or the
Specification Required policy [BCP26].
Such combinations will commonly use one of {Standards Action, IETF
Review, RFC Required} in combination with one of {Specification
Required, Expert Review}.
4.4. What to Put in Documents That Create a Registry
The previous sections presented some issues that should be considered The previous sections presented some issues that should be considered
in formulating a policy for assigning values in namespaces. It is in formulating a policy for assigning values in namespaces. It is
the working group and/or document author's job to formulate an the working group and/or document author's job to formulate an
appropriate policy and specify it in the appropriate document. In appropriate policy and specify it in the appropriate document. In
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 namespace (or modify the definition of an Documents that create a new namespace (or modify the definition of an
skipping to change at page 21, line 37 skipping to change at page 22, line 37
1 Frobnitz See Section y.1 1 Frobnitz See Section y.1
2 NitzFrob See Section y.2 2 NitzFrob See Section y.2
3-254 Unassigned 3-254 Unassigned
255 Reserved 255 Reserved
--------------------------------------------------------------- ---------------------------------------------------------------
For examples of documents that provide detailed guidance to IANA on For examples of documents that provide detailed guidance to IANA on
the issue of assigning numbers, consult [RFC6195], [RFC3575], the issue of assigning numbers, consult [RFC6195], [RFC3575],
[RFC3968], and [RFC4520]. [RFC3968], and [RFC4520].
4.4. Updating IANA Guidelines for Existing Registries 4.5. Updating IANA Guidelines for 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 managing (then)
skipping to change at page 29, line 14 skipping to change at page 30, line 14
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.
8.6. BCP 78/79 Issues in Registries 8.6. Closing or Obsoleting a Registry
[[anchor2: This section needs to be resolved before publication.]] [[anchor2: This section needs to be resolved before publication.]]
8.7. BCP 78/79 Issues in Registries
[[anchor3: This section needs to be resolved before publication.]]
9. Appeals 9. Appeals
Appeals of registration decisions made by IANA can be made using the Appeals of registration decisions made by IANA can be made using the
normal IETF appeals process as described in Section 6.5 of [RFC2026]. normal IETF appeals process as described in Section 6.5 of [RFC2026].
Specifically, appeals should be directed to the IESG, followed (if Specifically, appeals should be directed to the IESG, followed (if
necessary) by an appeal to the IAB, etc. necessary) by an appeal to the IAB, etc.
10. Mailing Lists 10. Mailing Lists
All IETF mailing lists associated with evaluating or discussing All IETF mailing lists associated with evaluating or discussing
skipping to change at page 30, line 26 skipping to change at page 31, line 30
Significant additions: Significant additions:
o Added Section 3.4, Expert Reviews and the Document Lifecycle o Added Section 3.4, Expert Reviews and the Document Lifecycle
o Moved well-known policies into a separate section for each, o Moved well-known policies into a separate section for each,
subsections of Section 4.1. subsections of Section 4.1.
o Added Section 4.2, Best Practice for Selecting an Appropriate o Added Section 4.2, Best Practice for Selecting an Appropriate
Policy. Policy.
o Added Section 4.3, Using Multiple Policies in Combination.
o Added Section 6, Documentation References in IANA Registries o Added Section 6, Documentation References in IANA Registries
o Added Section 7, What to Do in "bis" Documents o Added Section 7, What to Do in "bis" Documents
o Added Section 8.5, Contact Person vs Assignee or Owner o Added Section 8.5, Contact Person vs Assignee or Owner
o Added Section 8.6, BCP 78/79 Issues in Registries o Added Section 8.6, Closing or Obsoleting a Registry
o Added Section 8.7, BCP 78/79 Issues in Registries
Clarifications and such: Clarifications and such:
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".
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.
skipping to change at page 32, line 37 skipping to change at page 33, line 44
14. References 14. References
14.1. Normative References 14.1. Normative References
[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.
14.2. Informative References 14.2. Informative References
[I-D.iab-extension-recs]
Carpenter, B., Aboba, B., and S. Cheshire, "Design
Considerations for Protocol Extensions",
draft-iab-extension-recs-10 (work in progress),
February 2012.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[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.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
skipping to change at page 35, line 26 skipping to change at page 36, line 26
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
Header Compression (ROHC) Framework", RFC 5795, Header Compression (ROHC) Framework", RFC 5795,
March 2010. March 2010.
[RFC6195] Eastlake, D., "Domain Name System (DNS) IANA [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6195, March 2011. Considerations", BCP 42, RFC 6195, March 2011.
[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
Considerations for Protocol Extensions", RFC 6709,
September 2012.
Authors' Addresses Authors' Addresses
Michelle Cotton Michelle Cotton
Internet Assigned Numbers Authority (IANA) Internet Assigned Numbers Authority (IANA)
4676 Admiralty Way, Suite 330 4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292 Marina del Rey, CA 90292
USA USA
Phone: +1 310 301 5812 Phone: +1 310 301 5812
Email: michelle.cotton@icann.org Email: michelle.cotton@icann.org
 End of changes. 21 change blocks. 
71 lines changed or deleted 118 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/