doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc6461.txt b/doc/rfc/rfc6461.txt
new file mode 100644
index 0000000..86e6a31
--- /dev/null
+++ b/doc/rfc/rfc6461.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)             S. Channabasappa, Ed.
+Request for Comments: 6461                                     CableLabs
+Category: Informational                                     January 2012
+ISSN: 2070-1721
+
+
+       Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS)
+                  Use Cases and Protocol Requirements
+
+Abstract
+
+   This document captures the use cases and associated requirements for
+   interfaces that provision session establishment data into Session
+   Initiation Protocol (SIP) Service Provider components to assist with
+   session routing.  Specifically, this document focuses on the
+   provisioning of one such element termed the "registry".
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6461.
+
+Copyright Notice
+
+   Copyright (c) 2012 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
+   described in the Simplified BSD License.
+
+
+
+
+Channabasappa                 Informational                     [Page 1]
+
+RFC 6461            DRINKS Use Cases and Requirements       January 2012
+
+
+Table of Contents
+
+   1. Overview ........................................................2
+   2. Terminology .....................................................5
+   3. Registry Use Cases ..............................................6
+      3.1. Category: Provisioning Mechanisms ..........................6
+      3.2. Category: Interconnect Schemes .............................7
+      3.3. Category: SED Exchange and Discovery Models ................8
+      3.4. Category: SED Record Content ...............................9
+      3.5. Category: Separation and Facilitation of Data Management ...9
+      3.6. Category: Public Identifiers, TN Ranges, and RNs ..........10
+      3.7. Category: Misc ............................................11
+   4. Requirements ...................................................11
+      4.1. Provisioning Mechanisms ...................................12
+      4.2. Interconnect Schemes ......................................12
+      4.3. SED Exchange and Discovery Requirements ...................12
+      4.4. SED Record Content Requirements ...........................12
+      4.5. Data Management Requirements ..............................13
+      4.6. Public Identifier, TN Range, and RN Requirements ..........13
+      4.7. Misc. Requirements ........................................13
+   5. Security Considerations ........................................14
+   6. Acknowledgments ................................................14
+   7. References .....................................................15
+      7.1. Normative References ......................................15
+      7.2. Informative References ....................................15
+
+1.  Overview
+
+   [RFC5486] (Section 3.3) defines Session Establishment Data, or SED,
+   as the data used to route a call to the next hop associated with the
+   called domain's ingress point.  More specifically, the SED is the set
+   of parameters that the outgoing signaling path border elements (SBEs)
+   need to establish a session.  However, [RFC5486] does not specify the
+   protocol(s) or format(s) to provision SED.  To pave the way to
+   specify such a protocol, this document presents the use cases and
+   associated requirements that have been proposed to provision SED.
+
+   SED is typically created by the terminating or next-hop SIP service
+   provider (SSP) and consumed by the originating SSP.  To avoid a
+   multitude of bilateral exchanges, SED is often shared via
+   intermediary systems -- termed "registries" within this document.
+   Such registries receive data via provisioning transactions from SSPs,
+   and then distribute the received data into Local Data Repositories
+   (LDRs).  These LDRs are used for call routing by outgoing SBEs.  This
+   is depicted in Figure 1.
+
+
+
+
+
+
+Channabasappa                 Informational                     [Page 2]
+
+RFC 6461            DRINKS Use Cases and Requirements       January 2012
+
+
+                                       *-------------*
+                1. Provision SED       |             |
+              -----------------------> |  Registry   |
+                                       |             |
+                                       *-------------*
+                                            /  \
+                                           /    \
+                                          /      \
+                                         /        \
+                                        /          \
+                                       /            \
+                                      / 2.Distribute \
+                                     /      SED       \
+                                    V                  V
+                              +----------+       +----------+
+                              |Local Data|       |Local Data|
+                              |Repository|       |Repository|
+                              +----------+       +----------+
+
+                         Figure 1: General Diagram
+
+   In this document, we address the use cases and requirements for
+   provisioning registries.  Data distribution to local data
+   repositories is out of scope for this document.  The resulting
+   provisioning protocol can be used to provision data into a registry
+   or between multiple registries operating in parallel.  In Figure 2,
+   the case of multiple registries is depicted with dotted lines.
+
+                                  . . . . . . .
+                  . . . .  . . .   registry    . . . . . . .
+                .                 . . . . . . .              .
+              .                        .                      .
+             .                         .                       .
+            .                          . provision             .
+       +-----------+                   .                 +-----------+
+       |           |  provision  +----------+  provision |           |
+       |   SSP 1   |------------>| Registry |<-----------|   SSP 2   |
+       |           |             +----------+            |           |
+       |  +-----+  |                   /\                |  +-----+  |
+       |  | LDR | <--------------------  ------------------>| LDR |  |
+       |  +-----+  |   distribute           distribute   |  +-----+  |
+       |           |                                     |           |
+       +-----------+                                     +-----------+
+              .                                                .
+               . . . . . . . . . . . . . . . . . . . . . . . .
+                              (provision / distribute)
+
+                       Figure 2: Functional Overview
+
+
+
+Channabasappa                 Informational                     [Page 3]
+
+RFC 6461            DRINKS Use Cases and Requirements       January 2012
+
+
+   In addition, this document proposes two aggregation groups, as
+   follows:
+
+   o  Aggregation of public Identifiers into a destination group.
+
+   o  Aggregation of SED records into a route group.
+
+   The use cases in Section 3.5 provide the rationale.  The data model
+   depicted in Figure 3 shows the various entities, aggregations, and
+   the relationships between them.
+
+       +---------+            +--------------+               +---------+
+       |  Data   |0..n    0..n|     Route    | 1         0..n|   SED   |
+       |Recipient|------------|     Group    | --------------|  Record |
+       +---------+            +--------------+               +---------+
+                                     |0..n                        |0..n
+                                     |                            |
+                                     |                            |
+                                     |                            |
+                                     |0..n                        |
+                            1 +--------------+  0..1              |
+                     ---------| Destination  |---------           |
+                    |         |    Group     |         |          |
+                    |         +--------------+         |          |
+                    |                |                 |          |
+                    |               1|                 |          |
+                    |                |                 |          |
+                    |                |                 |          |
+               0..n |           0..n |                 | 0..n     |
+               +---------+      +---------+       +----------+    |
+               |   RN    |      |   TN    |       | Public   |----
+               |         |      |  Range  |       |Identifier| 1
+               +---------+      +---------+       +----------+
+
+
+                       Figure 3: Data Model Diagram
+
+   The relationships are as described below:
+
+   -  A public identifier object can be directly related to zero or more
+      SED Record objects, and a SED Record object can be related to
+      exactly one public identifier object.
+
+   -  A destination group object can contain zero or more TN (telephone
+      number) Range objects, and a TN Range object can be contained in
+      exactly one destination group object.
+
+
+
+
+
+Channabasappa                 Informational                     [Page 4]
+
+RFC 6461            DRINKS Use Cases and Requirements       January 2012
+
+
+   -  A destination group object can contain zero or more public
+      identifier objects, and a public identifier object can be
+      contained in exactly one destination group object.
+
+   -  A destination group object can contain zero or more RN (routing
+      number) objects, and an RN object can be contained in exactly one
+      destination group object.
+
+   -  A route group object can contain zero or more SED Record objects,
+      and a SED Record object can be contained in exactly one route
+      group object.
+
+   -  A route group object can be associated with zero or more
+      destination group objects, and a destination group object can be
+      associated with zero or more route group objects.
+
+   -  A data recipient object can be associated with zero or more route
+      group objects, and a route group object can refer to zero or more
+      data recipient objects.
+
+2.  Terminology
+
+   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].
+
+   This document reuses terms from [RFC3261] (e.g., SIP), [RFC5486]
+   (e.g., SSP, LUF, LRF, SED) and [RFC5067] (carrier-of-record and
+   transit provider).  In addition, this document specifies the
+   following additional terms.
+
+   Registry:  The authoritative source for provisioned session
+      establishment data (SED) and related information.  A registry can
+      be part of an SSP or be an independent entity.
+
+   Registrar:  An entity that provisions and manages data into the
+      registry.  An SSP can act as its own registrar or -- additionally
+      or alternatively -- delegate this function to a third party (who
+      acts as its registrar).
+
+   Local Data Repository (LDR):  The data store component of an
+      addressing server that provides resolution responses.
+
+   Public Identifier:  A public identifier refers to a telephone number
+      (TN), a SIP address, or other identity as deemed appropriate, such
+      as a globally routable URI of a user address (e.g.,
+      sip:john.doe@example.net).
+
+
+
+
+Channabasappa                 Informational                     [Page 5]
+
+RFC 6461            DRINKS Use Cases and Requirements       January 2012
+
+
+   Telephone Number (TN) Range:  A numerically contiguous set of
+      telephone numbers.
+
+   Telephone Number (TN) Prefix:  A preceding portion of the digits
+      common across a series of E.164 numbers.  A given TN prefix will
+      include all the valid E.164 numbers that satisfy the expansion
+      rules mandated by the country or the region with which the TNs
+      comply.
+
+   Routing Number (RN):  A Routing Number.  For more information, see
+      [RFC4694].
+
+   Destination Group:  An aggregation of a set of public identifiers, TN
+      Ranges, or RNs that share common SED, which is exposed to a common
+      set of peers.
+
+   Data Recipient:  An entity with visibility into a specific set of
+      public identifiers (or TN Ranges or RNs), the destination groups
+      that contain these public identifiers (or TN Ranges and RNs), and
+      a route group's SED records.
+
+   Route Group:  An aggregation that contains a related set of SED
+      records and is associated with a set of destination groups.  Route
+      groups facilitate the management of SED records for one or more
+      data recipients.
+
+3.  Registry Use Cases
+
+   This section documents use cases related to the provisioning of the
+   registry.  Any request to provision, modify, or delete data is
+   subject to several security considerations (see Section 5).  The
+   protocols that implement these use cases (and associated
+   requirements) will need to explicitly identify and address them.
+
+3.1.  Category: Provisioning Mechanisms
+
+   UC PROV #1  Real-Time Provisioning: Registrars have operational
+               systems that provision public identifiers (or TN Ranges
+               or RNs) in association with their SED.  These systems
+               often function in a manner that expects or requires that
+               these provisioning activities be completed immediately,
+               as opposed to an out-of-band or batch provisioning scheme
+               that can occur at a later time.  This type of
+               provisioning is referred to as "real-time" or "on-demand"
+               provisioning.
+
+
+
+
+
+
+Channabasappa                 Informational                     [Page 6]
+
+RFC 6461            DRINKS Use Cases and Requirements       January 2012
+
+
+   UC PROV #2  Non-Real-Time Bulk Provisioning: Operational systems that
+               provision public identifiers (or TN Ranges or RNs) and
+               associated SED sometimes expect that these provisioning
+               activities be batched up into large sets.  These batched
+               requests are then processed using a provisioning
+               mechanism that is out of band and occurs at a later time.
+
+   UC PROV #3  Multi-Request Provisioning: Regardless of whether or not
+               a provisioning action is performed in real time, SSPs
+               often perform several provisioning actions on several
+               objects in a single request or transaction.  This is done
+               for performance and scalability reasons, and for
+               transactional reasons, such that the set of provisioning
+               actions either fail or succeed atomically, as a complete
+               set.
+
+3.2.  Category: Interconnect Schemes
+
+   UC INTERCONNECT #1  Inter-SSP SED: SSPs create peering relationships
+                       with other SSPs in order to establish
+                       interconnects.  Establishing these interconnects
+                       involves, among other things, communicating and
+                       enabling the points of ingress and other SED used
+                       to establish sessions.
+
+   UC INTERCONNECT #2  Direct and Indirect Peering: Some inter-SSP
+                       peering relationships are created to enable the
+                       establishment of sessions to the public
+                       identifiers for which an SSP is the carrier-of-
+                       record.  This is referred to as "direct peering".
+                       Other inter-SSP peering relationships are created
+                       to enable the establishment of sessions to public
+                       identifiers for which an SSP is a transit
+                       provider.  This is referred to as "indirect
+                       peering".  Some SSPs take into consideration an
+                       SSP's role as a transit or carrier-of-record
+                       provider when selecting a route to a public
+                       identifier.
+
+   UC INTERCONNECT #3  Intra-SSP SED: SSPs support the establishment of
+                       sessions between their own public identifiers,
+                       not just to other SSPs' public identifiers.
+                       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.
+
+
+
+
+
+Channabasappa                 Informational                     [Page 7]
+
+RFC 6461            DRINKS Use Cases and Requirements       January 2012
+
+
+   UC INTERCONNECT #4  Selective Peering (a.k.a. per-peer policies):
+                       SSPs create peering relationships with other SSPs
+                       in order to establish interconnects.  However,
+                       SSP peering relationships often result in
+                       different points of ingress or other SED for the
+                       same set of public identifiers.  This is referred
+                       to as "selective peering" and 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 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.
+
+3.3.  Category: SED Exchange and Discovery Models
+
+   UC SED EXCHANGE #1  SED Exchange and Discovery using unified LUF/LRF:
+                       When establishing peering relationships, some
+                       SSPs may wish to communicate or receive SED
+                       (e.g., points of ingress) that constitutes the
+                       aggregated result of both LUF and LRF.
+
+   UC SED EXCHANGE #2  SED Exchange and Discovery using LUF's Domain
+                       Name: When establishing peering relationships,
+                       some SSPs may not wish to communicate or receive
+                       points of ingress and other SED using a registry.
+                       They only wish to communicate or receive domain
+                       names (LUF step only), and then independently
+                       resolve those domain names via [RFC3263] to the
+                       final points of ingress data (and other SED).
+
+   UC SED EXCHANGE #3  SED Exchange and Discovery using LUF's
+                       Administrative Domain Identifier: When
+                       establishing peering relationships, some SSPs may
+                       not wish to communicate or receive points of
+                       ingress and other SED using a registry.  They
+                       only wish to communicate or receive an
+                       administrative domain identifier, which is not
+                       necessarily resolvable via DNS.  The subsequent
+                       process of using that administrative domain
+
+
+
+Channabasappa                 Informational                     [Page 8]
+
+RFC 6461            DRINKS Use Cases and Requirements       January 2012
+
+
+                       identifier to select points of ingress or other
+                       SED can be SSP specific and is out of scope for
+                       this document.
+
+   UC SED EXCHANGE #4  Coexistent SED Exchange and Discovery Models:
+                       When supporting multiple peering relationships,
+                       some SSPs have the need to concurrently support
+                       all three of the SED Exchange and Discovery
+                       Models already described in this section
+                       (Section 3.3) for the same set of public
+                       identifiers.
+
+3.4.  Category: SED Record Content
+
+   UC SED RECORD #1  SED Record Content: Establishing interconnects
+                     between SSPs involves, among other things,
+                     communicating points of ingress, the service types
+                     (SIP, SIPS, etc.) supported by each point of
+                     ingress, and the relative priority of each point of
+                     ingress for each service type.
+
+   UC SED RECORD #2  Time-To-Live (TTL): For performance reasons,
+                     querying SSPs sometimes cache SED that had been
+                     previously looked up for a given public identifier.
+                     In order to accomplish this, SSPs sometimes specify
+                     the TTL associated with a given SED record.
+
+3.5.  Category: Separation and Facilitation of Data Management
+
+   UC DATA #1  Separation of Provisioning Responsibility: An SSP's
+               operational practices often separate the responsibility
+               of provisioning the points of ingress and other SED from
+               the responsibility of provisioning public identifiers (or
+               TN Ranges or RNs).  For example, a network engineer can
+               establish a physical interconnect with a peering SSP's
+               network and provision the associated domain name, host,
+               and IP addressing information.  Separately, for each new
+               subscriber, the SSP's provisioning systems provision the
+               associated public identifiers.
+
+   UC DATA #2  Destination Groups: SSPs often provision identical SED
+               for large numbers of public identifiers (or TN Ranges or
+               RNs).  For reasons of efficiency, groups of public
+               identifiers that have the same SED can be aggregated.
+               These aggregations are known as destination groups.  The
+               SED is then indirectly associated with destination groups
+               rather than with each individual public identifier (or TN
+               Ranges or RNs).
+
+
+
+Channabasappa                 Informational                     [Page 9]
+
+RFC 6461            DRINKS Use Cases and Requirements       January 2012
+
+
+   UC DATA #3  Route Groups: SSPs often provision identical SED for
+               large numbers of public identifiers (or TN Ranges or
+               RNs), and then expose that relationship between a group
+               of SED records and a group of public identifiers (or TN
+               Ranges or RNs) to one or more SSPs.  This combined
+               grouping of SED records and destination groups
+               facilitates efficient management of relationships and the
+               list of peers (data recipients) that can look up public
+               identifiers and receive the associated SED.  This dual
+               set of SED records and destination groups is termed a
+               "route group".
+
+3.6.  Category: Public Identifiers, TN Ranges, and RNs
+
+   UC PI #1  Additions and Deletions: SSPs often allocate and de-
+             allocate specific public identifiers to and from end-users.
+             This involves, among other things, activating or
+             deactivating specific public identifiers (TN Ranges or
+             RNs), and directly or indirectly associating them with the
+             appropriate points of ingress and other SED.
+
+   UC PI #2  Carrier-of-Record versus Transit Provisioning: Some inter-
+             SSP peering relationships are created to enable the
+             establishment of sessions to the public identifiers (or TN
+             Ranges or RNs) for which an SSP is the carrier-of-record.
+             Other inter-SSP peering relationships are created to enable
+             the establishment of sessions for which an SSP is a transit
+             provider.  Some SSPs take into consideration an SSP's role
+             as a transit or carrier-of-record provider when selecting a
+             route.
+
+   UC PI #3  Multiplicity: As described in previous use cases, SSPs
+             provision public identifiers (or TN Ranges or RNs) and
+             their associated SED for multiple peering SSPs, and as both
+             the carrier-of-record and transit provider.  As a result, a
+             given public identifier (or TN Range or RN) key can reside
+             in multiple destination groups at any given time.
+
+   UC PI #4  Destination Group Modification: SSPs often change the SED
+             associated with a given public identifier (or TN Range or
+             RN).  This involves, among other things, directly or
+             indirectly associating them with a different point of
+             ingress, different services, or different SED.
+
+   UC PI #5  Carrier-of-Record versus Transit Modification: SSPs may
+             have the need to change their carrier-of-record versus
+             transit role for public identifiers (or TN Ranges or RNs)
+             that they previously provisioned.
+
+
+
+Channabasappa                 Informational                    [Page 10]
+
+RFC 6461            DRINKS Use Cases and Requirements       January 2012
+
+
+   UC PI #6  Modification of Authority: An SSP indicates that it is the
+             carrier-of-record for an existing public identifier or TN
+             Range.  If the public identifier or TN Range were
+             previously associated with a different carrier-of-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  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 the original SSP
+               but has been ported to a recipient SSP, who provides
+               access to these identifiers via a switch on the Signaling
+               System Number 7 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 its 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
+               numbering plan is used, where the carrier-of-record is
+               only aware of a portion of the E.164 number (i.e., the TN
+               prefix).  The carrier-of-record may not know the complete
+               number or the number of digits in the number.  The rest
+               of the digits are handled offline (e.g., by a Private
+               Branch Exchange, or PBX).  For example, an SSP can be the
+               carrier-of-record for "+123456789" and be the carrier-of-
+               record for every possible expansion of that number, such
+               as "+12345678901" and "+123456789012", even though the
+               SSP does not know what those expansions could be.  This
+               can be described as the carrier-of-record effectively
+               being authoritative for the TN prefix.
+
+4.  Requirements
+
+   This section lists the requirements extracted from the use cases in
+   Section 3.  The objective is to make it easier for protocol designers
+   to understand the underlying requirements and to reference and list
+
+
+
+Channabasappa                 Informational                    [Page 11]
+
+RFC 6461            DRINKS Use Cases and Requirements       January 2012
+
+
+   the requirements that they support (or not).  The requirements listed
+   here, unless explicitly indicated otherwise, are expected to be
+   supported.  Protocol proposals are also expected to indicate their
+   compliance with these requirements and highlight ones that they don't
+   meet (if any).  Furthermore, the requirements listed here are not
+   meant to be limiting, i.e., protocol implementations and deployments
+   may choose to support additional requirements based on use cases that
+   are not listed in this document.
+
+4.1.  Provisioning Mechanisms
+
+   REQ-PROV-1:  Real-time provisioning.
+
+   REQ-PROV-2:  (Optional) Non-real-time bulk provisioning.
+
+   REQ-PROV-3:  Multi-request provisioning.
+
+4.2.  Interconnect Schemes
+
+   REQ-INTERCONNECT-1:  Inter-SSP peering.
+
+   REQ-INTERCONNECT-2:  Direct and Indirect peering.
+
+   REQ-INTERCONNECT-3:  Intra-SSP SED.
+
+   REQ-INTERCONNECT-4:  Selective peering.
+
+   REQ-INTERCONNECT-5:  Provisioning of a delegated hierarchy.
+
+4.3.  SED Exchange and Discovery Requirements
+
+   REQ-SED-1:  SED containing unified LUF and LRF content.
+
+   REQ-SED-2:  SED containing LUF-only data using domain names.
+
+   REQ-SED-3:  SED containing LUF-only data using administrative
+               domains.
+
+   REQ-SED-4:  Support for all the other REQ-SED requirements (listed in
+               this section), concurrently, for the same public
+               identifier (or TN Range or RN).
+
+4.4.  SED Record Content Requirements
+
+   REQ-SED-RECORD-1:  Ability to provision SED record content.
+
+   REQ-SED-RECORD-2:  (Optional) Communication of an associated TTL for
+                      a SED Record.
+
+
+
+Channabasappa                 Informational                    [Page 12]
+
+RFC 6461            DRINKS Use Cases and Requirements       January 2012
+
+
+4.5.  Data Management Requirements
+
+   REQ-DATA-MGMT-1:  Separation of responsibility for the provisioning
+                     the points of ingress and other SED, from the
+                     responsibility of provisioning public identifiers.
+
+   REQ-DATA-MGMT-2:  Ability to aggregate a set of public identifiers as
+                     destination groups.
+
+   REQ-DATA-MGMT-3:  Ability to create the aggregation termed route
+                     group.
+
+4.6.  Public Identifier, TN Range, and RN Requirements
+
+   REQ-PI-TNR-RN-1:  Provisioning of, and modifications to, the
+                     following aggregations: destination group and route
+                     groups.
+
+   REQ-PI-TNR-RN-2:  Ability to distinguish an SSP as either the
+                     carrier-of-record provider or the transit provider.
+
+   REQ-PI-TNR-RN-3:  A given public identifier (or TN Range or RN) can
+                     reside in multiple destination groups at the same
+                     time.
+
+   REQ-PI-TNR-RN-4:  Modification of public identifier (or TN Range or
+                     RN) by allowing them to be moved to a different
+                     destination group via an atomic operation.
+
+   REQ-PI-TNR-RN-5:  SSPs can indicate a change to their role from
+                     carrier-of-record provider to transit, or vice
+                     versa.
+
+   REQ-PI-TNR-RN-6:  Support for modification of authority with the
+                     conditions described in UC PI #6.
+
+4.7.  Misc. Requirements
+
+   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.
+
+
+
+
+
+
+Channabasappa                 Informational                    [Page 13]
+
+RFC 6461            DRINKS Use Cases and Requirements       January 2012
+
+
+5.  Security Considerations
+
+   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 framework or protocol that implements the described
+   use cases MUST, therefore, provide data confidentiality and message
+   integrity.  Such frameworks and protocols MUST specify mechanisms to
+   authenticate and authorize any entity that provisions data into the
+   registry, i.e., that the entity is who it says it is and is allowed
+   to use the provisioning interface.  The determination of whether such
+   an entity is authorized to provision specific data elements (e.g., a
+   certain public identifier or TN Range) -- while REQUIRED -- may be
+   left to local policy.
+
+6.  Acknowledgments
+
+   This document is a result of various contributions from (and
+   discussions within) the IETF DRINKS Working Group; specifically, in
+   alphabetical order: Alexander Mayrhofer, Deborah A Guyton, Gregory
+   Schumacher, Jean-Francois Mule, Kenneth Cartwright, Manjul Maharishi,
+   Penn Pfautz, Ray Bellis, Richard Shockey, and Syed Ali.
+
+   The editor also wishes to thank the following for their comments and
+   suggestions: Otmar Lendl, Sohel Khan, Peter Koch, Brian Rosen, Jon
+   Peterson, Gonzalo Camarillo, and Stephen Farrell.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Channabasappa                 Informational                    [Page 14]
+
+RFC 6461            DRINKS Use Cases and Requirements       January 2012
+
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC5486]  Malas, D. and D. Meyer, "Session Peering for Multimedia
+              Interconnect (SPEERMINT) Terminology", RFC 5486,
+              March 2009.
+
+7.2.  Informative References
+
+   [RFC3261]  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.
+
+   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
+              Protocol (SIP): Locating SIP Servers", RFC 3263,
+              June 2002.
+
+   [RFC4694]  Yu, J., "Number Portability Parameters for the "tel" URI",
+              RFC 4694, October 2006.
+
+   [RFC5067]  Lind, S. and P. Pfautz, "Infrastructure ENUM
+              Requirements", RFC 5067, November 2007.
+
+Author's Address
+
+   Sumanth Channabasappa (editor)
+   CableLabs
+   858 Coal Creek Circle
+   Louisville, CO  80027
+   USA
+
+   EMail: sumanth@cablelabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Channabasappa                 Informational                    [Page 15]
+