SIMPLE WG T. Rang Internet-Draft Microsoft Corporation Expires: December 21, 2006 A. Houri IBM E. Aoki AOL LLC June 19, 2006 Problem Statement for SIP/SIMPLE draft-rang-simple-problem-statement-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 December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract SIMPLE based presence systems today require a unique dialog to be established between every unique presentity-watcher pair. Even though some optimizations have been suggested to the protocol, in cases where many users within a domain are subscribed to a number of users in another domain, the number of subscriptions between domains Rang, et al. Expires December 21, 2006 [Page 1] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 quickly becomes an issue. This document examines the scaling issue and concludes that additional optimizations are necessary. It also suggests an initial list of requirements for these optimizations. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Known Optimizations . . . . . . . . . . . . . . . . . . . 4 3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. SIMPLE with no optimizations . . . . . . . . . . . . . . . . . 7 5. SIMPLE with suggested optimizations . . . . . . . . . . . . . 8 6. Presence Federations . . . . . . . . . . . . . . . . . . . . . 9 6.1. Widely distributed inter-domain presence . . . . . . . . . 9 6.2. Associated inter-domain presence . . . . . . . . . . . . . 11 6.3. Very large network peering . . . . . . . . . . . . . . . . 12 6.4. Intra-domain peering . . . . . . . . . . . . . . . . . . . 14 7. Conclusions & Requirements . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.2. Informational References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Rang, et al. Expires December 21, 2006 [Page 2] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. Rang, et al. Expires December 21, 2006 [Page 3] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 2. Introduction SIMPLE based presence systems today are based on RFCs 3265 [2] and 3856 [3]. These systems require a unique dialog to be established between every unique presentity-watcher pair. Even though some optimizations are approved or are being defined, we show in this document that a very large number of messages are needed in order to establish federation between presence systems of large communities. Further thinking is needed in order to make large deployment of presence systems less resource demanding. The term presence domain or presence system appears in this document several time. By this term we refer to an presence system that provides presence subscription and notification services to its users. The system can be a system that is deployed in a small enterprise or in a very large consumer network. 2.1. Known Optimizations The current optimizations that are approved or considered in the SIMPLE group can be divided into two categories: o Dialogs saving optimization - Here we refer to optimizations as the even list draft [4] or to the uri list subscriptions draft [5]. These documents define ways to reduce the number of dialogs that are required between the subscriber and the presence system. o Notification optimizations - Here we refer to the optimizations that are suggested in the subnot-etags draft [6]. This draft suggests ways to suppress the sending of unnecessary notifies when for example a subscription is refreshed. There are other drafts that reduce the size of messages as partial notifies or filtering but in this document we mostly care about the amount of messages. Rang, et al. Expires December 21, 2006 [Page 4] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 3. Analysis The basic SIMPLE subscription dialog involves the following message- transfer: o SUBSCRIBE/200 o Initial NOTIFY/200 o (j) NOTIFY/200 where 'j' is the number of presence changes seen by the watcher o (k) SUBSCRIBE/200 where 'k' is the number of subscription dialog refresh periods o SUBSCRIBE/200 with Expires = 0 to terminate the dialog o NOTIFY/200 ending the dialog An individual watcher will generate X number of SIMPLE subscription dialogs corresponding to the number of presentities it chooses to watch. The amount of traffic generated is significantly affected by several factors: o Number of watchers connected to the system o Number of presentities connected to the system o Complexity of presence & frequency of presence change This document contains several calculations that show the expected message rate between presence domains. The following explains the assumptions and methods behind the calculations: o (A01) Subscription lifetime (hours)- The assumed lifetime of a subscription in hours. Here we assume 8 hours for all calculations. o (A02) Presence state changes / hour - The average time that a presentity changes his/hers status in one hour. We assumed 3 times a hour for most calculations. Note that for some users in consumer messaging systems, the actual numbers are likely to be much higher. o (A03) Subscription refresh interval / hour - The duration of the SUBSCRIBE session after which it needs to be refreshed. We assumed that the duration is one hour. Rang, et al. Expires December 21, 2006 [Page 5] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 o (A04) Total federated presentities per watcher - The number of presentities that the watcher is watching. The number here changes in this document according to the type of the specific deployment o (A05) Number of dialogs to maintain per watcher - The number of the SUBSCRIBE dialogs that are maintained per watcher. if a dialog optimization is not assumed this number is equal to A4, otherwise it is 1 o (A06) Number of watchers in a federated presence domain - The number of watchers in one presence domain that watch users in the other domain. The number here varies according to the assumptions for a specific deployment o (A07) Initial SUBSCRIBE/200 per watcher = A5*2 (message and an OK) o (A08) Initial NOTIFY/200 per watcher = A5*2 (message and an OK) o (A09) Total initial messages = (A7+A8)*A6 o (A10) NOTIFY/200 per watched presentity = (A2*A1*A4*2) (message and an OK) o (A11) SUBSCRIBE/200 refreshes = (A1/A3)*A5*2 (message and an OK) o (A12) NOTIFY/200 due to subscribe refresh - In a deployment where the notification optimization is not deployed this number will be ((A1/A3)*A5), otherwise it is 0 o (A13) Number of steady state messages = (A10+A11+A12)*A6 o (A14) SUBSCRIBE termination = A5*2 (message and an OK) o (A15) NOTIFY terminated = A5*2 (message and an OK) o (A16) Number of sign-out messages = (A7+A8)*A6 o (A17) Total messages between domains (both directions where users from domain A subscribe to users from domain B and vice versa)= (A9+A13+A16)*2 o (A18) Total number of messages / second = A17/A1/3600 (seconds in hour) Rang, et al. Expires December 21, 2006 [Page 6] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 4. SIMPLE with no optimizations The following table uses some common presence characteristics to demonstrate the effect these factors have on state and message rate within a presence domain using base SIMPLE protocols without any proposed optimizations. In this example, there are two presence domains, each with 20,000 federating users with an average of 4 contacts in the peer domain (A01) Subscription lifetime (hours)...........................8 (A02) Presence state changes / hour...........................3 (A03) Subscription refresh interval / hour....................1 (A04) Total federated presentities per watcher................4 (A05) Number of dialogs to maintain per watcher...............4 (A06) Number of watchers in a federated presence domain..20,000 (A07) Initial SUBSCRIBE/200 per watcher.......................8 (A08) Initial NOTIFY/200 per watcher..........................8 (A09) Total initial messages............................320,000 (A10) NOTIFY/200 per watched presentity.....................192 (A11) SUBSCRIBE/200 refreshes................................64 (A12) NOTIFY/200 due to subscribe refresh....................64 (A13) Number of steady state messages.................6,400,000 (A14) SUBSCRIBE termination...................................8 (A15) NOTIFY terminated.......................................8 (A16) Number of sign-out messages.......................320,000 (A17) Total messages between domains.................14,080,000 (A18) Total number of messages / second.....................489 SIMPLE with no optimizations Rang, et al. Expires December 21, 2006 [Page 7] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 5. SIMPLE with suggested optimizations The same analysis provided above is repeated here with the assumption that both the dialog and the notification optimizations are applied. Note that while the sign-in (ramp up) and sign-out messages flows are positively affected, the steady state rates are not. The optimizations enable the creation of a single dialog to the other domain from each subscriber for the set of presentities it is subscribing to. The optimizations also enable that there will be no need for a NOTIFY upon refreshing a SUBSCRIBE since the NOTIFY should not be sent in the refresh since it should be the same one as was sent when there was a state change for the presentity. (A01) Subscription lifetime (hours)...........................8 (A02) Presence state changes /hour............................3 (A03) Subscription refresh interval / hour....................1 (A04) Total federated presentities per watcher................4 (A05) Number of dialogs to maintain per watcher...............1 (A06) Number of watchers in a federated presence domain..20,000 (A07) Initial SUBSCRIBE/200 per watcher.......................2 (A08) Initial NOTIFY/200 per watcher..........................2 (A09) Total initial messages.............................80,000 (A10) NOTIFY/200 per watched presentity.....................192 (A11) SUBSCRIBE/200 refreshes................................16 (A12) NOTIFY/200 due to subscribe refresh.....................0 (A13) Number of steady state messages.................4,160,000 (A14) SUBSCRIBE termination...................................2 (A15) NOTIFY terminated.......................................2 (A16) Number of sign-out messages........................80,000 (A17) Total messages between domains..................8,640,000 (A18) Total number of messages / second.....................300 SIMPLE with optimizations Rang, et al. Expires December 21, 2006 [Page 8] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 6. Presence Federations While these scalability issues exist in any large deployment, certain characteristics make the deployment conducive to the existing resource- list optimizations, and others have characteristics that cannot be exploited with the existing SIMPLE model. Following is a list of federation relationships that have varying usage characteristics. For each, a message rate table is provided reflecting typical changes message rates. Those characteristics can alter the overall effectiveness of existing optimizations. 6.1. Widely distributed inter-domain presence In some environments presence federation may be very common, perhaps even more common than intra-domain presence. An example of this type of environment is a small ISV or public server. Users in that small ISV are not likely to subscribe to the presence of other users in the their server since they do not necessarily have any relationship with each other aside from receiving service from the same provider. They are much more likely to be subscribed to the presence of users in one of the federated domains (whether in consumer domains, academic, other ISVs, etc). Common characteristics of this deployment are: o Federated subscriptions are the majority of subscription traffic o Individual users are likely to subscribe to multiple users in any one domain o The intersection of users in the deployment watching the same presentities is quite small (i.e., probability that watchers in the domain subscribe to the same presentity) To account for the extraordinarily high percentage of federation traffic, the number of federated presentities is increased to 20. The number of watchers in the domain could also be adjusted to account for an expected larger community of users being peered with, it is omitted here for simplification The first table below provides the calculations without optimizations the second table provides the calculations with optimization. Note that the number of messages per second decreases by a quarter with the optimizations but it is still quite big. Rang, et al. Expires December 21, 2006 [Page 9] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 (A01) Subscription lifetime (hours)...........................8 (A02) Presence state changes / hour...........................3 (A03) Subscription refresh interval / hour....................1 (A04) Total federated presentities per watcher...............20 (A05) Number of dialogs to maintain per watcher..............20 (A06) Number of watchers in a federated presence domain..20,000 (A07) Initial SUBSCRIBE/200 per watcher......................40 (A08) Initial NOTIFY/200 per watcher.........................40 (A09) Total initial messages..........................1,600,000 (A10) NOTIFY/200 per watched presentity.....................960 (A11) SUBSCRIBE/200 refreshes...............................320 (A12) NOTIFY/200 due to subscribe refresh...................320 (A13) Number of steady state messages................32,000,000 (A14) SUBSCRIBE termination..................................40 (A15) NOTIFY terminated......................................40 (A16) Number of sign-out messages.....................1,600,000 (A17) Total messages between domains.................70,400,000 (A18) Total number of messages / second...................2,444 Widely distributed inter-domain with no optimizations Rang, et al. Expires December 21, 2006 [Page 10] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 (A01) Subscription lifetime (hours)...........................8 (A02) Presence state changes / hour...........................3 (A03) Subscription refresh interval / hour....................1 (A04) Total federated presentities per watcher...............20 (A05) Number of dialogs to maintain per watcher...............1 (A06) Number of watchers in a federated presence domain..20,000 (A07) Initial SUBSCRIBE/200 per watcher.......................2 (A08) Initial NOTIFY/200 per watcher..........................2 (A09) Total initial messages.............................80,000 (A10) NOTIFY/200 per watched presentity.....................960 (A11) SUBSCRIBE/200 refreshes................................16 (A12) NOTIFY/200 due to subscribe refresh.....................0 (A13) Number of steady state messages................19,520,000 (A14) SUBSCRIBE termination...................................2 (A15) NOTIFY terminated.......................................2 (A16) Number of sign-out messages........................80,000 (A17) Total messages between domains.................39,360,000 (A18) Total number of messages / second...................1,367 Widely distributed inter-domain with optimizations 6.2. Associated inter-domain presence In this type of environment, the domain is a collection of associated users such as an enterprise. Here, federation is once again very common. However, there is also a strong association between some users in the deployment. These associations make it somewhat more likely that users in that domain will be watchers of the same presentity. This can occur because of business relationships (e.g. two co-workers on a project federating with a partner company). Common characteristics of this deployment are: o Federated subscriptions are large minority or small majority of subscription traffic o Individual users are likely to subscribe to multiple users in any one domain, especially their own o The intersection of users in the deployment watching the same presentities increases This federation type has traffic rates similar to the previous examples but with different levels of association of the users. Rang, et al. Expires December 21, 2006 [Page 11] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 6.3. Very large network peering In this environment, two or more very large networks create a peering relationship allowing their users to subscribe to presence in the other domains. Where as the number of users in other deployment types ranges from hundreds to several hundred thousand, these large networks host up to hundreds of millions of users. Examples of these networks are large wireless carriers at the low end and consumer IM networks at the high end. Common characteristics of this deployment are: o As users become accustomed to network boundaries disappearing, federated subscriptions become as common as subscriptions within the same domain o Individual users are highly likely to want to see presence of multiple presentities in the peer network o The intersection of users in the deployment watching the same presentities is very high (i.e., two or more users in network A are extremely likely to be watching a same user in network B) o Status changes increase greatly due to typical observed consumer behavior The first table below provides the calculations without optimizations the second table provides the calculations with optimization. Even though the optimization help a lot (almost cut the number of messages by half), the numbers are still very concerning. Rang, et al. Expires December 21, 2006 [Page 12] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 (A01) Subscription lifetime (hours)..............................8 (A02) Presence state changes / hour..............................6 (A03) Subscription refresh interval / hour.......................1 (A04) Total federated presentities per watcher..................10 (A05) Number of dialogs to maintain per watcher.................10 (A06) Number of watchers in a federated presence domain.10,000,000 (A07) Initial SUBSCRIBE/200 per watcher.........................20 (A08) Initial NOTIFY/200 per watcher............................20 (A09) Total initial messages...........................400,000,000 (A10) NOTIFY/200 per watched presentity........................960 (A11) SUBSCRIBE/200 refreshes..................................160 (A12) NOTIFY/200 due to subscribe refresh......................160 (A13) Number of steady state messages...............12,800,000,000 (A14) SUBSCRIBE termination.....................................20 (A15) NOTIFY terminated.........................................20 (A16) Number of sign-out messages....................4,000,000,000 (A17) Total messages between domains................27,200,000,000 (A18) Total number of messages / second....................944,444 Very large network peering with no optimizations Rang, et al. Expires December 21, 2006 [Page 13] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 (A01) Subscription lifetime (hours)..............................8 (A02) Presence state changes / hour..............................6 (A03) Subscription refresh interval / hour.......................1 (A04) Total federated presentities per watcher..................10 (A05) Number of dialogs to maintain per watcher..................1 (A06) Number of watchers in a federated presence domain.10,000,000 (A07) Initial SUBSCRIBE/200 per watcher..........................2 (A08) Initial NOTIFY/200 per watcher.............................2 (A09) Total initial messages............................40,000,000 (A10) NOTIFY/200 per watched presentity........................960 (A11) SUBSCRIBE/200 refreshes...................................16 (A12) NOTIFY/200 due to subscribe refresh........................0 (A13) Number of steady state messages................9,760,000,000 (A14) SUBSCRIBE termination......................................2 (A15) NOTIFY terminated..........................................2 (A16) Number of sign-out messages.......................40,000,000 (A17) Total messages between domains................19,680,000,000 (A18) Total number of messages / second....................683,333 Very large network peering with optimizations 6.4. Intra-domain peering Within a particular domain, multiple presence infrastructures are deployed with users split between the two. This scenario is unique in that federated messages do not pass outside the administrative domain's network. The two infrastructures peer directly inside the domain. A common example of this is an enterprise IT system with multiple independent vendor presence solutions deployed(e.g., a presence solution for desktop messaging deployed alongside a presence solution for IP telephony). Common characteristics of this deployment are o The difference between subscriptions to presentities in one system vs. the other are completely arbitrary. Any one presentity is as likely to be homed on one infrastructure as the other o Active users are almost guaranteed of subscribing to many users in the peer infrastructure o The level of intersection of presentities is extremely high The first table below provides the calculations without optimizations Rang, et al. Expires December 21, 2006 [Page 14] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 the second table provides the calculations with optimization. Even though the relatively conservative numbers are used, the amount of messages is still very high even though optimization may cut the traffic by more then half (A01) Subscription lifetime (hours)..............................8 (A02) Presence state changes / hour..............................3 (A03) Subscription refresh interval / hour.......................1 (A04) Total federated presentities per watcher..................10 (A05) Number of dialogs to maintain per watcher.................10 (A06) Number of watchers in a federated presence domain.....60,000 (A07) Initial SUBSCRIBE/200 per watcher.........................20 (A08) Initial NOTIFY/200 per watcher............................20 (A09) Total initial messages.............................2,400,000 (A10) NOTIFY/200 per watched presentity........................480 (A11) SUBSCRIBE/200 refreshes..................................160 (A12) NOTIFY/200 due to subscribe refresh......................160 (A13) Number of steady state messages...................48,400,000 (A14) SUBSCRIBE termination.....................................20 (A15) NOTIFY terminated.........................................20 (A16) Number of sign-out messages........................2,400,000 (A17) Total messages between domains...................105,600,000 (A18) Total number of messages / second......................3,667 Inter-domain peering with no optimizations Rang, et al. Expires December 21, 2006 [Page 15] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 (A01) Subscription lifetime (hours)..............................8 (A02) Presence state changes / hour..............................3 (A03) Subscription refresh interval / hour.......................1 (A04) Total federated presentities per watcher..................10 (A05) Number of dialogs to maintain per watcher..................1 (A06) Number of watchers in a federated presence domain.....60,000 (A07) Initial SUBSCRIBE/200 per watcher..........................2 (A08) Initial NOTIFY/200 per watcher.............................2 (A09) Total initial messages...............................240,000 (A10) NOTIFY/200 per watched presentity........................480 (A11) SUBSCRIBE refreshes.......................................16 (A12) NOTIFY/200 due to subscribe refresh........................0 (A13) Number of steady state messages...................29,760,000 (A14) SUBSCRIBE termination......................................2 (A15) NOTIFY terminated..........................................2 (A16) Number of sign-out messages..........................240,000 (A17) Total messages between domains....................60,480,000 (A18) Total number of messages / second......................2,100 Inter-domain peering with optimizations Rang, et al. Expires December 21, 2006 [Page 16] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 7. Conclusions & Requirements We have shown several calculations of message rate between various type of SIP presence systems deployments. These calculations show that the current suggested optimizations although effective in some circumstances and can reduce the traffic up to the 50%, there is still a very high volume traffic occur in SIP deployments of presence. In order to make the deployment of SIP presence more effective additional optimizations are needed. The following is an initial list of very general requirements from the seeked for optimizations: Backward compatibility requirements o The solution should not hinder the ability of existing SIMPLE clients and/or servers from peering with a domain or client implementing the solution. No changes may be required of existing servers to interoperate o It does NOT constrain any existing RFC functional or security requirements for presence o Systems that are not using the new additions to the protocol should operate at the same level as they do today Policy, privacy, permissions requirements o The solution does not limit the ability for presentities to present different views of presence to different watchers o The solution does not restrict the ability of a presentity to obtain its list of watchers o The solution MUST NOT create any new or make worse any existing privacy holes Scalability requirements o It is highly desirable for inter-domain network to scale linearly as number of watchers and presentities increase linearly o The solution SHOULD NOT require significantly more state in order to implement the solution o It MUST be able to scale to tens of millions of concurrent users in each peer domain Rang, et al. Expires December 21, 2006 [Page 17] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 o It MUST support a very high level of watcher/presentity intersections in various intersection models o Protocol changes MUST NOT prohibit optimizations in different deployment models esp. where there is a high level of cross subscriptions between the domains Topology requirement o The solution SHOULD allow for arbitrary federation topologies including direct peering and intermediary routing Rang, et al. Expires December 21, 2006 [Page 18] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 8. Security Considerations This document discusses scalability issues with the existing SIP/ SIMPLE presence protocol. Therefore, there are no security considerations to be considered for this document. Rang, et al. Expires December 21, 2006 [Page 19] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informational References [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [3] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. [4] Roach, A., Rosenberg, J., and B. Campbell, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", draft-ietf-simple-event-list-07 (work in progress), January 2005. [5] Camarillo, G., "Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)", draft-ietf-sipping-uri-list-subscribe-05 (work in progress), May 2006. [6] Niemi, A., "An Extension to Session Initiation Protocol (SIP) Events for Issuing Conditional Subscriptions", draft-niemi-sip-subnot-etags-00 (work in progress), January 2006. Rang, et al. Expires December 21, 2006 [Page 20] Internet-Draft Problem Statement for SIP/SIMPLE June 2006 Authors' Addresses Tim Rang Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Email: timrang@microsoft.com Avshalom Houri IBM Science Park Building 18/D Rehovot, Israel Email: avshalom@il.ibm.com Edwin Aoki AOL LLC 360 W. Caribbean Drive Sunnyvale, CA 94089 USA Email: aoki@aol.net Rang, et al. Expires December 21, 2006 [Page 21] Internet-Draft Problem Statement for SIP/SIMPLE June 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. Rang, et al. Expires December 21, 2006 [Page 22]