draft-ietf-sip-session-timer-12.txt   draft-ietf-sip-session-timer-13.txt 
SIP S. Donovan SIP S. Donovan
Internet-Draft J. Rosenberg Internet-Draft J. Rosenberg
Expires: March 31, 2004 dynamicsoft Expires: July 14, 2004 dynamicsoft
October 1, 2003 January 14, 2004
Session Timers in the Session Initiation Protocol (SIP) Session Timers in the Session Initiation Protocol (SIP)
draft-ietf-sip-session-timer-12 draft-ietf-sip-session-timer-13
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
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 March 31, 2004. This Internet-Draft will expire on July 14, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document defines an extension to the Session Initiation Protocol This document defines an extension to the Session Initiation Protocol
(SIP). This extension allows for a periodic refresh of SIP sessions (SIP). This extension allows for a periodic refresh of SIP sessions
through a re-INVITE or UPDATE request. The refresh allows both user through a re-INVITE or UPDATE request. The refresh allows both user
agents and proxies to determine if the SIP session is still active. agents and proxies to determine if the SIP session is still active.
The extension defines two new header fields, Session-Expires, which The extension defines two new header fields, Session-Expires, which
conveys the lifetime of the session, and Min-SE, which conveys the conveys the lifetime of the session, and Min-SE, which conveys the
minimum allowed value for the session timer. minimum allowed value for the session timer.
skipping to change at page 16, line 7 skipping to change at page 16, line 7
RECOMMENDED that the UPDATE request not contain an offer [4], but a RECOMMENDED that the UPDATE request not contain an offer [4], but a
re-INVITE SHOULD contain one, even if the details of the session have re-INVITE SHOULD contain one, even if the details of the session have
not changed. In that case, the offer MUST indicate that it has not not changed. In that case, the offer MUST indicate that it has not
changed. In the case of SDP, this is accomplished by including the changed. In the case of SDP, this is accomplished by including the
same value for the origin field as previous SDP messages to its peer. same value for the origin field as previous SDP messages to its peer.
The same is true for an answer exchanged as a result of a session The same is true for an answer exchanged as a result of a session
refresh request; if it has not changed, that MUST be indicated. refresh request; if it has not changed, that MUST be indicated.
8. Proxy Behavior 8. Proxy Behavior
Session timers are mostly of interest to call stateful proxy servers. Session timers are mostly of interest to call stateful proxy servers
However, a stateful proxy server MAY also follow the rules described (that is, servers that maintain the state of calls and dialogs
here. Stateless proxies MUST NOT attempt to request session timers. established through them). However, a stateful proxy server (that is,
Proxies that ask for session timers SHOULD record-route, since they a server which is aware of transaction state, but does not retain
won't receive refreshes if they don't. call or dialog state) MAY also follow the rules described here.
Stateless proxies MUST NOT attempt to request session timers. Proxies
that ask for session timers SHOULD record-route, since they won't
receive refreshes if they don't.
The proxy processing rules require the proxy to remember The proxy processing rules require the proxy to remember
information between the request and response, ruling out stateless information between the request and response, ruling out stateless
proxies. proxies.
8.1 Processing of Requests 8.1 Processing of Requests
Processing of requests is identical for all session refresh requests. Processing of requests is identical for all session refresh requests.
To request a session timer for a session, a proxy makes sure that a To request a session timer for a session, a proxy makes sure that a
skipping to change at page 19, line 47 skipping to change at page 19, line 47
Session-Expires header. The value MUST NOT be set it to a duration Session-Expires header. The value MUST NOT be set it to a duration
lower than the value in the Min-SE header field in the request, if lower than the value in the Min-SE header field in the request, if
present. present.
The UAS MUST set the value of the refresher parameter in the The UAS MUST set the value of the refresher parameter in the
Session-Expires header field in the 2xx response. This value Session-Expires header field in the 2xx response. This value
specifies who will perform refreshes for the dialog. The value is specifies who will perform refreshes for the dialog. The value is
based on the value of this parameter in the request, and on whether based on the value of this parameter in the request, and on whether
the UAC supports the session timer extension. The UAC supports the the UAC supports the session timer extension. The UAC supports the
extension if the 'timer' option tag was present in a Supported header extension if the 'timer' option tag was present in a Supported header
field in the request. Table 2 defines how the value in the response field in the request. Figure 3 defines how the value in the response
is set. A value of 'none' in the 2nd column means that there was no is set. A value of 'none' in the 2nd column means that there was no
refresher parameter in the request. A value of 'NA' in the third refresher parameter in the request. A value of 'NA' in the third
column means that this particular combination shouldn't happen, as column means that this particular combination shouldn't happen, as
it's disallowed by the protocol. it's disallowed by the protocol.
+----------------------+----------------------+---------------------+ UAC supports? refresher parameter refresher parameter
| UAC supports? | refresher parameter | refresher parameter | in request in response
| | in request | in response | -------------------------------------------------------
+----------------------+----------------------+---------------------+ N none uas
| N | none | uas | N uac NA
| | | | N uas NA
| N | uac | NA | Y none uas or uac
| | | | Y uac uac
| N | uas | NA | Y uas uas
| | | |
| Y | none | uas or uac |
| | | |
| Y | uac | uac |
| | | |
| Y | uas | uas |
+----------------------+----------------------+---------------------+
Table 2: UAS Behavior Figure 3: UAS Behavior
The fourth row of Table 2 describes a case where both the UAC and UAS The fourth row of Table 2 describes a case where both the UAC and UAS
support the session timer extension, and the UAC did not select who support the session timer extension, and the UAC did not select who
will perform refreshes. This allows the UAS to decide whether it, or will perform refreshes. This allows the UAS to decide whether it, or
the UAC, will perform the refreshes. However, as the table indicates, the UAC, will perform the refreshes. However, as the table indicates,
the UAS cannot override the UAC's choice of refresher, if it made the UAS cannot override the UAC's choice of refresher, if it made
one. one.
If the refresher parameter in the Session-Expires header field in the If the refresher parameter in the Session-Expires header field in the
2xx response has a value of 'uac', the UAS MUST place a Require 2xx response has a value of 'uac', the UAS MUST place a Require
skipping to change at page 24, line 15 skipping to change at page 24, line 15
11.2 Outside Attacks 11.2 Outside Attacks
An element that can observe and modify a request or response in An element that can observe and modify a request or response in
transit can force rapid session refreshes. To prevent that, requests transit can force rapid session refreshes. To prevent that, requests
and responses need to be protected by message integrity. Since the and responses need to be protected by message integrity. Since the
session timer headers are not end-to-end, and are manipulated by session timer headers are not end-to-end, and are manipulated by
proxies, the SIP S/MIME capabilities are not suitable for this task. proxies, the SIP S/MIME capabilities are not suitable for this task.
Rather, integrity needs to be protected using hop-by-hop mechanisms. Rather, integrity needs to be protected using hop-by-hop mechanisms.
As a result, it is RECOMMENDED that an element that sends a request As a result, it is RECOMMENDED that an element that sends a request
with a Session-Expires header field, or a Supported header field with with a Session-Expires header field, or a Supported header field with
the value 'timer', do so using IPSec or TLS. Since adequate the value 'timer', do so using TLS. Since adequate protection is
protection is obtained only if TLS or IPSec is applied on each hop, obtained only if security is applied on each hop, it is RECOMMENDED
it is RECOMMENDED that the SIPS URI scheme be used in conjunction that the SIPS URI scheme be used in conjunction with this extension.
with this extension. This means that proxies that record-route and This means that proxies that record-route and request session timer,
request session timer, SHOULD record-route with a SIPS URI. A UA that SHOULD record-route with a SIPS URI. A UA that inserts a
inserts a Session-Expires header into a request or response SHOULD Session-Expires header into a request or response SHOULD include a
include a Contact URI that is a SIPS URI. Contact URI that is a SIPS URI.
12. IANA Considerations 12. IANA Considerations
This extension defines two new header fields, a new response code, This extension defines two new header fields, a new response code,
and a new option tag. SIP [1] defines IANA procedures for registering and a new option tag. SIP [1] defines IANA procedures for registering
these. these.
12.1 IANA Registration of Min-SE and Session-Expires Header Fields 12.1 IANA Registration of Min-SE and Session-Expires Header Fields
The following is the registration for the Min-SE header field: The following is the registration for the Min-SE header field:
skipping to change at page 28, line 37 skipping to change at page 28, line 37
|<-----------| | | |<-----------| | |
| |(24) 408 | | | |(24) 408 | |
| |------------------------>| | |------------------------>|
Figure 1: Example Session Timer Flow Figure 1: Example Session Timer Flow
Figure 1 gives an example of a call flow that makes use of the Figure 1 gives an example of a call flow that makes use of the
session timer. In this example, both the UAC and UAS support the session timer. In this example, both the UAC and UAS support the
session timer extension. The initial INVITE request generated by the session timer extension. The initial INVITE request generated by the
UAC, Alice (message 1), might look like: UAC, Alice (message 1), might look like:
INVITE sip:bob@biloxi.example.com SIP/2.0 INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds8 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
Supported: timer Supported: timer
Session-Expires: 50 Session-Expires: 50
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com> To: Bob <sips:bob@biloxi.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774 From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 314159 INVITE CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.example.com> Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 142 Content-Length: 142
(Alice's SDP not shown) (Alice's SDP not shown)
This request indicates that Alice supports the session timer, and is This request indicates that Alice supports the session timer, and is
request session refreshes every 50 seconds. This arrives at the first request session refreshes every 50 seconds. This arrives at the first
proxy, P1. This session interval is below the minimum allowed value proxy, P1. This session interval is below the minimum allowed value
of 3600. So, P1 rejects the request with a 422 (message 2): of 3600. So, P1 rejects the request with a 422 (message 2):
SIP/2.0 422 Session Interval Too Small SIP/2.0 422 Session Interval Too Small
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds8 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
;received=192.0.2.1 ;received=192.0.2.1
Min-SE: 3600 Min-SE: 3600
To: Bob <sip:bob@biloxi.example.com>;tag=9a8kz To: Bob <sips:bob@biloxi.example.com>;tag=9a8kz
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774 From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 314159 INVITE CSeq: 314159 INVITE
This response contains a Min-SE header field with the value of 3600. This response contains a Min-SE header field with the value of 3600.
Alice then retries the request. This time, the request contains a Alice then retries the request. This time, the request contains a
Min-SE header, since Alice has received a 422 for other INVITE Min-SE header, since Alice has received a 422 for other INVITE
requests with the same Call-ID. The new request (message 4) might requests with the same Call-ID. The new request (message 4) might
look like: look like:
INVITE sip:bob@biloxi.example.com SIP/2.0 INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
Supported: timer Supported: timer
Session-Expires: 3600 Session-Expires: 3600
Min-SE: 3600 Min-SE: 3600
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com> To: Bob <sips:bob@biloxi.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774 From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 314160 INVITE CSeq: 314160 INVITE
Contact: <sip:alice@pc33.atlanta.example.com> Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 142 Content-Length: 142
(Alice's SDP not shown) (Alice's SDP not shown)
Proxy P1 record-routes. Since the session interval is now acceptable Proxy P1 record-routes. Since the session interval is now acceptable
to it, it forwards the request to P2 (message 5). However, the to it, it forwards the request to P2 (message 5). However, the
session interval is below its minimum configured amount of 4000. So, session interval is below its minimum configured amount of 4000. So,
it rejects the request with a 422 response code (message 6), and it rejects the request with a 422 response code (message 6), and
includes a Min-SE header field with the value of 4000. Once more, includes a Min-SE header field with the value of 4000. Once more,
Alice retries the INVITE. This time, the Min-SE header field in her Alice retries the INVITE. This time, the Min-SE header field in her
INVITE is the maximum of all Min-SE she has received (3600 and 4000). INVITE is the maximum of all Min-SE she has received (3600 and 4000).
Message 10 might look like: Message 10 might look like:
INVITE sip:bob@biloxi.example.com SIP/2.0 INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds10 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10
Supported: timer Supported: timer
Session-Expires: 4000 Session-Expires: 4000
Min-SE: 4000 Min-SE: 4000
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com> To: Bob <sips:bob@biloxi.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774 From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 314161 INVITE CSeq: 314161 INVITE
Contact: <sip:alice@pc33.atlanta.example.com> Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 142 Content-Length: 142
(Alice's SDP not shown) (Alice's SDP not shown)
P1 record-routes once again, but P2 does not (this wouldn't normally P1 record-routes once again, but P2 does not (this wouldn't normally
happen; presumably, if it asked for session timer, it would happen; presumably, if it asked for session timer, it would
record-route the subsequent request). The UAS receives the request. record-route the subsequent request). The UAS receives the request.
It copies the Session-Expires header from the request to the It copies the Session-Expires header from the request to the
response, and adds a refresher parameter with value 'uac'. This 200 response, and adds a refresher parameter with value 'uac'. This 200
OK is forwarded back to Alice. The response she receives (message 15) OK is forwarded back to Alice. The response she receives (message 15)
might look like: might look like:
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds10 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10
;received=192.0.2.1 ;received=192.0.2.1
Require: timer Require: timer
Supported: timer Supported: timer
Record-Route: sip:p1.atlanta.example.com;lr Record-Route: sips:p1.atlanta.example.com;lr
Session-Expires: 4000;refresher=uac Session-Expires: 4000;refresher=uac
To: Bob <sip:bob@biloxi.example.com>;tag=9as888nd To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774 From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 314161 INVITE CSeq: 314161 INVITE
Contact: <sip:bob@192.0.2.4> Contact: <sips:bob@192.0.2.4>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 142 Content-Length: 142
(Bob's SDP not shown) (Bob's SDP not shown)
Alice generates an ACK (message 16), which is routed through P1 and Alice generates an ACK (message 16), which is routed through P1 and
then to Bob. Since Alice is the refresher, around 3000 seconds later, then to Bob. Since Alice is the refresher, around 3000 seconds later,
Alice sends an UPDATE request to refresh the session. Since this Alice sends an UPDATE request to refresh the session. Since this
request is part of an established dialog, and Alice has not received request is part of an established dialog, and Alice has not received
any 422 responses or requests on that dialog, there is no Min-SE any 422 responses or requests on that dialog, there is no Min-SE
header field in her request (message 18): header field in her request (message 18):
UPDATE sip:bob@192.0.2.4 SIP/2.0 UPDATE sips:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds12 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12
Route: sip:p1.atlanta.example.com;lr Route: sips:p1.atlanta.example.com;lr
Supported: timer Supported: timer
Session-Expires: 4000;refresher=uac Session-Expires: 4000;refresher=uac
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com>;tag=9as888nd To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774 From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 314162 UPDATE CSeq: 314162 UPDATE
Contact: <sip:alice@pc33.atlanta.example.com> Contact: <sips:alice@pc33.atlanta.example.com>
This is forwarded through P1 to Bob. Bob generates a 200 OK, copying This is forwarded through P1 to Bob. Bob generates a 200 OK, copying
the Session-Expires header field into the response. This is forwarded the Session-Expires header field into the response. This is forwarded
through P1, and arrives at Alice. The response she receives (message through P1, and arrives at Alice. The response she receives (message
21) might look like: 21) might look like:
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds12 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12
;received=192.0.2.1 ;received=192.0.2.1
Require: timer Require: timer
Session-Expires: 4000;refresher=uac Session-Expires: 4000;refresher=uac
To: Bob <sip:bob@biloxi.example.com>;tag=9as888nd To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774 From: Alice <sips:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 314162 UPDATE CSeq: 314162 UPDATE
Contact: <sip:bob@192.0.2.4> Contact: <sips:bob@192.0.2.4>
Shortly afterwards, Alice's UA crashes. As a result, she never sends Shortly afterwards, Alice's UA crashes. As a result, she never sends
a session refresh request. 3990 seconds later, Bob gives up, and a session refresh request. 3990 seconds later, Bob gives up, and
sends a BYE request (message 22). This is sent to P1. P1 attempts to sends a BYE request (message 22). This is sent to P1. P1 attempts to
deliver it, but fails (since Alice's UA has crashed). P1 then returns deliver it, but fails (since Alice's UA has crashed). P1 then returns
a 408 (Request Timeout) to Bob. a 408 (Request Timeout) to Bob.
14. Acknowledgements 14. Acknowledgements
The authors wish to thank Brett Tate for his contributions to this The authors wish to thank Brett Tate for his contributions to this
skipping to change at page 34, line 30 skipping to change at page 34, line 30
dynamicsoft dynamicsoft
5100 Tennyson Parkway 5100 Tennyson Parkway
Suite 1200 Suite 1200
Plano, TX 75024 Plano, TX 75024
US US
EMail: sdonovan@dynamicsoft.com EMail: sdonovan@dynamicsoft.com
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
72 Eagle Rock Avenue 600 Lanidex Plaza
East Hanover, NJ 07936 Parsippany, NJ 07054
US US
EMail: jdrosen@dynamicsoft.com EMail: jdrosen@dynamicsoft.com
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 or other rights that might be claimed to intellectual property 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
skipping to change at page 35, line 29 skipping to change at page 35, line 29
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
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 which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). 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
skipping to change at page 36, line 7 skipping to change at page 36, line 7
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 assignees. 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.
Acknowledgment Acknowledgement
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. 

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