draft-ietf-crisp-iris-lwz-06.txt   draft-ietf-crisp-iris-lwz-07.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Expires: November 26, 2006 May 25, 2006 Expires: July 13, 2007 January 9, 2007
A Lightweight UDP Transfer Protocol for the the Internet Registry A Lightweight UDP Transfer Protocol for the the Internet Registry
Information Service Information Service
draft-ietf-crisp-iris-lwz-06 draft-ietf-crisp-iris-lwz-07
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 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 26, 2006. This Internet-Draft will expire on July 13, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2007).
Abstract Abstract
This document describes a lightweight UDP transfer protocol for the This document describes a lightweight UDP transfer protocol for the
Internet Registry Information Service (IRIS). This transfer protocol Internet Registry Information Service (IRIS). This transfer protocol
uses a single packet for every request and response, and optionally uses a single packet for every request and response, and optionally
employs compression over the contents of the packet. employs compression over the contents of the packet.
Table of Contents Table of Contents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
6. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 13 6. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 13
6.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Application Protocol Label . . . . . . . . . . . . . . . . 13 6.2. Application Protocol Label . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 14
7.1.1. URI Scheme Registration . . . . . . . . . . . . . . . 14 7.1.1. URI Scheme Registration . . . . . . . . . . . . . . . 14
7.1.2. Well-known UDP Port Registration . . . . . . . . . . . 14 7.1.2. Well-known UDP Port Registration . . . . . . . . . . . 14
7.1.3. S-NAPTR Registration . . . . . . . . . . . . . . . . . 15 7.1.3. S-NAPTR Registration . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Normative References . . . . . . . . . . . . . . . . . . . . . 16 9. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 22 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 25
1. Introduction 1. Introduction
Using S-NAPTR [4], IRIS has the ability to define the use of multiple Using Straightforward Name Authority Pointers [4], IRIS has the
application transports or transfer protocols for different types of ability to define the use of multiple application transports or
registry services, all at the descretion of the server operator. The transfer protocols for different types of registry services, all at
UDP transfer protocol defined in this document is completely modular the descretion of the server operator. The UDP transfer protocol
and may be used by any registry types. defined in this document is completely independent of the registry
types for which it can carry data.
The binding of this UDP transfer protocol to IRIS is called IRIS-LWZ The binding of this UDP transfer protocol to IRIS is called IRIS-LWZ
(for IRIS Lightweight using Compression). Its message exchange (for IRIS Lightweight using Compression). Its message exchange
pattern is simple: a client sends a request in one UDP packet, and a pattern is simple: a client sends a request in one UDP packet, and a
server responds with an answer in one UDP packet. server responds with an answer in one UDP packet.
IRIS-LWZ packets are composed of two parts, a binary payload IRIS-LWZ packets are composed of two parts, a binary payload
descriptor and an request/response transaction payload. The request/ descriptor and an request/response transaction payload. The request/
response transaction payload may be compressed using the DEFLATE [1] response transaction payload may be compressed using the DEFLATE [1]
algorithm. algorithm.
2. Document Terminology 2. Document Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [6]. document are to be interpreted as described in RFC2119 [6].
Octet fields with numberic values are given according to the Octet fields with numberic values are given according to the
conventions in RFC 1166 [8]: the left most bit of the whole field is conventions in RFC 1166 [10]: the left most bit of the whole field is
the most significant bit; when a multi-octet quantity is transmitted the most significant bit; when a multi-octet quantity is transmitted
the most significant octet is transmitted first. Bits signifying the most significant octet is transmitted first. Bits signifying
flags in an octet are numbered according to the conventions of RFC flags in an octet are numbered according to the conventions of RFC
1166 [8]: bit 0 is the most significant bit and bit 7 is the least 1166 [10]: bit 0 is the most significant bit and bit 7 is the least
significant bit. When a diagram describes a group of octets, the significant bit. When a diagram describes a group of octets, the
order of tranmission for the octets starts from the left. order of tranmission for the octets starts from the left.
3. Packet Format 3. Packet Format
The UDP packet format for IRIS-LWZ is as follows: The packet format for IRIS-LWZ is as follows:
+------+------+----------+--------+------------+---------+ +------------+---------+
field | src | dest | checksum | UDP | payload | payload | field | payload | payload |
| port | port | | length | descriptor | | | descriptor | |
+------+------+----------+--------+------------+---------+ +------------+---------+
octets 2 2 2 2 3 or 6..261* 0..n octets 3 or 6..261* 0..n
* In request packets, the payload descriptor can vary in length * In request packets, the payload descriptor can vary in length
from 6 to 261 octets (i.e. 6..261). In response packets, the from 6 to 261 octets (i.e. 6..261). In response packets, the
payload descriptor is always 3 octets. payload descriptor is always 3 octets.
(where "src port" means source port and "dest port" means destination (where "src port" means source port and "dest port" means destination
port). port).
Each IRIS-LWZ query or response is contained in a single UDP packet. Each IRIS-LWZ query or response is contained in a single UDP packet.
Servers MUST be prepared to accepted packets as large as 4000 octets, Servers MUST be prepared to accepted packets as large as 4000 octets,
skipping to change at page 5, line 51 skipping to change at page 5, line 51
+--------+-------------+----------+-----------+-----------+ +--------+-------------+----------+-----------+-----------+
octets 1 2 2 1 0..255 octets 1 2 2 1 0..255
These fields have the following meanings: These fields have the following meanings:
header - as described in Section 3.1.3. header - as described in Section 3.1.3.
transaction ID - a 16 bit value identifying the transaction. This transaction ID - a 16 bit value identifying the transaction. This
value will be returned in the payload response descriptor value will be returned in the payload response descriptor
(Section 3.1.2) and can be used by clients to match requests with (Section 3.1.2) and can be used by clients to match requests with
responses. Clients SHOULD pick the value randomly and SHOULD NOT responses. Clients SHOULD NOT use sequential values (See
use sequences of 16 bit values. Clients MUST NOT set all the bits Section 8). Clients MUST NOT set all the bits in this value to 1
in this value to 1 (i.e. use a value of 0xFFFF). (i.e. use a value of 0xFFFF).
maximum response length - the total length of the UDP packet (i.e. maximum response length - the total length of the UDP packet (i.e.
UDP header length + payload descriptor length + XML payload UDP header length + payload descriptor length + XML payload
length) that should not be exceeded when responding to this length) that should not be exceeded when responding to this
request. If the server cannot provide a response that is equal to request. If the server cannot provide a response that is equal to
or less than this value, then it MUST respond with size or less than this value, then it MUST respond with size
information (Section 3.1.6). information (Section 3.1.6).
authority length - the length of the authority field in this authority length - the length of the authority field in this
payload descriptor. payload descriptor.
skipping to change at page 7, line 7 skipping to change at page 7, line 7
2. If the transaction ID in the corresponding request is a value of 2. If the transaction ID in the corresponding request is a value of
0xFFFF, servers MUST us a transaction ID of 0xFFFF and send a 0xFFFF, servers MUST us a transaction ID of 0xFFFF and send a
descriptor error (see Section 3.1.7). descriptor error (see Section 3.1.7).
3. Otherwise, the transaction ID MUST be the value of the 3. Otherwise, the transaction ID MUST be the value of the
transaction ID of the corresponding request. transaction ID of the corresponding request.
3.1.3. Payload Header 3.1.3. Payload Header
The bits of the payload header are ordered according to RFC 1166 [8], The bits of the payload header are ordered according to RFC 1166
where bit 0 is the most significant and bit 7 is the least [10], where bit 0 is the most significant and bit 7 is the least
significant. Each bit in the one octet payload header has the significant. Each bit in the one octet payload header has the
following meaning: following meaning:
bits 0 and 1 - version number ('V' field) - If 0 (both bits are bits 0 and 1 - version number ('V' field) - If 0 (both bits are
zero), the protocol is the version defined in this document. zero), the protocol is the version defined in this document.
Otherwise, the rest of the bits in the header and the payload may Otherwise, the rest of the bits in the header and the payload may
be interpreted as another version. be interpreted as another version.
bit 2 - request/response flag ('RR' flag) - If 0, this packet is a bit 2 - request/response flag ('RR' flag) - If 0, this packet is a
request (Section 3.1.1) packet. If 1, this packet is a response request (Section 3.1.1) packet. If 1, this packet is a response
skipping to change at page 8, line 18 skipping to change at page 8, line 18
(Section 3.1.6). (Section 3.1.6).
11 - other info ('oi' type). This payload type has no meaning in 11 - other info ('oi' type). This payload type has no meaning in
a request packet and is a descriptor error. In a response packet, a request packet and is a descriptor error. In a response packet,
this payload type indicates that the payload is other information this payload type indicates that the payload is other information
(Section 3.1.7). (Section 3.1.7).
3.1.5. Version Information 3.1.5. Version Information
A payload type with version information ('vi') MUST be comformant to A payload type with version information ('vi') MUST be comformant to
the XML defined in [7] and use the <versions> element as the root the XML defined in [8] and use the <versions> element as the root
element. element.
In the context of IRIS-LWZ, the protocol identifiers for these In the context of IRIS-LWZ, the protocol identifiers for these
elements are as follows: elements are as follows:
<transferProtocol> - the value "iris.lwz1" to indicate the <transferProtocol> - the value "iris.lwz1" to indicate the
protocol specified in this document. protocol specified in this document.
<application> - the XML namespace identifier for IRIS [3]. <application> - the XML namespace identifier for IRIS [3].
skipping to change at page 8, line 47 skipping to change at page 8, line 47
set to 'vi'). set to 'vi').
2. The version in a payload descriptor header does not match a 2. The version in a payload descriptor header does not match a
version the server supports. version the server supports.
3. The IRIS-based XML payload does not match a version the server 3. The IRIS-based XML payload does not match a version the server
supports. supports.
The protocols identified by the <transferProtocol> element MUST only The protocols identified by the <transferProtocol> element MUST only
indicate protocols running on the same socket as the sender of the indicate protocols running on the same socket as the sender of the
corresponding request. In other words, while a server operator may corresponding response. In other words, while a server operator may
also be running IRIS-XPC, this XML instance is only intended to also be running IRIS-XPC [9], this XML instance is only intended to
describe version negotiation for IRIS-LWZ. describe version negotiation for IRIS-LWZ.
The definition of octet size for the 'requestSizeOctets' and The definition of octet size for the 'requestSizeOctets' and
'responseSizeOctets' attributes of the <tranferProtocol> element are 'responseSizeOctets' attributes of the <tranferProtocol> element are
defined in Section 3.1.6. defined in Section 3.1.6.
3.1.6. Size Information 3.1.6. Size Information
A payload type with size information ('si') MUST be comformant to the A payload type with size information ('si') MUST be comformant to the
XML defined in [7] and use the <size> element as the root element. XML defined in [8] and use the <size> element as the root element.
Octet counts provided by this information are defined as the total Octet counts provided by this information are defined as the total
length of the UDP packet (i.e. UDP header length + payload length of the UDP packet (i.e. UDP header length + payload
descriptor length + XML payload length). descriptor length + XML payload length).
3.1.7. Other Information 3.1.7. Other Information
A payload type with other information ('oi') MUST be comformant to A payload type with other information ('oi') MUST be comformant to
the XML defined in [7] and use the <other> element as the root the XML defined in [8] and use the <other> element as the root
element. element.
The values for the 'type' attribute of <other> are as follows: The values for the 'type' attribute of <other> are as follows:
'descriptor-error' - indicates there was an error decoding the 'descriptor-error' - indicates there was an error decoding the
descriptor. Servers SHOULD send a descriptor error in the descriptor. Servers SHOULD send a descriptor error in the
following cases: following cases:
1. When a request is received with a payload type indicating size 1. When a request is received with a payload type indicating size
information (i.e. the PT flag is 'si'). information (i.e. the PT flag is 'si').
skipping to change at page 11, line 10 skipping to change at page 11, line 10
'no-inflation-support-error' - indicates that the receiver does 'no-inflation-support-error' - indicates that the receiver does
not support payloads that have been compressed with DEFLATE [1]. not support payloads that have been compressed with DEFLATE [1].
Servers MUST send this error when they receive a request that has Servers MUST send this error when they receive a request that has
been compressed with DEFLATE but they do not support inflation. been compressed with DEFLATE but they do not support inflation.
4. Interactions 4. Interactions
The intent of IRIS-LWZ is to utilize UDP for IRIS requests and The intent of IRIS-LWZ is to utilize UDP for IRIS requests and
responses when UDP is appropriate. Not all IRIS requests and responses when UDP is appropriate. Not all IRIS requests and
responses will be able to utilize UDP and may require the use of responses will be able to utilize UDP and may require the use of
other transfer protocols (i.e. IRIS-XPC and/or BEEP). The following other transfer protocols (i.e. IRIS-XPC [9] and/or BEEP). The
strategy SHOULD be used: following strategy SHOULD be used:
1. If a request requires authentication, confidentiality, or other 1. If a request requires authentication, confidentiality, or other
security, use another transfer protocol. security, use another transfer protocol. IRIS-XPC [9] is
RECOMMENDED.
2. If a request is less than or equal to 4000 octets, send it 2. If a request is less than or equal to 4000 octets, send it
uncompressed. uncompressed.
3. If a request can be compressed to a size less than or equal to 3. If a request can be compressed to a size less than or equal to
4000 octets, send the request using compression. Otherwise use 4000 octets, send the request using compression. Otherwise use
another transfer protocol. another transfer protocol. In cases where another transfer
protocol is needed, IRIS-XPC [9] is RECOMMENDED.
4. If a request yields a size error, send the request with another 4. If a request yields a size error, send the request with another
transfer protocol. transfer protocol. IRIS-XPC [9] is RECOMMENDED.
For retransmission of requests considered to be unanswered, a client
SHOULD retransmit using a timeout value initially set to 1 second.
This timeout value SHOULD be doubled for every retransmission, and it
a client SHOULD not retransmit any request once the timeout value has
reached 60 seconds.
Additionally, if a client intends thousands of requests to the same
server in a short amount of time, this protocol offers no real
advantage over IRIS-XPC [9]. In such a case, IRIS-XPC should be used
as it would be similarly effecient and would offer greater reponse
sizes and allow better security.
5. Internationalization Considerations 5. Internationalization Considerations
XML processors are obliged to recognize both UTF-8 and UTF-16 [2] XML processors are obliged to recognize both UTF-8 and UTF-16 [2]
encodings. Use of the XML defined by [7] MUST NOT use any other encodings. Use of the XML defined by [8] MUST NOT use any other
character encodings other than UTF-8 or UTF-16. character encodings other than UTF-8 or UTF-16.
6. IRIS Transport Mapping Definitions 6. IRIS Transport Mapping Definitions
This section lists the definitions required by IRIS [3] for transport This section lists the definitions required by IRIS [3] for transport
mappings. mappings.
6.1. URI Scheme 6.1. URI Scheme
See Section 7.1.1. See Section 7.1.1.
skipping to change at page 16, line 8 skipping to change at page 16, line 8
Relevant Publications: IRIS [3]. Relevant Publications: IRIS [3].
Contact Information: Andrew Newton <andy@hxr.us> Contact Information: Andrew Newton <andy@hxr.us>
Author/Change controller: the IESG Author/Change controller: the IESG
8. Security Considerations 8. Security Considerations
IRIS-LWZ is intended for serving public data; it provides no in-band IRIS-LWZ is intended for serving public data; it provides no in-band
mechanisms for authentication or encryption. Any application with mechanisms for authentication or confidentiality. Any application
this need must provide out of band mechanisms to provide it (e.g., with these needs must provide out of band mechanisms (e.g., IPSec),
IPSec), or use the IRIS transfer protocols that provides such or use the IRIS transfer protocols that provides such capabilities,
capabilities. such as IRIS-XPC [9].
Due to this lack of security, it is possible for an attacker to alter
IRIS-LWZ messages sent from the client to the server and from the
server to the client. Such an attack can result in denying usage of
an IRIS service or in supplying false information to end users and
many other scenarios.
Because IRIS-LWZ is a UDP based protocol, it is possible for servers Because IRIS-LWZ is a UDP based protocol, it is possible for servers
using IRIS-LWZ to be used in a type of distributed denial of service using IRIS-LWZ to be used in a type of distributed denial of service
attack known as a reflection attack. This type of attack affects attack known as a reflection attack. This type of attack affects
other types of UDP using protocols, such as DNS. Server operators other types of UDP using protocols, such as DNS. Server operators
should be prepared to apply the same methods used for mitigating should be prepared to apply the same methods used for mitigating
reflection attacks with other protocols, such as DNS, when using reflection attacks with other protocols, such as DNS, when using
IRIS-LWZ. IRIS-LWZ. All operators should follow the advice given in BCP 38
[7].
IRIS-LWZ uses transaction IDs in the payload descriptors to better
enable a client to match a response to a request. By randomizing the
transaction IDs being used (i.e. not using sequential numbers),
attackers flooding the network with a large amount of spoofed packets
have a lesser chance of succeeding with the attack. This measure is
not guaranteed to thwart any such attack. Client implementers MUST
take appropriate measures when ignoring this advice.
9. Normative References 9. Normative References
[1] Deutsch, P., "DEFLATE Compressed Data Format Specification [1] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996. version 1.3", RFC 1951, May 1996.
[2] The Unicode Consortium, "The Unicode Standard, Version 3", [2] The Unicode Consortium, "The Unicode Standard, Version 3",
ISBN 0-201-61633-5, 2000, <The Unicode Standard, Version 3>. ISBN 0-201-61633-5, 2000, <The Unicode Standard, Version 3>.
[3] Newton, A. and M. Sanz, "Internet Registry Information Service", [3] Newton, A. and M. Sanz, "Internet Registry Information
RFC 3891, January 2004. Service", RFC 3891, January 2004.
[4] Daigle, L. and A. Newton, "Domain-Based Application Service [4] Daigle, L. and A. Newton, "Domain-Based Application Service
Location Using SRV RRs and the Dynamic Delegation Discovery Location Using SRV RRs and the Dynamic Delegation Discovery
Service (DDDS)", RFC 3958, January 2005. Service (DDDS)", RFC 3958, January 2005.
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998. August 1998.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[7] Newton, A., "A Common Schema for Internet Registry Information [7] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[8] Newton, A., "A Common Schema for Internet Registry Information
Service Transfer Protocols", Service Transfer Protocols",
draft-ietf-crips-iris-common-transport-00 (work in progress), draft-ietf-crips-iris-common-transport-00 (work in progress),
April 2005. April 2005.
[8] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", [9] Newton, A., "XML Pipelining with Chunks for the Information
Registry Information Service", draft-ietf-crips-iris-xpc-05
(work in progress), January 2007.
[10] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers",
RFC 1166, July 1990. RFC 1166, July 1990.
Appendix A. Examples Appendix A. Examples
This section gives examples of IRIS-LWZ exchanges. Lines beginning This section gives examples of IRIS-LWZ exchanges. Lines beginning
with "C:" denote data sent by the client to the server, and lines with "C:" denote data sent by the client to the server, and lines
beginning with "S:" denote data sent by the server to the client. beginning with "S:" denote data sent by the server to the client.
Following the "C:" or "S:", the line either contains octet values in Following the "C:" or "S:", the line either contains octet values in
hexadecimal notation with comments or XML fragments. No line hexadecimal notation with comments or XML fragments. No line
contains both octet values with comments and XML fragments. Comments contains both octet values with comments and XML fragments. Comments
skipping to change at page 24, line 41 skipping to change at page 25, line 41
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 AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 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.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The Internet Society (2007). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 27 change blocks. 
47 lines changed or deleted 85 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/