SPEERMINT WG A. Houri Internet-Draft IBM Expires: December 21, 2006 E. Aoki AOL LLC T. Rang Microsoft Corporation June 19, 2006 RTC Provisioning Requirements draft-houri-speermint-rtc-provisioning-reqs-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 Real Time Communications (RTC) tools are becoming as prevalent and essential for users on the Internet as email. While RTC tools can, like email, be implemented directly by users in a point-to-point fashion, they are often provided for or on behalf of a community of users within an administrative domain. As the use of these tools Houri, et al. Expires December 21, 2006 [Page 1] Internet-Draft RTC Provisioning Requirements June 2006 grows, users increasingly have the need to communicate with users not only within their own community but with those in other communities as well. In practice, each community is controlled by some authority, and so there is a need to provide for easier establishment of connectivity between communities, and the management of the inter- community link. This document contains an initial list of requirements for provisioning and managing connectivity between communities. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Core Requirements . . . . . . . . . . . . . . . . . . . . . . 6 4. Additional Requirements . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Houri, et al. Expires December 21, 2006 [Page 2] Internet-Draft RTC Provisioning Requirements 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 [RFC2119]. Houri, et al. Expires December 21, 2006 [Page 3] Internet-Draft RTC Provisioning Requirements June 2006 2. Introduction Real Time Communications (RTC) tools are becoming as prevalent and essential for users on the Internet as email. While RTC tools can, like email, be implemented directly by users in a point-to-point fashion, they are often provided for or on behalf of a community of users within an administrative domain. As the use of these tools grows, users increasingly have the need to communicate with users not only within their own community but with those in other communities as well. In practice, each community is controlled by some authority, and so there is a need to provide for easier establishment of connectivity between communities, and the management of the inter- community link. This document contains an initial list of requirements for provisioning and managing connectivity between communities. The following terminology will be used in the document: o Single community - A server or a set of servers (e.g. an enterprise or a consumer domain) that provides service to a single community of users. Users connect to a server within the community in order to get RTC services from the community. o Clearing house - A service that facilitates interaction between multiple communities. The communities connect to the clearing house and this clearinghouse provides transitive connectivity to any of the other communities connected to and receiving service from the clearing house. o Provisioning - The ability to supply in whatever means or protocols a set of attributes that are required for smoother and safer establishment of connectivity between communities. The requirements that are provided in this document are targeted to enable two communities to connect to each other while knowing in advance what is the expectation of the other community regarding connectivity and other features that are part of the federation between the communities. In the clearing house model the intention is to enable each community that connects to the clearing house to know what services to accept from the clearing house. The requirements in this document are divided into core requirements and requirements that are nice to have or can be implemented in the future. The following categories of requirements are considered as out of scope requirements for this document (at least for this version): Houri, et al. Expires December 21, 2006 [Page 4] Internet-Draft RTC Provisioning Requirements June 2006 o The establishment of any out of band agreements agreement between the various communities that participate in the federation o Quality of Service (QoS) requirements o Billing requirements Houri, et al. Expires December 21, 2006 [Page 5] Internet-Draft RTC Provisioning Requirements June 2006 3. Core Requirements The requirements that are listed in this section are considered as core requirements and are intended to enable easier and safer connectivity between communities CORE-REQ-001: It should be possible to push and pull provisioning data between communities CORE-REQ-002: It should be possible to secure the pushing and pulling of provisioning data. Provisioning data should be provided only to the appropriate community and only on a need to know basis. CORE-REQ-003: It should be possible to provide the FQDN of the edge proxies of the other community. CORE-REQ-004: It should be possible to provide necessary details regarding firewall and NAT that will enable easier connection of other communities to the community CORE-REQ-005: It should be possible to provide the details of the how to contact the other community's administrator(s). Phone number, email etc. CORE-REQ-006: It should be possible to provide the details of the certificates that are expected by the other community. I.e. common name, certificate issuer and expiration. CORE-REQ-007: It should be possible to provide the details of the certificates that are acceptable by the community. E.g. certificate authority. CORE-REQ-008: It should be possible to provide the possible encryption methods that are expected by the community. CORE-REQ-009: It should be possible to provide the possible compression methods that are expected by the community. CORE-REQ-010: It should be possible to provide the maximum number of allowed concurrent connection that are acceptable by the community. Houri, et al. Expires December 21, 2006 [Page 6] Internet-Draft RTC Provisioning Requirements June 2006 4. Additional Requirements The requirements that are listed in this section are more "nice to have" requirements. Although the services can be established without them, these requirements can increase the quality and reduce the overhead of providing services between communities. ADD-REQ-001: It should be possible to provide the list of services that are provided by the community. E.g. N- way chat, file transfer. ADD-REQ-002: It should be possible to provide the characteristic for each service that is provided by the community. These characteristic should include additional info on each service provided ADD-REQ-003: It should be possible to provide the expected policy regarding various parameters that may affect the service between the communities. These SHOULD include the following: o A flag if the community supports polling (fetches i.e. SUBSCRIBE with duration 0) for presence information o The time limits for periodic operations as re-subscriptions o The time period in which a user-ID that was removed from the community will not be reassigned to another user. This period can affect the maximum duration of subscription. for example a community may keep subscription open for half of the above period and reassert it every half of the period o The error codes that are to be expected for certain conditions ADD-REQ-004: it should be possible to provide the intended usage profile. for example the expected number of subscriptions, message rate per second and more. These parameters should be the highest limit and provisioning requests that are below this limit should be expected to succeed, and could be performed automatically without user intervention. ADD-REQ-005: It should be possible to provide updates regarding changes to provisioning parameters immediately as they are changed ADD-REQ-006: A clearing house should be able to provide the list of communities that are enabled to connect to it ADD-REQ-007: It should be possible for a community that connects the clearing house to provide whether it should be listed in the list of the communities that can connect to the clearing house Houri, et al. Expires December 21, 2006 [Page 7] Internet-Draft RTC Provisioning Requirements June 2006 ADD-REQ-008: It should be possible for a community that connects the clearing house to provide a white or a black list of communities to the clearing house. if the community provides a white list then only the communities that are listed in the white list are allowed to connect to that community. if the community provides a black list then only the communities that are not listed in the black list are allowed to connect to that community. if neither a white or nor black list is provided then the community imposes no restrictions on connecting to it from the clearing house Houri, et al. Expires December 21, 2006 [Page 8] Internet-Draft RTC Provisioning Requirements June 2006 5. Security Considerations This document discusses requirements for provisioning between communities. Some of these requirements may have security implications when they are provided for. for example the ability to securely connect between communities and making sure that the other community is the community it claims to be. When these requirements will be addressed the security implications of them should be addressed also. 6. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Houri, et al. Expires December 21, 2006 [Page 9] Internet-Draft RTC Provisioning Requirements June 2006 Authors' Addresses 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 Tim Rang Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Email: timrang@microsoft.com Houri, et al. Expires December 21, 2006 [Page 10] Internet-Draft RTC Provisioning Requirements 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. Houri, et al. Expires December 21, 2006 [Page 11]