< draft-narten-iana-considerations-rfc2434bis-08.txt   draft-narten-iana-considerations-rfc2434bis-09.txt >
INTERNET-DRAFT Thomas Narten INTERNET-DRAFT Thomas Narten
IBM IBM
<draft-narten-iana-considerations-rfc2434bis-08.txt> Harald Alvestrand <draft-narten-iana-considerations-rfc2434bis-09.txt> Harald Alvestrand
Obsoletes (if approved): 2434 Google Obsoletes (if approved): 2434 Google
Expires: April 4, 2007 October 4, 2007 Expires: September 21, 2007 March 26, 2008
Intended Status: BCP Intended Status: BCP
Guidelines for Writing an IANA Considerations Section in RFCs Guidelines for Writing an IANA Considerations Section in RFCs
<draft-narten-iana-considerations-rfc2434bis-08.txt> <draft-narten-iana-considerations-rfc2434bis-09.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 1, line 46 skipping to change at page 1, line 46
This Internet-Draft expires in six months. This Internet-Draft expires in six months.
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 (e.g., for a deployment has begun, new values may need to be assigned (e.g., for a
new option type in DHCP, or a new encryption or authentication 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 in different 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
protocols, that role is provided by the Internet Assigned Numbers protocols, that role is provided by the Internet Assigned Numbers
Authority (IANA). Authority (IANA).
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
skipping to change at page 3, line 16 skipping to change at page 3, line 16
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............... 5 3.1. The Motivation For Designated Experts............... 5
3.2. The Role of the Designated Expert................... 7 3.2. The Role of the Designated Expert................... 7
3.3. Designated Expert Reviews........................... 7 3.3. Designated Expert Reviews........................... 8
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.................. 10
4.2. What To Put In Documents That Create A Registry..... 13 4.2. What To Put In Documents That Create A Registry..... 13
4.3. Updating IANA Guidelines For Existing Registries.... 15 4.3. Updating IANA Guidelines For Existing Registries.... 16
5. Registering New Values In An Existing Registry........... 15 5. Registering New Values In An Existing Registry........... 16
5.1. What to Put In Documents When Registering Values.... 15 5.1. What to Put In Documents When Registering Values.... 16
5.2. Updating Registrations.............................. 17 5.2. Updating Registrations.............................. 18
5.3. Overriding Registration Procedures.................. 18 5.3. Overriding Registration Procedures.................. 18
6. Miscellaneous Issues..................................... 18 6. Miscellaneous Issues..................................... 19
6.1. When There Are No IANA Actions...................... 18 6.1. When There Are No IANA Actions...................... 19
6.2. Namespaces Lacking Documented Guidance.............. 19 6.2. Namespaces Lacking Documented Guidance.............. 20
6.3. After-The-Fact Registrations........................ 19 6.3. After-The-Fact Registrations........................ 20
6.4. Reclaiming Assigned Values.......................... 20 6.4. Reclaiming Assigned Values.......................... 20
7. Appeals.................................................. 20 7. Appeals.................................................. 21
8. Mailing Lists............................................ 20 8. Mailing Lists............................................ 21
9. Security Considerations.................................. 21 9. Security Considerations.................................. 21
10. Changes Relative to RFC 2434............................ 21 10. Changes Relative to RFC 2434............................ 22
11. IANA Considerations..................................... 22 11. IANA Considerations..................................... 23
12. Acknowledgments......................................... 22 12. Acknowledgments......................................... 23
13. Normative References.................................... 23 13. Normative References.................................... 23
14. Informative References.................................. 23 14. Informative References.................................. 23
15. Authors' Addresses...................................... 26 15. Authors' Addresses...................................... 26
1. Introduction 1. Introduction
Many protocols make use of fields that contain constants and other Many protocols make use of fields that contain constants and other
skipping to change at page 7, line 39 skipping to change at page 7, line 39
norms, e.g., those in section 3.3. norms, e.g., those in section 3.3.
Section 5.2 discusses disputes and appeals in more detail. Section 5.2 discusses disputes and appeals in more detail.
Designated experts are appointed by the IESG (normally upon Designated experts are appointed by the IESG (normally upon
recommendation by the relevant Area Director). They are typically recommendation by the relevant Area Director). They are typically
named at the time a document creating or updating a name space is named at the time a document creating or updating a name space is
approved by the IESG, but as experts originally appointed may later approved by the IESG, but as experts originally appointed may later
become unavailable, the IESG will appoint replacements if necessary. become unavailable, the IESG will appoint replacements if necessary.
For some registries, it has proven useful to have multiple designated
experts. Sometimes those experts work together in evaluating a
request, while in other cases additional experts serve as backups. In
cases of disagreement among those experts, it is the responsibility
of those experts to make a single clear recommendation to IANA. It is
not appropriate for IANA to resolve disputes among experts. In
extreme situations (e.g., deadlock) the IESG may need to step in to
resolve the problem.
In registries where a pool of experts evaluates requests, the pool
should have a single chair responsible for defining how requests are
to be assigned to and reviewed by experts. In some cases, the expert
pool may consist of a primary and backups, with the backups involved
only when the primary expert is unavailable. In other cases, IANA
might assign requests to a individual members in sequential or
approximate random order. In the event that IANA finds itself havnig
received conflicting advice from its experts, it is the
responsibility of the pool's chair to resolve the issue and provide
IANA with clear
Since the designated experts are appointed by the IESG, they may be Since the designated experts are appointed by the IESG, they may be
removed by the IESG. removed by the IESG.
3.3. Designated Expert Reviews 3.3. Designated Expert Reviews
In the eight years since RFC 2434 was published and has been put to In the eight years since RFC 2434 was published and has been put to
use, experience has led to the following observations: use, experience has led to the following observations:
- a designated expert must respond in a timely fashion, normally - a designated expert must respond in a timely fashion, normally
within a week for simple requests to a few weeks for more complex within a week for simple requests to a few weeks for more complex
skipping to change at page 11, line 5 skipping to change at page 11, line 23
Expert Review (or Designated Expert) - approval by a Designated Expert Review (or Designated Expert) - approval by a Designated
Expert is required. The required documentation and review Expert is required. The required documentation and review
criteria for use by the Designated Expert should be criteria for use by the Designated Expert should be
provided when defining the registry. For example, see provided when defining the registry. For example, see
Sections 6 and 7.2 in [RFC3748]. Sections 6 and 7.2 in [RFC3748].
Examples: EAP Method Types [RFC3748], HTTP Digest AKA Examples: EAP Method Types [RFC3748], HTTP Digest AKA
algorithm versions [RFC4169], URI schemes [RFC4395], algorithm versions [RFC4169], URI schemes [RFC4395],
GEOPRIV Location Types [RFC4589]. GEOPRIV Location Types [RFC4589].
Specification required - Values and their meaning must be Specification Required - Values and their meaning must be
documented in an RFC or other permanent and readily documented in a permanent and readily available public
available public specification, in sufficient detail so specification, in sufficient detail so that
that interoperability between independent implementations interoperability between independent implementations is
is possible. When used, Specification Required also implies 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 reasonably be expected to be findable and retrievable
IANA assignment of the requested value. Publication of an long after IANA assignment of the requested value.
RFC is the ideal means of achieving this requirement. For Publication of an RFC is an ideal means of achieving this
RFC publication, the normal RFC review process is expected requirement, but Specification Required is intended to also
to provide the necessary review for interoperability, cover the case of a document published outside of the RFC
though the Designated Expert may be a particularly well- path. For RFC publication, the normal RFC review process is
qualified person to perform such a review. expected to provide the necessary review for
interoperability, though the Designated Expert may be a
particularly well-qualified person to perform such a
review.
Examples: Diffserv-aware TE Bandwidth Constraints Model Examples: Diffserv-aware TE Bandwidth Constraints Model
Identifiers [RFC4124], TLS ClientCertificateType Identifiers [RFC4124], TLS ClientCertificateType
identifiers [RFC4346], ROHC Profile Identifiers [RFC4995]. identifiers [RFC4346], ROHC Profile Identifiers [RFC4995].
RFC Required - RFC publication (either as IETF Submission or as an RFC Required - RFC publication (either as IETF Submission or as an
RFC Editor submission [RFC3932]) suffices. Unless otherwise RFC Editor submission [RFC3932]) suffices. Unless otherwise
specified, any type of RFC is sufficient (e.g., specified, any type of RFC is sufficient (e.g.,
Informational, Experimental, Standards Track, etc.) Informational, Experimental, Standards Track, etc.)
IETF Review - (Formerly called "IETF Consensus" in [IANA- IETF Review - (Formerly called "IETF Consensus" in [IANA-
CONSIDERATIONS]) New values are assigned only through RFCs CONSIDERATIONS]) New values are assigned only through RFCs
that have been shepherded through the IESG as AD-Sponsored that have been shepherded through the IESG as AD-Sponsored
IETF (or WG) Documents [RFC3932,RFC3978]. The intention is or IETF WGs 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
inappropriate or damaging manner. inappropriate or damaging manner.
To ensure adequate community review, such documents are To ensure adequate community review, such documents are
shepherded through the IESG as AD-sponsored documents with shepherded through the IESG as AD-sponsored (or WG)
an IETF Last Call. documents with an IETF Last Call.
Examples: IPSECKEY Algorithm Types [RFC4025], Accounting- Examples: IPSECKEY Algorithm Types [RFC4025], Accounting-
Auth-Method AVP values in DIAMETER [RFC4005], TLS Handshake Auth-Method AVP values in DIAMETER [RFC4005], TLS Handshake
Hello Extensions [RFC4366]. Hello Extensions [RFC4366].
Standards Action - Values are assigned only for Standards Track Standards Action - Values are assigned only for Standards Track
RFCs approved by the IESG. RFCs approved by the IESG.
Examples: BGP message types [RFC4271], Mobile Node Examples: BGP message types [RFC4271], Mobile Node
Identifier option types [RFC4283], DCCP Packet Types Identifier option types [RFC4283], DCCP Packet Types
skipping to change at page 12, line 33 skipping to change at page 13, line 6
processes implied by other policies that could have been processes implied by other policies that could have been
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 for registration is available that is more
no compelling reason to bypass normal community review. appropriate and there is no compelling reason to use
that path.
- before approving a request, the community should be - before approving a request, the community should be
consulted, via a "call for comments" that provides as consulted, via a "call for comments" that provides as
much information as is reasonably possible about the much information as is reasonably possible about the
request. request.
Examples: IPv4 Multicast address assignments [RFC3171], IPv4 IGMP Examples: IPv4 Multicast address assignments [RFC3171], IPv4 IGMP
Type and Code values [RFC3228], Mobile IPv6 Mobility Header Type and Type and Code values [RFC3228], Mobile IPv6 Mobility Header Type and
Option values [RFC3775]. Option values [RFC3775].
It should be noted that it often makes sense to partition a name It should be noted that it often makes sense to partition a name
space into multiple categories, with assignments within each category space into multiple categories, with assignments within each category
handled differently. For example, many protocols now partition name handled differently. For example, many protocols now partition name
spaces into two (or even more) parts, where one range is reserved for spaces into two (or even more) parts, where one range is reserved for
Private or Experimental Use, while other ranges are reserved for Private or Experimental Use, while other ranges are reserved for
globally unique assignments assigned following some review process. globally unique assignments assigned following some review process.
Dividing a name space into ranges makes it possible to have different Dividing a name space into ranges makes it possible to have different
policies in place for different ranges. policies in place for different ranges.
Examples: LDAP [RFC4520], Pseudowire Edge to Edge Emulation (PWE3)
[RFC4446].
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 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.
skipping to change at page 14, line 40 skipping to change at page 15, line 19
the desired level of review. It is also acceptable to cite one of the the desired level of review. It is also acceptable to cite one of the
above policies and include additional guidelines for what kind of above policies and include additional guidelines for what kind of
considerations should be taken into account by the review process. considerations should be taken into account by the review process.
For example, RADIUS [RFC3575] specifies the use of a Designated For example, RADIUS [RFC3575] specifies the use of a Designated
Expert, but includes specific additional criteria the Designated Expert, but includes specific additional criteria the Designated
Expert should follow. Expert should follow.
For example, a document could say something like: For example, a document could say something like:
This document defines a new DHCP option, entitled "FooBar" (see This document defines a new DHCP option, entitled "FooBar" (see
Section y), assigned a value of TBD1 from the DCHP Option space Section y), assigned a value of TBD1 from the DHCP Option space
[to be removed upon publication: [to be removed upon publication:
http://www.iana.org/assignments/bootp-dhcp-parameters] [DHCP- http://www.iana.org/assignments/bootp-dhcp-parameters] [DHCP-
OPTIONS,DHCP-IANA]: OPTIONS,DHCP-IANA]:
Data Data
Tag Name Length Meaning Tag Name Length Meaning
---- ---- ------ ------- ---- ---- ------ -------
TBD1 FooBar N FooBar server TBD1 FooBar N FooBar server
The FooBar option also defines an 8-bit FooType field, for which The FooBar option also defines an 8-bit FooType field, for which
IANA is to create and maintain a new sub-registry entitled IANA is to create and maintain a new sub-registry entitled
"FooType values" under the FooBar option. Initial values for the "FooType values" under the FooBar option. Initial values for the
DHCP FooBar FooType registry are given below; future assignments DHCP FooBar FooType registry are given below; future assignments
are to be made through Expert Review [IANA-CONSIDERATIONS]. are to be made through Expert Review [IANA-CONSIDERATIONS].
Assignments consist of a DHCP FooBar FooType name and its Assignments consist of a DHCP FooBar FooType name and its
associated value. associated value.
Value DHCP FooBar FooType Name Definition Value DHCP FooBar FooType Name Definition
---- ------------------------ ---------- ---- ------------------------ ----------
0 Reserved 0 Reserved
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 [RFC2929, RFC3575, RFC3968, the issue of assigning numbers, consult [RFC2929, RFC3575, RFC3968,
RFC4520]. RFC4520].
4.3. Updating IANA Guidelines For Existing Registries 4.3. Updating IANA Guidelines For Existing Registries
Updating the registration process for an already existing (i.e., Updating the registration process for an already existing (i.e.,
previously created) name space (whether created explicitly or previously created) name space (whether created explicitly or
implicitly) follows a process similar to that used when creating a implicitly) follows a process similar to that used when creating a
skipping to change at page 16, line 9 skipping to change at page 16, line 37
value is to be registered. If the registration goes into a sub- value is to be registered. If the registration goes into a sub-
registry, the author should clearly describe where the assignment registry, the author should clearly describe where the assignment
or registration should go. It is helpful to use the exact name or registration should go. It is helpful to use the exact name
space name as listed on the IANA web page (and defining RFC), and space name as listed on the IANA web page (and defining RFC), and
cite the RFC where the name space is defined. cite the RFC where the name space is defined.
Note 1: There is no need to mention what the assignment policy for Note 1: There is no need to mention what the assignment policy for
new assignments is, as that should be clear from the references. new assignments is, as that should be clear from the references.
Note 2: When referring to an existing registry, providing a URL to Note 2: When referring to an existing registry, providing a URL to
precisely identify the registry is helpful. All such URLs, precisely identify the registry is helpful. Such URLs, however,
however, will be removed from the RFC prior to final publication. should usually be removed from the RFC prior to final publication,
For example, documents could contain: [TO BE REMOVED: This since IANA URLs are not guaranteed to be stable in the future. In
cases where it is important to include a URL in the document, IANA
should should concur on its inclusion.
As an example, documents could contain: [TO BE REMOVED: This
registration should take place at the following location: registration should take place at the following location:
http://www.iana.org/assignments/foobar-registry] http://www.iana.org/assignments/foobar-registry]
- Each value requested should be given a unique reference. When the - Each value requested should be given a unique reference. When the
value is numeric, use the notation: TBD1, TBD2, etc. Throughout value is numeric, use the notation: TBD1, TBD2, etc. Throughout
the document where an actual IANA-assigned value should be filled the document where an actual IANA-assigned value should be filled
in, use the "TBDx" notation. This helps ensure that the final RFC in, use the "TBDx" notation. This helps ensure that the final RFC
has the correct assigned values inserted in in all of the relevant has the correct assigned values inserted in in all of the relevant
places where the value is expected to appear in the final places where the value is expected to appear in the final
document. For values that are text strings, a specific name can be document. For values that are text strings, a specific name can be
skipping to change at page 16, line 52 skipping to change at page 17, line 37
- 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. For example: IANA web site. For example:
Value Description Reference Value Description Reference
-------- ------------------- --------- -------- ------------------- ---------
tbd1 Foobar [RFCXXXX] TBD1 Foobar [RFCXXXX]
Note: in cases where authors feel that including the full table is Note: in cases where authors feel that including the full table is
too verbose or repetitive, authors should still include the table, too verbose or repetitive, authors should still include the table,
but may include a note asking the table be removed prior to but may include a note asking the table be removed prior to
publication of the final RFC. publication of the final RFC.
As an example, the following text could be used to request assignment As an example, the following text could be used to request assignment
of a DHCPv6 option number: of a DHCPv6 option number:
IANA has assigned an option code value of TBD1 to the DNS IANA has assigned an option code value of TBD1 to the DNS
skipping to change at page 21, line 39 skipping to change at page 22, line 26
security considerations must be provided when assigning new values, security considerations must be provided when assigning new values,
and the process for reviewing such claims. and the process for reviewing such claims.
10. Changes Relative to RFC 2434 10. Changes Relative to RFC 2434
Changes include: Changes include:
- Major reordering of text to expand descriptions and to better - Major reordering of text to expand descriptions and to better
group topics such as "updating registries" vs. "creating new group topics such as "updating registries" vs. "creating new
registries", in order to make it easier for authors to find the registries", in order to make it easier for authors to find the
text most applicable to thier needs. text most applicable to their needs.
- Numerous editorial changes to improve readability. - Numerous editorial changes to improve readability.
- Changed the term "IETF Consensus" to "IETF Review" and added more - Changed the term "IETF Consensus" to "IETF Review" and added more
clarifications. History has shown that people see the words "IETF clarifications. History has shown that people see the words "IETF
Consensus" (without consulting the actual definition) are quick to Consensus" (without consulting the actual definition) are quick to
make incorrect assumptions about what the term means in the make incorrect assumptions about what the term means in the
context of IANA Considerations. context of IANA Considerations.
- Added "RFC Required" to list of defined policies. - Added "RFC Required" to list of defined policies.
skipping to change at page 22, line 38 skipping to change at page 23, line 24
This document is all about IANA Considerations, but has no IANA This document is all about IANA Considerations, but has no IANA
actions. actions.
12. Acknowledgments 12. Acknowledgments
This document has benefited from specific feedback from Jari Arkko, This document has benefited from specific feedback from Jari Arkko,
Marcelo Bagnulo Braun, Brian Carpenter, Michelle Cotton, Barbara Marcelo Bagnulo Braun, Brian Carpenter, Michelle Cotton, Barbara
Denny, Spencer Dawkins, Miguel Garcia, Paul Hoffman, Russ Housley, Denny, Spencer Dawkins, Miguel Garcia, Paul Hoffman, Russ Housley,
John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus
Westerland and Bert Wijnen. Westerlund and Bert Wijnen.
The original acknowledgments section in RFC 2434 was: The original acknowledgments section in RFC 2434 was:
Jon Postel and Joyce Reynolds provided a detailed explanation on what Jon Postel and Joyce Reynolds provided a detailed explanation on what
IANA needs in order to manage assignments efficiently, and patiently IANA needs in order to manage assignments efficiently, and patiently
provided comments on multiple versions of this document. Brian provided comments on multiple versions of this document. Brian
Carpenter provided helpful comments on earlier versions of the Carpenter provided helpful comments on earlier versions of the
document. One paragraph in the Security Considerations section was document. One paragraph in the Security Considerations section was
borrowed from [MIME-REG]. borrowed from [MIME-REG].
skipping to change at page 25, line 37 skipping to change at page 26, line 25
[RFC4346] "The Transport Layer Security (TLS) Protocol Version 1.1," [RFC4346] "The Transport Layer Security (TLS) Protocol Version 1.1,"
T. Dierks, E. Rescorla. April 2006. T. Dierks, E. Rescorla. April 2006.
[RFC4395] "Guidelines and Registration Procedures for New URI [RFC4395] "Guidelines and Registration Procedures for New URI
Schemes," T. Hansen, T. Hardie, L. Masinter. Schemes," T. Hansen, T. Hardie, L. Masinter.
February 2006. February 2006.
[RFC4422] "Simple Authentication and Security Layer (SASL)". A. [RFC4422] "Simple Authentication and Security Layer (SASL)". A.
Melnikov, Ed., K. Zeilenga, Ed.. June 2006. Melnikov, Ed., K. Zeilenga, Ed.. June 2006.
[RFC4446] "IANA Allocations for Pseudowire Edge to Edge Emulation
(PWE3)," L. Martini. April 2006.
[RFC4520] "Internet Assigned Numbers Authority (IANA) Considerations [RFC4520] "Internet Assigned Numbers Authority (IANA) Considerations
for the Lightweight Directory Access Protocol for the Lightweight Directory Access Protocol
(LDAP)," K. Zeilenga. June 2006. (LDAP)," K. Zeilenga. June 2006.
[RFC4589] "Location Types Registry," H. Schulzrinne, H. Tschofenig. [RFC4589] "Location Types Registry," H. Schulzrinne, H. Tschofenig.
July 2006. July 2006.
[RFC4727] "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, [RFC4727] "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP,
and TCP Headers". B. Fenner. November 2006. and TCP Headers". B. Fenner. November 2006.
skipping to change at page 26, line 45 skipping to change at page 27, line 33
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
Copyright Statement Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 31 change blocks. 
48 lines changed or deleted 82 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/