< draft-narten-iana-considerations-rfc2434bis-05.txt   draft-narten-iana-considerations-rfc2434bis-06.txt >
INTERNET-DRAFT Thomas Narten INTERNET-DRAFT Thomas Narten
IBM IBM
<draft-narten-iana-considerations-rfc2434bis> Harald Tveit Alvestrand <draft-narten-iana-considerations-rfc2434bis-06.txt> Harald Alvestrand
Google Google
September 15, 2006 March 6, 2007
Guidelines for Writing an IANA Considerations Section in RFCs Guidelines for Writing an IANA Considerations Section in RFCs
<draft-narten-iana-considerations-rfc2434bis-05.txt> <draft-narten-iana-considerations-rfc2434bis-06.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 21 skipping to change at page 3, line 21
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............... 6
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.... 13 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.................. 15 5.3. Overriding Registration Procedures.................. 16
6. Miscellaneous Issues..................................... 16 6. Miscellaneous Issues..................................... 17
6.1. When There Are No IANA Actions...................... 16 6.1. When There Are No IANA Actions...................... 17
6.2. Appeals............................................. 17 6.2. Appeals............................................. 18
6.3. Namespaces Lacking Documented Guidance.............. 17 6.3. Namespaces Lacking Documented Guidance.............. 18
6.4. After-The-Fact Registrations........................ 17 6.4. After-The-Fact Registrations........................ 18
6.5. Reclaiming Assigned Values.......................... 18 6.5. Reclaiming Assigned Values.......................... 18
7. Mailing Lists............................................ 18 7. Mailing Lists............................................ 19
8. Security Considerations.................................. 19 8. Security Considerations.................................. 19
9. Open Issues.............................................. 19 9. Open Issues.............................................. 20
10. Changes Relative to RFC 2434............................ 19 10. Changes Relative to RFC 2434............................ 20
10.1. Changes Relative to -00............................ 20 10.1. Changes Relative to -00............................ 21
10.2. Changes Relative to -02............................ 20 10.2. Changes Relative to -02............................ 21
11. IANA Considerations..................................... 21 11. IANA Considerations..................................... 21
12. Acknowledgments......................................... 21 12. Acknowledgments......................................... 21
13. Normative References.................................... 21 13. Normative References.................................... 22
14. Informative References.................................. 21 14. Informative References.................................. 22
15. Authors' Addresses...................................... 23 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] or a new encryption assigned (e.g., a new option type in DHCP [DHCP-OPTIONS] or a new
or authentication transform for IPsec [IPSEC]). To ensure that such encryption or authentication transform for IPsec [IPSEC]). To ensure
fields have consistent values and interpretations in different that such fields have consistent values and interpretations in
implementations, their assignment must be administered by a central different implementations, their assignment must be administered by a
authority. For IETF protocols, that role is provided by the Internet central authority. For IETF protocols, that role is provided by the
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" or "protocol number (or assigned value, or sometimes a "code point", "protocol
constant"). Each assignment of a value in a name space is called a constant", or "protocol constant"). Each assignment of a value in 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 7, line 12 skipping to change at page 7, line 12
expert" to advise it in the specific question of whether an expert" to advise it in the specific question of whether an
assignment should be made. The designated expert is a single assignment should be made. The designated expert is a single
individual who is responsible for carrying out an appropriate individual who is responsible for carrying out an appropriate
evaluation and returning a recommendation to IANA. evaluation and 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 single-person subject
matter expert to whom the evaluation process can be delegated. IANA matter expert to whom the evaluation process can be delegated. IANA
forwards requests for an assignment to the expert for evaluation, and forwards requests for an assignment to the expert for evaluation, and
the expert (after performing the evaluation) informs IANA whether or the expert (after performing the evaluation) informs IANA whether or
not to make the assignment. not 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 as wide a review of an assignment request as appropriate to evaluate
it properly. This may involve consultation with a set of technology it properly. This may involve consultation with a set of technology
experts, discussion on a public mailing list, or consultation with a experts, discussion on a public mailing list, or consultation with a
working group (or its mailing list if the working group has working group (or its mailing list if the working group has
disbanded), etc. Ideally, the designated expert follows specific disbanded), etc. Ideally, the designated expert follows specific
review criteria as documented with the protocol that creates or uses review criteria as documented with the protocol that creates or uses
skipping to change at page 9, line 37 skipping to change at page 9, line 37
possible, since their meaning is widely understood. possible, since their meaning is widely understood.
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] 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 bases. 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 and a brief information, such as a a point of contact (including an
description of what the value would be used for. Additional email address) and a brief description of what the value
information specific to the type of value requested may would be used for. Additional information specific to the
also need to be provided, as defined by the name space. For type of value requested may also need to be provided, as
numbers, the exact value is generally assigned by IANA; defined by the name space. For numbers, the exact value is
with names, specific text strings can usually be requested. generally assigned by IANA; with names, specific text
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 to be used 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
skipping to change at page 10, line 42 skipping to change at page 10, line 43
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. RFC publication.
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. RFC Editor submission [RFC3932]) suffices. Unless otherwise
specified, any type of RFC is sufficient (e.g.,
Informational, Experimental, Standards Track, BCP, 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 13, line 9 skipping to change at page 13, line 10
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, a Designated Expert MUST also
be specified (see Section 3). 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
name/number space, authors must specify the size of the registry
or sub-registry as well as the exact format for recording
registry values. For number assignments, one should specify
whether values are to be recorded in decimal, hexadecimal or
some other format. For strings, the encoding format should be
specified (e.g., ascii, UTF8, etc.) Authors should also clear
specify what fields to record in the registry.
5) Initial assignments and reservations. Clear instructions should
be provided to identify any initial assignments or
registrations. In addition, any ranges that are to be reserved
for "Private Use", "Reserved", "Unassigned", etc. should be
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 (ore more) of the example policies quite acceptable to pick one (or more) of the example policies listed
listed in Section 4.1 and refer to it by name. Indeed, this is the in Section 4.1 and refer to it by name. Indeed, this is the
preferred mechanism in those cases where the sample policies provide preferred mechanism in those cases where the sample policies provide
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:
skipping to change at page 14, line 13 skipping to change at page 14, line 30
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 documents should make clear:
- From what name space is a value is being requested? It is helpful - From what name space is a value is being requested? If the regis-
to use the exact name space name as listed on the IANA web page tration goes into a sub-registry, the author should clearly
(and defining RFC), and cite the RFC where the name space is describe where the assignment 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 cite the RFC where the name space is
defined. (Note: There is no need to mention what the assignment defined. (Note: There is no need to mention what the assignment
policy for new assignments is, as that should be clear from the policy for new assignments is, as that should be clear from the
references.) references.)
- For each value being requested, give it a unique reference. When - For each value being requested, give it a unique reference. When
the value is numeric, use the notation: TBD1, TBD2, etc. Through- the value is numeric, use the notation: TBD1, TBD2, etc. Through-
out the document where an actual IANA-assigned value should be out the document where an actual IANA-assigned value should be
filled in, use the "TBDx" notation. This helps ensure that the filled in, use the "TBDx" notation. This helps ensure that the
final RFC has the correct assigned values inserted in in all of final RFC has the correct assigned values inserted in in all of
the relevant places where the value is expected to appear in the the relevant places where the value is expected to appear in the
skipping to change at page 14, line 51 skipping to change at page 15, line 26
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 docu-
ment is intended to change those policies or prevent their future ment is intended to change those policies or prevent their future
application. 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 often generally helpful to include a summary table. It is also helpful
useful for this table to be in the format of a registry data as it for this table to be in the same format as it should appear on the
should appear on the IANA web site IANA web site.
Note: in cases where authors feel that including the full table is
too verbose or repetitive, authors should still include the table,
but may include a note asking the table be removed prior to publi-
cation 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 Recur-
sive Name Server option and an option code value of TBD2 to the sive Name Server option and an option code value of TBD2 to the
Domain Search List option from the DHCP option code space defined Domain Search List option from the DHCP option code space defined
in section 24.3 of RFC 3315. in section 24.3 of RFC 3315.
5.2. Updating Registrations 5.2. Updating Registrations
Registrations are a request for an assigned number, 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.
Example information can include point of contact information, Example information can include point of contact information,
security issues, pointers to updates, literature references, etc. In security issues, pointers to updates, literature references, etc. In
such cases, the document defining the namespace must clearly state such cases, the document defining the namespace must clearly state
who is responsible for maintaining and updating a registration. In who is responsible for maintaining and updating a registration. In
different cases, it may be appropriate to specify one or more of the different cases, it may be appropriate to specify one or more of the
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.
skipping to change at page 19, line 34 skipping to change at page 20, line 11
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 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 9. Open Issues
- the security considerations section seems out of whack with - the security considerations section seems out of whack with
reality and existing practice. Which registries actually talk reality and existing practice. Which registries actually talk
about security implications? Is this a common thing to do? Should about security implications? Is this a common thing to do? Should
security issues be discussed in published RFCs instead? security issues be discussed in published RFCs instead? (Note:
IANA reports that few if any registries talk about security
- Added text to "Specification Required" stating that an Expert will issues.)
be used to evaluate a spec for adequate "implementability". Is
this reasonable? [IANA can't do the evaluation, as they lack the
necessary time/expertise. So someone has to do it...] Note:
Consensus seems to be yes.
- It would be good to get additional feedback on whether the - It would be good to get additional feedback on whether the
examples of "good IANA Considerations" that are cited are actually examples of "good IANA Considerations" that are cited are actually
good, or whether better ones are available. 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"
skipping to change at page 20, line 47 skipping to change at page 21, line 21
[RFC Editor: please remove the "changes relative to individual [RFC Editor: please remove the "changes relative to individual
drafts" below upon publication.] drafts" below upon publication.]
10.1. Changes Relative to -00 10.1. Changes Relative to -00
- Revised Section 5.3 to try and make it even more clear. - Revised Section 5.3 to try and make it even more clear.
10.2. Changes Relative to -02 10.2. Changes Relative to -02
- Significantly changed the wording in Section 3. Main purpose is - Significantly changed the wording in Section 3. Main purpose is
to make clear the Expert Reviewers are accountable to the to make clear the Expert Reviewers are accountable to the com-
community, and to provide some guidance for review criteria in munity, and to provide some guidance for review criteria in the
the default case. default case.
- removed wording: "By virtue of the IAB's role as overseer of - removed wording: "By virtue of the IAB's role as overseer of
IANA administration [RFC 1602], the IAB's decision is final IANA administration [RFC 1602], the IAB's decision is final
[IETF-PROCESS]." This document now makes no changes to existing [IETF-PROCESS]." This document now makes no changes to existing
appeal mechanisms relative to RFC 2026. appeal mechanisms relative to RFC 2026.
11. IANA Considerations 11. IANA Considerations
This document is all about IANA Considerations. This document is all about IANA Considerations.
skipping to change at page 22, line 23 skipping to change at page 22, line 40
[IANA-MOU] Memorandum of Understanding Concerning the Technical Work [IANA-MOU] Memorandum of Understanding Concerning the Technical Work
of the Internet Assigned Numbers Authority. B. of the Internet Assigned Numbers Authority. B.
Carpenter, F. Baker, M. Roberts, RFC 2860, June Carpenter, F. Baker, M. Roberts, RFC 2860, June
2000. 2000.
[IETF-PROCESS] Bradner, S., "The Internet Standards Process -- [IETF-PROCESS] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996. Revision 3", BCP 9, RFC 2026, October 1996.
[IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IPSEC] Atkinson, R., "Security Architecture for the Internet [IPSEC] S. Kent, K. Seo., "Security Architecture for the Internet
Protocol", RFC 1825, August 1995. Protocol", RFC 4301, December 2005.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[MIME-LANG] Freed, N. and K. Moore, "MIME Parameter Value and Encoded [MIME-LANG] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and Word Extensions: Character Sets, Languages, and
Continuations", RFC 2184, August 1997. Continuations", RFC 2184, August 1997.
[MIME-REG] Freed, N., Klensin, J. and J. Postel, "Multipurpose [MIME-REG] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Internet Mail Extension (MIME) Part Four: Internet Mail Extension (MIME) Part Four:
skipping to change at page 23, line 49 skipping to change at page 24, line 23
IBM Corporation IBM Corporation
3039 Cornwallis Ave. 3039 Cornwallis Ave.
PO Box 12195 - BRQA/502 PO Box 12195 - BRQA/502
Research Triangle Park, NC 27709-2195 Research Triangle Park, NC 27709-2195
Phone: 919-254-7798 Phone: 919-254-7798
EMail: narten@us.ibm.com EMail: narten@us.ibm.com
Harald Tveit Alvestrand Harald Tveit Alvestrand
Google Google
Beddingen 10
Trondheim, 7014
Norway
Email: Harald@Alvestrand.no Email: Harald@Alvestrand.no
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
skipping to change at page 24, line 29 skipping to change at page 25, line 5
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 ietf-
ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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 AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 30 change blocks. 
72 lines changed or deleted 87 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/