SIPPING Working Group A. Johnston Internet-Draft SIPStation Expires: September 6, 2006 H. Sinnreich pulver.com March 5, 2006 SIP, P2P, and Internet Communications draft-johnston-sipping-p2p-ipcom-02 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 September 6, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This draft discusses issues related to the application of peer to peer (P2P) technologies to SIP in particular, and Internet communications in general. After an analysis of the P2P and non-P2P capabilities of SIP, this draft proposes that a P2P protocol be standardized in the IETF as a protocol used between a Registrar/ Proxy/Redirect server and a Location Service. This allows the operator of a Registrar to decide how much registration state is be Johnston & Sinnreich Expires September 6, 2006 [Page 1] Internet-Draft P2P, SIP and IP Com March 2006 stored locally and how much can be distributed using the P2P network to a distributed Location Server. A number of DHT (Distributed Hash Table) P2P protocols that solve some similar functions are given as examples and could be used as input to this work. Finally, existing SIP and P2P work is surveyed with respect to this proposal. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. P2P Capabilities in SIP . . . . . . . . . . . . . . . . . . . 3 3. Making SIP a True P2P Protocol . . . . . . . . . . . . . . . . 4 4. Operation of a Location Service Protocol . . . . . . . . . . . 7 5. Location Service Protocol as a P2P Protocol . . . . . . . . . 8 6. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 9 7. P2P Implementation using Distributed Hash Tables . . . . . . . 9 8. SIP P2P Implementations . . . . . . . . . . . . . . . . . . . 10 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 12. Informative References . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Johnston & Sinnreich Expires September 6, 2006 [Page 2] Internet-Draft P2P, SIP and IP Com March 2006 1. Introduction P2P technologies have been widely used on the Internet in file sharing and other applications including VoIP, IM, and presence. Other Internet-Drafts have been written which explore some of the requirements [4] and example implementations [3] of P2P SIP. This draft attempts to analyze the current P2P capabilities in SIP, then discusses the non-P2P aspects of SIP. The high level operation of the proposed Location Service Protocol is outline. Some P2P research work using the Chord protocol is then surveyed. Finally, existing SIP and P2P work is compared to this proposal. 2. P2P Capabilities in SIP SIP [1] actually already has quite a lot of inherent P2P capabilities, although most deployments of SIP today barely take advantage of them. For instance, all servers in SIP are optional, allowing User Agents (UAs) to directly communicate. Even when a server such as a proxy server is utilized, after the initial exchange, subsequent messaging is routed on a peer to peer basis using the Contact URI. Even presence can be published and retrieved in a peer to peer manner [2]. However, much development in SIP has been in the area of intermediaries. While the standard specification discusses in detail the roles of registrars, proxy servers, and redirect servers, many actual deployments of SIP have instead used B2BUA intermediaries which completely break the P2P properties of SIP by design. Efforts in SIP to make Contact URIs routable outside dialogs seemed to be moving SIP in a P2P direction. However, the current work in this area (i.e. standardizing GRUUs, Globally Routable User Agent URIs [12]) unfortunately mixes the definition of the GRUU and a particular acquisition mechanism. The proposed mechanism actually permanently includes intermediaries in the signaling path. As such, the currently defined GRUU mechanism is not applicable to P2P SIP. Hopefully alternative GRUU mechanisms compatible with P2P will be developed in the future as the full implications of the current approach are realized. As a result, SIP is not yet a true Internet protocol. It is used today in closed networks, within walled gardens, and in mediated- middle networks. Much of its complexity is a side effect of its deployment in these environments. Some of us, however, have used SIP in P2P mode over the Internet for our personal communication for years. Johnston & Sinnreich Expires September 6, 2006 [Page 3] Internet-Draft P2P, SIP and IP Com March 2006 For SIP to truly become an Internet protocol, it needs to escape these closed networks and spread in the public Internet. The best way to make this happen is for SIP to take advantage of P2P technology and truly harness the P2P properties of SIP, rendering the closed networks and their intermediaries irrelevant. 3. Making SIP a True P2P Protocol As hinted in the previous section, there are a variety of non- technical reasons why the P2P capabilities in SIP have not been widely utilized. In this section, some technical reasons why SIP is currently not truly P2P are discussed. This leads to a proposal to correct this. Consider the typical routing of a SIP request over the SIP Trapezoid introduced in RFC 3261 [1] is reproduced in part in Figure 1 below. atlanta.com . . . biloxi.com . proxy proxy . . . Alice . . . . . . . . . . . . . . . . . . . . Bob sip:alice@atlanta.com sip:bob@biloxi.com | | | | | REQUEST F1 | | | |--------------->| REQUEST F2 | | | |--------------->| REQUEST F3 | | | |--------------->| Figure 1. SIP Request Routing with the Trapezoid An analysis of why this typical interdomain request flow involves multiple proxies provides some useful insights into how SIP can operate in a more P2P manner. Alice wants to send a SIP request to Bob using Bob's Address of Record (AOR) sip:bob@biloxi.com. The request is shown as first routing through the atlanta.com proxy server before being routed to the biloxi.com proxy server. As such, atlanta.com is acting as a "outbound proxy" server. The use of a default outbound proxy server could be required if the UA, for example, does not support the DNS queries necessary to locate the biloxi.com domain. Another reason might be that the outbound proxy server is performing some NAT/ firewall traversal or other services needed to allow Alice to communicate with the outside world. Today, all UAs support DNS queries including SRV, so the DNS argument is no longer valid - Alice is perfectly capable of locating the Johnston & Sinnreich Expires September 6, 2006 [Page 4] Internet-Draft P2P, SIP and IP Com March 2006 biloxi.com server without assistance from the atlanta.com server. In addition, since the publication of RFC 3261, we have other NAT traversal techniques such as STUN, TURN, and ICE. As such, it is possible to remove the atlanta.com proxy server from this call flow, collapsing the trapezoid to a triangle. However, the biloxi.com proxy server is not so easy to eliminate. The NAT/firewall traversal services provided can likely be migrated to STUN and TURN as in the outbound proxy case. However, the proxy server can only be bypassed if Alice can discover Bob's Contact URI (sip:bob@192.0.2.4 in this example) which routes directly to Bob's UA. UAs publish this AOR/Contact URI binding using registration, which is then maintained in the network as soft state. Note that a domain can create AORs which utilized non-SIP methods to maintain this soft state. For example, if Bob uses an AOR URI which has a host part which resolves using dynamic DNS, then registrar and proxy servers can be removed from the call flow. This requires Bob's SIP devices to run a dynamic DNS client which sends a message to the dynamic DNS Server to update Bob's DNS A record each time Bob's IP address changes. In this mode, Bob no longer sends REGISTERs - the dynamic DNS updates take the place of registrations. (Note that in this context, dynamic DNS is not DNS Dynamic Updates [5],[6]. For information on dynamic DNS in this context, Google "dynamic DNS"). This dynamic DNS approach works, and has been used by a number of us for many years to successfully run P2P SIP. Note, however, that many SIP clients require a successful registration before permitting outgoing requests, even though this goes explicitly against RFC 3261 which makes it clear that a successful registration has no impact on outgoing requests. Note also that this approach is actually not P2P, as there is still a client/server dynamic DNS protocol being used. Assuming that dynamic DNS is not used, let us examine closely the reasons why the biloxi.com proxy must remain in this call flow. Bob's UA generates registration messages which contain all the information needed to perform P2P SIP routing directly to Bob's UA. This registration information is sent by Bob to the registrar for the biloxi.com domain. The information is then stored in the Location Service for the biloxi.com domain. RFC 3261 formally defines a Location Service as: A location service is used by a SIP redirect or proxy server to obtain information about a callee's possible location(s). It contains a list of bindings of address-of- record keys to zero or more contact addresses. The bindings can be created and removed in many ways; this specification Johnston & Sinnreich Expires September 6, 2006 [Page 5] Internet-Draft P2P, SIP and IP Com March 2006 defines a REGISTER method that updates the bindings. This information is then generally only available to proxy servers in the biloxi.com domain. Also, note that the protocol between a registrar and a Location Service or a proxy and a Location Service has never been standardized in the IETF. It is the one protocol in the SIP Trapezoid which is not standardized, and it is this lack of standardization that traps the registration data in the biloxi.com domain and precludes true P2P SIP. In giving SIP tutorials, I am often asked why this protocol has not been standardized. There are a number of reasons given in the past: 1. There has been no push to standardize this protocol, and the SIP Trapezoid model does not require it to be standardized. 2. The IETF typically does not standardize decomposition protocols such as these, although there are notable exceptions such as MEGACO. 3. In addition to the AOR/Contact URI binding, the Location Service is often used to store service logic. Since the IETF does not standardize services, a standard protocol to access a Location Service would be difficult to define without also standardizing (and hence limiting) the services. However, I believe that given the desire to make SIP more P2P, these reasons no longer apply. Specifically: 1. Standardizing a Location Service Protocol would allow the biloxi.com proxy server to be bypassed, allowing true interdomain P2P communication between Alice and Bob, a goal shared by many of us in the SIP community for a variety of scalability, privacy, and security reasons. 2. While this protocol could be used to decompose a SIP Server farm (and this is a very useful thing) within a domain, its use in an interdomain P2P network makes it an Internet protocol and hence of interest to the IETF. 3. In the pure P2P model, services are exclusively provided by endpoints, not intermediary servers, reducing the requirements of his protocol to purely AOR/Contact URI binding. The analysis in [4] confirms this view and suggests that even standard telephony services can be provided by peers without resorting to centralized servers. As such, the IETF should standardize this protocol to enable true P2P SIP. Johnston & Sinnreich Expires September 6, 2006 [Page 6] Internet-Draft P2P, SIP and IP Com March 2006 As an aside, the IETF has developed TRIP (Telephony Routing over IP) [7] which is an inter-Location Service protocol used to discover PSTN gateway routes. It is possible that TRIP could be extended beyond telephony routing to allow Location Servers to exchange AOR/Contact URI bindings. However, it is fundamentally a routing protocol rather than a URI discovery mechanism and as such not suitable for this application. 4. Operation of a Location Service Protocol The new Location Service Protocol (LSP) (Editor's Note: we definitely need a better name so as to be clear that this protocol has nothing to do with GEOPRIV) would be used between a Registrar, Proxy, or Redirect Server and a Location Service. Other Internet Communication Protocols could also utilize this protocol. For example, in a H.323 network, the protocol could be used between a RAS Server and its database. The basic functions are publication of AOR/Contact URI binding, and the querying of AOR/Contact URI binding. Publication would be performed by suitably authorized registrars for a domain, while querying could be performed by proxy servers, redirect servers, or even UAs in other domains. In a conventional SIP network, only the SIP servers would need to support this new protocol - UAs would not need to support a new protocol to take advantage. SIP Servers performing lookups using the Location Service Protocol would redirect the results of the query. A Registrar of a domain can decide if it wants to operate a local Location Service. If so, the protocol can be utilized to store and retrieve the information in the local Location Service. Request routing within the domain could consult this local Location Service for routing. DNS SRV records would be populated to point to the Proxy Servers which would query the local Location Service using the protocol. In short, normal SIP operation. In addition, or instead of a local Location Service, the Registrar may opt to publish registration data in a public Location Service. The protocol could then be used by users in other domains to query the public Location Service, discover the Contact URI of a particular user, and route SIP requests directly, bypassing the domain's Proxy Servers. The reasons why a domain might decide to only publish registration information to the public Location Service are obvious - the domain no longer needs to store this state and maintain SIP Proxy or Johnston & Sinnreich Expires September 6, 2006 [Page 7] Internet-Draft P2P, SIP and IP Com March 2006 Redirect Servers for incoming requests. The reasons why a domain might decide to publish this information both locally and publicly are similar. If the information is published locally then the domain still has to run SIP Proxy and Redirect Servers - however, the more users that utilize the public Location Service, the lighter the load on the SIP Servers, reducing cost and complexity for the domain. In this hybrid mode, users have the choice of either performing a DNS query and routing though a SIP Server or using the Location Service Protocol The most interesting scenario from a P2P perspective is when the Registrar decides to keep no registration state. In this case, the Registrar would simply statelessly translate a REGISTER request into the corresponding Location Service Protocol message and publish this information into the public Location Service P2P network. Note that if a UA acts as its own Registrar, it can utilize the Location Service Protocol to publish its information directly into the public Location Service. This mode is the "pure" P2P operation. In this way, the Location Service Protocol does not replace DNS or provide conflicting information, as only the registrar authoritative for the domain would publish information. Once a request is sent, normal SIP identity and security mechanisms can be used to verify that the correct destination has been reached. 5. Location Service Protocol as a P2P Protocol This proposed Location Service Protocol would not necessarily need to be a P2P protocol. None of the arguments in the previous sections requires the protocol to be P2P. In the case where the protocol is used within a single domain, the protocol need not be P2P. However, the more interesting case where the protocol is used to establish a distributed public Location Service, or a confederation or clearing house Location Service, the scaling requirements point to a P2P protocol. The need for nodes to join and leave, and for distributed storage and retrieval points to a P2P protocol. The protocol should allow a joining peer to learn the scaling size of the P2P network and provide a mechanism to insert itself into the overlay network. Johnston & Sinnreich Expires September 6, 2006 [Page 8] Internet-Draft P2P, SIP and IP Com March 2006 6. NAT Traversal In some P2P Internet communications networks, the discovery, rendezvous, and NAT traversal functions are combined into a single network and service. In fact, joining some networks require you to agree to provide all of these functions, despite the disparate resource requirements. Logically, the Location Service Protocol proposed in this draft should be separate from any NAT traversal functions. A node agreeing to participate in a distributed Location Service network should not have to agree to participate in offering NAT traversal. Also, the underlying P2P protocols, optimized for discovery and rendezvous, should not be complicated and burdened with NAT traversal issues. Instead, these protocols should assume that peers manage their own NAT traversal. The discovery of NAT traversal relay services is a useful P2P functionality in itself, however, and is an orthogonal topic. Once a node behind a NAT acquires a relay, it may then participate in the distributed Location Service P2P network. Note: The NAT traversal required is not identical to TURN [17] as it is defined today. The "lock down" property of TURN that limits it to relaying between a pair of hosts is a useful security property in a peer-wise media session. However, this property will block the arbitrary inter-node communication needed for normal P2P communication. As such, a relay acquired for the purposes of allowing a node behind a NAT to participate in a P2P network, for example, will be similar, but not exactly the same as a TURN server. 7. P2P Implementation using Distributed Hash Tables Distributed Hash Tables (DHTs) are an active research area in the P2P community that is highly scalable and offers efficient, low latency search and retrieval of data over an overlay network. These algorithms use a hash function to map a search key to a set of node numbers. Data related to that particular search key are then stored and retrieved from this set of nodes. The search key in the distributed Location Service Protocol would be an Address of Record URI. This URI is effectively a name, and would require resolution to a particular device (URL) or Contact performed in real time. As an example set of functions provided by the P2P protocol is: Johnston & Sinnreich Expires September 6, 2006 [Page 9] Internet-Draft P2P, SIP and IP Com March 2006 o Lookup of a key. Returns a set of addresses of peer nodes that store information about the key. o Retrieval of the data from a key node or nodes. o Publishing data to key node or nodes. Chord [9] is an example of a distributed hash lookup primitive. There is an active open source research project (http://www.pdos.lcs.mit.edu/chord/) which provides the first of these functions using Remote Procedure Calls (RPCs). With the addition of the other two functions, complete P2P systems can be constructed. As another example, the CFS (Cooperative File System) [10] is a read- only file system built on top of Chord that utilizes P2P techniques to request the retrieval of data. CFS utilizes load balancing techniques to break stored data into chunks and randomly distribute them across a number of nodes. Chord is used to maintain routing tables identifying which node stores which blocks. The second and third functions are provided by DHash which stores the data reliably in a number of nodes. CFS layers on top a file system that puts the retrieved blocks together as a complete data file. In another example, DDNS [13] is a Chord-based approach for providing DNS lookups. Besides DHTs, there are other classes of P2P algorithms including CAN (Content Addressable Network) [14], Pastry [15], and Tapestry [16], The problem statement for each of these algorithms bears a striking similarity to the P2P discovery and rendezvous capability that would be useful in a SIP P2P network. This body of work should be taken as an input to any IETF Location Service Protocol standardization effort. 8. SIP P2P Implementations Some preliminary work [3], [8] has been published on the use of SIP and Chord. However, these SIP approaches propose utilizing SIP as a transport, with all P2P messages tunneled over SIP. These implementations are good demonstrations of the use of DHT algorithms and the use of P2P and SIP, but are not a good starting point for the design of the Location Service Protocol. Specifically, the approach of tunneling P2P messages over a SIP REGISTER request has the following issues: Johnston & Sinnreich Expires September 6, 2006 [Page 10] Internet-Draft P2P, SIP and IP Com March 2006 - It is SIP specific. A distributed Location Service Protocol would be of use to more protocols than just SIP, and requiring non-SIP protocols to implement the REGISTER method is not likely to be acceptable. - It is not a logical extension of the REGISTER method. REGISTER is only used in SIP between a UA and a Registrar Server. Redirection of REGISTER requests is uncommon, and likely to be interpreted as an attempt at registration hijacking. To interoperate with non-P2P SIP networks, this would require a Registrar Server to initiate REGISTER requests on behalf of a UA - undesirable for a number of architectural and security reasons. - SIP transport has a high overhead and transactional state cost. For large P2P networks, this is likely to translate into long search delays and overloading of the query network. 9. Conclusion This draft has discussed the P2P capabilities of SIP and identified P2P limitations in current SIP usage. An analysis of SIP message routing over the SIP Trapezoid was used to motivate the proposal to standardize a protocol to implement a distributed Location Service. The NAT traversal requirements of this protocol were briefly discussed. Finally, the draft included a brief discussion of the applicability of some SIP P2P approaches and this proposal. 10. Acknowledgements I'd like to thank the members of the SIP community for their conversations about P2P SIP including Henry Sinnreich, Henning Schulzrinne, Robert Sparks, Cullen Jennings, Jon Peterson, Adam Roach, Adrian Georgescu, David Bryan, and Philip Matthews. In addition, thanks to the Chord developers especially Emil Sit for their feedback. 11. Security Considerations SIP utilization of P2P discovery and rendezvous techniques will introduce a number of new security, identity, and privacy considerations that will need to be solved. As a starting point, general P2P security papers such as [18] should be studied, then considerations specific to the Internet communications application should be applied. Johnston & Sinnreich Expires September 6, 2006 [Page 11] Internet-Draft P2P, SIP and IP Com March 2006 12. 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] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [3] Bryan, D. and C. Jennings, "A P2P Approach to SIP Registration and Resource Location", draft-bryan-sipping-p2p-01 (work in progress), July 2005. [4] Matthews, P., "Industrial-Strength P2P SIP", draft-matthews-sipping-p2p-industrial-strength-00 (work in progress), February 2005. [5] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [6] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [7] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002. [8] Singh, K. and H. Schulzrinne, "Peer-to-peer Internet Telephony using SIP", Columbia University Technical Report CUCS-044-04, New York, NY October 2004. [9] Stoica, I., Morris, R., Karger, D., Kaashoek, M., and H. Balakrishnan, "Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications", ACM SIGCOMM 2001, San Diego, CA August 2001, pp. 149-160. [10] Dabek, F., Kaashoek, M., Karger, D., Morris, R., and I. Stoica, "Wide-area Cooperative Storage with CFS", Proceedings of the 18th SOSP 2001. [11] Dabek, F., Kaashoek, M., Li, J., Morris, R., Robertson, J., and E. Sit, "Designing a DHT for Low Latency and High Throughput", NSDI 2004 March 2004. [12] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-06 (work in progress), October 2005. Johnston & Sinnreich Expires September 6, 2006 [Page 12] Internet-Draft P2P, SIP and IP Com March 2006 [13] Cox, R., Muthitacharoen, A., and R. Morris, "Serving DNS using a Peer-to-Peer Lookup Service", First International Workshop on Peer-to-Peer Systems (Cambridge, MA, Mar. 2002). [14] Ratmasamy, S., Francis, P., Handley, M., Karp, R., and S. Shenker, "A scalable content-addressable network", Proc. ACM SIGCOMM, San Diego, CA August 2001, pp. 161-172. [15] Rowstron, A. and P. Druschel, "Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems", Proceedings of the 18th IFIP/ACM International Conference on Distributed Systems Platforms (Middleware 2001) (Nov. 2001), pp. 329-350. [16] Zhao, B., Kubiatowicz, J., and A. Joseph, "Tapestry: An infrastructure for fault-tolerant wide-area location and routing", Tech. Rep. UCB/CSD-01-1141, Computer Science Division, U. C. Berkeley April 2001. [17] Rosenberg, J., "Traversal Using Relay NAT (TURN)", draft-rosenberg-midcom-turn-08 (work in progress), September 2005. [18] Sit, E. and J. Robertson, "Security Considerations for Peer-to- Peer Distributed Hash Tables", First International Workshop on Peer-to-Peer Systems (IPTPS 02) March 2002; Cambridge, MA. Johnston & Sinnreich Expires September 6, 2006 [Page 13] Internet-Draft P2P, SIP and IP Com March 2006 Authors' Addresses Alan Johnston SIPStation St. Louis, MO 63124 Email: alan@sipstation.com Henry Sinnreich pulver.com 115 Broadhollow Rd Suite 225 Melville, NY 11747 Email: henry@pulver.com Johnston & Sinnreich Expires September 6, 2006 [Page 14] Internet-Draft P2P, SIP and IP Com March 2006 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 (2006). 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. Johnston & Sinnreich Expires September 6, 2006 [Page 15]