Session Initiation Proposal V. Hilt Investigation Working Group Bell Labs/Lucent Technologies Internet-Draft G. Camarillo Expires: January 8, 2005 Ericsson July 10, 2004 Evaluating Scenarios for Session-specific Policies draft-hilt-sipping-policy-scenarios-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 8, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This draft describes detailed call flows for different use cases of session-specific policies. It compares the two approaches that are currently being discussed for session-specific policies, namely the piggyback model and the separate channel model. Hilt & Camarillo Expires January 8, 2005 [Page 1] Internet-Draft Session Policy Scenarios July 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 4 4.1.1 Piggyback Model . . . . . . . . . . . . . . . . . . . 4 4.1.2 Separate Channel Model . . . . . . . . . . . . . . . . 9 4.2 Codec Selection . . . . . . . . . . . . . . . . . . . . . 12 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1 Disclosure of Session Descriptions and Policies . . . . . 13 5.2 UA Support of Policies . . . . . . . . . . . . . . . . . . 13 5.3 Re-Use of Document Formats and Mechanisms . . . . . . . . 13 5.4 Asynchronous Policies . . . . . . . . . . . . . . . . . . 14 5.5 Separation of Tasks . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 16 Hilt & Camarillo Expires January 8, 2005 [Page 2] Internet-Draft Session Policy Scenarios July 2004 1. Introduction The concept of session-specific SIP session policies [3] has been around for some time. However, it has proven that the mechanisms for establishing session-specific policies are non-trivial and most likely require to sacrifice some of the requirements defined in [5]. In this draft, we compare two approaches that have been proposed for session-specific policies: the piggyback model and the separate channel model. We analyze detailed call flows of use cases for both models and discuss advantages and drawbacks of each model. The main purpose of this draft is to spark the discussion about the two models and to come to a conclusion on which if the models is the most appropriate approach for session-specific policies. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, [1] and indicate requirement levels for compliant implementations. 3. Scenario All use cases in the subsequent sections are based on the following scenario (see Figure 1). The user agent UA A is registered at proxy P A, which is responsible for domain A. UA B is registered at P B in domain B. Both domains A and B are separate and they are connected through a transit network. It is assumed that user agent and proxy of each domain have a relationship (e.g. UA A is a customer of provider running domain A). It is also assumed that the entities in different domains do not necessarily have a relationship. This corresponds to a scenario where a customer of one provider is establishing a session with a customer of another provider. As a consequence, entities in one domain can't make any assumptions about the capabilities of entities in the other domain. In particular, it can't be assumed that session policies are supported in the other domain. Additionally, it is assumed that entities in one domain are not willing to disclose network internals such as session policies to the other domain. Hilt & Camarillo Expires January 8, 2005 [Page 3] Internet-Draft Session Policy Scenarios July 2004 : : +---+ : : +---+ /-|P A|-:---------:--|P B|-\ +----+/ +---+ : : +---+ \+----+ |UA A| : : |UA B| +----+ : : +----+ : : Domain A Transit Domain B Network Figure 1 4. Use Cases 4.1 NAT Traversal In this scenario, each domain is connected to the public Internet through a NAT. UA A and UA B have local, non-routable addresses. The proxies P A and P B implement MIDCOM [6] agents an control an associated NAT that connects their domain to the Internet. Session policies are needed to accomplish the following tasks for NAT traversal: o Enable proxies to examine the media addresses and ports in the session description created by its associated UA (can either be an offer or an answer). This information is needed to configure NAT rules for incoming media traffic. o Enable proxies to modify the media addresses and ports in the session description created by its associated UA (offer or answer). The modification is needed to replace the local addresses with globally routable addresses at which the associated UA is reachable from outside. o Enable a proxy to examine the media addresses and ports in the session description created by the remote UA (offer or answer). This information is needed to configure NAT rules for outgoing media traffic. 4.1.1 Piggyback Model In the piggyback model, session policies are piggybacked on the SIP messages used for the corresponding SDP offer/answer exchange. 4.1.1.1 Offer in Request - Alternative 1 The call flow in Figure 2 describes the piggyback model for INVITE Hilt & Camarillo Expires January 8, 2005 [Page 4] Internet-Draft Session Policy Scenarios July 2004 requests carrying a session description offer. This alternative is based on encryption to protect MIOs and MFOs from being inspected by unauthorized network entities (e.g. in the transit network). It corresponds to the piggyback model that has been discussed so far (e.g. in [3]) It is important to note that this alternative still requires that the UAs on both sides support session-specific policies, even if policies are only used in one domain. In other words, to enable the use of policies between UA A and P A in domain A, UA B in domain B also needs to support policies, even if policies are not used in this domain. Furthermore, encryption can only protect policies from being inspected in the transit network. Entities in both domains must be able to inspect the policies of the other domain. UA A P A P B UA B | | | | | INVITE offer | | | |--------------->| | | (1) | 488 | | | | +DiscloseInfoA | | | |<---------------| | | (2) | ACK | | | |--------------->| | | | | | | | INVITE offer | INVITE offer | | | +[MIOAoffer]A | +[MIOAoffer]A | | | | +[MFOAoffer]B | | |--------------->|--------------->| | (3) | 488 | 488 | | | +DiscloseInfoB | +DiscloseInfoB | | |<---------------|<---------------| | (4) | ACK | ACK | | |--------------->|--------------->| | | | | | | INVITE offer | INVITE offer | INVITE offer | | +[MIOAoffer]AB | +[MIOAoffer]AB | +[MIOAoffer]AB | | | +[MFOAoffer]B | +[MFOAoffer]B | | | | +DiscloseInfoB | |--------------->|--------------->|--------------->| (5) | | | | | 183 answer | 183 answer | 183 answer | | +[MIOBanswer]B | +[MIOBanswer]B | +[MIOBanswer]B | | +[MFOBanswer]A | +[MFOBanswer]A | | |<---------------|<---------------|<---------------| (6) | | | | | PRACK | PRACK | PRACK | Hilt & Camarillo Expires January 8, 2005 [Page 5] Internet-Draft Session Policy Scenarios July 2004 | +[MIOAanswer]A | +[MIOAanswer]A | +[MIOAanswer]A | |--------------->|--------------->|--------------->| (7) | OK | OK | OK | |<---------------|<---------------|<---------------| | | | | | OK | OK | OK | |<---------------|<---------------|<---------------| | | | | | ACK | |------------------------------------------------->| | | Figure 2 Steps (1) and (2) are needed if P A detects that UA A does not disclose the required aspects of its session description offer in a Media Interface Object A (MIOAoffer). In this case, P A returns a 488 response that requests the disclosure of these aspects. This steps could be avoided, for example, by providing information about what to disclose as part of the device configuration [4]. In step (3) UA A creates Media Interface Object A (MIOAoffer) that discloses the IP addresses and ports it has used in the offer. UA A encrypts MIOAoffer with a key known to P A ([MIOAoffer]A). P A can now perform its MIDCOM functionalities based on the data in MIOAoffer and creates a Media Filter Object for MIOAoffer (MFOAoffer), which contains the external addresses and ports UA B must use to reach UA A. P A encrypts MFOAoffer with a key known to UA B. In step (4) P B returns a 488 response and asks UA A to disclose the addresses and ports used in the offer. It also asks P A to disclose all policies that affect the addresses and ports in the offer, since these are the addresses and ports that will later be used in the session. Step (5) is analogous to step (3) except that MIOAoffer and MFOAoffer are now encrypted with a keys known to P B and UA B. Finally, P B asks UA B to disclose the addresses and ports it is going to use in the answer. In step (6) UA B has accepted the policies contained in MFOAoffer. It creates a 183 response with its session description answer and a MIOBanswer containing the local IP addresses and ports. UA B encrypts MIOBanswer with a key known to P B. The use of a 183 response instead of a 200 OK later enables UA A to cancel the INVITE transaction if it decides not to accept the requested policies before the INVITE transaction is completed. Hilt & Camarillo Expires January 8, 2005 [Page 6] Internet-Draft Session Policy Scenarios July 2004 P B examines the addresses and ports in MIOBanswer and inserts MFOBanswer containing the external addresses and ports to be used with the session description answer. It encrypts MFOBanswer with a key known to UA A. In step (7) UA A accepts the policies in MFOBanswer and creates a PRACK. It inserts a MIOAanswer, which contains the addresses and ports it is using to send media to UA B. UA A encrypts MIOAanswer with a key known to P A. Since P A has no policies for the answer, no additional MFOs are needed. 4.1.1.2 Offer in Request - Alternative 2 The call flow in Figure 3 also piggybacks policy information on messages exchanged within a SIP INVITE transaction. In this call flow, these messages are used to exchange policies between UA and proxy. The flow ensures that policy information does not leave the local domain by rejecting messages and removing policy headers. UA A P A P B UA B | | | | | INVITE offer | | | |--------------->| | | (1) | 488 | | | | +DiscloseInfoA | | | |<---------------| | | (2) | ACK | | | |--------------->| | | | | | | | INVITE offer | | | | +MIOAoffer | | | |--------------->| | | (3) | 488 | | | | +MFOAoffer | | | |<---------------| | | (4) | ACK | | | |--------------->| | | | | | | | INVITE offer | INVITE offer | INVITE offer | | | | +DiscloseInfoB | |--------------->|--------------->|--------------->| (5) | | | | | 183 answer | 183 answer | 183 answer | | | | +MIOBoffer | | | | +MIOBanswer | |<---------------|<---------------|<---------------| (6) | | | | Hilt & Camarillo Expires January 8, 2005 [Page 7] Internet-Draft Session Policy Scenarios July 2004 | PRACK | PRACK | PRACK | | +MIOAanswer | | | | | | +MFOBanswer | |--------------->|--------------->|--------------->| (7) | OK | OK | OK | |<---------------|<---------------|<---------------| | | | | | UPDATE offer | UPDATE offer | UPDATE offer | |<---------------|<---------------|<---------------| (8) | | | | | OK answer | OK answer | OK answer | | +MIOAanswer | | | |--------------->|--------------->|--------------->| (9) | | | | | OK | OK | OK | |<---------------|<---------------|<---------------| | | | | | ACK | |------------------------------------------------->| | | Figure 3 The basic idea of exchanging MIOs and MFOs is the same as in the above flow. Steps (1) - (3) are identical. In step (4) P A returns a MFOAoffer containing the modified addresses and ports for the offer to UA A. UA A can now apply these policies and create a new offer in step (5). In step (5) P B also requests the disclosure of the addresses used in the offer and answer and receives them from UA B in step (6). Since UA B has not received policies from P B yet, the answer in step (6) is a dummy answer that needs to be updated later. In step (7) UA A creates a PRACK containing a MIOAanswer which is still based on the dummy answer. P B uses this PRACK message to transmit the addresses and ports it wants UA B to use in its session description to UA B. To make these addresses and ports known to UA A, UA B creates an new offer and sends an UPDATE in step (8) to which UA A responds in step (9). UA A also creates a new MIOAanswer for P A that is now based on the actual session description used in the session. 4.1.1.3 Offer in Response The piggyback model call flows for INVITEs that carry the session description offer in the response are analogous to the above call Hilt & Camarillo Expires January 8, 2005 [Page 8] Internet-Draft Session Policy Scenarios July 2004 flows. However, these flow are generally more complex that the flows described above for the offer in request scenario. 4.1.2 Separate Channel Model The idea behind the Separate Channel Model is that user agents retrieve session-specific policies through a separate channel before they create the session description offer/answer. The channel can be implemented in different ways, based on SIP or on another protocol. In this document we simply make the assumption that this channel enables a UA to send a MIO to the policy server and to retrieve a MFO as a response. 4.1.2.1 Offer in Request The call flow in Figure 4 depicts the separate channel model for INVITE requests carrying a session description offer. PS A and PS B are the policy servers in the respective domains. They can be co-located with the proxies P A and P B but do not have to be. UA A P A P B UA B | | | | | INVITE offer | | | |--------------->| | | (1) | 488 | | | | + DiscloseInfA | | | |<---------------| | | (2) | ACK | | | |--------------->| | | | | PS A | | | Sep.Channel | | | | + MIOAoffer | | | |------------------>| | | (3) | Sep.Channel | | | | + MFOAoffer | | | |<------------------| | | (4) | | | | | | | | | INVITE offer | INVITE offer | INVITE offer | | | | + DiscloseInfB | |--------------->|--------------->|--------------->| (5) | | | | | | PS B | | | | | | | | | Sep.Channel | | | | + MIOBoffer | | | | + MIOBanswer | Hilt & Camarillo Expires January 8, 2005 [Page 9] Internet-Draft Session Policy Scenarios July 2004 | | |<------------------| (6) | | | Sep.Channel | | | | + MFOBanswer | | | |------------------>| (7) | | | | | | | | | OK answer | OK answer | OK answer | |<---------------|<---------------|<---------------| (8) | ACK | |------------------------------------------------->| | | | | | Sep.Channel | | | | + MIOAanswer | | | |------------------>| | | (9) | | | | | | | | Figure 4 Steps (1) and (2) are needed if P A detects that UA A has not requested policies for the current session before creating the SDP offer. In this case, P A returns a 488 response that contains the address to which UA A should establish a channel to and information about what should be disclosed in an MIO. These steps can be avoided, for example, by providing the information about what to disclosure to where as part of the device configuration. In step (3) UA A establishes a channel to PS A and submits a MIOAoffer in which it reveals the addresses and ports it is going to use in the offer. PS A uses this information in its function as MIDCOM agent and returns the addresses and ports UA A should include in its offer in an MFOAoffer in step (4). In step (5) UA A decides to accept the policies in MFOAoffer and creates the offer using the given addresses and ports. P B inserts disclosure information for UA B into this message. Before creating an answer, UA B retrieves the policies that apply to this session by establishing a channel to its policy server in step (6). It submits the addresses and ports from the offer in MIOBoffer and the addresses and ports it is going to use in its answer in MIOBanswer. PS B returns the addresses and ports to be used in the answer in MFOBanswer in step (7). If UA B decides to accept these policies, it creates an answer in step (8). If not, UA B can return a final response rejecting the INVITE. In step (9), UA A submits MIOAanswer to the local policy server Hilt & Camarillo Expires January 8, 2005 [Page 10] Internet-Draft Session Policy Scenarios July 2004 disclosing the addresses and ports received in the answer from UA B. 4.1.2.2 Offer in Response The call flow for an INVITE carrying the offer in the response is depicted in Figure 5. In contrast to call flow Figure 4, UA A has to wait until it receives an offer from UA B before it can retrieve the policies for the current session. UA A P/M A P/M B UA B | | | | | INVITE | INVITE | INVITE | | | | + DiscloseInfB | |--------------->|--------------->|--------------->| (1) | | | | | | PS B | | | | | Sep.Channel | | | | + MIOBoffer | | | |<------------------| (2) | | | Sep.Chanel | | | | + MFOBoffer | | | |------------------>| (3) | | | | | | | | | 183 offer | 183 offer | 183 offer | | + DiscloseInfA | | | |<---------------|<---------------|<---------------| (4) | PRACK answer | |------------------------------------------------->| (5) | OK | |<-------------------------------------------------| | | | | | | PS A | | | Sep.Channel | | | | + MIOAoffer | | | | + MIOAanswer | | | |------------------>| | | (6) | Sep.Channel | | | | + MFOAanswer | | | |<------------------| | | (7) | | | | | | | | | UPDATE offer' | |------------------------------------------------->| (8) | OK answer' | |<-------------------------------------------------| | | | | Hilt & Camarillo Expires January 8, 2005 [Page 11] Internet-Draft Session Policy Scenarios July 2004 | | | | | | | Sep.Channel | | | | + MIOBanswer | | | |<------------------| (9) | | | | | | | | | OK | OK | OK | |<---------------|<---------------|<---------------| | ACK | |------------------------------------------------->| | | Figure 5 After receiving the 183 response in step (4), UA A must respond immediately with a PRACK to avoid the expiration of timer T1 in UA B and the retransmission of the 183. UA A therefore creates a PRACK with an answer that does not yet consider session-specific policies. It then retrieves the policies for the current session in steps (6) and (7) in which it gets the external addresses and ports from PS A in MFOAanswer. It creates a new offer and sends it to UA B in the UPDATE shown in step (7). ISSUE: If it can be assumed that UA A and the policy server are located in the same network, there might be enough time for UA A to retrieve policies before generating the PRACK. The sequence of steps would then be (1)-(3),(5)-(6),(4) without a need for the UPDATE in step (7). Is this a reasonable assumption? 4.2 Codec Selection In this scenario, session-specific policies are used to limit the set of codecs a UA can use. By using session-specific policies, a network provider does not need to reveal the list of allowed codecs to the UA. Instead it can limit the use of certain codecs only if endpoints announce them in an SDP description. Session policies are needed to accomplish the following tasks for codec selection: o Enable a proxy to examine the codecs listed in the session description offer (independent of whether the offer was created by the local or the remote UA). o Enable proxies to remove codecs from the offer (independent of whether the offer was created by the local or the remote UA). The call flows for both models are analogous to the NAT scenario, Hilt & Camarillo Expires January 8, 2005 [Page 12] Internet-Draft Session Policy Scenarios July 2004 with the difference that the policy servers do not not provide policies for the answer. Instead, they both provide policies for the session description offer. Also, MIOs contain lists of codecs and MFOs identify those codecs that should not be used. 5. Discussion 5.1 Disclosure of Session Descriptions and Policies In the piggyback model (alternative 1), all MIOs and MFOs travel through the network. End-to-middle and middle-to-end encryption can be used to prevent unauthorized network entities from examining them. However, even with encryption, UAs need to disclose MIOs to all policy-enabled proxies even if they are located in remote networks. Moreover, proxies must disclose their policies to UAs in remote networks and to other proxies that are interested in examining or modifying the same aspect of a session description. In the piggyback model (alternative 2), the MIOs and MFOs are piggybacked on messaged which are destined at entities outside of the local network. By rejecting messages and removing headers, the proxies keep the MIOs and MFOs within the local network. End-to-middle and middle-to-end encryption can be used to further protect the MIOs and MFOs so that they can't be examined by unauthorized entities even if these packets accidentally leave the local network. In the separate channel model, UAs exchange MIOs and MFOs on a separate channel directly with the policy server. UAs can therefore disclose different aspects of a session description to each server. Each server can return policies directly to the UA. End-to-end encryption can be used to secure these transmissions. If UA and the policy server are in the same network, the MIOs and MFOs never exit that network. 5.2 UA Support of Policies In the piggyback model (alternative 1) both UAs need to support policies, even if they are only used in one of the domains. In the piggyback model (alternative 2) and the separate channel model, it is sufficient if one of the UAs supports policies. 5.3 Re-Use of Document Formats and Mechanisms The piggyback model (both alternatives) requires that proxy servers insert MFOs into SIP messages. The current standards require the use of headers for this purpose, since a proxy is not allowed to add body Hilt & Camarillo Expires January 8, 2005 [Page 13] Internet-Draft Session Policy Scenarios July 2004 elements to a message. As a consequence, standard document formats that could be used in MIME bodies can't be used for MFOs in the piggyback model. In addition, S/MIME encryption doesn't apply. In the separate channel model, MIOs and MFOs are exchanged over a separate channel which is potentially able to carry arbitrary documents. This enables the use of existing document formats for MIOs and MFOs and the use of encryption. In particular, the document formats that are defined for session-independent policies [2] can be re-used for session-specific policies. This greatly simplifies UAs which support both types of policies. 5.4 Asynchronous Policies Some scenarios require that a policy server can update the session policies at any time for ongoing sessions. In the piggyback model (both alternatives), the exchange of policies is tied to UA initiated offer/answer exchanges of session descriptions (i.e. INVITE, re-INVITE or UPDATE). For this reason, a proxy can't introduce new policies at arbitrary times during a session. In the separate channel model, the policy server can send updates for the current policy at any time, independent of messages exchanged between the UAs. 5.5 Separation of Tasks It is generally desirable to develop separate solutions for different tasks. In the piggyback model (both alternatives), the task of exchanging MIOs and MFOs between UA and policy server is coupled to the task of exchanging the offer/answer between UAC and UAS. This increases the complexity of call flows, in particular if the transmission of MIO/MFOs is spread across different SIP transactions, and leads lower re-usability of solutions for each task. The separate channel model provides a clear separation of tasks. 6 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Hilt, V., Camarillo, G. and J. Rosenberg, "Session-Independent Policies for the Session Initiation Protocol (SIP)", draft-hilt-sipping-session-indep-policy-01 (work in progress), May 2004. Hilt & Camarillo Expires January 8, 2005 [Page 14] Internet-Draft Session Policy Scenarios July 2004 [3] Hilt, V. and J. Rosenberg, "A Framework for Session-Specific Intermediary Session Policies in SIP", draft-hilt-sipping-session-spec-policy-00 (work in progress), September 2003. [4] Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-03 (work in progress), May 2004. [5] Rosenberg, J., "Requirements for Session Policy for the Session Initiation Protocol (SIP)", draft-ietf-sipping-session-policy-req-01 (work in progress), February 2004. [6] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. Authors' Addresses Volker Hilt Bell Labs/Lucent Technologies 101 Crawfords Corner Rd Holmdel, NJ 07733 USA EMail: volkerh@bell-labs.com Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Appendix A. Acknowledgements Many thanks to Jonathan Rosenberg and Allison Mankin. Hilt & Camarillo Expires January 8, 2005 [Page 15] Internet-Draft Session Policy Scenarios July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-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 (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hilt & Camarillo Expires January 8, 2005 [Page 16]