--- 1/draft-ietf-drinks-usecases-requirements-04.txt 2011-03-13 07:14:37.000000000 +0100 +++ 2/draft-ietf-drinks-usecases-requirements-05.txt 2011-03-13 07:14:37.000000000 +0100 @@ -1,18 +1,18 @@ DRINKS S. Channabasappa, Ed. Internet-Draft CableLabs -Intended status: Informational October 25, 2010 -Expires: April 28, 2011 +Intended status: Informational March 13, 2011 +Expires: September 14, 2011 DRINKS Use cases and Protocol Requirements - draft-ietf-drinks-usecases-requirements-04 + draft-ietf-drinks-usecases-requirements-05 Abstract This document captures the use cases and associated requirements for interfaces that provision session establishment data into SIP Service Provider components, to assist with session routing. Specifically, the current version of this document focuses on the provisioning of one such element, termed the registry. Status of this Memo @@ -23,25 +23,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on April 28, 2011. + This Internet-Draft will expire on September 14, 2011. Copyright Notice - Copyright (c) 2010 IETF Trust and the persons identified as the + Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -325,25 +325,26 @@ Enabling this involves, among other things, communicating and enabling intra-SSP signaling points and other SED that can differ from inter- SSP signaling points and SED. UC INTERCONNECT #4 Selective Peering (a.k.a. per peer policies): SSPs create peering relationships with other SSPs in order to establish interconnects. However, SSPs peering relationships often result in different points of ingress or other SED for the - same set of public identifiers. + same set of public identifiers. Selective + peering is done on a Route Group basis. UC INTERCONNECT #5 Provisioning of a delegated hierarchy: An SSP may decide to maintain its own infrastructure to - contain the route records that constitue the + contain the route records that constitute the terminal step in the LUF. In such cases, the SSP will provision registries to direct queries for the SSP's public identifiers to its own infrastructure, rather than provisioning the route records directly. For example, in the case of DNS-based route records, such a delegated hierarchy would make use of NS and CNAME records, while a flat structure would make use of NAPTR resource records. @@ -478,28 +479,27 @@ record then there are multiple possible outcomes, such as: a) the previous carrier-of-record is disassociated, b) the previous carrier-of-record is relegated to transit status, or c) the new carrier-of-record is placed in inactive mode. The choice may be dependent on the deployment scenario, and is out of scope for this document. 3.7. Category: Misc - UC MISC #1 - - The SSP wishes to provide, in query response to public - identifiers, an associated routing number (RN). This is - the case where a set of public identifiers is no longer - associated with original SSP but have been ported to a - recipient SSP, who provides access to these identifiers - via a switch on the SS7 network identified by the RN. + UC MISC #1 Number Portability: The SSP wishes to provide, in query + response to public identifiers, an associated routing + number (RN). This is the case where a set of public + identifiers is no longer associated with original SSP but + have been ported to a recipient SSP, who provides access + to these identifiers via a switch on the SS7 network + identified by the RN. UC MISC #2 Data Recipient Offer and Accept: When a peering relationship is established (or invalidated) SSPs provision (or remove) data recipients in the registry. However, a peer may first need to accept it's role (as a data recipient) before such a change is made effective. Alternatively an auto-accept feature can be configured for a given data recipient. UC MISC #3 Open numbering plans: In several countries, an open @@ -599,21 +599,21 @@ REQ-MISC-1: Number portability support. REQ-MISC-2: Ability for the SSP to be offered a peering relationship, and for the SSP to accept (explicitly or implicitly) or reject such an offer. REQ-MISC-3: Support for open numbering plans. 5. Security Considerations - Session establishment data allows for the routing of SIP sesions + Session establishment data allows for the routing of SIP sessions within, and between, SIP Service Providers. Access to this data can compromise the routing of sessions and expose a SIP Service Provider to attacks such as service hijacking and denial of service. The data can be compromised by vulnerable functional components and interfaces identified within the use cases. A provisioning protocol or interface that implements the described use cases MUST therefore provide data confidentiality, and MUST ensure message integrity for the provisioning flow. Authentication and authorization of the provisioning entities are REQUIRED features