SPEERMINT WG J. Elwell Internet-Draft Siemens Enterprise Communications Intended status: Informational Limited Expires: August 20, 2007 B. Rodrig Avaya February 16, 2007 Use cases for Enterprise Peering using the Session Initiation Protocol (SIP) draft-elwell-speermint-enterprise-usecases-00.txt Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 20, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Work in the SPEERMINT Working Group has focused to some extent on peering between carrier VoIP Service Providers (VSP). This draft describes some use cases involving SIP peering between enterprise VSPs, with and without the involvement of carrier VSPs, and also peering between enterprise VSPs and carrier VSPs. It also discusses Elwell & Rodrig Expires August 20, 2007 [Page 1] Internet-Draft Enterprise peering February 2007 some of the key technical considerations applicable to these use cases. This work is being discussed on the speermint@ietf.org mailing list. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Direct peering between enterprises . . . . . . . . . . . . 4 3.2. Indirect peering between enterprises via an intermediate enterprise . . . . . . . . . . . . . . . . . 4 3.3. Indirect peering between enterprises via an intermediate carrier VSP . . . . . . . . . . . . . . . . . 5 3.4. Indirect peering between enterprises via two intermediate carrier VSPs . . . . . . . . . . . . . . . . 6 3.5. Direct peering between enterprise and carrier . . . . . . 6 3.6. Indirect peering between enterprise and carrier via an intermediate carrier VSP . . . . . . . . . . . . . . . . . 7 4. Summary of peering relationship cases . . . . . . . . . . . . 7 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Enterprise user identities . . . . . . . . . . . . . . . . 8 5.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Calling and connected identities . . . . . . . . . . . . . 9 5.4. User agent identities . . . . . . . . . . . . . . . . . . 9 5.5. Signalling Security . . . . . . . . . . . . . . . . . . . 9 5.6. Media and Media Security . . . . . . . . . . . . . . . . . 10 5.7. Transparency . . . . . . . . . . . . . . . . . . . . . . . 11 5.8. Regulatory aspects . . . . . . . . . . . . . . . . . . . . 11 5.9. Management . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security considerations . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. Informative References . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Elwell & Rodrig Expires August 20, 2007 [Page 2] Internet-Draft Enterprise peering February 2007 1. Introduction Work in the SPEERMINT Working Group has focused to some extent on peering between carrier VoIP Service Providers (VSP). This draft describes some use cases involving SIP (RFC 3261 [1])peering (layer 5 peering) between Enterprise VSPs, with and without the involvement of carrier VSPs, and also peering between enterprise VSPs and carrier VSPs. It also discusses some of the key technical considerations applicable to these use cases. A subset of these use cases has been addressed by the SIP Forum IP PBX / Service Provider Interoperability specification [12]. This draft is intended to provide input to the SPEERMINT group with respect to enterprise peering and is not necessarily intended as a basis for a separate RFC. 2. Overview The basic requirement of enterprise layer 5 peering is for a User Agent (UA) belonging to an enterprise A to send a SIP request to a UA belonging to an enterprise B and to receive a response. One particular example of a request is a SIP INVITE request, which is used to establish a session between the two UAs. Within the context of the session, media will flow between the two UAs. In addition to INVITE requests, other types of request (e.g., SUBSCRIBE, MESSAGE) will need to be sent. The basic requirement for enterprise-carrier peering is for a UA belonging to enterprise A to send a SIP request to a UA belonging to carrier B, or vice versa, and to receive a response. The UA in carrier B could belong to a residential or small business user or could be a PSTN gateway, for example. A SIP request will follow a certain path through the peering entities. Any media established as a result of that SIP request will not necessarily follow the same path. This draft considers only the routing of SIP requests. For the purposes of this draft it is assumed that a proxy is involved in each enterprise or carrier service provider. This does not preclude the use of B2BUAs. Also, no assumption is made about the presence of session border controllers (SBC). Elwell & Rodrig Expires August 20, 2007 [Page 3] Internet-Draft Enterprise peering February 2007 3. Use cases 3.1. Direct peering between enterprises In this use case a proxy in enterprise A is able to route requests directly to enterprise B. This assumes that enterprise A can obtain the address of the proxy at enterprise B, e.g., through configuration or DNS look-up. It also requires the proxy at enterprise B to accept requests directly from enterprise A. It is likely that some form of bilateral arrangement will need to be in place for this case to work. +-----------------------+ +-----------------------+ | Enterprise A | | Enterprise B | | +------+ +-------+ | | +-------+ +------+ | | | | | Proxy | | | | Proxy | | | | | | UA A |----| A |-+------+-| B |----| UA B | | | +------+ +-------+ | | +-------+ +------+ | +-----------------------+ +-----------------------+ 3.2. Indirect peering between enterprises via an intermediate enterprise In this use case a proxy in enterprise A is unable to route requests directly to enterprise B but is able to do so via an intermediate enterprise, I. Enterprises A and B each have some form of agreement in place with enterprise I, which allows them to route requests to enterprise I and receive requests from enterprise I. This could be part of a larger federation in which enterprise I acts as an intermediary between a multiplicity of enterprises. In this case peering between enterprises A and B is achieved through a combination of peering between enterprise A and enterprise I and peering between enterprise I and enterprise B. A special sub-case of this case is where enterprises A and B are really different parts of the same enterprise but for some reason do not have direct connectivity available at the time (e.g., due to outage or overflow). This sub-case assumes that enterprise I can obtain the address of the appropriate proxy in part A or B of the enterprise, e.g. that enterprise I regards these distinct parts of the enterprise as different domains. Elwell & Rodrig Expires August 20, 2007 [Page 4] Internet-Draft Enterprise peering February 2007 +-----------------------+ +-------------+ +-----------------------+ | Enterprise A | |Enterprise I | | Enterprise B | | +------+ +-------+ | | +-------+ | | +-------+ +------+ | | | | | Proxy | | | | Proxy | | | | Proxy | | | | | | UA A |----| A |-+---+--| I |--+---+-| B |----| UA B | | | +------+ +-------+ | | +-------+ | | +-------+ +------+ | +-----------------------+ +-------------+ +-----------------------+ 3.3. Indirect peering between enterprises via an intermediate carrier VSP In this use case a proxy in enterprise A is unable to route requests directly to enterprise B but is able to do so via an intermediate carrier VSP, I. Enterprises A and B each have some form of agreement in place with carrier I, which allows them to route requests to carrier I and receive requests from carrier I. In this case peering between enterprises A and B is achieved through a combination of "peering" between enterprise A and carrier I and "peering" between carrier I and enterprise B. The term "peering" is used here because in many respects the relationship between an enterprise and a carrier is similar to a peering relationship. However, in some respects the two VSPs (enterprise and carrier) are not regarded as peers, e.g., charging, regulatory matters. A special sub-case of this case is where enterprises A and B are really different parts of the same enterprise but for some reason do not have direct connectivity available at the time (e.g., due to outage or overflow). This sub-case assumes that carrier I can obtain the address of the appropriate proxy in part A or B of the enterprise, e.g. that carrier I regards these distinct parts of the enterprise as different domains. +-----------------------+ +-------------+ +-----------------------+ | Enterprise A | | Carrier I | | Enterprise B | | +------+ +-------+ | | +-------+ | | +-------+ +------+ | | | | | Proxy | | | | Proxy | | | | Proxy | | | | | | UA A |----| A |-+---+--| I |--+---+-| B |----| UA B | | | +------+ +-------+ | | +-------+ | | +-------+ +------+ | +-----------------------+ +-------------+ +-----------------------+ Elwell & Rodrig Expires August 20, 2007 [Page 5] Internet-Draft Enterprise peering February 2007 3.4. Indirect peering between enterprises via two intermediate carrier VSPs In this use case a proxy in enterprise A is unable to route requests directly to enterprise B but enterprise A is able to route requests to an intermediate carrier VSP, I, and enterprise B is able to receive requests from an intermediate carrier J, where I and J have direct or indirect peering relationships. Thus a request can go from A via I and J to B. In this case peering between enterprises A and B is achieved through a combination of "peering" between enterprise A and carrier I, peering between carriers I and J, and "peering" between carrier J and enterprise B. A special sub-case of this case is where enterprises A and B are really different parts of the same enterprise but for some reason do not have direct connectivity available at the time (e.g., due to outage or overflow). This sub-case assumes that carriers I/J can obtain the address of the appropriate proxy in part A or B of the enterprise, e.g. that carriers I/J regard these distinct parts of the enterprise as different domains. +------------------+ +-----------+ +-----------+ +------------------+ | Enterprise A | | Carrier I | | Carrier J | | Enterprise B | |+------+ +-------+| | +-------+ | | +-------+ | |+-------+ +------+| || | | Proxy || | | Proxy | | | | Proxy | | || Proxy | | || || UA A |-| A |+--+-| I |-+--+-| J |-+--+| B |-| UA B || |+------+ +-------+| | +-------+ | | +-------+ | |+-------+ +------+| +------------------+ +-----------+ +-----------+ +------------------+ 3.5. Direct peering between enterprise and carrier In this use case a proxy in enterprise A is able to route requests directly to carrier B or vice versa. The UA in carrier B could belong to a residential or small business user or could be a PSTN gateway, for example. This assumes that the first VSP can obtain the address of the proxy at the other VSP, e.g., through configuration or DNS look-up. It also requires the proxy at the second VSP to accept requests directly from the first VSP. It is likely that some form of bilateral arrangement will need to be in place for this case to work. Elwell & Rodrig Expires August 20, 2007 [Page 6] Internet-Draft Enterprise peering February 2007 +-----------------------+ +-----------------------+ | Enterprise A | | Carrier B | | +------+ +-------+ | | +-------+ +------+ | | | | | Proxy | | | | Proxy | | | | | | UA A |----| A |-+------+-| B |----| UA B | | | +------+ +-------+ | | +-------+ +------+ | +-----------------------+ +-----------------------+ 3.6. Indirect peering between enterprise and carrier via an intermediate carrier VSP In this use case a proxy in enterprise A is unable to route requests directly to carrier B but is able to do so via an intermediate carrier VSP, I. Enterprise A and carrier B each have some form of agreement in place with carrier I, which allows them to route requests to carrier I and receive requests from carrier I. In this case peering between enterprise A and carrier B is achieved through a combination of "peering" between enterprise A and carrier I and peering between carrier I and carrier B. +-----------------------+ +-------------+ +-----------------------+ | Enterprise A | | Carrier I | | Carrier B | | +------+ +-------+ | | +-------+ | | +-------+ +------+ | | | | | Proxy | | | | Proxy | | | | Proxy | | | | | | UA A |----| A |-+---+--| I |--+---+-| B |----| UA B | | | +------+ +-------+ | | +-------+ | | +-------+ +------+ | +-----------------------+ +-------------+ +-----------------------+ 4. Summary of peering relationship cases The various use cases above showing direct and indirect peering reveal the following peering relationships: 1. Enterprise-enterprise peering. 2. Enterprise-carrier peering. 3. Enterprise-enterprise peering (at least one of the enterprises is a transit) as part of broader enterprise-enterprise peering. 4. Enterprise-carrier peering (the carrier is a transit) as part of broader enterprise-enterprise or enterprise-carrier peering. 5. Carrier-carrier peering (at least one of the carriers is a transit) as part of broader enterprise-enterprise or enterprise- carrier peering. Elwell & Rodrig Expires August 20, 2007 [Page 7] Internet-Draft Enterprise peering February 2007 Cases 1 and 2 should be considered separately for the time being. Analysis of technical requirements will reveal the similarities and differences between these two cases. It is not clear at present whether case 3 differs from case 1. Similarly, it is not clear at present whether case 4 differs from case 2. Further work should reveal whether there is any scope for combining these cases. Case 5 is probably the same as carrier-carrier peering in its own right (i.e., with no enterprise involvement), in which case it would fall outside the scope of this draft. However, analysis of technical requirements will reveal whether or not this is true. 5. Discussion 5.1. Enterprise user identities Enterprise user identities used between peers can be expressed in different SIP/SIPS URI formats, including E.164-based URIs and non- E.164-based URIs. Non-E.164-based URIs may or may not be able to be mapped to/from E.164 numbers. Enterprise-carrier peering, particularly for voice, will generally require enterprise user identity URIs that can be mapped to/from E.164 numbers (for direct reachability from PSTN). However, for enterprise-enterprise peering (even if a transit carrier is involved) it should be possible to use user identity URIs that do not map to E.164 numbers, e.g. for IM and presence and even for voice. A VSP should not need to be aware of which individual user identities are valid within a peer's domain. For example, if domain example.com has URIs of the form SIP:xxx@example.com, where xxx can be any value, only example.com should be aware of which values of xxx are valid (e.g., sip:12345@example.com, sip:+12345678910@example.com;user=phone, sip:alice@example.com). 5.2. Routing In order to route a SIP request to a peer, a VSP needs to know the domain of the peer (e.g., example.com) and be able to obtain the address of a ingress proxy in that domain or in some intermediate domain that may be able to reach the target domain. For example, when given a SIP URI such as sip:alice@example.com, a VSP just needs to be able route directly or indirectly towards the example.com domain. RFC 3263 [5] provides a means to do this. One of multiple ingress proxies may be chosen depending, for example, on the location Elwell & Rodrig Expires August 20, 2007 [Page 8] Internet-Draft Enterprise peering February 2007 of the egress proxy. The target peer is then responsible for further routing either within that domain (e.g., by loose routing or retargeting) or by redirection. When faced with just a telephone number (or TEL URI), a VSP will need some means of looking up a domain that is responsible for the number concerned, e.g., using ENUM (RFC 3761 [2]) or statically configured routing tables. For enterprise peering, the granularity of this look-up might not be down to the level of an individual number but on the basis of prefixes. Different numbers or prefixes might map to different sub-domains of the domain concerned or might map directly to different ingress proxies in that domain. 5.3. Calling and connected identities Calling and connected user identities are delivered to and from a peer enterprise network during call establishment and at other times. The enterprise can choose to use an individual user identity, an enterprise main identity or some enterprise group identity e.g. Enterprise A Sales, provided this is suitable for making a return or repeat call. Anonymous identities will need to be used where privacy is required. An alternative would be to submit the true identity together with an indication that it is subject to privacy, relying on the peer not to disclose this information further. This might be necessary in certain situations (e.g., emergency calls). User identities sent to or from an enterprise peer network must have some means to guarantee authenticity. This could be based either on the P-Asserted-Identity header field (RFC 3325 [3]), with reliance on transitive trust in indirect peering scenarios, or it could be a cryptographically verifiable identity in the From header field coupled with a signature in the Identity header field added by the originating domain (RFC 4474 [4]). 5.4. User agent identities SIP transports UA identities, for example in the Contact header field. It is essential that these be globally routable. GRUU [9] provides one way of assigning a globally routable identity to entities that do not have globally routable IP addresses or host names. 5.5. Signalling Security Except in special situations where infrastructure is known to be secured between peers, it is essential that signalling be secured. Elwell & Rodrig Expires August 20, 2007 [Page 9] Internet-Draft Enterprise peering February 2007 The standard SIP way of achieving this is by means of TLS, which assumes that TCP is used as transport. An alternative would be to use DTLS [6] with UDP. However, message size considerations will prevent the use of UDP in many circumstances. Mutual authentication between adjacent peers is required. The peer sending a request will need to verify that the request has been received by and that the response comes from the expected domain. Likewise, the peer that receives a request will need to verify that the peer from which it is received is a domain from which it is prepared to receive requests. TLS can provide this mutual authentication based on certificates. Some signalling information may need to be secured end-to-end. Although the SIPS URI scheme provides a way of requesting that all hops be secured by TLS, information is still exposed at SIP intermediaries. Furthermore it does not provide a means of "best effort" security, whereby UAs are informed whether a request is secured on all hops or not. With these shortcomings in mind, S/MIME bodies may be used to provide end-to-end encryption and/or integrity protection and authentication. Furthermore, the Identity header field, if used, provides integrity protection from the originating domain as far as the UAS. Finally MIKEY [8], as one means of performing key management for media security (see also [11]) provides various forms of end-to-end protection for keying information. Intermediate peers must provide transparency for information secured in these ways. 5.6. Media and Media Security Ideally media, particularly real-time media, should be sent directly between the two endpoints (SIP UAs). In certain circumstances media relays may be required to assist NAT traversal. In particular, for indirect peering between enterprises, media would not necessarily be routed through relays in the domain of intermediate peers, whose function would be to assist in routing signalling and not media. When exchanging IP addresses and ports for media reception, each peer is responsible for supplying addresses and ports that are reachable from the other peer. To achieve this, a peer may delegate this to the endpoint, which can use well-known methods such as STUN and ICE [10]. Manipulation of addresses and ports by SIP intermediaries for NAT traversal purposes is also possible. Media will need to be secured, e.g., using SRTP [7]. Key exchange for this purpose will generally need to be agreed securely using Elwell & Rodrig Expires August 20, 2007 [Page 10] Internet-Draft Enterprise peering February 2007 signalling, thus placing end-to-end security requirements on this aspect of signalling, as discussed in Section 5.5. In-band and hybrid methods of key management for media security are being discussed in the IETF (e.g., RTPSEC BoF at IETF 66). These discussions may lead to alternative mechanisms, but current standardised approaches use signalling to perform key management. 5.7. Transparency When peering is indirect (e.g., peering between two enterprises via intervening carrier or enterprise networks), it is important that an adequate level of transparency is available. In particular, the intervening peer must not modify or remove information beyond what is necessary for the purpose of routing. For example, an intervening peer should not: o remove header fields and bodies that are intended for the destination peer (whether or not they are understood); o modify header fields and bodies in a way that will break any integrity protection. In addition, an intervening peer must not rely on information being sent in the clear except where inspection is necessary to accomplish routing. For cases where a carrier or enterprise network intervenes between two parts of the same enterprise, requirements for transporting additional information transparently can be greater in order to cover information specific to the enterprise. Such additional information might relate to work groups, permissions, etc.. 5.8. Regulatory aspects Regulatory issues for enterprise peering are at present unclear, but may have impact in some territories. Considerations may differ from those impacting communication within a single enterprise on the one hand and from those impacting carriers on the other hand. One possible impact of regulation is support for lawful interception, which may introduce some technical challenges in balancing the needs of legitimate business communications against those of law enforcement. 5.9. Management Peer enterprise domains will need to be managed to provide information needed to route outgoing requests, authorise incoming requests and authenticate peers. Although information for routing Elwell & Rodrig Expires August 20, 2007 [Page 11] Internet-Draft Enterprise peering February 2007 might be available from public DNS, information might still need to be provisioned to indicate the peer's policy for accepting incoming requests (to avoid unnecessary attempts at sending requests that will be blocked). For authentication, CA certificates will need to be provisioned. 6. Conclusions The discussion above does not necessarily identify significant differences between enterprise peering and carrier peering. However, examples of potential differences in detail are discussed in Section 5.2 on routing and Section 5.8 on regulatory aspects. Thus current SPEERMINT work could be extended to include enterprise peering without significant impact. However, as investigations into enterprise peering continue and as work in SPEERMINT proceeds, if differences emerge, these would need to be taken into account. 7. IANA considerations None. 8. Security considerations Security aspects are discussed in Section 5.5, Section 5.6 and Section 5.9 above. 9. Acknowledgements The authors acknowledge assistance given by members of Ecma TC32-TG17 during the drafting of this document. 10. Informative References [1] 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. [2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [3] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity Elwell & Rodrig Expires August 20, 2007 [Page 12] Internet-Draft Enterprise peering February 2007 within Trusted Networks", RFC 3325, October 2005. [4] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [6] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [7] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [8] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [9] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-11 (work in progress), October 2006. [10] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-13 (work in progress), January 2007. [11] Wing, D., Fried, S., and H. Tschofenig, "Media Security Requirements", draft-wing-media-security-requirements-00 (work in progress), October 2006. [12] Sibley, C. and C. Gatch, "IP PBX / Service Provider Interoperability", SIP Forum Recommendation-Draft sf-draft-twg- IP_PBX_SP_Interop-sibley-sipconnect, March 2006. Elwell & Rodrig Expires August 20, 2007 [Page 13] Internet-Draft Enterprise peering February 2007 Authors' Addresses John Elwell Siemens Enterprise Communications Limited Technology Drive Beeston, Nottingham NG9 1LA UK Phone: +44 115 943 4989 Email: john.elwell@siemens.com Benny Rodrig Avaya 150 Apollo Drive Chelmsford, MA 01824 USA Phone: +1 978 677 5236 Email: brodrig@avaya.com Elwell & Rodrig Expires August 20, 2007 [Page 14] Internet-Draft Enterprise peering February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Elwell & Rodrig Expires August 20, 2007 [Page 15]