Internet DRAFT - draft-houri-speermint-rtc-provisioning-reqs

draft-houri-speermint-rtc-provisioning-reqs







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]