SIPPING Working Group V. Hilt Internet-Draft Bell Labs/Lucent Technologies Expires: August 15, 2005 G. Camarillo Ericsson J. Rosenberg Cisco Systems February 11, 2005 A Delivery Mechanism for Session-Specific Session Initiation Protocol (SIP) Session Policies draft-hilt-sipping-session-spec-policy-02 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any 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 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 August 15, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This specification defines a delivery mechanism for session-specific Session Initiation Protocol (SIP) sessions policies. Hilt, et al. Expires August 15, 2005 [Page 1] Internet-Draft Session-Specific Policies February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 4.1 Offer in Request . . . . . . . . . . . . . . . . . . . . . 7 4.2 Offer in Response . . . . . . . . . . . . . . . . . . . . 8 5. Distributing Policy Server URIs . . . . . . . . . . . . . . . 10 5.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 10 5.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 11 5.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 12 5.4 Header Definition and Syntax . . . . . . . . . . . . . . . 12 6. Policy Channel . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Updating Policies . . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 17 Hilt, et al. Expires August 15, 2005 [Page 2] Internet-Draft Session-Specific Policies February 2005 1. Introduction Some domains have policies in place, which impact the sessions established using the Session Initiation Protocol (SIP). These policies are often needed to support the network infrastructure or for the execution of services. For example, wireless networks usually have limited resources for media traffic. During periods of high activity, a wireless network provider may want to restrict codec usage on the network to lower rate codecs or disallow the use of high bandwidth media types such as video. In another example, a SIP user agent is using a network which connects to the public Internet through a firewall or a network border device. The provider would like to tell the user agent to direct the media streams to the appropriate IP addresses and ports of that firewall or border device. Knowing this policy enables the user agent to setup sessions with other user agents across the firewall or the network border. In a third example, a domain A has a limited bandwidth pipe to another domain B. The pipe is realized through two routers that are managed. Domain A would like to direct each call to one of the routers based on their capacity. With session policies, the domain can inform the user agent about the route with the most capacity available. Domains sometimes enforce policies they have in place. For example, a domain might have a configuration in which all packets containing a certain audio codec are dropped. Unfortunately, enforcement mechanisms usually do not inform the user about the policies they are enforcing and silently keep the user from doing anything against them. This may lead to the malfunctioning of devices that is incomprehensible to the user. With session policies, the user knows about the restricted codecs and can use a different codec or simply connect to a domain with less stringent policies. Session policies provide an important combination of consent coupled with enforcement. That is, the user becomes aware of the policy and needs to act on it, but the provider still retains the right to enforce the policy. Session-policies can be set up in two different ways: specifically for a session or independent of a session. Session-specific policies are created for one particular session, usually under consideration of certain aspects of this session (e.g. the IP addresses and ports that are used for media). Since session-specific policies are tailored to a session, they only apply to the session they are created for. These policies require a delivery mechanism that enables the exchange of session policy information at the time a session is established. This document defines a delivery mechanism Hilt, et al. Expires August 15, 2005 [Page 3] Internet-Draft Session-Specific Policies February 2005 for session-specific session policies. It enables user agents to submit session details to a policy server and allows the policy server to provide policies for this session in response. Session-independent policies on the other hand are independent of a specific session and generally apply to the sessions set up by a user agent. An example is a policy which prohibits the use of high-bandwidth codecs. In principle, these policies could also be delivered to user agents individually for each session, using the session-specific policy framework. However, since these policies apply to many sessions, it is more efficient to deliver them to user agents only when the user agent is initialized or a policy changes. The framework for session-independent policies [4] defines a delivery mechanism for session-independent policies. It also defines the Basic Session Policy Format (BSPF), which is a minimal session policy format aimed at achieving interoperability between different user agents and policy servers. The BSPF format is independent of the policy delivery mechanism and can be used for session-independent as well as 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, RFC 2119 [1] and indicate requirement levels for compliant implementations. 3. Architecture +-------------+ /------| Proxy |----... +----+ / +-------------+ | |---/ +-------------+ | | | Policy | | UA |============| Server | | | +-------------+ | |**** +-------------+ +----+ * | Router w/ | *******| Policy |****... | Enforcement | +-------------+ --- SIP Signaling === Policy Channel *** Media Figure 1 Hilt, et al. Expires August 15, 2005 [Page 4] Internet-Draft Session-Specific Policies February 2005 The mechanism defined in this specification enables the creation and delivery of session-specific SIP session policies. The following entities are involved in setting up session-specific policies (see Figure 1): a user agent (UA), a proxy, a policy server and possibly a router with policy enforcement functionality. The proxy's role is to provide a rendezvous mechanism for user agent and policy server. It conveys the URI of the policy server in its domain to a user agent and therefore ensures that user agents know where to retrieve policies from. It does not deliver the actual policies to user agents. The policy server is a separate logical entity that may be physically co-located with the proxy. Each domain has at most one policy server. The role of the policy server is to receive session information from the user agent, to generate a session policy for that session and to deliver the policy back to the user agent. The way policies are generated is outside the scope of this specification. A policy server could, for example, use local rules, query external sources for more information or retrieve policies from a policy infrastructure. A user agent receives the URI of a policy server from the proxy. It uses this URI to establish a channel to the policy server. It provides information about the current session to the policy server and receives session policies in response. The policy server can also send updated policies to the user agent over this channel during the course of a session. A network may have a policy enforcement infrastructure in place. This specification does not make any assumptions about the presence of an enforcement infrastructure. It is orthogonal to an enforcement system. It defines a mechanism that enables a user agent to convey session information to a policy server and to retrieve session policies in response. The protocol defined in this specification follows a separate channel model. I.e. SIP signaling is only used to rendezvous the user agent with the policy server. From this point on, user agent and policy server communicate directly with each other over a separate policy channel. This is opposed to a piggyback model, where session information is extracted from and policy information is piggybacked onto SIP signaling messages. A disadvantage of the separate channel model is that it requires additional messages and adds delay for the exchange of policy information. The advantages of using a separate policy channel are that it provides a distinction between the signaling messages flowing Hilt, et al. Expires August 15, 2005 [Page 5] Internet-Draft Session-Specific Policies February 2005 from one endpoint through the network to the other endpoint and the exchange of policy information between an endpoint and a policy server in the network. This distinction enables the use of cryptographic mechanisms on the signaling path between the endpoints as well as on the policy channel between an endpoint and the policy server. Existing schemes for authorization, authentication, signing and encryption can be used to secure the exchange of session policies as well as the signaling flow. This is not possible if policies are piggybacked onto the signaling messages. Another advantage of the separate channel model is that policies are not sent across the network along the signaling path. If policy server and user agent are in the same network, policy information never leaves this network. In addition, endpoints can specifically decide which aspects of a session they want to disclose to a certain policy server. Finally, a policy server does not rely on SIP signaling messages flowing by to provide session policies to an endpoint. A policy server can use the separate channel to update session policies at any time the policies need to be adjusted. The communication on the policy channel between a user agent and a policy server involves two main operations: 1. The UA discloses information about the current session and the offer/answer exchange to the policy server. 2. The policy server sends policy instructions to the UA. Some types of policies do not involve sending policy instructions, but only information disclosure. Still, a general session-specific policy mechanism needs to support both operations. The same way, some policy servers only need to inspect the offer, but not the answer. Nevertheless, a general mechanism needs to consider policy servers which need to inspect both. Finally, some policy servers need to update the session policies that have been sent to a user agent. Again, a general mechanism should provide this capability. 4. Overview of Operation The section provides example call flows to illustrate the establishment of session policies. It does not contain a normative protocol definition. In this scenario, there are two domains (domain A and domain B), which both have session-specific policies for the UAs in their domain. Both domains do not provide policies to UAs outside of their domain. The two domains have a proxy (P A and P B) and a policy Hilt, et al. Expires August 15, 2005 [Page 6] Internet-Draft Session-Specific Policies February 2005 server (PS A and PS B). The policies in both domains involve the session description offer and answer. 4.1 Offer in Request The first call flow depicts an INVITE transaction with the offer in the request. It is assumed that UAC does not have previous knowledge about the policy server in its domain. (1) UA A creates an INVITE that is routed to proxy P A. P A knows that policies apply to this session and (2) returns a 488 to UA A, which contains the URI of PS A. (3) UA A contacts PS A, discloses the session description offer to PS A and (4) receives policies for the offer. (5) UA A reformulates the INVITE request under consideration of the received policies and includes a Policy-Id header to indicates that it has already contacted PS A. P A does not reject the INVITE this time and removes the Policy-Id header when forwarding the INVITE. P B adds a Policy-Contact header containing the URI of PS B. (6) UA B uses this URI to contact PS B. It discloses the offer and the answer it is about to return and (7) receives policies for the offer and answer. (8) UA B applies these policies and returns the answer in the 200 OK. (9) UA A contacts PS A with the answer and (10) retrieves policies from PS A. UA A P A P B UA B | | | | | INVITE offer | | | |---------------->| | | (1) | 488 | | | | + Policy-Contact| | | |<----------------| | | (2) | ACK | | | |---------------->| | | | | PS A | | | | | | | PolicyChannel | | | | + InfoOffer | | | |------------------->| | | (3) | PolicyChannel | | | | + PolicyOffer | | | |<-------------------| | | (4) | | | | | | | | | INVITE offer' | INVITE offer' | INVITE offer | | + Policy-Id | | + Policy-Contact| |---------------->|--------------->|---------------->| (5) | | | | | | PS B | | Hilt, et al. Expires August 15, 2005 [Page 7] Internet-Draft Session-Specific Policies February 2005 | | | | | | | PolicyChannel | | | | + InfoOffer | | | | + InfoAnswer | | | |<-------------------| (6) | | | PolicyChannel | | | | + PolicyOffer | | | | + PolicyAnswer | | | |------------------->| (7) | | | | | | | | | OK answer | OK answer | OK answer | |<----------------|<---------------|<----------------| (8) | ACK | |--------------------------------------------------->| | | | | | | | | | PolicyChannel | | | | + InfoAnswer | | | |------------------->| | | (9) | PolicyChannel | | | | + PolicyAnswer | | | |<-------------------| | | (10) | | | | Figure 2 4.2 Offer in Response This call flow depicts an INVITE transaction with the offer in the response. The steps (1) - (8) in this call flow are analogous to steps (1) - (8) in the above flow. An important difference is that in steps (9) and (10) UA A contacts PS A after receiving an offer in the 200 OK and before returning the answer in step (11). This is discussed in more detail in the sections below. UA A P A P B UA B | | | | | INVITE | | | |---------------->| | | (1) | 488 | | | | + Policy-Contact| | | |<----------------| | | (2) | ACK | | | |---------------->| | | Hilt, et al. Expires August 15, 2005 [Page 8] Internet-Draft Session-Specific Policies February 2005 | | PS A | | | | | | | PolicyChannel | | | |------------------->| | | (3) | PolicyChannel | | | |<-------------------| | | (4) | | | | | | | | | INVITE | INVITE | INVITE | | + Policy-Id | | + Policy-Contact| |---------------->|--------------->|---------------->| (5) | | | | | | PS B | | | | | | | | | PolicyChannel | | | | + InfoOffer | | | |<-------------------| (6) | | | PolicyChannel | | | | + PolicyOffer | | | |------------------->| (7) | | | | | | | | | OK offer | OK offer | OK offer | |<----------------|<---------------|<----------------| (8) | | | | | | | | | PolicyChannel | | | | + InfoOffer | | | | + InfoAnswer | | | |------------------->| | | (9) | PolicyChannel | | | | + PolicyOffer | | | | + PolicyAnswer | | | |<-------------------| | | (10) | | | | | ACK answer | |--------------------------------------------------->| (11) | | | | | | | | | | | PolicyChannel | | | | + InfoAnswer | | | |<-------------------| (12) | | | PolicyChannel | | | | + PolicyAnswer | | | |------------------->| (13) | | | | Figure 3 Hilt, et al. Expires August 15, 2005 [Page 9] Internet-Draft Session-Specific Policies February 2005 5. Distributing Policy Server URIs The first step in setting up session policies is to rendezvous the UAs with the relevant policy servers. 5.1 UAC Behavior When a UA compliant to this specification generates an INVITE or UPDATE request, it MUST include the Supported header field with the option tag "policy" in the request. A UAC may receive a 488, which contains a Policy-Contact header, in response to an INVITE or UPDATE request. The Policy-Contact header contains the URI of a policy server the UAC SHOULD contact and retrieve session policies for the current request. If the UAC decides to accept the received policies, it SHOULD apply them to the request and resend the modified request. If the UAC has received multiple 488 responses for the same request, it MUST process the policy server URIs in the order in which the 488 responses were received. The UAC should contact the first policy server and apply the received policies before contacting the next server and so on. When the UAC discloses session information to a policy server, it MUST use the most recent session information that considers all policies that have been applied so far. This ensures that policy servers are contacted in the order in which the request travels through the proxies. The order in which policy servers are contacted and session policies are applied to a session is significant for the final result of the policy process. For example, a policy for NAT traversal requires that the policy server can examine the IP address on which the media stream will be sent/received in the previous domain. The UAC MUST insert a Policy-Id header into the INVITE and UPDATE requests it is generating. The UAC MUST add the URIs of all policy servers it has contacted for the current request to the Policy-Id header. This enables a proxy to determine whether the UAC knows the policy server in its domain or whether the policy server URI needs to be conveyed to the UAC. If no policy server has been contacted for a request, the UAC SHOULD NOT include a Policy-Id header. The syntax of the Policy-Id header field is defined in Section 5.4. Depending on the policy, the UAC may need to contact the policy servers when receiving an answer (or a offer in case the original request did not contain a session description) from the UAS. The UAC MUST contact the same policy servers it has used for the request. If the response is for an INVITE request that contained an offer (i.e. the response contains an answer), the UAC MUST first send the ACK (or Hilt, et al. Expires August 15, 2005 [Page 10] Internet-Draft Session-Specific Policies February 2005 PRACK) and then contact the policy servers. If the response is for an INVITE request without a session description (i.e. the response contains an offer), the UAC MUST first contact the policy servers then send the ACK (or PRACK). The answer included in the ACK (or PRACK) MUST be based on the received policies. It is important that the policy server responds immediately to these requests in order to minimize the time between receiving the response and sending the ACK (or PRACK) (see Section 6). This flow is analogous to call flow I defined in [7]. A UA SHOULD cache the URI of the policy server in the local domain. It receives this URI in a 488 from the local proxy after sending out the first INVITE request. The UAC SHOULD use the cached policy server URI to retrieve session policies before sending a new INVITE request outside of a dialog. Caching the local policy server URI avoids the retransmission of this URI for each out-of-dialog INVITE request. The UAC SHOULD NOT cache policy server URIs it receives from proxies outside of the local domain since these servers may not be relevant for subsequent sessions. A new session might traverse different networks and have a different destination. Some domains have policy servers which do not need to be involved in all sessions a UAC sets up or which may change on a session-by-session basis. A proxy can mark the URI of such a policy server as "non-cacheable". The UA SHOULD NOT cache a non-cacheable policy server URI and SHOULD remove the current URI from its cache when receiving such a URI. For each INVITE-initiated dialog, the UAC SHOULD maintain the list of policy server URIs that were used to construct the INVITE which established the dialog. The UAC SHOULD keep this list of policy server URIs until the dialog is terminated. The UAC SHOULD contact the stored policy server URIs before sending an INVITE or UPDATE request within that dialog. This avoids the transmission of policy server URIs for mid-dialog requests. Contacting policy servers for mid-dialog INVITE and UPDATE requests is needed so that the policy servers can keep track of the current session description and provide updated policies. 5.2 UAS Behavior If an incoming INVITE or UPDATE request includes a Policy-Contact header containing a list of policy server URIs, the UAS SHOULD use these URIs to retrieve session policies. The UAS MUST use the policy server URIs in the order they were contained in the Policy-Contact header, starting with the topmost value. Hilt, et al. Expires August 15, 2005 [Page 11] Internet-Draft Session-Specific Policies February 2005 If the UAS receives an ACK with a session description answer, it may need to contact the policy servers again depending on the policy type. In this case, it MUST contact the same policy servers it has contacted after receiving the corresponding INVITE request. 5.3 Proxy Behavior A proxy may provide the contact URI of the local policy server to the UAC or the UAS when processing an INVITE or UPDATE request. If an INVITE or UPDATE request contains a Supported header field with the option tag "policy", the proxy MAY reject the request with a 488 response to provide a policy server URI to the UAC. If the request contains a Policy-Id header field, the proxy MUST determine if this field includes the URI of the local policy server. If this URI is not present or if the Policy-Id header field is missing, the proxy MAY reject the request with a 488. The proxy MUST include a Policy-Contact header in the 488 with the URI of the local policy server as the value. The proxy MAY add the header field parameter "non-cacheable" to avoid that this policy server URI is cached by the UAC. If an INVITE or UPDATE request has a Policy-Id header field which does contain the URI of the local policy server, the proxy SHOULD remove this URI from the Policy-Id header field before forwarding the request. The proxy MAY insert a Policy-Contact header field into an INVITE or UPDATE request that is forwarded in order to provide the policy server URI to the UAS. If the request already contains a Policy-Contact header field, the proxy MUST insert the URI ahead of all existing values at the beginning of the list. A proxy MUST NOT change the order of existing Policy-Contact header values. 5.4 Header Definition and Syntax The Policy-Id header field is inserted into an INVITE or UPDATE request by the UAC. It identifies all policy servers the UAC has contacted for the request. A Policy-Id header value is the URI of a policy server. The syntax of the Policy-Id header field is: Policy-Id = "Policy-Id" HCOLON absoluteURI *(COMMA absoluteURI) The Policy-Contact header field can be inserted into INVITE and UPDATE requests by a proxy. It contains an ordered list of policy Hilt, et al. Expires August 15, 2005 [Page 12] Internet-Draft Session-Specific Policies February 2005 server URIs that need to be contacted by the UAS. The UAS starts to process the header field at the topmost value of this list. New header field values are inserted at the top. The Policy-Contact header field effectively forms a stack. The "non-cacheable" header field parameter MUST NOT be inserted into a request. The Policy-Contact header field can also be inserted into a 488 response to an INVITE or UPDATE request by a proxy. It contains a policy server URI that needs to be contacted by the UAC. A proxy MAY add the "non-cacheable" header field parameter to indicate that the UAC should not cache the policy server URI. The syntax of the Policy-Contact header field is: Policy-Contact = "Policy-Contact" HCOLON policyURI *(COMMA policyURI) policyURI = absoluteURI [ SEMI "non-cacheable" ] The BNF for absoluteURI is defined in [8]. Table 1 is an extension of Tables 2 and 3 in [8]. The column 'UPD' is for the UPDATE method [6]. Header field where proxy ACK BYE CAN INV OPT REG UPD _______________________________________________________________ Policy-Id R rd - - - o - - o Policy-Contact R a - - - o - - o Policy-Contact 488 a - - - o - - o Table 1: Policy-Id and Policy-Contact Header Fields Figure 6 6. Policy Channel A UA and policy server compliant with this specification MUST use the mechanism defined in this section for the policy channel. OPEN ISSUE: Which protocol should be used on the policy channel. The following protocols are potential candidates: 1. SIP SUBSCRIBE/NOTFY: the UA sends a SUBSCRIBE to the session policy server using the URI it has received from the proxy. The UA provides the session description as filter criteria in the SUBSCRIBE request. The NOTIFY messages contain the policies that apply to the described session. Policies can be updated at any time by sending additional NOTIFY messages. Hilt, et al. Expires August 15, 2005 [Page 13] Internet-Draft Session-Specific Policies February 2005 2. HTTP: the UA sends a HTTP request to the policy server using the URI received from the proxy. The body of the HTTP request contains the session description. The policy server responds with the policies that apply to this session. The policy server can not send policy updates to the user agent. 3. COPS: the UA takes the role of a COPS policy enforcement point and submits policy requests to the policy server. The policy server has the role of a COPS policy decision point and returns policies to the UA. Policies can be updated at any time by the policy server. 4. BEEP: the UA establishes a BEEP channel to the policy server using a session policy BEEP profile. The UA sends the session description to the policy server and receives policies through this channel. Policies can be updated at any time by the policy server. OPEN ISSUE: Do we want to specify a default protocol for the policy channel and allow the use of other protocols (e.g. depending on the URI received from the proxy). Or should there be only one protocol that must be used by everybody. 7. Updating Policies A UA may receive policy updates through a policy channel. The UA SHOULD apply these policies to the current session. It MUST generate a re-INVITE or UPDATE request if the updated policies modify aspects of the session that need to be communicated to the peer UA. 8. Security Considerations In particular authentication and authorization are critical issues that need to be addressed here. [TBD.] 9. IANA Considerations [TBD.] 10. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [3] Handley, M. and V. Jacobson, "SDP: Session Description Hilt, et al. Expires August 15, 2005 [Page 14] Internet-Draft Session-Specific Policies February 2005 Protocol", RFC 2327, April 1998. [4] Hilt, V., Camarillo, G. and J. Rosenberg, "Session-Independent Session Initiation Protocol (SIP) Policies - Profile Data and Mechanisms", Internet-Draft draft-ietf-sipping-session-indep-policy-01, October 2004. [5] Rosenberg, J., "Requirements for Session Policy for the Session Initiation Protocol (SIP)", Internet-Draft draft-ietf-sipping-session-policy-req-02, July 2004. [6] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [7] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004. [8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 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 Hilt, et al. Expires August 15, 2005 [Page 15] Internet-Draft Session-Specific Policies February 2005 Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 USA Email: jdrosen@cisco.com Appendix A. Acknowledgements Many thanks to Allison Mankin for the discussions and the suggestions for this draft. Hilt, et al. Expires August 15, 2005 [Page 16] Internet-Draft Session-Specific Policies February 2005 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 procedures with respect to rights in RFC 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 (2005). 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, et al. Expires August 15, 2005 [Page 17]