draft-ietf-sip-congestsafe-00.txt   draft-ietf-sip-congestsafe-01.txt 
SIP -- Session Initiation Protocol D. Willis SIP -- Session Initiation Protocol D. Willis
Working Group B. Campbell Working Group B. Campbell
Internet-Draft dynamicsoft Inc. Internet-Draft dynamicsoft Inc.
Expires: January 30, 2003 Aug 01, 2002 Expires: August 13, 2003 Feb 12, 2003
Session Initiation Protocol Extension to Assure Congestion Safety Session Initiation Protocol Extension to Assure Congestion Safety
draft-ietf-sip-congestsafe-00 draft-ietf-sip-congestsafe-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. 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 January 30, 2003. This Internet-Draft will expire on August 13, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
The Session Initiation Protocol allows the use of UDP for transport The Session Initiation Protocol allows the use of UDP for transport
of SIP messages. The use of UDP inherently risks network congestion of SIP messages. The use of UDP inherently risks network congestion
problems, as UDP itself does not define congestion prevention, problems, as UDP itself does not define congestion prevention,
avoidance, detection, or correction mechanisms. This problem is avoidance, detection, or correction mechanisms. This problem is
aggravated by large SIP messages which fragment at the UDP level. aggravated by large SIP messages which fragment at the UDP level.
Transport protocols in SIP are also negotiated on a per-hop basis, at Transport protocols in SIP are also negotiated on a per-hop basis, at
the SIP level, so SIP proxies may convert from TCP to UDP and so the SIP level, so SIP proxies may convert from TCP to UDP and so
skipping to change at page 2, line 18 skipping to change at page 2, line 18
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definition of Congestion Safety for SIP . . . . . . . . . . . 3 3. Definition of Congestion Safety for SIP . . . . . . . . . . . 3
4. Assuring Transitive Congestion Safety with Proxy-Require . . . 4 4. Assuring Transitive Congestion Safety with Proxy-Require . . . 4
5. Responsible use of SIP over UDP . . . . . . . . . . . . . . . 4 5. Responsible use of SIP over UDP . . . . . . . . . . . . . . . 4
5.1 Requirements For Use of SIP Over UDP . . . . . . . . . . . . . 6 5.1 Requirements For Use of SIP Over UDP . . . . . . . . . . . . . 6
5.2 Pacing SIP Requests Over UDP . . . . . . . . . . . . . . . . . 6 5.2 Pacing SIP Requests Over UDP . . . . . . . . . . . . . . . . . 6
5.3 Proxy Rejects Requests That Would Require UDP Fragmentation . 7 5.3 Proxy Rejects Request That Would Require UDP Fragmentation . 7
5.4 Server Rejects Request Because Response Could Not Be Sent
Safely . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Syntax of Extensions and Changes to SIP Specifications . . . . 8 6. Syntax of Extensions and Changes to SIP Specifications . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
Normative References . . . . . . . . . . . . . . . . . . . . . 10 Normative References . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12
1. Terminology 1. 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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Background 2. Background
The Session Initiation Protocol RFC 3261 [4] provides application The Session Initiation Protocol RFC 3261 [4] provides application
skipping to change at page 3, line 41 skipping to change at page 3, line 41
appears to be quite useful such as tiny mobile phones and in appears to be quite useful such as tiny mobile phones and in
extremely high-volume proxies connecting over dedicated networks. extremely high-volume proxies connecting over dedicated networks.
As an alternative, this draft: As an alternative, this draft:
1. Defines what it means for a SIP node to be "congestion-safe". 1. Defines what it means for a SIP node to be "congestion-safe".
2. Defines a mechanism whereby a congestion-safe UA may require that 2. Defines a mechanism whereby a congestion-safe UA may require that
any proxy processing its requests be congestion safe. any proxy processing its requests be congestion safe.
3. Defines a mechanism whereby a proxy may reject a request that it 3. Defines a mechanism whereby a proxy may reject a request that it
would be forced to fragment, and in so doing inform the would be forced to fragment, and in so doing inform the
originating UA of relevant sizing parameters. originating UA of relevant sizing parameters.
4. Defines a mechanism whereby a server may reject requests that
would result in responses that might not be transmitted
congestion-safely if the request itself was not received in a
congestion-safe manner.
3. Definition of Congestion Safety for SIP 3. Definition of Congestion Safety for SIP
A SIP node can be considered "congestion safe" if it never emits a A SIP node can be considered "congestion safe" if it never emits a
request in a manner not known to be congestion safe. Requests may be request or response in a manner not known to be congestion safe.
considered congestion-safe if any one of the following criteria is
met: Requests may be considered congestion-safe if any one of the
following criteria is met:
1. The transport toward the next SIP hop is TCP, SCTP, or other 1. The transport toward the next SIP hop is TCP, SCTP, or other
transport providing congestion control and the next hop is known transport providing congestion control and the next hop is known
to be either a UA or a congestion-safe proxy. to be either a UA or a congestion-safe proxy.
2. The transport toward the next hop is UDP, the next hop is known 2. The transport toward the next hop is UDP, the next hop is known
to be a UA or congestion-safe proxy, and the network between the to be a UA or congestion-safe proxy, and the network between the
two is known to support congestion management at a lower layer. two is known to support congestion management at a lower layer.
Note that this is an uncomoon case in typical Internet Note that this is an uncomoon case in typical Internet
applications. applications.
3. If the only available transport toward the next hop is UDP and 3. If the only available transport toward the next hop is UDP and
the next hop is known to be a UA or congestion-safe proxy, the the next hop is known to be a UA or congestion-safe proxy, the
request MAY be transmitted over UDP or rejected by local policy. request MAY be transmitted over UDP or rejected by local policy.
If the request is transmitted over UDP, the procedures described If the request is transmitted over UDP, the procedures described
under the heading "Responsible use of SIP over UDP" in this under the heading "Responsible use of SIP over UDP" in this
document MUST be followed. document MUST be followed.
Responses may be considered congestion-safe if any one of the
following criteria is met:
1. The request was congestion-safe, as defined above.
2. The response is no larger than the request.
The preceding uses the phrase "the next hop is known to be either a The preceding uses the phrase "the next hop is known to be either a
UA or a congestion-safe proxy." Such knowledge may be derived either UA or a congestion-safe proxy." Such knowledge may be derived either
through administrative configuration or through use of the Proxy- through administrative configuration or through use of the
Require mechanism defined herein under the heading "Assuring Proxy-Require mechanism defined herein under the heading "Assuring
Transitive Congestion Safety with Proxy-Require". Transitive Congestion Safety with Proxy-Require".
4. Assuring Transitive Congestion Safety with Proxy-Require 4. Assuring Transitive Congestion Safety with Proxy-Require
SIP provides a mechanism whereby a user agent making a request can be SIP provides a mechanism whereby a user agent making a request can be
assured that any proxy servicing that request support a specific assured that any proxy servicing that request support a specific
extension or set of behavior. To do so, the user agent includes a extension or set of behavior. To do so, the user agent includes a
"Proxy-Require" header field with a value indicating a tag for the "Proxy-Require" header field with a value indicating a tag for the
specific extension or behavior required. There is an IANA specific extension or behavior required. There is an IANA
registration process for these tags. Proxies not recognizing a registration process for these tags. As per [4], proxies not
specific tag or unwilling to support the associated behavior MUST recognizing a specific tag or unwilling to support the associated
reject a request referincing that tag with a 420 response, which has behavior reject a request referencing that tag with a 420 response,
the semantic "Unsupported". which has the semantic "Unsupported".
We herein define a tag value of "congestion-safe". A proxy We herein define a tag value of "congestion-safe". A proxy
forwarding a request containing a Proxy-Require with this tag value forwarding a request containing a Proxy-Require with this tag value
MUST manifest the property of congestion-safety as defined by this MUST manifest the property of congestion-safety as defined by this
document. document.
5. Responsible use of SIP over UDP 5. Responsible use of SIP over UDP
The fundamental problem with UDP is that it provides no feedback The fundamental problem with UDP is that it provides no feedback
mechanism to allow a sender to pace its transmissions against the mechanism to allow a sender to pace its transmissions against the
skipping to change at page 5, line 17 skipping to change at page 5, line 21
UA1----\ /----UA10 UA1----\ /----UA10
UA2-----\ /-----UA11 UA2-----\ /-----UA11
UA3------\ /------UA12 UA3------\ /------UA12
UA4-------\ /-------UA13 UA4-------\ /-------UA13
UA5--------P1------P2--------UA14 UA5--------P1------P2--------UA14
UA6-------/ \-------UA15 UA6-------/ \-------UA15
UA7------/ \------UA16 UA7------/ \------UA16
UA8-----/ \-----UA17 UA8-----/ \-----UA17
UA9----/ \----UA18 UA9----/ \----UA18
Figure 1
In this scenario, any requests from UA(1..9) to UA(10..18) traverse In this scenario, any requests from UA(1..9) to UA(10..18) traverse
the proxy-proxy link P1&lt-->P2. Assuming current SIP practices, if the proxy-proxy link P1&lt-->P2. Assuming current SIP practices, if
this link is UDP and every UA emits a request simultaneously, each this link is UDP and every UA emits a request simultaneously, each
proxy will insert nine (one for each UA) requests, resulting in proxy will insert nine (one for each UA) requests, resulting in
eighteen simultaneous requests on the P1&lt-->P2 link. Each request eighteen simultaneous requests on the P1&lt-->P2 link. Each request
may require retransmissions, and large requests may require may require retransmissions, and large requests may require
fragmentation to fit the link MTU -- at the worst case, producing fragmentation to fit the link MTU -- at the worst case, producing
more than one hundred packets per request, or approximately 2,000 more than one hundred packets per request, or approximately 2,000
simultaneously expressed packets in this scenario. If the capacity simultaneously expressed packets in this scenario. If the capacity
of link P1&lt-->P2 is inadequate to deliver these messages within the of link P1&lt-->P2 is inadequate to deliver these messages within the
SIP retransmission window, the originating UAs (or the proxies, if SIP retransmission window, the originating UAs (or the proxies, if
acting in transaction-stateful mode) generate retransmissions, acting in transaction-stateful mode) generate retransmissions,
further compounding the problem into a "retransmission storm". Real- further compounding the problem into a "retransmission storm".
world scenarios may scale far more seriously. It is not unreasonable Real-world scenarios may scale far more seriously. It is not
to assume that there may be tens of thousands of UAs on each side of unreasonable to assume that there may be tens of thousands of UAs on
the network. each side of the network.
Clearly the best thing to do is to use a more sophisticated transport Clearly the best thing to do is to use a more sophisticated transport
protocol (TCP, SCTP, etc.) between P1 and P2, and between each UA and protocol (TCP, SCTP, etc.) between P1 and P2, and between each UA and
its associated proxy. If this is not feasible, it may be necessary its associated proxy. If this is not feasible, it may be necessary
to fall back to UDP. This is especially common in the case of low- to fall back to UDP.
capacity UAs such as those proposed for 3G wireless systems.
It should be noted that the fundamental problem not just between UAs It should be noted that the fundamental problem not just between UAs
and proxies, but whenever there is a high fan-out or fan-in ration. and proxies, but whenever there is a high fan-out or fan-in ratio.
If in the above example, each UA were behind a "residential proxy", If in the above example, each UA were behind a "residential proxy",
the problem would occur in similar fashion. the problem would occur in similar fashion.
One might propose that SIP ALWAYS use a congestion-controlled One might propose that SIP ALWAYS use a congestion-controlled
transport to talk to proxies, and only fall back to UDP when the next transport to talk to proxies, and only fall back to UDP when the next
hop is a UA. The primary problem with this approach is that in hop is a UA. The primary problem with this approach is that in
general, a SIP node does not and cannot know whether the next node is general, a SIP node does not and cannot know whether the next node is
a UA or a proxy -- it is this ability to "insert" proxies into a a UA or a proxy -- it is this ability to "insert" proxies into a
sequence that provides much of the flexibility of SIP. A secondary sequence that provides much of the flexibility of SIP. A secondary
problem is that even if the next hop is a UA, some UAs are problem is that even if the next hop is a UA, some UAs are
skipping to change at page 7, line 40 skipping to change at page 7, line 45
and that implementations that are "congestion-safe" per this and that implementations that are "congestion-safe" per this
specification will have reduced performance when used with UDP over a specification will have reduced performance when used with UDP over a
shared or public network. We counter that congestion-safe transport shared or public network. We counter that congestion-safe transport
protocols are readily available, and that network users which insist protocols are readily available, and that network users which insist
on using unsafe transports (such as UDP) MUST be responsible for on using unsafe transports (such as UDP) MUST be responsible for
assuring that they do not impede the function of other users of the assuring that they do not impede the function of other users of the
network, even at the expense of reducing their own efficiency. It is network, even at the expense of reducing their own efficiency. It is
simply irresponsible to "blast away" at the network without regard simply irresponsible to "blast away" at the network without regard
for congestion or its impact on other users of the network. for congestion or its impact on other users of the network.
5.3 Proxy Rejects Requests That Would Require UDP Fragmentation 5.3 Proxy Rejects Request That Would Require UDP Fragmentation
A proxy may be faced with a request to deliver a large message using A proxy may be faced with a request to deliver a large message using
UDP as a transport. Fragmentation of such messages is problematic in UDP as a transport. Fragmentation of such messages is problematic in
several ways. Loss of any fragment requires time-out and several ways. Loss of any fragment requires time-out and
retransmission of the message. The fragments are commonly retransmission of the message. The fragments are commonly
transmitted out the interface at local interface (usually LAN) rates, transmitted out the interface at local interface (usually LAN) rates,
without awareness of intervening network conditions. For these without awareness of intervening network conditions. For these
reason, we believe it in general a bad practice to send large reason, we believe it in general a bad practice to send large
requests over UDP. requests over UDP.
skipping to change at page 8, line 40 skipping to change at page 8, line 45
link. If a Proxy-Max-Size header field is sent, the proxy MUST also link. If a Proxy-Max-Size header field is sent, the proxy MUST also
include a "Proxy-Seen-Size" header indicating the size of the request include a "Proxy-Seen-Size" header indicating the size of the request
as seen at this proxy. as seen at this proxy.
A UA receiving a 513 response has the options of giving up, trying a A UA receiving a 513 response has the options of giving up, trying a
smaller request, or trying a different set of proxies. Should it smaller request, or trying a different set of proxies. Should it
choose to try a smaller request, it may estimate the size of the choose to try a smaller request, it may estimate the size of the
largest message that can be sent by taking the original request size, largest message that can be sent by taking the original request size,
subtracting it from the value of the Proxy-Seen-Size header field, subtracting it from the value of the Proxy-Seen-Size header field,
and subtracting that result from the value of the Proxy-max-Size and subtracting that result from the value of the Proxy-max-Size
header field. header field. Note that a UA SHOULD NOT repeatedly downsize and
retry a request. This technique is not an adequate replacement for
TCP's Path MTU Discovery. Any request that has been rejected more
than once with a 513 SHOULD either be abandoned or re-issued over
congestion-safe channels.
5.4 Server Rejects Request Because Response Could Not Be Sent Safely
A server receiving a SIP request generates a resposne to that
request. Delivery of this response may raise issues of
congestion-safety. Because SIP requires that responses traverse
exactly the reverse of the route taken by the request (recorded in
the Via: header fields values), the server has no options about
routing the response. If the request was delivered in a
congestion-safe manner, it can be safely assumed that the response
will also be returned in a congestion-safe manner, as it must
traverse exactly this recorded route. However, if the request was
NOT received in a congestion-safe manner, the server cannot negotiate
a congestion-safe path for the response, as the response must follow
the path of the request.
If the size of the generated response is less than the size of the
received request, it may be reasonably assumed that since the request
arrived intact, a response of equal or smaller size is likely to
traverse the reverse of that path succesfully. However, no such
assumptions can be made about responses that are larger than the
corresponding request.
When a congestion-safe server generates a response to a request that
is larger than the request and that request was not received over a
congestion-safe channel, it cannot be assumed that the response can
be safely transmitted. An unsafe response cannot be transmitted by a
congestion-safe server. Instead the server MUST reject the request
and return an error response using response code 514, which has the
semantic of "Response Could Not Be Sent Safely".
A UA receiving a 514 response to a request may either retry the
request in a congestion-safe manner or abandon the request.
6. Syntax of Extensions and Changes to SIP Specifications 6. Syntax of Extensions and Changes to SIP Specifications
The syntax for the Proxy-Max-Size header field is: The syntax for the Proxy-Max-Size header field is:
Proxy-Max-Size = "Proxy-Max-Size" HCOLON 1*DIGIT Proxy-Max-Size = "Proxy-Max-Size" HCOLON 1*DIGIT
The syntax for the Proxy-Seen-Size header field is: The syntax for the Proxy-Seen-Size header field is:
Proxy-Seen-Size = "Proxy-Seen-Size" HCOLON 1*DIGIT Proxy-Seen-Size = "Proxy-Seen-Size" HCOLON 1*DIGIT
Additions to SIP Table 3:
Header field where proxy ACK BYE CAN INV OPT REG PRA
_______________________________________________________________
Proxy-Max-Size 513 a - - - - - -
Proxy-Seen-Size 513 a - - - - - - -
7. IANA Considerations 7. IANA Considerations
This document defines the SIP extension header fields "Proxy-Max- This document defines the SIP extension header fields
Size" and "Proxy-Seen-Size" ", which IANA will add to the registry of "Proxy-Max-Size" and "Proxy-Seen-Size" ", which IANA will add to the
SIP header fields defined in RFC 3261 [4]. registry of SIP header fields defined in [4].
This document also defines the SIP option tag "congestion-safe" which This document also defines the SIP option tag "congestion-safe" which
IANA will add to the registry of SIP option tags defined in RFC 3261 IANA will add to the registry of SIP option tags defined in [4].
[4].
This document also defines the SIP response code 514, with the
semantic "Response Cannot Be Sent Safely" which IANA will add to the
registry of SIP response codes defined in [4] in the section for 5xx
clase response codes.
The following is the registration for the Proxy-Max-Size header The following is the registration for the Proxy-Max-Size header
field: field:
RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of
this specification.] this specification.]
Header Field Name: Proxy-Max-Size Header Field Name: Proxy-Max-Size
Compact Form: none Compact Form: none
skipping to change at page 10, line 5 skipping to change at page 10, line 40
Compact Form: none Compact Form: none
The following is the registration for the congestion-safe option tag: The following is the registration for the congestion-safe option tag:
RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of
this specification.] this specification.]
Option Tag: congestion-safe Option Tag: congestion-safe
The following is the registration for the SIP response code 514:
RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of
this specification.]
Response Code: 514 Response Cannot Be Sent Safely
8. Acknowledgements 8. Acknowledgements
Robert Sparks and Jonathan Rosenberg argued with us vociferously over Robert Sparks and Jonathan Rosenberg argued with us vociferously over
this topic and contributed substantial insight. this topic and contributed substantial insight.
Normative References Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC [3] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
2223, October 1997. 2223, October 1997.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[5] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B.
Rosen, "Change Process for the Session Initiation Protocol
(SIP)", BCP 67, RFC 3427, December 2002.
Authors' Addresses Authors' Addresses
Dean Willis Dean Willis
dynamicsoft Inc. dynamicsoft Inc.
5100 Tennyson Parkway 5100 Tennyson Parkway
Suite 1200 Suite 1200
Plano, TX 75028 Plano, TX 75028
US US
Phone: +1 972 473 5455 Phone: +1 972 473 5455
skipping to change at page 11, line 5 skipping to change at page 12, line 5
dynamicsoft Inc. dynamicsoft Inc.
5100 Tennyson Parkway 5100 Tennyson Parkway
Suite 1200 Suite 1200
Plano, TX 75028 Plano, TX 75028
US US
Phone: +1 972 473 5452 Phone: +1 972 473 5452
EMail: bcampbell@dynamicsoft.com EMail: bcampbell@dynamicsoft.com
URI: http://www.dynamicsoft.com/ URI: http://www.dynamicsoft.com/
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any 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 such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/