< draft-narten-iana-considerations-rfc2434bis-06.txt   draft-narten-iana-considerations-rfc2434bis-07.txt >
INTERNET-DRAFT Thomas Narten INTERNET-DRAFT Thomas Narten
IBM IBM
<draft-narten-iana-considerations-rfc2434bis-06.txt> Harald Alvestrand <draft-narten-iana-considerations-rfc2434bis-07.txt> Harald Alvestrand
Google Obsoletes: 2434 Google
March 6, 2007 July 9, 2007
Guidelines for Writing an IANA Considerations Section in RFCs Guidelines for Writing an IANA Considerations Section in RFCs
<draft-narten-iana-considerations-rfc2434bis-06.txt> <draft-narten-iana-considerations-rfc2434bis-07.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 3, line 5 skipping to change at page 2, line 15
In order for IANA to manage a given name space prudently, it needs In order for IANA to manage a given name space prudently, it needs
guidelines describing the conditions under which new values can be guidelines describing the conditions under which new values can be
assigned, or when modifications to existing values can be made. If assigned, or when modifications to existing values can be made. If
IANA is expected to play a role in the management of a name space, IANA is expected to play a role in the management of a name space,
the IANA must be given clear and concise instructions describing that the IANA must be given clear and concise instructions describing that
role. This document discusses issues that should be considered in role. This document discusses issues that should be considered in
formulating a policy for assigning values to a name space and formulating a policy for assigning values to a name space and
provides guidelines to document authors on the specific text that provides guidelines to document authors on the specific text that
must be included in documents that place demands on IANA. must be included in documents that place demands on IANA.
This document obsoletes RFC 2434.
Contents Contents
Status of this Memo.......................................... 1 Status of this Memo.......................................... 1
1. Introduction............................................. 4 1. Introduction............................................. 4
2. Why Management of a Name Space May be Necessary.......... 5 2. Why Management of a Name Space May be Necessary.......... 5
3. Designated Experts....................................... 5 3. Designated Experts....................................... 5
3.1. The Motivation For Designated Experts............... 6 3.1. The Motivation For Designated Experts............... 5
3.2. The Role of the Designated Expert................... 7 3.2. The Role of the Designated Expert................... 7
3.3. Designated Expert Reviews........................... 7 3.3. Designated Expert Reviews........................... 7
4. Creating A Registry...................................... 9 4. Creating A Registry...................................... 9
4.1. Well-Known IANA Policy Definitions.................. 9 4.1. Well-Known IANA Policy Definitions.................. 9
4.2. What To Put In Documents That Create A Registry..... 12 4.2. What To Put In Documents That Create A Registry..... 12
4.3. Updating IANA Guidelines For Existing Registries.... 14 4.3. Updating IANA Guidelines For Existing Registries.... 14
5. Registering New Values In An Existing Registry........... 14 5. Registering New Values In An Existing Registry........... 14
5.1. What to Put In Documents When Registering Values.... 14 5.1. What to Put In Documents When Registering Values.... 14
5.2. Updating Registrations.............................. 15 5.2. Updating Registrations.............................. 15
5.3. Overriding Registration Procedures.................. 16 5.3. Overriding Registration Procedures.................. 16
6. Miscellaneous Issues..................................... 17 6. Miscellaneous Issues..................................... 17
6.1. When There Are No IANA Actions...................... 17 6.1. When There Are No IANA Actions...................... 17
6.2. Appeals............................................. 18 6.2. Namespaces Lacking Documented Guidance.............. 18
6.3. Namespaces Lacking Documented Guidance.............. 18 6.3. After-The-Fact Registrations........................ 18
6.4. After-The-Fact Registrations........................ 18 6.4. Reclaiming Assigned Values.......................... 18
6.5. Reclaiming Assigned Values.......................... 18
7. Mailing Lists............................................ 19 7. Appeals.................................................. 19
8. Security Considerations.................................. 19 8. Mailing Lists............................................ 19
9. Open Issues.............................................. 20 9. Security Considerations.................................. 19
10. Changes Relative to RFC 2434............................ 20 10. Changes Relative to RFC 2434............................ 20
10.1. Changes Relative to -00............................ 21 10.1. Changes Relative to -00............................ 21
10.2. Changes Relative to -02............................ 21 10.2. Changes Relative to -02............................ 21
11. IANA Considerations..................................... 21 11. IANA Considerations..................................... 21
12. Acknowledgments......................................... 21 12. Acknowledgments......................................... 21
13. Normative References.................................... 22 13. Normative References.................................... 21
14. Informative References.................................. 22 14. Informative References.................................. 22
15. Authors' Addresses...................................... 24 15. Authors' Addresses...................................... 24
1. Introduction 1. Introduction
Many protocols make use of fields that contain constants and other Many protocols make use of fields that contain constants and other
well-known values (e.g., the Protocol field in the IP header [IP] or well-known values (e.g., the Protocol field in the IP header [IP] or
MIME types in mail messages [MIME-REG]). Even after a protocol has MIME types in mail messages [MIME-REG]). 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 (e.g., a new option type in DHCP [DHCP-OPTIONS] or a new assigned (e.g., a new option type in DHCP [DHCP-OPTIONS] or a new
encryption or authentication transform for IPsec [IPSEC]). To ensure encryption or authentication transform for IPsec [IPSEC]). To ensure
that such fields have consistent values and interpretations in that such fields have consistent values and interpretations in
different implementations, their assignment must be administered by a different implementations, their assignment must be administered by a
central authority. For IETF protocols, that role is provided by the central authority. For IETF protocols, that role is provided by the
Internet Assigned Numbers Authority (IANA) [IANA-MOU]. Internet Assigned Numbers Authority (IANA) [IANA-MOU].
In this document, we call the set of possible values for such a field In this document, we call the set of possible values for such a field
a "name space"; its actual value may be a text string, a number or a "name space"; its actual value may be a text string, a number or
another kind of value. The binding or association of a specific value another kind of value. The binding or association of a specific value
with a particular purpose within a name space is called an assigned with a particular purpose within a name space is called an assigned
number (or assigned value, or sometimes a "code point", "protocol number (or assigned value, or sometimes a "code point", "protocol
constant", or "protocol constant"). Each assignment of a value in a constant", or "protocol parameter"). Each assignment of a value in a
name space is called a registration. name space is called a registration.
In order for IANA to manage a given name space prudently, it needs In order for IANA to manage a given name space prudently, it needs
guidelines describing the conditions under which new values should be guidelines describing the conditions under which new values should be
assigned, or when (and how) modifications to existing values can be assigned, or when (and how) modifications to existing values can be
made. This document provides guidelines to authors on what sort of made. This document provides guidelines to authors on what sort of
text should be added to their documents in order to provide IANA text should be added to their documents in order to provide IANA
clear guidelines and reviews issues that should be considered in clear guidelines and reviews issues that should be considered in
formulating an appropriate policy for assigning numbers to name formulating an appropriate policy for assigning numbers to name
spaces. spaces.
skipping to change at page 5, line 38 skipping to change at page 5, line 37
A second consideration is whether it makes sense to delegate the name A second consideration is whether it makes sense to delegate the name
space in some manner. This route should be pursued when appropriate, space in some manner. This route should be pursued when appropriate,
as it lessens the burden on IANA for dealing with assignments. as it lessens the burden on IANA for dealing with assignments.
A third, and perhaps most important consideration, concerns potential A third, and perhaps most important consideration, concerns potential
impact on interoperability of unreviewed extensions. Proposed impact on 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
[PROTOCOL-EXT]. [PROTOCOL-EXT].
In some cases, the name space is essentially unlimited and there are When the name space is essentially unlimited and there are no
no potential interoperability issues; in such cases assigned numbers potential interoperability issues, assigned numbers can safely be
can safely be given out to anyone. When no subjective review is given out to anyone without any subjective review. In such cases,
needed, IANA can make assignments directly, provided that IANA is IANA can make assignments directly, provided that IANA is given
given specific instructions on what types of requests it should specific instructions on what types of requests it should grant, and
grant, and what information must be provided as part of a well-formed what information must be provided as part of a well-formed request
request for an assigned number. for an assigned number.
3. Designated Experts 3. Designated Experts
3.1. The Motivation For Designated Experts 3.1. The Motivation For Designated Experts
It should be noted that IANA does not create or define assignment It should be noted that IANA does not create or define assignment
policy itself; rather, it carries out policies that have been defined policy itself; rather, it carries out policies that have been defined
by others, i.e., in RFCs. IANA must be given a set of guidelines by others and published in RFCs. IANA must be given a set of
that allow it to make allocation decisions with minimal subjectivity guidelines that allow it to make allocation decisions with minimal
and without requiring any technical expertise with respect to the subjectivity and without requiring any technical expertise with
protocols that make use of a registry. respect to the protocols that make use of a registry.
In most cases, some review of prospective allocations is appropriate, In many cases, some review of prospective allocations is appropriate,
and the question becomes who should perform the review and what is and the question becomes who should perform the review and what is
the purpose of the review. In many cases, one might think that an the purpose of the review. One might think that an IETF Working
IETF Working Group (WG) familiar with the name space at hand should Group (WG) familiar with the name space at hand should be consulted.
be consulted. In practice, however, WGs eventually disband, so they In practice, however, WGs eventually disband, so they cannot be
cannot be considered a permanent evaluator. It is also possible for considered a permanent evaluator. It is also possible for name spaces
name spaces to be created through individual submission documents, to be created through individual submission documents, for which no
for which no WG is ever formed. WG is ever formed.
One way to ensure community review of prospective assignments is to One way to ensure community review of prospective assignments is to
have the requester submit a document for publication as an RFC. Such have the requester submit a document for publication as an RFC. Such
an action helps ensure that the specification is publicly and an action helps ensure that the specification is publicly and
permanently available, and allows some review of the specification permanently available, and allows some review of the specification
prior to publication and assignment of the requested code points. prior to publication and assignment of the requested code points.
This is the preferred way of ensuring review, and is particularly This is the preferred way of ensuring review, and is particularly
important if any potential interoperability issues can arise. For important if any potential interoperability issues can arise. For
example, some assignments are not just assignments, but also involve example, some assignments are not just assignments, but also involve
an element of protocol specification. A new option may define fields an element of protocol specification. A new option may define fields
skipping to change at page 6, line 50 skipping to change at page 6, line 46
current or former IETF WG). Such a mailing list provides a way for current or former IETF WG). Such a mailing list provides a way for
new registrations to be publicly reviewed prior to getting assigned, new registrations to be publicly reviewed prior to getting assigned,
or to give advice to persons wanting help in understanding what a or to give advice to persons wanting help in understanding what a
proper registration should contain. proper registration should contain.
While discussion on a mailing list can provide valuable technical While discussion on a mailing list can provide valuable technical
feedback, opinions may vary and discussions may continue for some feedback, opinions may vary and discussions may continue for some
time without clear resolution. In addition, IANA cannot participate time without clear resolution. In addition, IANA cannot participate
in all of these mailing lists and cannot determine if or when such in all of these mailing lists and cannot determine if or when such
discussions reach consensus. Therefore, IANA relies on a "designated discussions reach consensus. Therefore, IANA relies on a "designated
expert" to advise it in the specific question of whether an expert" for advice regarding the specific question of whether an
assignment should be made. The designated expert is a single assignment should be made. The designated expert is an individual who
individual who is responsible for carrying out an appropriate is responsible for carrying out an appropriate evaluation and
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 single-person subject experts is for the IETF to provide IANA with a subject matter expert
matter expert to whom the evaluation process can be delegated. IANA to whom the evaluation process can be delegated. IANA forwards
forwards requests for an assignment to the expert for evaluation, and requests for an assignment to the expert for evaluation, and the
the expert (after performing the evaluation) informs IANA whether or expert (after performing the evaluation) informs IANA whether or not
not to make the assignment or registration. to make the assignment or registration.
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
as wide a review of an assignment request as appropriate to evaluate the appropriate review of an assignment request. The review may be
it properly. This may involve consultation with a set of technology wide or narrow, depending to the situation and the judgment of the
experts, discussion on a public mailing list, or consultation with a designated expert. This may involve consultation with a set of
working group (or its mailing list if the working group has technology experts, discussion on a public mailing list, or
disbanded), etc. Ideally, the designated expert follows specific consultation with a working group (or its mailing list if the working
review criteria as documented with the protocol that creates or uses group has disbanded), etc. Ideally, the designated expert follows
the namespace. (See the IANA Considerations sections of specific review criteria as documented with the protocol that creates
or uses the namespace. (See the IANA Considerations sections of
[RFC3748,RFC3575] for examples that have been done for specific name [RFC3748,RFC3575] for examples that have been done for specific name
spaces). spaces).
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, e.g., those in section 3.3. norms, e.g., those in section 3.3.
skipping to change at page 8, line 20 skipping to change at page 8, line 16
firm deadline, but they must be started, and the requester and firm deadline, but they must be started, and the requester and
IANA should have some transparency into the process if an answer IANA should have some transparency into the process if an answer
cannot be given quickly. cannot be given quickly.
- if a designated expert does not respond to IANA's requests within - if a designated expert does not respond to IANA's requests within
a reasonable period of time, either with a response, or with a a reasonable period of time, either with a response, or with a
reasonable explanation for a delay (e.g., some requests may be reasonable explanation for a delay (e.g., some requests may be
particularly complex), and if this is a recurring event, IANA must particularly complex), and if this is a recurring event, IANA must
raise the issue with the IESG. Because of the problems caused by raise the issue with the IESG. Because of the problems caused by
delayed evaluations and assignments, the IESG should take delayed evaluations and assignments, the IESG should take
appropriate actions, such as ensuring that the expert understands appropriate actions to ensure that the expert understands and
and accepts their responsibilities, or appointing a new expert. accepts their responsibilities, or appoint a new expert.
- The designated expert is not required to personally bear the - The designated expert is not required to personally bear the
burden of evaluating and deciding all requests, but acts as a sort burden of evaluating and deciding all requests, but acts as a
of shepherd for the request, enlisting the help of others as shepherd for the request, enlisting the help of others as
appropriate. In the case that a request is denied, and rejecting appropriate. In the case that a request is denied, and rejecting
the request is likely to be controversial, the expert should have the request is likely to be controversial, the expert should have
the support of other subject matter experts. That is, the expert the support of other subject matter experts. That is, the expert
must be able to defend a decision to the community as a whole. must be able to defend a decision to the community as a whole.
In the case where a designated expert is used, but there are no In the case where a designated expert is used, but there are no
specific documented criteria for performing an evaluation, the specific documented criteria for performing an evaluation, the
presumption should be that a code point should be granted, unless presumption should be that a code point should be granted, unless
there is a compelling reason not to. Possible reasons to deny a there is a compelling reason to the contrary. Possible reasons to
request include: deny a request include:
- scarcity of codepoints, where the finite remaining codepoints - scarcity of codepoints, where the finite remaining codepoints
should be prudently managed, or when a request for a large number should be prudently managed, or when a request for a large number
of codepoints is made, when a single codepoint is the norm. of codepoints is made, when a single codepoint is the norm.
- documentation is not of sufficient clarity to evaluate or ensure - documentation is not of sufficient clarity to evaluate or ensure
interoperability interoperability.
- the code point is needed for a protocol extension, but the - the code point is needed for a protocol extension, but the
extension is not consistent with the documented (or generally extension is not consistent with the documented (or generally
understood) architecture of the base protocol being extended, and understood) architecture of the base protocol being extended, and
would be harmful to the protocol if widely deployed. It is not the would be harmful to the protocol if widely deployed. It is not the
intent that "inconsistencies" refer to minor differences "of a intent that "inconsistencies" refer to minor differences "of a
personal preference nature;" instead, they refer to significant personal preference nature;" instead, they refer to significant
differences such as inconsistencies with the underlying security differences such as inconsistencies with the underlying security
model, implying a change to the semantics of an existing message model, implying a change to the semantics of an existing message
type or operation, requiring unwarranted changes in deployed type or operation, requiring unwarranted changes in deployed
skipping to change at page 9, line 38 skipping to change at page 9, line 36
Private Use - For private or local use only, with the type and Private Use - For private or local use only, with the type and
purpose defined by the local site. No attempt is made to purpose defined by the local site. No attempt is made to
prevent multiple sites from using the same value in prevent multiple sites from using the same value in
different (and incompatible) ways. There is no need for different (and incompatible) ways. There is no need for
IANA to review such assignments (since IANA does not record IANA to review such assignments (since IANA does not record
them) and assignments are not generally useful for broad them) and assignments are not generally useful for broad
interoperability. interoperability.
Examples: Site-specific options in DHCP [DHCP-OPTIONS] have Examples: Site-specific options in DHCP [DHCP-OPTIONS] have
significance only within a single site. "X-foo:" header significance only within a single site, "X-foo:" header
lines in email messages. lines in email messages.
Experimental Use - Similar to private or local use only, with the Experimental Use - Similar to private or local use only, with the
purpose being to facilitate experimentation. See purpose being to facilitate experimentation. See
[EXPERIMENTATION] for details. [EXPERIMENTATION] for details.
Hierarchical allocation - Delegated managers can assign values Hierarchical allocation - Delegated managers can assign values
provided they have been given control over that part of the provided they have been given control over that part of the
name space. IANA controls the higher levels of the name space. IANA controls the higher levels of the
namespace according to one of the other policies. namespace according to one of the other policies.
Examples: DNS names, Object Identifiers, IP addresses Examples: DNS names, Object Identifiers, IP addresses
First Come First Served - Assignments are made to anyone on a First Come First Served - Assignments are made to anyone on a
first come, first served bases. There is no substantive first come, first served basis. There is no substantive
review of the request, other than to ensure that it is review of the request, other than to ensure that it is
well-formed and doesn't duplicate an existing assignment. well-formed and doesn't duplicate an existing assignment.
However, requests must include a minimal amount of clerical However, requests must include a minimal amount of clerical
information, such as a a point of contact (including an information, such as a a point of contact (including an
email address) and a brief description of what the value email address) and a brief description of how the value
would be used for. Additional information specific to the will be used. Additional information specific to the type
type of value requested may also need to be provided, as of value requested may also need to be provided, as defined
defined by the name space. For numbers, the exact value is by the name space. For numbers, the exact value is
generally assigned by IANA; with names, specific text generally assigned by IANA; with names, specific text
strings can usually be requested. strings can usually be requested.
Examples: vnd. (vendor assigned) MIME types [MIME-REG]. Examples: vnd. (vendor assigned) MIME types [MIME-REG].
Expert Review (or Designated Expert) - approval by a Designated Expert Review (or Designated Expert) - approval by a Designated
Expert is required. The required documentation and review Expert is required. The required documentation and review
criteria to be used by the Designated Expert should be criteria for use by the Designated Expert should be
provided when defining the registry. For example, see provided when defining the registry. For example, see
Sections 6 and 7.2 in [RFC3748]. Sections 6 and 7.2 in [RFC3748].
Specification required - Values and their meaning must be Specification required - Values and their meaning must be
documented in an RFC or other permanent and readily documented in an RFC or other permanent and readily
available public specification, in sufficient detail so available public specification, in sufficient detail so
that interoperability between independent implementations that interoperability between independent implementations
is possible. When used, Specification Required also implies is possible. When used, Specification Required also implies
usage of a Designated Expert, who will review the public usage of a Designated Expert, who will review the public
specification and evaluate whether it is sufficiently clear specification and evaluate whether it is sufficiently clear
to allow interoperable implementations. The intention to allow interoperable implementations. The intention
behind "permanent and readily available" is that a document behind "permanent and readily available" is that a document
can be reasonably be expected to easily be found long after can be reasonably be expected to easily be found long after
RFC publication. IANA assignment of the requested value. Publication of an
RFC is the ideal means of achieving this requirement.
Examples: SCSP [SCSP] Examples: SCSP [SCSP].
RFC Required - RFC publication (either as IETF Submission or as an RFC Required - RFC publication (either as IETF Submission or as an
RFC Editor submission [RFC3932]) suffices. Unless otherwise RFC Editor submission [RFC3932]) suffices. Unless otherwise
specified, any type of RFC is sufficient (e.g., specified, any type of RFC is sufficient (e.g.,
Informational, Experimental, Standards Track, BCP, etc.) Informational, Experimental, Standards Track, etc.)
IETF Review - (Formerly called "IETF Consensus" in [IANA- IETF Review - (Formerly called "IETF Consensus" in [IANA-
CONSIDERATIONS]) New values are assigned only through RFCs CONSIDERATIONS]) New values are assigned only through RFCs
that have been shepherded through the IESG as AD-Sponsored that have been shepherded through the IESG as AD-Sponsored
IETF (or WG) Documents [RFC3932,RFC3978]. The intention is IETF (or WG) Documents [RFC3932,RFC3978]. The intention is
that the document and proposed assignment will be reviewed that the document and proposed assignment will be reviewed
by the IESG and appropriate IETF WGs (or experts, if by the IESG and appropriate IETF WGs (or experts, if
suitable working groups no longer exist) to ensure that the suitable working groups no longer exist) to ensure that the
proposed assignment will not negatively impact proposed assignment will not negatively impact
interoperability or otherwise extend IETF protocols in an interoperability or otherwise extend IETF protocols in an
skipping to change at page 11, line 19 skipping to change at page 11, line 17
To ensure adequate community review, such documents are To ensure adequate community review, such documents are
shepherded through the IESG as AD-sponsored documents with shepherded through the IESG as AD-sponsored documents with
an IETF Last Call. an IETF Last Call.
Examples: SMTP extensions [SMTP-EXT], BGP Subsequent Examples: SMTP extensions [SMTP-EXT], BGP Subsequent
Address Family Identifiers [BGP4-EXT]. Address Family Identifiers [BGP4-EXT].
Standards Action - Values are assigned only for Standards Track Standards Action - Values are assigned only for Standards Track
RFCs approved by the IESG. RFCs approved by the IESG.
Examples: MIME top level types [MIME-REG] Examples: MIME top level types [MIME-REG].
IESG Approval - New assignments may be approved by the IESG. IESG Approval - New assignments may be approved by the IESG.
Although there is no requirement that the request be Although there is no requirement that the request be
documented in an RFC, the IESG has discretion to request documented in an RFC, the IESG has discretion to request
documents or other supporting materials on a case-by-case documents or other supporting materials on a case-by-case
basis. basis.
IESG Approval is not intended to be used often or as a IESG Approval is not intended to be used often or as a
"common case;" indeed, it has seldom been used in practice "common case;" indeed, it has seldom been used in practice
during the period RFC 2434 was in effect. Rather, it is during the period RFC 2434 was in effect. Rather, it is
skipping to change at page 11, line 46 skipping to change at page 11, line 44
employed for a particular assignment. IESG Approval would employed for a particular assignment. IESG Approval would
be appropriate, however, in cases where expediency is be appropriate, however, in cases where expediency is
desired and there is strong consensus for making the desired and there is strong consensus for making the
assignment (e.g., WG consensus). assignment (e.g., WG consensus).
The following guidelines are suggested for any evaluation The following guidelines are suggested for any evaluation
under IESG Approval: under IESG Approval:
- The IESG can (and should) reject a request if another - The IESG can (and should) reject a request if another
path is available that is more appropriate and there is path is available that is more appropriate and there is
no compelling reason to bypass normal community review no compelling reason to bypass normal community review.
- before approving a request, the community should be - before approving a request, the community should be
consulted, via a "call for comments" that provides as consulted, via a "call for comments" that provides as
much information as is reasonably possible about the much information as is reasonably possible about the
request. request.
It should be noted that it often makes sense to partition a name It should be noted that it often makes sense to partition a name
space into multiple categories, with assignments within each category space into multiple categories, with assignments within each category
handled differently. For example, many protocols now partition name handled differently. For example, many protocols now partition name
spaces into two (or even more) parts, where one range is reserved for spaces into two (or even more) parts, where one range is reserved for
skipping to change at page 12, line 21 skipping to change at page 12, line 19
Dividing a name space into ranges makes it possible to have different Dividing a name space into ranges makes it possible to have different
policies in place for different ranges. policies in place for different ranges.
4.2. What To Put In Documents That Create A Registry 4.2. What To Put In Documents That Create A Registry
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 name spaces. It is in formulating a policy for assigning values in name spaces. 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 subsections define what is needed for the appropriate. The following and later sections define what is needed
different types of IANA actions. for the different types of IANA actions.
Documents that create a new name space (or modify the definition of Documents that create a new name space (or modify the definition of
an existing space) and that expect IANA to play a role in maintaining an existing space) and that expect IANA to play a role in maintaining
that space (e.g., serving as a repository for registered values) MUST that space (e.g., serving as a repository for registered values) MUST
provide clear instructions on details of the name space. In provide clear instructions on details of the name space. In
particular, instructions MUST include: particular, instructions MUST include:
1) The name of the registry being created and/or maintained. The 1) The name of the registry being created and/or maintained. The
name will appear on the IANA web page and will be referred to in name will appear on the IANA web page and will be referred to in
future documents that need to allocate a value from the new future documents that need to allocate a value from the new
space. The full name (and abbreviation, if appropriate) should space. The full name (and abbreviation, if appropriate) should
be provided. It is highly desirable that the chosen name not be be provided. It is highly desirable that the chosen name not be
easily confusable with the name of another registry. easily confusable with the name of another registry.
2) What information must be provided as part of a request in order 2) What information must be provided as part of a request in order
to assign a new value. to assign a new value. This information may include the need to
document relevant security considerations, if any.
3) The review process that will apply to all future requests for a 3) The review process that will apply to all future requests for a
value from the namespace. value from the namespace.
Note: When a Designated Expert is used, documents MUST NOT name Note: When a Designated Expert is used, documents MUST NOT name
the Designated Expert in the document itself; instead, the name the Designated Expert in the document itself; instead, the name
should be relayed to the appropriate IESG Area Director at the should be relayed to the appropriate Area Director at the time
time the document is sent to the IESG for approval. the document is sent to the IESG for approval.
If the request should also be reviewed on a specific public If the request should also be reviewed on a specific public
mailing list (such as the ietf-types@iana.org for media types), mailing list (such as the ietf-types@iana.org for media types),
that mailing address should be specified. Note, however, that that mailing address should be specified. Note, however, that
when mailing lists are specified, a Designated Expert MUST also when mailing lists are specified, the requirement for a
be specified (see Section 3). Designated Expert MUST also be specified (see Section 3).
If IANA is expected to make assignments without requiring an If IANA is expected to make assignments without requiring an
outside review, sufficient guidance MUST be provided so that the outside review, sufficient guidance MUST be provided so that the
requests can be evaluated with minimal subjectivity. requests can be evaluated with minimal subjectivity.
4) The size and format of registry entries. When creating a new 4) The size and format of registry entries. When creating a new
name/number space, authors must specify the size of the registry name/number space, authors must specify the size of the registry
or sub-registry as well as the exact format for recording or sub-registry as well as the exact format for recording
registry values. For number assignments, one should specify registry values. For number assignments, one should specify
whether values are to be recorded in decimal, hexadecimal or whether values are to be recorded in decimal, hexadecimal or
some other format. For strings, the encoding format should be some other format. For strings, the encoding format should be
specified (e.g., ascii, UTF8, etc.) Authors should also clear specified (e.g., ASCII, UTF8, etc.) Authors should also clear
specify what fields to record in the registry. specify what fields to record in the registry.
5) Initial assignments and reservations. Clear instructions should 5) Initial assignments and reservations. Clear instructions should
be provided to identify any initial assignments or be provided to identify any initial assignments or
registrations. In addition, any ranges that are to be reserved registrations. In addition, any ranges that are to be reserved
for "Private Use", "Reserved", "Unassigned", etc. should be for "Private Use", "Reserved", "Unassigned", etc. should be
clearly indicated. clearly indicated.
When specifying the process for making future assignments, it is When specifying the process for making future assignments, it is
quite acceptable to pick one (or more) of the example policies listed quite acceptable to pick one (or more) of the example policies listed
skipping to change at page 13, line 42 skipping to change at page 13, line 42
For example, RADIUS [RFC3575] specifies the use of a Designated For example, RADIUS [RFC3575] specifies the use of a Designated
Expert, but includes specific additional criteria the Designated Expert, but includes specific additional criteria the Designated
Expert should follow. Expert should follow.
For example, a document could say something like: For example, a document could say something like:
This document defines a new DHCP option, entitled "FooBar" (see This document defines a new DHCP option, entitled "FooBar" (see
Section y), assigned a value of TBD1 from the DCHP Option space Section y), assigned a value of TBD1 from the DCHP Option space
[RFCXXX]. The FooBar option also defines an 8-bit FooType field, [RFCXXX]. The FooBar option also defines an 8-bit FooType field,
for which IANA is to create and maintain a registry entitled for which IANA is to create and maintain a registry entitled
"FooType values". Initial values for the FooType registry are "FooType values". Initial values for the DHCP FooBar FooType
given below; future assignments are to be made through Expert registry are given below; future assignments are to be made
Review [IANA-CONSIDERATIONS]. Assignments consist of a FooType through Expert Review [IANA-CONSIDERATIONS]. Assignments consist
name and its associated value. of a DHCP FooBar FooType name and its associated value.
FooType Name Value Definition DHCP FooBar FooType Name Value Definition
---- ----- ---------- ------------------------ ----------
Frobnitz 1 See Section y.1 Frobnitz 1 See Section y.1
NitzFrob 2 See Section y.2 NitzFrob 2 See Section y.2
For examples of documents that provide good and detailed guidance to For examples of documents that provide good and detailed guidance to
IANA on the issue of assigning numbers, consult [MIME-LANG, RFC3757, IANA on the issue of assigning numbers, consult [MIME-LANG, RFC3757,
RFC3749, RFC3575, RFC3968]. RFC3749, RFC3575, RFC3968].
4.3. Updating IANA Guidelines For Existing Registries 4.3. Updating IANA Guidelines For Existing Registries
Updating the registration process for an already existing (i.e., Updating the registration process for an already existing (i.e.,
previously created) name space (whether created explicitly or previously created) name space (whether created explicitly or
implicitly) follows a process similar to that used when creating a implicitly) follows a process similar to that used when creating a
skipping to change at page 14, line 28 skipping to change at page 14, line 28
Example documents that updated the guidelines for managing (then) Example documents that updated the guidelines for managing (then)
pre-existing registries include: [RFC2929,RFC3228,RFC3575]. pre-existing registries include: [RFC2929,RFC3228,RFC3575].
5. Registering New Values In An Existing Registry 5. Registering New Values In An Existing Registry
5.1. What to Put In Documents When Registering Values 5.1. What to Put In Documents When Registering Values
Often, documents request an assignment from an already existing name Often, documents request an assignment from an already existing name
space (i.e., one created by a previously-published RFC). In such space (i.e., one created by a previously-published RFC). In such
cases documents should make clear: cases:
- From what name space is a value is being requested? If the regis- - Documents should clearly identify the name space in which each
tration goes into a sub-registry, the author should clearly value is to be registered. If the registration goes into a sub-
describe where the assignment or registration should go. It is registry, the author should clearly describe where the assignment
helpful to use the exact name space name as listed on the IANA web or registration should go. It is helpful to use the exact name
page (and defining RFC), and cite the RFC where the name space is space name as listed on the IANA web page (and defining RFC), and
defined. (Note: There is no need to mention what the assignment cite the RFC where the name space is defined. (Note: There is no
policy for new assignments is, as that should be clear from the need to mention what the assignment policy for new assignments is,
references.) as that should be clear from the references.)
- For each value being requested, give it a unique reference. When - Each value requested should be given a unique reference. When the
the value is numeric, use the notation: TBD1, TBD2, etc. Through- value is numeric, use the notation: TBD1, TBD2, etc. Throughout
out the document where an actual IANA-assigned value should be the document where an actual IANA-assigned value should be filled
filled in, use the "TBDx" notation. This helps ensure that the in, use the "TBDx" notation. This helps ensure that the final RFC
final RFC has the correct assigned values inserted in in all of has the correct assigned values inserted in in all of the relevant
the relevant places where the value is expected to appear in the places where the value is expected to appear in the final
final document. For values that are text strings, a specific name document. For values that are text strings, a specific name can be
can be suggested. IANA will normally assign the name, unless it suggested. IANA will normally assign the name, unless it conflicts
conflicts with a name already in use. with a name already in use.
- Normally, the values to be used are chosen by IANA; documents - Normally, the values to be used are chosen by IANA and documents
shouldn't pick values themselves. However, in some cases a value should specify values of "TBD". However, in some cases a value may
may have been used for testing or in early implementations. In have been used for testing or in early implementations. In such
such cases, it is acceptable to include text suggesting what spe- cases, it is acceptable to include text suggesting what specific
cific value should be used (together with the reason for the value should be used (together with the reason for the choice).
choice). For example, one might include the text "the value XXX is For example, one might include the text "the value XXX is
suggested as it is used in implementations". However, it should be suggested as it is used in implementations". However, it should be
noted that suggested values are just that; IANA will attempt to noted that suggested values are just that; IANA will attempt to
assign them, but may find that impossible, if the proposed number assign them, but may find that impossible, if the proposed number
has already been assigned for some other use. has already been assigned for some other use.
For some registries, IANA has a longstanding policy prohibiting For some registries, IANA has a longstanding policy prohibiting
assignment of names or codes on a vanity or organization name assignment of names or codes on a vanity or organization name
basis, e.g., codes are always assigned sequentially unless there basis, e.g., codes are always assigned sequentially unless there
is a strong reason for making an exception. Nothing in this docu- is a strong reason for making an exception. Nothing in this
ment is intended to change those policies or prevent their future document is intended to change those policies or prevent their
application. future application.
- The IANA Considerations section should summarize all of the IANA - The IANA Considerations section should summarize all of the IANA
actions, with pointers to the relevant sections elsewhere in the actions, with pointers to the relevant sections elsewhere in the
document as appropriate. When multiple values are requested, it is document as appropriate. When multiple values are requested, it is
generally helpful to include a summary table. It is also helpful generally helpful to include a summary table. It is also helpful
for this table to be in the same format as it should appear on the for this table to be in the same format as it should appear on the
IANA web site. IANA web site.
Note: in cases where authors feel that including the full table is Note: in cases where authors feel that including the full table is
too verbose or repetitive, authors should still include the table, too verbose or repetitive, authors should still include the table,
but may include a note asking the table be removed prior to publi- but may include a note asking the table be removed prior to
cation of the final RFC. publication of the final RFC.
As an example, the following text could be used to request assignment As an example, the following text could be used to request assignment
of a DHCPv6 option number: of a DHCPv6 option number:
IANA has assigned an option code value of TBD1 to the DNS Recur- IANA has assigned an option code value of TBD1 to the DNS
sive Name Server option and an option code value of TBD2 to the Recursive Name Server option and an option code value of TBD2 to
Domain Search List option from the DHCP option code space defined the Domain Search List option from the DHCP option code space
in section 24.3 of RFC 3315. defined in section 24.3 of RFC 3315.
5.2. Updating Registrations 5.2. Updating Registrations
Registrations are a request to assign a new value, including the Registrations are a request to assign a new value, including the
related information needed to evaluate and document the request. Even related information needed to evaluate and document the request. Even
after a number has been assigned, some types of registrations contain after a number has been assigned, some types of registrations contain
additional information that may need to be updated over time. For additional information that may need to be updated over time. For
example, MIME types, character sets, language tags, etc. typically example, MIME types, character sets, language tags, etc. typically
include more information than just the registered value itself. include more information than just the registered value itself.
skipping to change at page 16, line 20 skipping to change at page 16, line 20
following: following:
- Let the author update the registration, subject to the same - Let the author update the registration, subject to the same
constraints and review as with new registrations. constraints and review as with new registrations.
- Allow some mechanism to attach comments to the registration, for - Allow some mechanism to attach comments to the registration, for
cases where others have significant objections to claims in a cases where others have significant objections to claims in a
registration, but the author does not agree to change the registration, but the author does not agree to change the
registration. registration.
- Designate the IESG or another entity as having the right to - Designate the IESG, a Designated Expert or another entity as
change the registrant associated with a registration and any having the right to change the registrant associated with a
requirements or conditions on doing so. This is mainly to get registration and any requirements or conditions on doing so.
around the problem when a registrant cannot be reached in order This is mainly to get around the problem when a registrant
to make necessary updates. cannot be reached in order to make necessary updates.
5.3. Overriding Registration Procedures 5.3. Overriding Registration Procedures
Since RFC 2434 was published, experience has shown that the Since RFC 2434 was published, experience has shown that the
documented IANA considerations for individual protocols do not always documented IANA considerations for individual protocols do not always
adequately cover the reality on the ground. For example, many older adequately cover the reality after the protocol is deployed. For
routing protocols do not have documented, detailed IANA example, many older routing protocols do not have documented,
considerations. In addition, documented IANA considerations are detailed IANA considerations. In addition, documented IANA
sometimes found to be too stringent to allow even working group considerations are sometimes found to be too stringent to allow even
documents (for which there is strong consensus) to obtain code points working group documents (for which there is strong consensus) to
from IANA in advance of actual RFC publication. In other cases, the obtain code points from IANA in advance of actual RFC publication.
documented procedures are unclear or neglected to cover all the In other cases, the documented procedures are unclear or neglected to
cases. In order to allow assignments in individual cases where there cover all the cases. In order to allow assignments in individual
is strong IETF consensus that an allocation should go forward, but cases where there is strong IETF consensus that an allocation should
the documented procedures do not support such an assignment, the IESG go forward, but the documented procedures do not support such an
is granted authority to approve assignments in such cases. The assignment, the IESG is granted authority to approve assignments in
intention is not to overrule properly documented procedures, or to such cases. The intention is not to overrule properly documented
obviate the need for protocols to properly document their IANA procedures, or to obviate the need for protocols to properly document
Considerations. Instead, the intention is to permit assignments in their IANA Considerations. Instead, the intention is to permit
individual cases where it is obvious that the assignment should just assignments in individual cases where it is obvious that the
be made, but updating the IANA process just to assign a particular assignment should just be made, but updating the IANA process just to
code point is viewed as too heavy a burden. assign a particular code point is viewed as too heavy a burden.
In general, the IETF would like to see deficient IANA registration In general, the IETF would like to see deficient IANA registration
procedures for a namespace revised through the IETF standards procedures for a namespace revised through the IETF standards
process, but not at the cost of unreasonable delay for needed process, but not at the cost of unreasonable delay for needed
assignments. If the IESG has had to take the action in this section, assignments. If the IESG has had to take the action in this section,
it is a strong indicator that the IANA registration procedures should it is a strong indicator that the IANA registration procedures should
be updated, possibly in parallel with ongoing protocol work. be updated, possibly in parallel with ongoing protocol work.
6. Miscellaneous Issues 6. Miscellaneous Issues
skipping to change at page 18, line 5 skipping to change at page 18, line 5
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.]
6.2. Appeals 6.2. Namespaces Lacking Documented Guidance
Appeals on registration decisions made by IANA can be appealed using
the normal IETF appeals process as described in Section 6.5 of
[IETF-PROCESS]. Specifically, appeals should be directed to the IESG,
followed (if necessary) by an appeal to the IAB, etc.
6.3. 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 evaluate assignments without specifying a precise evaluation
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 name space assignments MUST provide register or otherwise manage name space assignments MUST provide
guidelines for managing the name space. guidelines for managing the name space.
6.4. After-The-Fact Registrations 6.3. After-The-Fact Registrations
Occasionally, IANA becomes aware that an unassigned value from a Occasionally, IANA becomes aware that an unassigned value from a
managed name space is in use on the Internet, or that an assigned managed name space is in use on the Internet, or that an assigned
value is being used for a different purpose than originally value is being used for a different purpose than originally
registered. IANA will not condone such misuse, i.e., procedures of registered. IANA will not condone such misuse, i.e., procedures of
the type described in this document MUST be applied to such cases. In the type described in this document MUST be applied to such cases. In
the absence of specifications to the contrary, values may only be the absence of specifications to the contrary, values may only be
reassigned for a different purpose with the consent of the original reassigned for a different purpose with the consent of the original
assignee (when possible) and with due consideration of the impact of assignee (when possible) and with due consideration of the impact of
such a reassignment. such a reassignment.
6.5. Reclaiming Assigned Values 6.4. Reclaiming Assigned Values
Reclaiming previously-assigned values for reuse is tricky, because Reclaiming previously-assigned values for reuse is tricky, because
doing so can lead to interoperability problems with deployed systems doing so can lead to interoperability problems with deployed systems
still using the assigned values. Moreover, it can be extremely still using the assigned values. Moreover, it can be extremely
difficult to determine the extent of deployment of systems making use difficult to determine the extent of deployment of systems making use
of a particular value. However, in cases where the name space is of a particular value. However, in cases where the name space is
running out of unassigned values and additional ones are needed, it running out of unassigned values and additional ones are needed, it
may be desirable to attempt to reclaim unused values. When reclaiming may be desirable to attempt to reclaim unused values. When reclaiming
unused values, the following (at a minimum) should be considered: unused values, the following (at a minimum) should be considered:
- attempts should be made to contact the original party to which a - attempts should be made to contact the original party to which a
value is assigned, to determine how widely used a value is. (In value is assigned, to determine if the value was ever used, and if
some cases, products were never shipped or have long ceased being so, the extent of deployment. (In some cases, products were never
used. In other cases, it may be known that a value was never shipped or have long ceased being used. In other cases, it may be
actually used at all.) known that a value was never actually used at all.)
- reassignments should not normally be made without the concurrence - reassignments should not normally be made without the concurrence
of the original requester. Reclamation under such conditions of the original requester. Reclamation under such conditions
should only take place where there is strong evidence that a value should only take place where there is strong evidence that a value
is not widely used, and the need to reclaim the value outweighs is not widely used, and the need to reclaim the value outweighs
the cost of a hostile reclamation. In any case, IESG approval is the cost of a hostile reclamation. In any case, IESG approval is
needed in this case. needed in this case.
- it may be appropriate to write up the proposed action and solicit - it may be appropriate to write up the proposed action and solicit
comments from relevant user communities. In some cases, it may be comments from relevant user communities. In some cases, it may be
appropriate to write an RFC that goes through a formal IETF appropriate to write an RFC that goes through a formal IETF
process (including IETF Last Call) as was done when DHCP reclaimed process (including IETF Last Call) as was done when DHCP reclaimed
some of its "Private Use" options [RFC3942] some of its "Private Use" options [RFC3942]
7. Mailing Lists 7. Appeals
Appeals on registration decisions made by IANA can be appealed using
the normal IETF appeals process as described in Section 6.5 of
[IETF-PROCESS]. Specifically, appeals should be directed to the IESG,
followed (if necessary) by an appeal to the IAB, etc.
8. 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.
8. Security Considerations 9. Security Considerations
Information that creates or updates a registration needs to be Information that creates or updates a registration needs to be
authenticated and authorized. IANA updates registries according to authenticated and authorized. IANA updates registries according to
instructions in published RFCs and from the IESG. It also may accept instructions in published RFCs and from the IESG. It also may accept
clarifications from document authors and relevant WG chairs. clarifications from document authors, relevant WG chairs, Designated
Experts and mail list participants too.
Information concerning possible security vulnerabilities of a Information concerning possible security vulnerabilities of a
protocol may change over time. Likewise, security vulnerabilities protocol may change over time. Likewise, security vulnerabilities
related to how an assigned number is used (e.g., if it identifies a related to how an assigned number is used (e.g., if it identifies a
protocol) may change as well. As new vulnerabilities are discovered, protocol) may change as well. As new vulnerabilities are discovered,
information about such vulnerabilities may need to be attached to information about such vulnerabilities may need to be attached to
existing registrations, so that users are not mislead as to the true existing registrations, so that users are not mislead as to the true
security issues surrounding the use of a registered number. security issues surrounding the use of a registered number.
An analysis of security issues is required for all parameters (data An analysis of security issues is required for all parameters (data
types, operation codes, keywords, etc.) used in IETF protocols or types, operation codes, keywords, etc.) used in IETF protocols or
registered by IANA. All descriptions of security issues must be as registered by IANA. All descriptions of security issues must be as
accurate as possible regardless of level of registration. In accurate as possible regardless of level of registration. In
particular, a statement that there are "no security issues associated particular, a statement that there are "no security issues associated
with this type" must not given when it would be more accurate to with this type" must not be given when it would be more accurate to
state that "the security issues associated with this type have not state that "the security issues associated with this type have not
been assessed". been assessed".
9. Open Issues It is the responsibility of the IANA Considerations associated with a
particular registry to specify what (if any) security considerations
- the security considerations section seems out of whack with must be provided when assigning new values.
reality and existing practice. Which registries actually talk
about security implications? Is this a common thing to do? Should
security issues be discussed in published RFCs instead? (Note:
IANA reports that few if any registries talk about security
issues.)
- It would be good to get additional feedback on whether the
examples of "good IANA Considerations" that are cited are actually
good, or whether better ones are available.
10. Changes Relative to RFC 2434 10. Changes Relative to RFC 2434
Changes include: Changes include:
- Major reordering of text to group the "creation of registries" - Major reordering of text to group the "creation of registries"
text in same section, etc. text in same section, etc.
- Numerous editorial changes to improve readability. - Numerous editorial changes to improve readability.
 End of changes. 57 change blocks. 
168 lines changed or deleted 166 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/