draft-ietf-drinks-spprov-07.txt   draft-ietf-drinks-spprov-08.txt 
DRINKS J-F. Mule DRINKS J-F. Mule
Internet-Draft CableLabs Internet-Draft CableLabs
Intended status: Standards Track K. Cartwright Intended status: Standards Track K. Cartwright
Expires: October 21, 2011 TNS Expires: January 13, 2012 TNS
S. Ali S. Ali
NeuStar NeuStar
A. Mayrhofer A. Mayrhofer
enum.at GmbH enum.at GmbH
April 19, 2011 July 12, 2011
Session Peering Provisioning Protocol Session Peering Provisioning Protocol
draft-ietf-drinks-spprov-07 draft-ietf-drinks-spprov-08
Abstract Abstract
This document defines a protocol for provisioning session This document defines a protocol for provisioning session
establishment data into Session Data Registries and SIP Service establishment data into Session Data Registries and SIP Service
Provider data stores. The provisioned data is typically used by Provider data stores. The provisioned data is typically used by
various network elements for session peering. various network elements for session peering.
This document describes the Session Peering Provisioning Protocol This document describes the Session Peering Provisioning Protocol
used by clients to provision registries. The document provides a set used by clients to provision registries. The document provides a set
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 21, 2011. This Internet-Draft will expire on January 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Protocol High Level Design . . . . . . . . . . . . . . . . . . 9 3. Protocol High Level Design . . . . . . . . . . . . . . . . . . 9
3.1. Protocol Layering . . . . . . . . . . . . . . . . . . . . 9 3.1. Protocol Layering . . . . . . . . . . . . . . . . . . . . 9
3.2. Protocol Data Model . . . . . . . . . . . . . . . . . . . 10 3.2. Protocol Data Model . . . . . . . . . . . . . . . . . . . 10
4. Transport Protocol Requirements . . . . . . . . . . . . . . . 14 4. Transport Protocol Requirements . . . . . . . . . . . . . . . 14
4.1. Connection Oriented . . . . . . . . . . . . . . . . . . . 14 4.1. Connection Oriented . . . . . . . . . . . . . . . . . . . 14
4.2. Request and Response Model . . . . . . . . . . . . . . . . 14 4.2. Request and Response Model . . . . . . . . . . . . . . . . 14
4.3. Connection Lifetime . . . . . . . . . . . . . . . . . . . 15 4.3. Connection Lifetime . . . . . . . . . . . . . . . . . . . 14
4.4. Authentication . . . . . . . . . . . . . . . . . . . . . . 15 4.4. Time value . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5. Confidentiality and Integrity . . . . . . . . . . . . . . 15 4.5. Authentication . . . . . . . . . . . . . . . . . . . . . . 15
4.6. Near Real Time . . . . . . . . . . . . . . . . . . . . . . 15 4.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 15
4.7. Request and Response Sizes . . . . . . . . . . . . . . . . 16 4.7. Confidentiality and Integrity . . . . . . . . . . . . . . 15
4.8. Request and Response Correlation . . . . . . . . . . . . . 16 4.8. Near Real Time . . . . . . . . . . . . . . . . . . . . . . 15
4.9. Request Acknowledgement . . . . . . . . . . . . . . . . . 16 4.9. Request and Response Sizes . . . . . . . . . . . . . . . . 15
4.10. Mandatory Transport . . . . . . . . . . . . . . . . . . . 16 4.10. Request and Response Correlation . . . . . . . . . . . . . 16
4.11. Request Acknowledgement . . . . . . . . . . . . . . . . . 16
4.12. Mandatory Transport . . . . . . . . . . . . . . . . . . . 16
5. Base Protocol Data Structures . . . . . . . . . . . . . . . . 17 5. Base Protocol Data Structures . . . . . . . . . . . . . . . . 17
5.1. Request and Response Structures . . . . . . . . . . . . . 17 5.1. Request and Response Structures . . . . . . . . . . . . . 17
5.1.1. Update Request and Response Structures . . . . . . . . 17 5.1.1. Update Request and Response Structures . . . . . . . . 17
5.1.2. Query Request and Response Structures . . . . . . . . 20 5.1.2. Query Request and Response Structures . . . . . . . . 20
5.2. Response Codes and Messages . . . . . . . . . . . . . . . 22 5.2. Response Codes and Messages . . . . . . . . . . . . . . . 23
5.3. Basic Object Type and Organization Identifiers . . . . . . 24 5.3. Basic Object Type and Organization Identifiers . . . . . . 25
6. Protocol Commands . . . . . . . . . . . . . . . . . . . . . . 26 6. Protocol Commands . . . . . . . . . . . . . . . . . . . . . . 26
6.1. Add Destination Group Operation . . . . . . . . . . . . . 26 6.1. Add Destination Group Operation . . . . . . . . . . . . . 26
6.2. Get Destination Groups Operation . . . . . . . . . . . . . 27 6.2. Get Destination Groups Operation . . . . . . . . . . . . . 27
6.3. Add Public Identifier Operation . . . . . . . . . . . . . 28 6.3. Add Public Identifier Operation . . . . . . . . . . . . . 28
6.4. Get Public Identifiers Operation . . . . . . . . . . . . . 33 6.4. Get Public Identifiers Operation . . . . . . . . . . . . . 33
6.5. Add Route Group Operation . . . . . . . . . . . . . . . . 33 6.5. Add Route Group Operation . . . . . . . . . . . . . . . . 33
6.6. Get Route Groups Operation . . . . . . . . . . . . . . . . 38 6.6. Get Route Groups Operation . . . . . . . . . . . . . . . . 38
6.7. Add Route Record Operation . . . . . . . . . . . . . . . . 39 6.7. Add Route Record Operation . . . . . . . . . . . . . . . . 39
6.8. Get Route Records Operation . . . . . . . . . . . . . . . 43 6.8. Get Route Records Operation . . . . . . . . . . . . . . . 43
6.9. Add Route Group Offer Operation . . . . . . . . . . . . . 44 6.9. Add Route Group Offer Operation . . . . . . . . . . . . . 44
skipping to change at page 4, line 7 skipping to change at page 4, line 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
11. Formal Specification . . . . . . . . . . . . . . . . . . . . . 80 11. Formal Specification . . . . . . . . . . . . . . . . . . . . . 80
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 93 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 93
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 94 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 94
13.1. Normative References . . . . . . . . . . . . . . . . . . . 94 13.1. Normative References . . . . . . . . . . . . . . . . . . . 94
13.2. Informative References . . . . . . . . . . . . . . . . . . 94 13.2. Informative References . . . . . . . . . . . . . . . . . . 94
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 96
1. Introduction 1. Introduction
Service providers and enterprises use registries to make call or Service providers and enterprises use registries to make session
session routing decisions for Voice over IP, SMS and MMS traffic routing decisions for Voice over IP, SMS and MMS traffic exchanges.
exchanges. This document is narrowly focused on the provisioning This document is narrowly focused on the provisioning protocol for
protocol for these registries. This protocol prescribes a way for an these registries. This protocol prescribes a way for an entity to
entity to provision session-related data into a registry. The data provision session-related data into a registry. The data being
being provisioned can be optionally shared with other participating provisioned can be optionally shared with other participating peering
peering entities. The requirements and use cases driving this entities. The requirements and use cases driving this protocol have
protocol have been documented in been documented in [I-D.ietf-drinks-usecases-requirements]. The
[I-D.ietf-drinks-usecases-requirements]. The reader is expected to reader is expected to be familiar with the terminology defined in the
be familiar with the terminology defined in the previously mentioned previously mentioned document.
document.
Three types of provisioning flows have been described in the use case Three types of provisioning flows have been described in the use case
document: client to registry provisioning, registry to local data document: client to registry provisioning, registry to local data
repository and registry-to-registry. This document addresses a repository and registry to registry. This document addresses client
subset (client-to-registry provisioning) by defining a Session to registry aspect to fulfill the need to provision Session
Peering Provisioning Protocol (SPPP) for provisioning Session Establishment Data (SED). The protocol that supports flow of
Establishment Data (SED) into a Registry (arrow "1" in the figure messages to facilitate client to registry provisioning is referred to
below). While the other "provisioning flows" are shown below as as Session Peering Provisioning Protocol (SPPP).
separate message flows, no determination has been made for whether
one common baseline protocol could be used for all three, or whether
distinct protocols are required.
*------------* *------------* Please note that the role of the "client" and the "server" only
(1). Provisioning SED | | (3).Registry | | applies to the connection, and those roles are not related in any way
-----------------------> | Registry |<------------->| Registry | to the type of entity that participates in a protocol exchange. For
data into Registries| | to Registry | | example, a registry might also include a "client" when such a
*------------* exchanges *------------* registry initiates a connection (for example, for data distribution
to SSP).
*--------* *------------* *------------*
| | (1). Client | | (3).Registry | |
| Client | ------------> | Registry |<------------->| Registry |
| | to Registry | | to Registry | |
*--------* *------------* *------------*
/ \ \ / \ \
/ \ \ / \ \
/ \ \ / \ \
/ \ v / \ v
/ \ ... / \ ...
/ \ / \
/ (2). \ / (2). Distrib \
/ Distributing \ / Registry data \
/ SED \ / to local data \
V V V store V
+----------+ +----------+ +----------+ +----------+
|Local Data| |Local Data| |Local Data| |Local Data|
|Repository| |Repository| |Repository| |Repository|
+----------+ +----------+ +----------+ +----------+
Three Registry Provisioning Flows Three Registry Provisioning Flows
Figure 1 Figure 1
The data provisioned for session establishment is typically used by The data provisioned for session establishment is typically used by
various downstream SIP signaling systems to route a call to the next various downstream SIP signaling systems to route a call to the next
hop associated with the called domain. These systems typically use a hop associated with the called domain. These systems typically use a
local data store ("Local Data Repository") as their source of session local data store ("Local Data Repository") as their source of session
routing information. More specifically, the SED data is the set of routing information. More specifically, the SED data is the set of
parameters that the outgoing signaling path border elements (SBEs) parameters that the outgoing signaling path border elements (SBEs)
need to initiate the session. See [RFC5486] for more details. need to initiate the session. See [RFC5486] for more details.
A "terminating" SIP Service Provider (SSP) provisions SED into the A "terminating" SIP Service Provider (SSP) provisions SED into the
registry to be selectively shared with other peer SSPs. registry to be selectively shared with other peer SSPs.
Subsequently, a Registry may distribute the provisioned data into Subsequently, a registry may distribute the provisioned data into
local Data Repositories used for look-up queries (identifier -> URI) local data repositories used for look-up queries (identifier -> URI)
or for lookup and location resolution (identifier -> URI -> ingress or for lookup and location resolution (identifier -> URI -> ingress
SBE of terminating SSP). In some cases, the Registry may SBE of terminating SSP). In some cases, the registry may
additionally offer a central query resolution service (not shown in additionally offer a central query resolution service (not shown in
the above figure). the above figure).
A key requirement for the SPPP protocol is to be able to accommodate A key requirement for the SPPP protocol is to be able to accommodate
two basic deployment scenarios: two basic deployment scenarios:
1. A Local Data Repository serves a Look-Up Function (LUF) to 1. A resolution system returns a Look-Up Function (LUF) that
determine the target domain to assist in call routing (as comprises of the target domain to assist in call routing (as
described in [RFC5486]). In this case, the querying entity may described in [RFC5486]). In this case, the querying entity may
use other means to perform the Location Routing Function (LRF) use other means to perform the Location Routing Function (LRF)
which in turn helps determine the actual location of the which in turn helps determine the actual location of the
Signaling Function in that domain. Signaling Function in that domain.
2. A Local Data Repository serves both a Look-Up function (LUF) and 2. A resolution system returns both a Look-Up function (LUF) and
Location Routing Function (LRF) to locate the SED data fully. Location Routing Function (LRF) to locate the SED data fully.
In terms of protocol design, SPPP protocol is agnostic to the In terms of protocol design, SPPP is agnostic to the transport. This
transport. This document includes the description of the data model document includes the description of the data model and the means to
and the means to enable protocol operations within a request and enable protocol operations within a request and response structure.
response structure. To encourage interoperability, the protocol To encourage interoperability, the protocol supports extensibility
supports extensibility aspects. aspects.
Transport requirements are provided in this document to help with the Transport requirements are provided in this document to help with the
selection of the optimum transport mechanism. selection of the optimum transport mechanism.
([I-D.ietf-drinks-sppp-over-soap]) identifies a SOAP transport ([I-D.ietf-drinks-sppp-over-soap]) identifies a SOAP transport
mechanism for SPPP. mechanism for SPPP.
This document is organized as follows: This document is organized as follows:
o Section 2 provides the terminology; o Section 2 provides the terminology;
o Section 3 provides an overview of the SPPP protocol, including o Section 3 provides an overview of the SPPP, including the
the layering approach, functional entities and data model; layering approach, functional entities and data model;
o Section 4 specifies requirements for SPPP transport protocols; o Section 4 specifies requirements for SPPP transport protocols;
o Section 5 describes the base protocol data structures including o Section 5 describes the base protocol data structures including
the request and response elements (Section 5.1), the response the request and response elements (Section 5.1), the response
codes and messages (Section 5.2) and the basic object type most codes and messages (Section 5.2) and the basic object type most
first class objects extend from; first class objects extend from;
o Section 6 and Section 7 describe the main protocol commands and o Section 6 and Section 7 describe the main protocol commands and
examples; examples;
skipping to change at page 7, line 26 skipping to change at page 7, line 26
SPPP: Session Peering Provisioning Protocol, the protocol used to SPPP: Session Peering Provisioning Protocol, the protocol used to
provision data into a Registry (see arrow labeled "1." in Figure 1 provision data into a Registry (see arrow labeled "1." in Figure 1
of [I-D.ietf-drinks-usecases-requirements]). It is the primary of [I-D.ietf-drinks-usecases-requirements]). It is the primary
scope of this document. scope of this document.
SPDP: Session Peering Distribution Protocol, the protocol used to SPDP: Session Peering Distribution Protocol, the protocol used to
distribute data to Local Data Repository (see arrow labeled "2." distribute data to Local Data Repository (see arrow labeled "2."
in Figure 1 of [I-D.ietf-drinks-usecases-requirements]). in Figure 1 of [I-D.ietf-drinks-usecases-requirements]).
Client: An application that supports an SPPP Client; it is Client: An application that supports an SPPP client; it is
sometimes referred to as a "Registry Client". sometimes referred to as a "registry client".
Registry: The Registry operates a master database of Session Registry: The Registry operates a master database of Session
Establishment Data for one or more Registrants. Establishment Data for one or more Registrants.
A Registry acts as an SPPP Server. A Registry acts as an SPPP server.
Registrant: In this document, we extend the definition of a Registrant: In this document we extend the definition of a
Registrant based on [RFC4725]. The Registrant is the end-user, Registrant based on [RFC4725]. The Registrant is the end-user,
the person or organization who is the "holder" of the Session the person or organization that is the "holder" of the Session
Establishment Data being provisioned into the Registry. For Establishment Data being provisioned into the Registry by a
example, in [I-D.ietf-drinks-usecases-requirements], a Registrant Registrar. For example, in
is pictured as a SIP Service Provider in Figure 2. [I-D.ietf-drinks-usecases-requirements], a Registrant is pictured
as a SIP Service Provider in Figure 2.
A Registrant is uniquely identified by its ID. Within the confines of a Registry, a Registrant is uniquely
identified by a well-known ID.
Registrar: In this document, we also extend the definition of a Registrar: In this document we extend the definition of a Registrar
Registrar from [RFC4725]. A Registrar performs provisioning from [RFC4725]. A Registrar is an entity that performs
operations on behalf of a Registrant by interacting with the provisioning operations on behalf of a Registrant by interacting
Registry, in our case via the SPPP protocol defined in this with the Registry via SPPP operations. In other words the
document. Registrar is the SPPP Client. The Registrar and Registrant roles
are logically separate to allow, but not require, a single
Registrar to perform provisioning operations on behalf of more
than one Registrant.
Peering Organization: A Peering Organization is an entity to which
a Registrant's Route Groups are made visible using the operations
of SPPP.
3. Protocol High Level Design 3. Protocol High Level Design
This section introduces the structure of the data model and provides This section introduces the structure of the data model and provides
the information framework for the SPPP protocol. An overview of the the information framework for the SPPP. An overview of the protocol
protocol operations is first provided with a typical deployment operations is first provided with a typical deployment scenario. The
scenario. The data model is then defined along with all the objects data model is then defined along with all the objects manipulated by
manipulated by the protocol and their relationships. the protocol and their relationships.
3.1. Protocol Layering 3.1. Protocol Layering
SPPP is a simple request/reply protocol that allows a client SPPP is a simple request/reply protocol that allows a client
application to submit provisioning data and query requests to a application to submit provisioning data and query requests to a
server. The SPPP data structures are designed to be protocol server. The SPPP data structures are designed to be protocol
agnostic. Concerns regarding encryption, non-repudiation, and agnostic. Concerns regarding encryption, non-repudiation, and
authentication are beyond the scope of this document. For more authentication are beyond the scope of this document. For more
details, please refer to the Transport Protocol Requirements section. details, please refer to the Transport Protocol Requirements section.
skipping to change at page 10, line 38 skipping to change at page 10, line 38
5. The data object layer defines the base set of SPPP data objects 5. The data object layer defines the base set of SPPP data objects
that can be included in update operations or returned in that can be included in update operations or returned in
operation responses. operation responses.
3.2. Protocol Data Model 3.2. Protocol Data Model
The data model illustrated and described in Figure 3 defines the The data model illustrated and described in Figure 3 defines the
logical objects and the relationships between these objects that the logical objects and the relationships between these objects that the
SPPP protocol supports. SPPP defines the protocol operations through SPPP protocol supports. SPPP defines the protocol operations through
which an SPPP Client populates a Registry with these logical objects. which an SPPP client populates a egistry with these logical objects.
Various clients belonging to different Registrars may use the Various clients belonging to different egistrars may use the protocol
protocol for populating the Registry's data. for populating the registry's data.
The logical structure presented below is consistent with the The logical structure presented below is consistent with the
terminology and requirements defined in terminology and requirements defined in
[I-D.ietf-drinks-usecases-requirements]. [I-D.ietf-drinks-usecases-requirements].
+-------------+ +------------------+ +-------------+ +------------------+
| all object | |Organization: | | all object | |Organization: |
| types | |orgId | | types |----->|orgId |
+------+------+ | | +------+------+ | |
+------------>| | All objects are +------------------+
All objects are +------------------+ associated with an ^
associated with an ^ organization to |A Route Group is
organization to |A Route Group is identify the |associated with +-----[abstract]-+
identify the |associated with object's registrant |zero or more Peering | Route Record: |
object's registrant |zero or more Peering |Organizations | rrName, |
|Organizations | | priority, |
| +--------+--------------+ | extension |
+--------+--------------+ |Route Group: |------->| |
|Route Group: | +-----[abstract]-+ | rant, | +----------------+
| rant, | | Route Record: | | rgName, | ^
| rgName, | | rrName, | | destGrpRef, | |
| destGrpRef, +------->| priority, | | isInSvc, | |Various types
| isInSvc, | | extension | | rrRef, | |of Route
| rrRef, | | | | peeringOrg, | |Records...
| peeringOrg, | +----------------+ | sourceIdent, | +-----+------------+
| sourceIdent, | ^ | priority, | | | |
| priority, | | | extension | +----+ +-------+ +----+
| extension | |Various types +-----------------------+ | URI| | NAPTR | | NS |
+-----------------------+ |of Route | +----+ +-------+ +----+
| |Records... |
| +------+------------... | +----------[abstract]-+
| | | | | |Public Identifier: |
| +----+ +-------+ +----+ | | |
v | URI| | NAPTR | | NS | | | rant, |
+----------------+-----+ +----+ +-------+ +----+ v | publicIdentifier, |
|Destination | +----------------------+ | destGrpRef, |
|Group: | +----------[abstract]-+ | Dest Group: |<----| rrRef, |
| rant, | |Public Identifier: | | rant, | | extension |
| dgName, | | | | dgName, | +---------------------+
| extension, | | rant, | | extension | ^
+----------------------+ | publicIdentifier, | +----------------------+ |Various types
| destGrpRef, | |of Public
| rrRef, | |Identifiers...
| extension | +---------+-------+------------...
+---------------------+ | | | |
^ +------+ +-----+ +-----+ +-----+
|Various types | TN | | TNP | | TNR | | RN |
|of Public +------+ +-----+ +-----+ +-----+
|Identifiers...
+---------+-------+------------...
| | | |
+------+ +-----+ +-----+ +-----+
| TN | | TNP | | TNR | | RN |
+------+ +-----+ +-----+ +-----+
SPPP Data Model SPPP Data Model
Figure 3 Figure 3
The objects and attributes that comprise the data model can be The objects and attributes that comprise the data model can be
described as follows (objects listed from the bottom up): described as follows (objects listed from the bottom up):
o Public Identifier: o Public Identifier:
From a broad perspective a public identifier is a well known From a broad perspective a public identifier is a well-known
attribute that is used as the key to perform resolution lookups. attribute that is used as the key to perform resolution lookups.
Within the context of SPPP, a Public Identifier object can be a Within the context of SPPP, a public identifier object can be a
telephone number, a range of telephone numbers, a PSTN Routing telephone number, a range of telephone numbers, a PSTN Routing
Number (RN), or a TN prefix. Number (RN), or a TN prefix.
An SPPP Public Identifier is associated with a Destination Group An SPPP Public Identifier is associated with a Destination Group
to create a logical grouping of Public Identifiers that share a to create a logical grouping of Public Identifiers that share a
common set of Routes. common set of Routes.
A TN Public Identifier may optionally be associated with zero or A TN Public Identifier may optionally be associated with zero or
more individual Route Records. This ability for a Public more individual Route Records. This ability for a Public
Identifier to be directly associated with a set of Route Records Identifier to be directly associated with a set of Route Records
skipping to change at page 12, line 33 skipping to change at page 12, line 33
Destination Group, supports the use cases where the target URI Destination Group, supports the use cases where the target URI
contains data specifically tailored to an individual TN Public contains data specifically tailored to an individual TN Public
Identifier. Identifier.
o Destination Group: o Destination Group:
A named collection of zero or more Public Identifiers that can be A named collection of zero or more Public Identifiers that can be
associated with one or more Route Groups for the purpose of associated with one or more Route Groups for the purpose of
facilitating the management of their common routing information. facilitating the management of their common routing information.
o Route Group: o Route Group:
A Route Group contains a set of references to Route Records, a set A Route Group contains a set of Route Record references, a set of
of Destination Group references, and a set of peering organization Destination Group references, and a set of peering organization
identifiers. This is used to establish a three part relationships identifiers. This is used to establish a three part relationships
between a set of Public Identifiers and their common routing between a set of Public Identifiers, the routing information (SED)
information (SED), and the list of peering organizations whose shared across the Public Identifiers, and the list of peering
query responses may include that routing information in their organizations whose query responses from the resolution system may
query responses. To support the use cases defined in [I-D.ietf- include the routing information from a given route group. In
drinks-usecases-requirements], this document defines the following addition, the sourceIdent element within a Route Group, in concert
types of Route Records: NAPTRType, NSType, and URIType. The with the set of peering organization identifiers, enables fine-
sourceIdent element within a Route Group, in concert with the set grained source based routing. For further details about the Route
of peering organization identifiers enables fine grained source Group and source based routing, refer to the definitions and
based routing. Further details about the Route Group and source descriptions of the Route Group operations found later in this
based routing refer to the definitions and descriptions of the document.
Route Group operations found later in this document.
o Route Record: o Route Record:
A Route Record contains the data that a resolution system returns A Route Record contains the data that a resolution system returns
in response to a successful query for a Public Identifier. Route in response to a successful query for a Public Identifier. Route
Recoords are associated with a Route Group for SED that is not Records are generally associated with a Route Group when the SED
specific to a Public Identifier. within is not specific to a Public Identifier.
To support the use cases defined in To support the use cases defined in
[I-D.ietf-drinks-usecases-requirements], SPPP protocol defines
three type of Route Records: URIType, NAPTRType, and NSType. [I-D.ietf-drinks-usecases-requirements], SPPP defines three type
These Route Records extend the abstract type RteRecType and of Route Records: URIType, NAPTRType, and NSType. These Route
inherit the common attribute 'priority' that is meant for setting Records extend the abstract type RteRecType and inherit the common
precedence across the route records defined within a Route Group attribute 'priority' that is meant for setting precedence across
in a protocol agnostic fashion. the route records defined within a Route Group in a protocol
agnostic fashion.
o Organization: o Organization:
An Organization is an entity that may fulfill any combination of An Organization is an entity that may fulfill the role of a
three roles: Registrant, Registrar, and Peering Organization. All Registrant or of the peering organization. All SPPP objects are
SPPP objects are associated with an organization identifier to associated with an organization identifier to identify each
identify each object's registrant, while tracking the identity of object's registrant, while tracking the identity of the registrar
the registrar that provisioned each SPPP object is left as a that provisioned each SPPP object is left as a matter of policy
matter of policy for an SPPP implementation. A Route Group object for an SPPP implementation. A Route Group object is also
is also associated with a set of zero or more organization associated with a set of zero or more organization identifiers
identifiers that identify the peering organization(s) whose that identify the peering organization(s) whose resolution query
resolution query responses may include the routing information responses may include the routing information (SED) defined in the
(SED) defined in the Route Records within that Route Group. Route Records within that Route Group. A peering organization is
an entity that the registrant intends to share the SED data with.
A route group SPPP object is associated with a set of zero or more
organization identifiers that identify the peering organizations
whose resolution query responses may include the routing
information (SED) defined in the route records within that route
group.
4. Transport Protocol Requirements 4. Transport Protocol Requirements
This section provides requirements for transport protocols suitable This section provides requirements for transport protocols suitable
for SPPP. More specifically, this section specifies the services, for SPPP. More specifically, this section specifies the services,
features, and assumptions that SPPP delegates to the chosen transport features, and assumptions that SPPP delegates to the chosen transport
and envelope technologies. and envelope technologies.
Two different groups of use cases are specified in
[I-D.ietf-drinks-usecases-requirements]. One group of use cases
describes the provisioning of data by a client into a Registry
(Section 3.1 of the above referenced document), while the other group
describes the distribution of data into local data repositories
(Section 3.2). The current version of this document focuses on the
first set of use cases (client to registry provisioning).
These use cases may involve the provisioning of very small data sets
like the modification or update of a single public identifier. Other
provisioning operations may deal with huge datasets like the
"download" of a whole local number portability database to a
Registry.
As a result, a transport protocol for SPPP must be very flexible and
accommodate various sizes of data set sizes.
For the reasons outlined above, it is conceivable that provisioning
and distributing may use different transport protocols. This
document focuses on the provisioning protocol.
4.1. Connection Oriented 4.1. Connection Oriented
The SPPP protocol follows a model where a Client establishes a The SPPP follows a model where a client establishes a connection to a
connection to a Server in order to further exchange provisioning server in order to further exchange SPPP messages over such point-to-
transactions over such point-to-point connection. A transport point connection. A transport protocol for SPPP MUST therefore be
protocol for SPPP MUST therefore be connection oriented. connection oriented.
Note that the role of the "Client" and the "Server" only applies to
the connection, and those roles are not related in any way to the
type of entity that participates in a protocol exchange. For
example, a Registry might also include a "Client" when such a
Registry initiates a connection (for example, for data distribution
to SSP).
4.2. Request and Response Model 4.2. Request and Response Model
Provisioning operations in SPPP follow the request - response model, Provisioning operations in SPPP follow the request-response model,
where a transaction is initiated by a Client using a Request command, where a client sends a request message to initiate a transaction and
and the Server responds to the Client by means of a Response. the server responds with a response. Multiple subsequent request-
response exchanges MAY be performed over a single persistent
Multiple subsequent request-response exchanges MAY be performed over connection.
a single connection.
Therefore, a transport protocol for SPPP MUST follow the request- Therefore, a transport protocol for SPPP MUST follow the request-
response model by allowing a response to be sent to the request response model by allowing a response to be sent to the request
initiator. initiator.
4.3. Connection Lifetime 4.3. Connection Lifetime
Some use cases involve provisioning a single request to a network Some use cases involve provisioning a single request to a network
element - connections supporting such provisioning requests might be element. Connections supporting such provisioning requests might be
short-lived, and only established on demand. short-lived, and may be established only on demand. Other use cases
involve either provisioning a large dataset, or a constant stream of
Other use cases involve either provisioning a huge set of data, or a small updates, either of which would likely require long-lived
constant stream of small updates, which would require long-lived
connections. connections.
Therefore, a protocol suitable for SPPP SHOULD support short lived as Therefore, a protocol suitable for SPPP SHOULD be able to support
well as long lived connections. both short-lived as well as long-lived connections.
4.4. Authentication 4.4. Time value
Many use cases require the Server to authenticate the Client, and Some SPPP request and response messages include time value(s) defined
potentially also the Client to authenticate the Server. While as type xs:dateTime, a built-in W3C XML Schema Datatype. Use of
authentication of the Server by the Client is expected to be used unqualified local time is discouraged as it can lead to
only to prevent impersonation of the Server, authentication of the interoperability issues. The value of time attribute MUST BE
Client by the Server is expected to be used to identify and further expressed in Coordinated Universal Time (UTC) format without the
authorize the Client to certain resources on the Server. timezone digits.
Therefore, an SPPP transport protocol MUST provide means for a Server "2010-05-30T09:30:10Z" is an example of an acceptable time value for
to authenticate and authorize a Client, and MAY provide means for use in SPPP message. "2010-05-30T06:30:10+3:00" is a valid UTC time,
Clients to authenticate a Server. but it is not approved for use in SPPP message.
4.5. Confidentiality and Integrity 4.5. Authentication
Data that is transported over the protocol is deemed confidential. All SPPP objects are associated with a registrant identifier. SPPP
Therefore, a transport protocol suitable for SPPP MUST ensure Clients provisions SPPP objects on behalf of registrants. An
confidentiality and integrity protection by providing encryption authenticated SPP Client is a registrar. Therefore, the SPPP
capabilities. transport protocol MUST provide means for an SPPP server to
authenticate an SPPP Client.
Additionally, a DRINKS protocol MUST NOT use an unreliable lower- 4.6. Authorization
layer transport protocol that does not provide confidentiality and
integrity protection.
4.6. Near Real Time After successful authentication of the SPPP client as a registrar the
registry performs authorization checks to determine if the registrar
is authorized to act on behalf of the Registrant whose identifier is
included in the SPPP request. Refer to the Security Considerations
section for further guidance.
Many use cases require near real-time responses from the Server. 4.7. Confidentiality and Integrity
Therefore, a DRINKS transport protocol MUST support near-real-time
response to requests submitted by the Client.
4.7. Request and Response Sizes In some deployments, the SPPP objects that an SPPP registry manages
can be private in nature. As a result it MAY NOT be appropriate to
for transmission in plain text over a connection to the SPPP
registry. Therefore, the transport protocol SHOULD provide means for
end-to-end encryption between the SPPP client and server.
SPPP covers a range of use cases - from cases where provisioning a For some SPPP implementations, it may be acceptable for the data to
single public identifier will create very small request and response be transmitted in plain text, but the failure to detect a change in
sizes to cases where millions of data records are submitted or data after it leaves the SPPP client and before it is received at the
retrieved in one transaction. Therefore, a transport protocol server, either by accident or with a malicious intent, will adversely
suitable for SPPP MUST support a great variety of request and affect the stability and integrity of the registry. Therefore, the
response sizes. transport protocol SHOULD provide means for data integrity
protection.
A transport protocol MAY allow splitting large chunks of data into 4.8. Near Real Time
several smaller chunks.
4.8. Request and Response Correlation Many use cases require near real-time responses from the server.
Therefore, a DRINKS transport protocol MUST support near real-time
response to requests submitted by the client.
4.9. Request and Response Sizes
Use of SPPP may involve simple updates that may consist of small
number of bytes, such as, update of a single public identifier.
Other provisioning operations may constitute large number of datasets
as in adding millions records to a registry. As a result, a suitable
transport protocol for SPPP SHOULD accommodate datasets of various
sizes.
4.10. Request and Response Correlation
A transport protocol suitable for SPPP MUST allow responses to be A transport protocol suitable for SPPP MUST allow responses to be
correlated with requests. correlated with requests.
4.9. Request Acknowledgement 4.11. Request Acknowledgement
Data transported in the SPPP protocol is likely crucial for the Data transported in the SPPP is likely crucial for the operation of
operation of the communication network that is being provisioned. the communication network that is being provisioned. A SPPP client
responsible for provisioning SED to the registry has a need to know
if the submitted requests have been processed correctly.
Failed transactions can lead to situations where a subset of public Failed transactions can lead to situations where a subset of public
identifiers (or even SSPs) might not be reachable, or situations identifiers or even SSPs might not be reachable, or the provisioning
where the provisioning state of the network is inconsistent. state of the network is inconsistent.
Therefore, a transport protocol for SPPP MUST provide a Response for Therefore, a transport protocol for SPPP MUST provide a response for
each Request, so that a Client can identify whether a Request each request, so that a client can identify whether a request
succeeded or failed. succeeded or failed.
4.10. Mandatory Transport 4.12. Mandatory Transport
As of this writing of this revision, one transport protocol proposal
has been provided in [I-D.ietf-drinks-sppp-over-soap].
This section will define a mandatory transport protocol to be At the time of this writing, a choice of transport protocol has been
compliant with this RFC. provided in [I-D.ietf-drinks-sppp-over-soap]. To encourage
interoperability, the SPPP server MUST provide support for this
transport protocol. With time, it is possible that other transport
layer choices may surface that agree with the requirements discussed
above.
5. Base Protocol Data Structures 5. Base Protocol Data Structures
SPPP uses a common model and a common set of data structures for most SPPP uses a common model and a common set of data structures for most
of the supported operations and object types. This section describes of the supported operations and object types. This section describes
these common data structures. these common data structures.
5.1. Request and Response Structures 5.1. Request and Response Structures
An SPPP client interacts with an SPPP server by using one of the An SPPP client interacts with an SPPP server by using one of the
skipping to change at page 18, line 11 skipping to change at page 18, line 11
<simpleType name="TransIdType"> <simpleType name="TransIdType">
<restriction base="string"/> <restriction base="string"/>
</simpleType> </simpleType>
<simpleType name="MinorVerType"> <simpleType name="MinorVerType">
<restriction base="unsignedLong"/> <restriction base="unsignedLong"/>
</simpleType> </simpleType>
The data elements within the <spppUpdateRequest> element are The data elements within the <spppUpdateRequest> element are
described as follows: described as follows:
o clientTransId: Zero or one client generated transaction ID that, o clientTransId: Zero or one client-generated transaction ID that,
within the context of the SPPP client, identifies this request. within the context of the SPPP client, identifies this request.
This value can be used at the discretion of the SPPP client to This value can be used at the discretion of the SPPP client to
track, log or correlate requests and their responses. This track, log or correlate requests and their responses. SPPP
value is also echoed back to the client in the SPPP update server MUST echo back this value to the client in the
response. An SPPP server will not check this value for corresponding response to the incoming request. SPPP server
uniqueness. will not check this value for uniqueness.
o minorVer: Zero or one minor version identifier, indicating the o minorVer: Zero or one minor version identifier, indicating the
minor version of the SPPP API that the client is attempting to minor version of the SPPP API that the client is attempting to
use. This is used in conjunction with the major version use. This is used in conjunction with the major version
identifier in the XML namespace to identify the version of SPPP identifier in the XML namespace to identify the version of SPPP
that the client is using. If the element is not present, the that the client is using. If the element is not present, the
server assumes that the client is using the latest minor version server assumes that the client is using the latest minor version
supported by the SPPP server for the given major version. The supported by the SPPP server for the given major version. The
versions supported by a given SPPP server can be retrieved by versions supported by a given SPPP server can be retrieved by
the client using the SPPP server menu operation described later the client using the SPPP server menu operation described later
skipping to change at page 20, line 9 skipping to change at page 20, line 9
<extension base="spppb:ResultCodeType"> <extension base="spppb:ResultCodeType">
<sequence> <sequence>
<element name="rqstObj" type="spppb:BasicUpdateRqstType"/> <element name="rqstObj" type="spppb:BasicUpdateRqstType"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
An <spppUpdateResponse> contains the elements necessary for the SPPP An <spppUpdateResponse> contains the elements necessary for the SPPP
client to precisely determine the overal result of the request, and client to precisely determine the overall result of the request, and
if an error occurred, it provides information about the specific if an error occurred, it provides information about the specific
object, data element, or condition caused the error. object, data element, or condition caused the error.
The data elements within the SPPP update response are described as The data elements within the SPPP update response are described as
follows: follows:
o clientTransId: Zero or one client transaction ID. This value is o clientTransId: Zero or one client transaction ID. This value is
simply an echo of the client transaction ID that SPPP client simply an echo of the client transaction ID that SPPP client
passed into the SPPP update request. passed into the SPPP update request. When included in the
request, the SPPP server MUST return it in the corresponding
response message.
o serverTransId: Exactly one server transaction ID that identifies o serverTransId: Exactly one server transaction ID that identifies
this request for tracking purposes. This value is guaranteed to this request for tracking purposes. This value MUST be unique
be unique for a given SPPP server. for a given SPPP server.
o overallResult: Exactly one response code and message pair that o overallResult: Exactly one response code and message pair that
explicitly identifies the result of the request. See the explicitly identifies the result of the request. See the
Response Code section for further details. Response Code section for further details.
o rqstObjResult: An optional response code, response message, and o rqstObjResult: An optional response code, response message, and
BasicRqstObject triplet. This element will be present only if BasicRqstObject triplet. This element will be present only if
an object level error condition occurs, and indicates exactly an object level error has occurred. It indicates the error
which error condition occurred and exactly which request object condition and the exact request object that contributed to the
that was passed in caused the error condition. The contained error. The response code will reflect the exact error. See the
BasicRqstObject is simply an echo of the request object instance Response Code section for further details.
that caused the error, while the response code and message
indicate the error condition for this object. See the Response
Code section for further details.
o ext: This is the standard extension element for this object. o ext: This is the standard extension element for this object.
Refer to the Extensibility section for more details. Refer to the Extensibility section for more details.
5.1.2. Query Request and Response Structures 5.1.2. Query Request and Response Structures
At times, on behalf of the registrant, the registrar may need to have
access to SPPP objects that were previously provisioned in the
registry. A few examples include logging, auditing, and pre-
provisioning dependency checking. This query mechanism is limited to
aid provisioning scenarios and should not be confused with query
protocols provided as part of the resolution system (e.g. ENUM and
SIP).
An SPPP query request is wrapped within the <spppQueryRequest> An SPPP query request is wrapped within the <spppQueryRequest>
element while an SPPP query response is wrapped within an element while an SPPP query response is wrapped within an
<spppQueryResponse> element. The following two sub-sections describe <spppQueryResponse> element. The following two sub-sections describe
these two element structures. these two element structures.
5.1.2.1. Query Request 5.1.2.1. Query Request
An SPPP query request object is contained within the generic An SPPP query request object is contained within the generic
<spppQueryRequest> element. <spppQueryRequest> element.
skipping to change at page 22, line 26 skipping to change at page 22, line 30
<complexType> <complexType>
<sequence> <sequence>
<element name="overallResult" type="spppb:ResultCodeType"/> <element name="overallResult" type="spppb:ResultCodeType"/>
<element name="resultSet" type="spppb:BasicObjType" <element name="resultSet" type="spppb:BasicObjType"
minOccurs="0" maxOccurs=" unbounded"/> minOccurs="0" maxOccurs=" unbounded"/>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
An <spppQueryResponse> contains the elements necessary for the SPPP An <spppQueryResponse> contains the elements necessary for the SPPP
client to precisely determine the overal result of the query, and if client to precisely determine the overall result of the query, and if
an error occurred, exactly what condition caused the error. an error occurred, exactly what condition caused the error.
The data elements within the SPPP query response are described as The data elements within the SPPP query response are described as
follows: follows:
o overallResult: Exactly one response code and message pair that o overallResult: Exactly one response code and message pair that
explicitly identifies the result of the request. See the explicitly identifies the result of the request. See the
Response Code section for further details. Response Code section for further details.
o resultSet: The set of zero or more objects that matched the o resultSet: The set of zero or more objects that matched the
skipping to change at page 24, line 45 skipping to change at page 25, line 26
existing object do not exist. If the data elements used to existing object do not exist. If the data elements used to
uniquely identify an object are malformed, then response code uniquely identify an object are malformed, then response code
2104 SHOULD be returned. 2104 SHOULD be returned.
5.3. Basic Object Type and Organization Identifiers 5.3. Basic Object Type and Organization Identifiers
This section introduces the basic object type that most first class This section introduces the basic object type that most first class
objects derive from. objects derive from.
All first class objects extend the basic object type BasicObjType All first class objects extend the basic object type BasicObjType
which contains the identifier of the registrant organization that that contains the identifier of the registrant organization that owns
owns this object, the date and time that the object was created by this object, the date and time that the object was created by the
the server, and the date and time that the object was last modified. server, and the date and time that the object was last modified.
<complexType name="BasicObjType" abstract="true"> <complexType name="BasicObjType" abstract="true">
<sequence> <sequence>
<element name="rant" type="spppb:OrgIdType"/> <element name="rant" type="spppb:OrgIdType"/>
<element name="cDate" type="dateTime" minOccurs="0"/> <element name="cDate" type="dateTime" minOccurs="0"/>
<element name="mDate" type="dateTime" minOccurs="0"/> <element name="mDate" type="dateTime" minOccurs="0"/>
<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/> <element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
</sequence> </sequence>
</complexType> </complexType>
skipping to change at page 27, line 10 skipping to change at page 27, line 10
<sequence> <sequence>
<element name="dgName" type="spppb:ObjNameType"/> <element name="dgName" type="spppb:ObjNameType"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
The DestGrpType object is composed of the following elements: The DestGrpType object is composed of the following elements:
o base: All first class objects extend BasicObjType which contains o base: All first class objects extend BasicObjType that contains
the ID of the registrant organization that owns this object, the the ID of the registrant organization that owns this object, the
date and time that the object was created by the server, and the date and time that the object was created by the server, and the
date and time that the object was last modified. If the client date and time that the object was last modified. If the client
passed in either the created date or the modification date, the passed in either the created date or the modification date, the
server will ignore them. The server sets these two date/time server will ignore them. The server sets these two date/time
values. values.
o dgName: The character string that contains the name of the o dgName: The character string that contains the name of the
Destination Group. This uniquely identifies this object within Destination Group. This uniquely identifies this object within
the context of the registrant ID (a child element of the base the context of the registrant ID (a child element of the base
skipping to change at page 27, line 34 skipping to change at page 27, line 34
this document. this document.
As with the responses to all update operations, the result of the As with the responses to all update operations, the result of the
AddDestGrpRqstType operation is contained in the generic AddDestGrpRqstType operation is contained in the generic
spppUpdateResponse data structure described in an earlier sections of spppUpdateResponse data structure described in an earlier sections of
this document. For a detailed description of the spppUpdateResponse this document. For a detailed description of the spppUpdateResponse
data structure refer to that section of the document. data structure refer to that section of the document.
6.2. Get Destination Groups Operation 6.2. Get Destination Groups Operation
The getDestGrpsRqst operation allows a client to get the properties The getDestGrpsRqst operation allows an SPPP client to get the
of Destination Group objects that a registrar organization is properties of Destination Group objects that a registrar is
authorized to view. The server will attempt to find a Destination authorized to view on behalf of the registrant. The server will
Group object that has the registrant ID and destination group name attempt to find a Destination Group object that has the registrant ID
pair contained in each ObjKeyType object instance. If there are no and destination group name pair contained in each ObjKeyType object
matching Destination Groups found then an empty result set will be instance. If there are no matching Destination Groups found then an
returned. If the set of ObjKeyType objects passed in is empty then empty result set will be returned. If no ObjKeyType objects are
the server will return the list of Destination Group objects that the found in the request then the server will return the list of all
querying registrar has the authority to view. Destination Group objects in the registry. If no matching records
can be located then an empty result set will be returned.
The element passed into the spppQueryRequest element for this The element passed into the spppQueryRequest element for this
operation is an instance of type GetDestGrpsRqstType, which extends operation is an instance of type GetDestGrpsRqstType, which extends
BasicQueryRqstType and contains zero or more ObjKeyType objects. Any BasicQueryRqstType and contains zero or more ObjKeyType objects. Any
limitation on the maximum number of objects that may be passed into limitation on the maximum number of objects that may be passed into
or returned by this operation is a policy decision and not limited by or returned by this operation is a policy decision and not limited by
the protocol. The XSD declaration of the operation is as follows: the protocol. The XSD declaration of the operation is as follows:
<complexType name="GetDestGrpsRqstType"> <complexType name="GetDestGrpsRqstType">
<complexContent> <complexContent>
skipping to change at page 28, line 29 skipping to change at page 28, line 29
Refer to that section of the document for a detailed description of Refer to that section of the document for a detailed description of
the spppQueryResponse element. the spppQueryResponse element.
6.3. Add Public Identifier Operation 6.3. Add Public Identifier Operation
A Public Identifier is the search key used for locating the session A Public Identifier is the search key used for locating the session
establishment data (SED). In many cases, a Public Identifier is establishment data (SED). In many cases, a Public Identifier is
attributed to the end user who has a retail relationship with the attributed to the end user who has a retail relationship with the
service provider or registrant organization. SPPP supports the service provider or registrant organization. SPPP supports the
notion of the carrier-of-record as defined in RFC 5067. Therefore, notion of the carrier-of-record as defined in RFC 5067. Therefore,
the Registrant under which the Public Identity is being created can the registrant under which the Public Identity is being created can
optionally claim to be a carrier-of-record. optionally claim to be a carrier-of-record.
SPPP identifies two types of Public Identifiers: telephone numbers SPPP identifies two types of Public Identifiers: telephone numbers
(TN), and the routing numbers (RN). SPPP provides structures to (TN), and the routing numbers (RN). SPPP provides structures to
manage a single TN, a contiguous range of TNs, and a TN prefix. manage a single TN, a contiguous range of TNs, and a TN prefix.
The abstract XML schema type definition PubIDType is a generalization The abstract XML schema type definition PubIDType is a generalization
for the concrete the Public Identifier schema types. PubIDType for the concrete the Public Identifier schema types. PubIDType
element 'dgName' represents the name of the destination group that a element 'dgName' represents the name of the destination group that a
given Public Identifier is a member of. Because a Destination Group given Public Identifier is a member of. Because a Destination Group
is uniquely identified by its composite business key, which is is uniquely identified by its composite business key, which is
comprised of its Registrant ID, rantId, and its name, dgName, the comprised of its registrant ID, rantId, and its name, dgName, the
Public Identity's containing Destination Group is identified by the Public Identity's containing Destination Group is identified by the
Public Identity's dgName element and the Public Identity's registrant Public Identity's dgName element and the Public Identity's registrant
ID, rantId, element. The PubIDType object structure is defined as ID, rantId, element. The PubIDType object structure is defined as
follows: follows:
<complexType name="PubIdType" abstract="true"> <complexType name="PubIdType" abstract="true">
<complexContent> <complexContent>
<extension base="spppb:BasicObjType"> <extension base="spppb:BasicObjType">
<sequence> <sequence>
<element name="dgName" type="spppb:ObjNameType" minOccurs="0"/> <element name="dgName" type="spppb:ObjNameType" minOccurs="0"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
A registrant can add a Public Identifier using the AddPubIdRqstType A registrant can add a Public Identifier using the AddPubIdRqstType
operation. To complete the add request, AddPubIdRqstType XML operation. To complete the add request, AddPubIdRqstType XML
instance is populated into the <spppUpdateRequest> element. A Public instance is populated into the <spppUpdateRequest> element. A Public
Identifier may provisioned as a member of a Destination Group or Identifier may be provisioned as a member of a Destination Group or
provisioned outside of a Destination Group. A Public Identifier that provisioned outside of a Destination Group. A Public Identifier that
is provisioned as a member of a Destionation Group is intended to be is provisioned as a member of a Destination Group is intended to be
associated with its SED through the Route Group(s) that are associated with its SED through the Route Group(s) that are
associated with its containing Destination Group. A Public associated with its containing Destination Group. A Public
Identifier that is not provisioned as a member of a Destionation Identifier that is not provisioned as a member of a Destination Group
Group is intended to be associated with its SED through the Route is intended to be associated with its SED through the Route Records
Records that are directly associated with the Public Identifier. If that are directly associated with the Public Identifier. If a Public
a Public Identifier being added already exists then that Public Identifier being added already exists then that Public Identifier
Identifier will be replaced with the newly provisioned Public will be replaced with the newly provisioned Public Identifier.
Identifier.
A telephone number is provisioned using the TNType, an extension of A telephone number is provisioned using the TNType, an extension of
PubIDType. Each TNType object is uniquely identified by the PubIDType. Each TNType object is uniquely identified by the
combination of its tn element, and the unique key of its parent combination of its <tn> element, and the unique key of its parent
Destination Group (dgName and rantId). In other words a given Destination Group (dgName and rantId). In other words a given
telephone number string may exist within one or more Destination telephone number string may exist within one or more Destination
Groups, but must not exist more than once within a Destination Group. Groups, but must not exist more than once within a Destination Group.
TNType is defined as follows: TNType is defined as follows:
<complexType name="TNType"> <complexType name="TNType">
<complexContent> <complexContent>
<extension base="spppb:PubIdType"> <extension base="spppb:PubIdType">
<sequence> <sequence>
<element name="tn" type="string"/> <element name="tn" type="string"/>
skipping to change at page 30, line 4 skipping to change at page 29, line 49
<extension base="spppb:PubIdType"> <extension base="spppb:PubIdType">
<sequence> <sequence>
<element name="tn" type="string"/> <element name="tn" type="string"/>
<element name="rrRef" type="spppb:RteRecRefType" <element name="rrRef" type="spppb:RteRecRefType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<element name="corInfo" type="spppb:CORInfoType" <element name="corInfo" type="spppb:CORInfoType"
minOccurs="0"/> minOccurs="0"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
TNType consists of the following attributes: TNType consists of the following attributes:
o tn: Telephone number to be added to the Registry. o tn: Telephone number to be added to the registry.
o rrRef: Optional reference to route records that are directly o rrRef: Optional reference to route records that are directly
associated with the TN Public Identifier. Following the SPPP associated with the TN Public Identifier. Following the SPPP
data model, the route record could be a protocol agnostic data model, the route record could be a protocol agnostic
URIType or another type. URIType or another type.
o corInfo: corInfo is an optional parameter of type CORInfoType o corInfo: corInfo is an optional parameter of type CORInfoType
that allows the registrant organization to set forth a claim to that allows the registrant organization to set forth a claim to
be the carrier-of-record [see RFC 5067]. This is done by be the carrier-of-record [see RFC 5067]. This is done by
setting the value of <corClaim> element of the CORInfoType setting the value of <corClaim> element of the CORInfoType
object structure to "true". The other two parameters of the object structure to "true". The other two parameters of the
CORInfoType, <cor> and <corDate> are set by the Registry to CORInfoType, <cor> and <corDate> are set by the registry to
describe the outcome of the carrier-of-record claim by the describe the outcome of the carrier-of-record claim by the
registrant. In general, inclusion of <corInfo> parameter is registrant. In general, inclusion of <corInfo> parameter is
useful if the Registry has the authority information, such as, useful if the registry has the authority information, such as,
the number portability data, etc., in order to qualify whether the number portability data, etc., in order to qualify whether
the registrant claim can be satisfied. If the carrier-of-record the registrant claim can be satisfied. If the carrier-of-record
claim disagrees with the authority data in the Registry, whether claim disagrees with the authority data in the registry, whether
the TN add operation fails or not is a matter of policy and it the TN add operation fails or not is a matter of policy and it
is beyond the scope of this document. In the response message is beyond the scope of this document. In the response message
<spppUpdateResponse>, the SPPP Server must include the <cor> <spppUpdateResponse>, the SPPP server must include the <cor>
parameter of the <corInfo> element to let the registrant know parameter of the <corInfo> element to let the registrant know
the outcome of the claim. the outcome of the claim.
A routing number is provisioned using the RNType, an extension of A routing number is provisioned using the RNType, an extension of
PubIDType. SSPs that possess the number portability data may be able PubIDType. SSPs that possess the number portability data may be able
to leverage the RN search key to discover the ingress routes for to leverage the RN search key to discover the ingress routes for
session establishment. Therefore, the registrant organization can session establishment. Therefore, the registrant organization can
add the RN and associate it with the appropriate destination group to add the RN and associate it with the appropriate destination group to
share the route information. Each RNType object is uniquely share the route information. Each RNType object is uniquely
identified by the combination of its rn element, and the unique key identified by the combination of its <rn> element, and the unique key
of its parent Destination Group (dgName and rantId). In other words of its parent Destination Group (dgName and rantId). In other words
a given routing number string may exist within one or more a given routing number string may exist within one or more
Destination Groups, but must not exist more than once within a Destination Groups, but must not exist more than once within a
Destination Group. RNType is defined as follows: Destination Group. RNType is defined as follows:
<complexType name="RNType"> <complexType name="RNType">
<complexContent> <complexContent>
<extension base="spppb:PubIdType"> <extension base="spppb:PubIdType">
<sequence> <sequence>
<element name="rn" type="string"/> <element name="rn" type="string"/>
skipping to change at page 31, line 30 skipping to change at page 31, line 30
o corInfo: Optional <corInfo> element of type CORInfoType. o corInfo: Optional <corInfo> element of type CORInfoType.
TNRType structure is used to provision a contiguous range of TNRType structure is used to provision a contiguous range of
telephone numbers. The object definition requires a starting TN and telephone numbers. The object definition requires a starting TN and
an ending TN that together define the span of the TN range. Use of an ending TN that together define the span of the TN range. Use of
TNRType is particularly useful when expressing a TN range that does TNRType is particularly useful when expressing a TN range that does
not include all the TNs within a TN block or prefix. The TNRType not include all the TNs within a TN block or prefix. The TNRType
definition accommodates the open number plan as well such that the definition accommodates the open number plan as well such that the
TNs that fall between the start and end TN range may include TNs with TNs that fall between the start and end TN range may include TNs with
different length variance. Whether the Registry can accommodate the different length variance. Whether the registry can accommodate the
open number plan semantics is a matter of policy and is beyond the open number plan semantics is a matter of policy and is beyond the
scope of this document. Each TNRType object is uniquely identified scope of this document. Each TNRType object is uniquely identified
by the combination of its startTn and endTn elements, and the unique by the combination of its <startTn> and <endTn> elements, and the
key of its parent Destination Group (dgName and rantId). In other unique key of its parent Destination Group (dgName and rantId). In
words a given TN Range may exist within one or more Destination other words a given TN Range may exist within one or more Destination
Groups, but must not exist more than once within a Destination Group. Groups, but must not exist more than once within a Destination Group.
TNRType object structure definition is as follows: TNRType object structure definition is as follows:
<complexType name="TNRType"> <complexType name="TNRType">
<complexContent> <complexContent>
<extension base="spppb:PubIdType"> <extension base="spppb:PubIdType">
<sequence> <sequence>
<element name="startTn" type="string"/> <element name="startTn" type="string"/>
<element name="endTn" type="string"/> <element name="endTn" type="string"/>
<element name="corInfo" type="spppb:CORInfoType" <element name="corInfo" type="spppb:CORInfoType"
skipping to change at page 32, line 19 skipping to change at page 32, line 19
o startTn: Starting TN in the TN range o startTn: Starting TN in the TN range
o endTn: The last TN in the TN range o endTn: The last TN in the TN range
o corInfo: Optional <corInfo> element of type CORInfoType o corInfo: Optional <corInfo> element of type CORInfoType
In some cases, it is useful to describe a set of TNs with the help of In some cases, it is useful to describe a set of TNs with the help of
the first few digits of the telephone number, also referred to as the the first few digits of the telephone number, also referred to as the
telephone number prefix or a block. A given TN prefix may include telephone number prefix or a block. A given TN prefix may include
TNs with different length variance in support of open number plan. TNs with different length variance in support of open number plan.
Once again, whether the Registry supports the open number plan Once again, whether the registry supports the open number plan
semantics is a matter of policy and it is beyond the scope of this semantics is a matter of policy and it is beyond the scope of this
document. The TNPType data structure is used to provision a TN document. The TNPType data structure is used to provision a TN
prefix. Each TNPType object is uniquely identified by the prefix. Each TNPType object is uniquely identified by the
combination of its tnPrefix element, and the unique key of its parent combination of its <tnPrefix> element, and the unique key of its
Destination Group (dgName and rantId). TNPType is defined as parent Destination Group (dgName and rantId). TNPType is defined as
follows: follows:
<complexType name="TNPType"> <complexType name="TNPType">
<complexContent> <complexContent>
<extension base="spppb:PubIdType"> <extension base="spppb:PubIdType">
<sequence> <sequence>
<element name="tnPrefix" type="string"/> <element name="tnPrefix" type="string"/>
<element name="corInfo" type="spppb:CORInfoType" <element name="corInfo" type="spppb:CORInfoType"
minOccurs="0"/> minOccurs="0"/>
</sequence> </sequence>
skipping to change at page 35, line 36 skipping to change at page 35, line 36
<complexType name="RteRecRefType"> <complexType name="RteRecRefType">
<sequence> <sequence>
<element name="rrKey" type="spppb:ObjKeyType"/> <element name="rrKey" type="spppb:ObjKeyType"/>
<element name="priority" type="unsignedShort"/> <element name="priority" type="unsignedShort"/>
<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/> <element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
</sequence> </sequence>
</complexType> </complexType>
The RteGrpType object is composed of the following elements: The RteGrpType object is composed of the following elements:
o base: All first class objects extend BasicObjType which contains o base: All first class objects extend BasicObjType that contains
the ID of the registrant organization that owns this object, the the ID of the registrant organization that owns this object, the
date and time that the object was created by the server, and the date and time that the object was created by the server, and the
date and time that the object was last modified. If the client date and time that the object was last modified. If the client
passes in either the created date or the modification date, the passes in either the created date or the modification date, the
server will ignore them. The server sets these two date/time server will ignore them. The server sets these two date/time
values. values.
o rgName: The character string that contains the name of the Route o rgName: The character string that contains the name of the Route
Group. It uniquely identifies this object within the context of Group. It uniquely identifies this object within the context of
the registrant ID (a child element of the base element as the registrant ID (a child element of the base element as
skipping to change at page 38, line 20 skipping to change at page 38, line 20
this document. this document.
As with the responses to all update operations, the result of the As with the responses to all update operations, the result of the
AddRteGrpRqstType operation is contained in the generic AddRteGrpRqstType operation is contained in the generic
spppUpdateResponse data structure described in an earlier sections of spppUpdateResponse data structure described in an earlier sections of
this document. For a detailed description of the spppUpdateResponse this document. For a detailed description of the spppUpdateResponse
data structure refer to that section of the document. data structure refer to that section of the document.
6.6. Get Route Groups Operation 6.6. Get Route Groups Operation
The getRteGrpsRqst operation allows a client to get the properties of The getRteGrpsRqst operation allows a SPPP client to get the
Route Group objects that a registrar organization is authorized to properties of Route Group objects that the registrar is authorized to
view. The server will attempt to find a Route Group object that has view on behalf of the registrant. The server will attempt to find a
the registrant ID and route group name pair contained in each Route Group object that has the registrant ID and route group name
ObjKeyType object instance. If the set of ObjKeyType objects is pair contained in each ObjKeyType object instance. If no ObjKeyType
empty then the server will return the list of Route Group objects objects are found in the request then the server will return the list
that the querying client has the authority to view. If there are no of all Route Group objects that belongs to the registrant. If there
matching Route Groups found then an empty result set will be are no matching Route Groups found then an empty result set will be
returned. returned.
The element passed into the spppQueryRequest element for this The element passed into the spppQueryRequest element for this
operation is an instance of type GetRteGrpsRqstType, which extends operation is an instance of type GetRteGrpsRqstType, which extends
BasicUpdateRqstType and contains zero or more ObjKeyType objects. BasicUpdateRqstType and contains zero or more ObjKeyType objects.
Any limitation on the maximum number of objects that may be passed Any limitation on the maximum number of objects that may be passed
into or returned by this operation is a policy decision and not into or returned by this operation is a policy decision and not
limited by the protocol. The XSD declaration of the operation is as limited by the protocol. The XSD declaration of the operation is as
follows: follows:
skipping to change at page 39, line 16 skipping to change at page 39, line 16
Refer to that section of the document for a detailed description of Refer to that section of the document for a detailed description of
the spppQueryResponse element. the spppQueryResponse element.
6.7. Add Route Record Operation 6.7. Add Route Record Operation
As described in the introductory sections, a Route Group represents a As described in the introductory sections, a Route Group represents a
combined grouping of Route Records that define route information. combined grouping of Route Records that define route information.
However, Route Records need not be created to just serve a single However, Route Records need not be created to just serve a single
Route Group. Route Records can be created and managed to serve Route Group. Route Records can be created and managed to serve
multiple Route Groups. As a result, a change to the properties of a multiple Route Groups. As a result, a change to the properties of a
network node, for example, that is used for multiple routes, would network node used for multiple routes, would necessitate just a
necessitate just a single update operation to change the properties single update operation to change the properties of that node. The
of that node. The change would then be reflected in all the Route change would then be reflected in all the Route Groups whose route
Groups whose route record set contains a reference to that node. record set contains a reference to that node.
The AddRteRecRqstType operation creates or overwrites a Route Record The AddRteRecRqstType operation creates or overwrites a Route Record
object. If a Route Record with the given name and registrant ID object. If a Route Record with the given name and registrant ID
(which together comprise the unique key or a Route Record) does not (which together comprise the unique key or a Route Record) does not
exist, then the server MUST create the Route Record. If a Route exist, then the server MUST create the Route Record. If a Route
Record with the given name and registrant ID does exist, then the Record with the given name and registrant ID does exist, then the
server MUST replace the current properties of the Route Record with server MUST replace the current properties of the Route Record with
the properties passed into the AddRteRecRqstType operation. The XSD the properties passed into the AddRteRecRqstType operation. The XSD
declarations of the AddRteRecRqstType operation request object are as declarations of the AddRteRecRqstType operation request object are as
follows: follows:
skipping to change at page 40, line 18 skipping to change at page 40, line 18
<sequence> <sequence>
<element name="rrName" type="spppb:ObjNameType"/> <element name="rrName" type="spppb:ObjNameType"/>
<element name="priority" type="unsignedShort" minOccurs="0"/> <element name="priority" type="unsignedShort" minOccurs="0"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
The RteRecType object is composed of the following elements: The RteRecType object is composed of the following elements:
o base: All first class objects extend BasicObjType which contains o base: All first class objects extend BasicObjType that contains
the ID of the registrant organization that owns this object, the the ID of the registrant organization that owns this object, the
date and time that the object was created by the server, and the date and time that the object was created by the server, and the
date and time that the object was last modified. If the client date and time that the object was last modified. If the client
passes in either the created date or the modification date, the passes in either the created date or the modification date, the
server will ignore them. The server sets these two date/time server will ignore them. The server sets these two date/time
values. values.
o rrName: The character string that contains the name of the Route o rrName: The character string that contains the name of the Route
Record. It uniquely identifies this object within the context Record. It uniquely identifies this object within the context
of the registrant ID (a child element of the base element as of the registrant ID (a child element of the base element as
skipping to change at page 40, line 42 skipping to change at page 40, line 42
a relative value weighting of one Route Record over another. a relative value weighting of one Route Record over another.
The manner in which this value is used, perhaps in conjunction The manner in which this value is used, perhaps in conjunction
with other factors, is a matter of policy. with other factors, is a matter of policy.
As described above, route records are based on an abstract type: As described above, route records are based on an abstract type:
RteRecType. The concrete types that use RteRecType as an extension RteRecType. The concrete types that use RteRecType as an extension
base are NAPTRType, NSType, and URIType. The definitions of these base are NAPTRType, NSType, and URIType. The definitions of these
types are included below. The NAPTRType object is comprised of the types are included below. The NAPTRType object is comprised of the
data elements necessary for a NAPTR that contains routing information data elements necessary for a NAPTR that contains routing information
for a Route Group. The NSType object is comprised of the data for a Route Group. The NSType object is comprised of the data
elements necessary for a Name Server that points to another DNS elements necessary for a DNS name server that points to another DNS
server that contains the desired routing information. The NSType is server that contains the desired routing information. The NSType is
relevant only when the resolution protocol is ENUM. The URIType relevant only when the resolution protocol is ENUM. The URIType
object is comprised of the data elements necessary to house a URI. object is comprised of the data elements necessary to house a URI.
The data provisioned in a Registry can be leveraged for many purposes The data provisioned in a registry can be leveraged for many purposes
and queried using various protocols including SIP, ENUM and others. and queried using various protocols including SIP, ENUM and others.
It is for this reason that a route record type offers a choice of URI It is for this reason that a route record type offers a choice of URI
and DNS resource record types. URIType fulfills the need for both and DNS resource record types. URIType fulfills the need for both
SIP and ENUM protocols. When a given URIType is associated to a SIP and ENUM protocols. When a given URIType is associated to a
destination group, the user part of the replacement string <uri> that destination group, the user part of the replacement string <uri> that
may require the Public Identifier cannot be preset. As a SIP may require the Public Identifier cannot be preset. As a SIP
Redirect, the resolution server will apply <ere> pattern on the input Redirect, the resolution server will apply <ere> pattern on the input
Public Identifier in the query and process the replacement string by Public Identifier in the query and process the replacement string by
substituting any back reference(s) in the <uri> to arrive at the substituting any back reference(s) in the <uri> to arrive at the
final URI that is returned in the SIP Contact header. For an ENUM final URI that is returned in the SIP Contact header. For an ENUM
skipping to change at page 42, line 32 skipping to change at page 42, line 32
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
The NAPTRType object is composed of the following elements: The NAPTRType object is composed of the following elements:
o order: Order value in an ENUM NAPTR, relative to other NAPTRType o order: Order value in an ENUM NAPTR, relative to other NAPTRType
objects in the same Route Group. objects in the same Route Group.
o svcs: ENUM service(s) that are served by the SBE. This field's o svcs: ENUM service(s) that are served by the SBE. This field's
value must be of the form specified in [RFC3761] (e.g., E2U+ value must be of the form specified in [RFC6116] (e.g., E2U+
pstn:sip+sip). The allowable values are a matter of policy and pstn:sip+sip). The allowable values are a matter of policy and
not limited by this protocol. not limited by this protocol.
o regx: NAPTR's regular expression field. If this is not included o regx: NAPTR's regular expression field. If this is not included
then the Repl field must be included. then the Repl field must be included.
o repl: NAPTR replacement field, should only be provided if the o repl: NAPTR replacement field, should only be provided if the
Regex field is not provided, otherwise it will be ignored by the Regex field is not provided, otherwise the server will ignore it
server.
o ttl: Number of seconds that an addressing server may cache this o ttl: Number of seconds that an addressing server may cache this
NAPTR. NAPTR.
o ext: Point of extensibility described in a previous section of o ext: Point of extensibility described in a previous section of
this document. this document.
The NSType object is composed of the following elements: The NSType object is composed of the following elements:
o hostName: Fully qualified host name of the name server. o hostName: Fully qualified host name of the name server.
o ipAddr: Zero or more objects of type IpAddrType. Each object o ipAddr: Zero or more objects of type IpAddrType. Each object
holds an IP Address and the IP Address type, IPv4 or IP v6. holds an IP Address and the IP Address type, IPv4 or IP v6.
o ttl: Number of seconds that an addressing server may cache this o ttl: Number of seconds that an addressing server may cache this
Name Server. DNS name server.
o ext: Point of extensibility described in a previous section of o ext: Point of extensibility described in a previous section of
this document. this document.
The URIType object is composed of the following elements: The URIType object is composed of the following elements:
o ere: The POSIX Extended Regular Expression (ere) as defined in o ere: The POSIX Extended Regular Expression (ere) as defined in
[RFC3986]. [RFC3986].
o uri: the URI as defined in [RFC3986]. In some cases, this will o uri: the URI as defined in [RFC3986]. In some cases, this will
skipping to change at page 43, line 33 skipping to change at page 43, line 33
resolution server to arrive at the final usable URI. resolution server to arrive at the final usable URI.
As with the responses to all update operations, the result of the As with the responses to all update operations, the result of the
AddRteRecRqstType operation is contained in the generic AddRteRecRqstType operation is contained in the generic
spppUpdateResponse data structure described in an earlier sections of spppUpdateResponse data structure described in an earlier sections of
this document. For a detailed description of the spppUpdateResponse this document. For a detailed description of the spppUpdateResponse
data structure refer to that section of the document. data structure refer to that section of the document.
6.8. Get Route Records Operation 6.8. Get Route Records Operation
The getRteRecsRqst operation allows a client to get the properties of The getRteRecsRqst operation allows a SPPP client to get the
Route Record objects that a registrar organization is authorized to properties of Route Record objects that a registrar is authorized to
view. The server will attempt to find a Route Record object that has view on behalf of the registrant. The server will attempt to find a
the registrant ID and route record name pair contained in each Route Record object that has the registrant ID and route record name
ObjKeyType object instance. If the set of ObjKeyType objects is pair contained in each ObjKeyType object instance. If no ObjKeyType
empty then the server will return the list of Route Record objects objects are found in the request then the server will return the list
that the querying client has the authority to view. If there are no of all Route Record that belongs to the registrant. If there are no
matching Route Record found then an empty result set will be matching Route Record found then an empty result set will be
returned. returned.
The element passed into the spppQueryRequest element for this The element passed into the spppQueryRequest element for this
operation is an instance of type GetRteRecsRqstType, which extends operation is an instance of type GetRteRecsRqstType, which extends
BasicUpdateRqstType and contains zero or more ObjKeyType objects. BasicUpdateRqstType and contains zero or more ObjKeyType objects.
Any limitation on the maximum number of objects that may be passed Any limitation on the maximum number of objects that may be passed
into or returned by this operation is a policy decision and not into or returned by this operation is a policy decision and not
limited by the protocol. The XSD declaration of the operation is as limited by the protocol. The XSD declaration of the operation is as
follows: follows:
skipping to change at page 44, line 38 skipping to change at page 44, line 38
requests (a data recipient, also know as a peering organization). requests (a data recipient, also know as a peering organization).
The registrant offers access to a Route Group by submitting a Route The registrant offers access to a Route Group by submitting a Route
Group Offer. The data recipient can then accept or reject that Group Offer. The data recipient can then accept or reject that
offer. Not until access to a Route Group has been offered and offer. Not until access to a Route Group has been offered and
accepted will the data recipient's organization ID be included in the accepted will the data recipient's organization ID be included in the
peeringOrg list in a Route Group object, and that Route Group's peeringOrg list in a Route Group object, and that Route Group's
peering information become a candidate for inclusion in the responses peering information become a candidate for inclusion in the responses
to the resolution requests submitted by that data recipient. The to the resolution requests submitted by that data recipient. The
AddRteGrpOffersRqstType operation creates or overwrites one or more AddRteGrpOffersRqstType operation creates or overwrites one or more
Route Group Offer objects. If a Route Group Offer for the given Route Group Offer objects. If a Route Group Offer for the given
Route Group object key and the offeredTo Org ID does not exist, then Route Group object key and the <offeredTo> Org ID does not exist,
the server creates the Route Group Offer object. If a such a Route then the server creates the Route Group Offer object. If a such a
Group Offer does exist, then the server replaces the current object Route Group Offer does exist, then the server replaces the current
with the new object. The XSD declarations of the operation request object with the new object. The XSD declarations of the operation
object are as follows: request object are as follows:
<complexType name="AddRteGrpOfferRqstType"> <complexType name="AddRteGrpOfferRqstType">
<complexContent> <complexContent>
<extension base="spppb:BasicUpdateRqstType"> <extension base="spppb:BasicUpdateRqstType">
<sequence> <sequence>
<element name="rteGrpOffer" type="spppb:RteGrpOfferType"/> <element name="rteGrpOffer" type="spppb:RteGrpOfferType"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
skipping to change at page 46, line 6 skipping to change at page 46, line 6
</complexType> </complexType>
<simpleType name="RteGrpOfferStatusType"> <simpleType name="RteGrpOfferStatusType">
<restriction base="token"> <restriction base="token">
<enumeration value="offered"/> <enumeration value="offered"/>
<enumeration value="accepted"/> <enumeration value="accepted"/>
</restriction> </restriction>
</simpleType> </simpleType>
The RteGrpOfferType object is composed of the following elements: The RteGrpOfferType object is composed of the following elements:
o base: All first class objects extend BasicObjType which contains o base: All first class objects extend BasicObjType that contains
the ID of the registrant organization that owns this object, the the ID of the registrant organization that owns this object, the
date and time that the object was created by the server, and the date and time that the object was created by the server, and the
date and time that the object was last modified. If the client date and time that the object was last modified. If the client
passed in either the created date or the modification date, the passed in either the created date or the modification date, the
will ignore them. The server sets these two date/time values. will ignore them. The server sets these two date/time values.
o rteGrpOfferKey: The object that identifies the route that is or o rteGrpOfferKey: The object that identifies the route that is or
has been offered and the organization that it is or has been has been offered and the organization that it is or has been
offered to. The combination of these three data elements offered to. The combination of these three data elements
uniquely identify a Route Group Offer. uniquely identify a Route Group Offer.
o status: The status of the offer, offered or accepted. This o status: The status of the offer, offered or accepted. The
status is controlled by the server. It is automatically set to server controls the status. It is automatically set to
"offered" when ever a new Route Group Offer is added, and is "offered" when ever a new Route Group Offer is added, and is
automatically set to "accepted" if and when that offer is automatically set to "accepted" if and when that offer is
accepted. The value of the element is ignored when passed in by accepted. The value of the element is ignored when passed in by
the client. the client.
o offerDateTime: Date and time in GMT when the Route Group Offer o offerDateTime: Date and time in UTC when the Route Group Offer
was added. was added.
o acceptDateTime: Date and time in GMT when the Route Group Offer o acceptDateTime: Date and time in UTC when the Route Group Offer
was accepted. was accepted.
As with the responses to all update operations, the result of the As with the responses to all update operations, the result of the
AddRteGrpOfferRqstType operation is contained in the generic AddRteGrpOfferRqstType operation is contained in the generic
spppUpdateResponse data structure described in an earlier sections of spppUpdateResponse data structure described in an earlier sections of
this document. For a detailed description of the spppUpdateResponse this document. For a detailed description of the spppUpdateResponse
data structure refer to that section of the document. data structure refer to that section of the document.
6.10. Accept Route Group Offer Operation 6.10. Accept Route Group Offer Operation
skipping to change at page 47, line 40 skipping to change at page 47, line 40
option of rejecting a Route Group Offer. Furthermore, that offer may option of rejecting a Route Group Offer. Furthermore, that offer may
be rejected, regardless of whether or not it has been previously be rejected, regardless of whether or not it has been previously
accepted. The RejectRteGrpOffersRqstType operation is used for these accepted. The RejectRteGrpOffersRqstType operation is used for these
purposes and is called by, or on behalf of, the data recipient to purposes and is called by, or on behalf of, the data recipient to
accept a Route Group Offer that is pending in the "offered" status or accept a Route Group Offer that is pending in the "offered" status or
is in the "accepted" status for the data recipient's organization ID. is in the "accepted" status for the data recipient's organization ID.
If a Route Group Offer for the given Route Group Offer key (route If a Route Group Offer for the given Route Group Offer key (route
name, route registrant ID, data recipient's organization ID) exists name, route registrant ID, data recipient's organization ID) exists
in either the offered or accepted status, then the server deletes in either the offered or accepted status, then the server deletes
that Route Group Offer object, and, if appropriate, removes the data that Route Group Offer object, and, if appropriate, removes the data
recipients organization ID from the list of peeringOrg IDs for that recipient's organization ID from the list of peeringOrg IDs for that
Route Group. If the Route Group Offer does not exist, then the Route Group. If the Route Group Offer does not exist, then the
server returns the appropriate error code, 2105. The XSD server returns the appropriate error code, 2105. The XSD
declarations for the operation request object are as follows: declarations for the operation request object are as follows:
<complexType name="RejectRteGrpOfferRqstType"> <complexType name="RejectRteGrpOfferRqstType">
<complexContent> <complexContent>
<extension base="spppb:BasicUpdateRqstType"> <extension base="spppb:BasicUpdateRqstType">
<sequence> <sequence>
<element name="rteGrpOfferKey" type="spppb:RteGrpOfferKeyType"/> <element name="rteGrpOfferKey" type="spppb:RteGrpOfferKeyType"/>
</sequence> </sequence>
skipping to change at page 48, line 27 skipping to change at page 48, line 27
BasicUpdateRqstType and contains a RteGrpOfferKeyType object. BasicUpdateRqstType and contains a RteGrpOfferKeyType object.
As with the responses to all update operations, the result of the As with the responses to all update operations, the result of the
RejectRteGrpOfferRqstType operation is contained in the generic RejectRteGrpOfferRqstType operation is contained in the generic
spppUpdateResponse data structure described in an earlier sections of spppUpdateResponse data structure described in an earlier sections of
this document. For a detailed description of the spppUpdateResponse this document. For a detailed description of the spppUpdateResponse
data structure refer to that section of the document. data structure refer to that section of the document.
6.12. Get Route Group Offers Operation 6.12. Get Route Group Offers Operation
The getRteGrpOffersRqst operation allows a client to get the The getRteGrpOffersRqst operation allows a SPPP client to get the
properties of zero or more Route Group Offer objects that registrar properties of zero or more Route Group Offer objects that registrar
is authorized to view. The server will attempt to find Route Group is authorized to view on behalf of the registrant. The server will
Offer objects that have all the properties specified in the criteria attempt to find Route Group Offer objects that have all the
passed into the operation. If no criteria is passed in then the properties specified in the criteria passed into the operation. If
server will return the list of Route Group Offer objects that the no criteria is passed in then the server will return the list of
querying client has the authority to view. If there are no matching Route Group Offer objects that belongs to the registrant. If there
Route Group Offers found then an empty result set will be returned. are no matching Route Group Offers found then an empty result set
will be returned.
The element passed into the spppQueryRequest element for this The element passed into the spppQueryRequest element for this
operation is an instance of GetRteGrpOffersRqstType, which extends operation is an instance of GetRteGrpOffersRqstType, which extends
BasicQueryRqstType and contains the criteria that the returned Route BasicQueryRqstType and contains the criteria that the returned Route
Group Offer objects must match. Any limitation on the maximum number Group Offer objects must match. Any limitation on the maximum number
of objects that may be returned by this operation is a policy of objects that may be returned by this operation is a policy
decision and not limited by the protocol. The XSD declaration of the decision and not limited by the protocol. The XSD declaration of the
operation is as follows: operation is as follows:
<complexType name="GetRteGrpOffersRqstType"> <complexType name="GetRteGrpOffersRqstType">
skipping to change at page 50, line 15 skipping to change at page 50, line 15
6.13. Egress Route Operations 6.13. Egress Route Operations
In a high-availability environment, the originating SSP likely has In a high-availability environment, the originating SSP likely has
more than one egress paths to the ingress SBE of the target SSP. If more than one egress paths to the ingress SBE of the target SSP. If
the originating SSP wants to exercise greater control and choose a the originating SSP wants to exercise greater control and choose a
specific egress SBE to be associated to the target ingress SBE, it specific egress SBE to be associated to the target ingress SBE, it
can do so using the AddEgrRteRqstType object. can do so using the AddEgrRteRqstType object.
Lets assume that the target SSP has offered to share one or more Lets assume that the target SSP has offered to share one or more
ingress route information and that the originating SSP has accepted ingress route information and that the originating SSP has accepted
the offer. In order to add the egress route to the Registry, the the offer. In order to add the egress route to the registry, the
originating SSP uses a valid regular expression to rewrite ingress originating SSP uses a valid regular expression to rewrite ingress
route in order to include the egress SBE information. Also, more route in order to include the egress SBE information. Also, more
than one egress route can be associated with a given ingress route in than one egress route can be associated with a given ingress route in
support of fault-tolerant configurations. The supporting SPPP support of fault-tolerant configurations. The supporting SPPP
protocol structure provides a way to include route precedence structure provides a way to include route precedence information to
information to help manage traffic to more than one outbound egress help manage traffic to more than one outbound egress SBE.
SBE.
An egress route is identified by type EgrRteType and its object An egress route is identified by type EgrRteType and its object
structure is shown below: structure is shown below:
<complexType name="EgrRteType"> <complexType name="EgrRteType">
<complexContent> <complexContent>
<extension base="spppb:BasicObjType"> <extension base="spppb:BasicObjType">
<sequence> <sequence>
<element name="egrRteName" type="spppb:ObjNameType"/> <element name="egrRteName" type="spppb:ObjNameType"/>
<element name="pref" type="unsignedShort"/> <element name="pref" type="unsignedShort"/>
skipping to change at page 50, line 44 skipping to change at page 50, line 43
<element name="ingrRteRec" type="spppb:ObjKeyType" <element name="ingrRteRec" type="spppb:ObjKeyType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/> <element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
The EgrRteType object is composed of the following elements: The EgrRteType object is composed of the following elements:
o base: All first class objects extend BasicObjType which contains o base: All first class objects extend BasicObjType that contains
the ID of the registrant organization that owns this object, the the ID of the registrant organization that owns this object, the
date and time that the object was created by the server, and the date and time that the object was created by the server, and the
date and time that the object was last modified. If the client date and time that the object was last modified. If the client
passes in either the created date or the modification date, the passes in either the created date or the modification date, the
server will ignore them. The server sets these two date/time server will ignore them. The server sets these two date/time
values. values.
o egrRteName: The name of the egress route. o egrRteName: The name of the egress route.
o pref: The preference of this egress route relative to other o pref: The preference of this egress route relative to other
skipping to change at page 52, line 18 skipping to change at page 52, line 18
<sequence> <sequence>
<element name="objKey" type="spppb:ObjKeyType" <element name="objKey" type="spppb:ObjKeyType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
6.14. Delete Operation 6.14. Delete Operation
In order to remove an object from the Registry, an authorized entity In order to remove an object from the registry, an authorized entity
can send the <spppUpdateRequest> to the Registry with a corresponding can send the <spppUpdateRequest> to the registry with a corresponding
delete BasicUpdateRqstType object. Each 'Add' operation in SPPP has delete BasicUpdateRqstType object. Each 'Add' operation in SPPP has
a corresponding 'Del' operation, which is used to delete the a corresponding 'Del' operation, which is used to delete the
respective object type from the Registry. If the entity that issued respective object type from the registry. If the entity that issued
the command is not authorized to perform this operation an the command is not authorized to perform this operation an
appropriate error code will be returned in the <spppUpdateRespnonse> appropriate error code will be returned in the <spppUpdateRespnonse>
message. message.
As an example, DelPubIdRqstType is used to delete Public Identifiers As an example, DelPubIdRqstType is used to delete Public Identifiers
The DelPubIdsRqstType object definition is shown below: The DelPubIdsRqstType object definition is shown below:
<complexType name="DelPubIdRqstType"> <complexType name="DelPubIdRqstType">
<complexContent> <complexContent>
<extension base="spppb:BasicUpdateRqstType"> <extension base="spppb:BasicUpdateRqstType">
skipping to change at page 53, line 25 skipping to change at page 53, line 25
by the SPPP implementation as part of fulfilling the deletion by the SPPP implementation as part of fulfilling the deletion
request. Furthermore, route group offers relating that route request. Furthermore, route group offers relating that route
group must also be deleted as part of fulfilling the deletion group must also be deleted as part of fulfilling the deletion
request. request.
o Route Records: When a route record is deleted any references o Route Records: When a route record is deleted any references
between that route record and any route group must be removed by between that route record and any route group must be removed by
the SPPP implementation as part of fulfilling the deletion the SPPP implementation as part of fulfilling the deletion
request. request.
o Puplic Identifiers: When a public identifier is deleted any o Public Identifiers: When a public identifier is deleted any
references between that public identifier and its containing references between that public identifier and its containing
destination group must be removed by the SPPP implementation as destination group must be removed by the SPPP implementation as
part of fulfilling the deletion request. And any route records part of fulfilling the deletion request. And any route records
contained directly within that Public Identifier must be deleted contained directly within that Public Identifier must be deleted
by the SPPP implementation as part of fulfilling the deletion by the SPPP implementation as part of fulfilling the deletion
request. request.
7. SPPP Examples 7. SPPP Examples
This section shows XML message exchange between two SIP Service This section shows XML message exchange between two SIP Service
Providers (SSP) and a Registry. For the sake of simplicity, the Providers (SSP) and a registry. For the sake of simplicity, the
transport wrapper for the SPPP protocol is left out. The SPPP transport wrapper for the SPPP is left out. The SPPP messages in
protocol messages in this section are valid XML instances that this section are valid XML instances that conform to the SPPP schema
conform to the SPPP schema version within this document. version within this document.
In this sample use case scenario, SSP1 and SSP2 provision resource In this sample use case scenario, SSP1 and SSP2 provision resource
data in the registry and use SPPP constructs to selectively share the data in the registry and use SPPP constructs to selectively share the
route groups. In the figure below, SSP2 has two ingress SBE route groups. In the figure below, SSP2 has two ingress SBE
instances that are associated with the public identities that SSP2 instances that are associated with the public identities that SSP2
has the retail relationship with. Also, the two SBE instances for has the retail relationship with. Also, the two SBE instances for
SSP1 are used to show how to use SPPP protocol to associate route SSP1 are used to show how to use SPPP to associate route preferences
preferences for the destination ingress routes and exercise greater for the destination ingress routes and exercise greater control on
control on outbound traffic to the peer's ingress SBEs. outbound traffic to the peer's ingress SBEs.
---------------+ +------------------ ---------------+ +------------------
| | | |
+------+ +------+ +------+ +------+
| sbe1 | | sbe2 | | sbe1 | | sbe2 |
+------+ +------+ +------+ +------+
SSP1 | | SSP2 SSP1 | | SSP2
+------+ +------+ +------+ +------+
| sbe3 | | sbe4 | | sbe3 | | sbe4 |
+------+ +------+ +------+ +------+
iana-en:111 | | iana-en:222 iana-en:111 | | iana-en:222
---------------+ +------------------ ---------------+ +------------------
| | | |
| | | |
| SPPP +------------------+ SPPP | | SPPP +------------------+ SPPP |
+------->| Registry |<--------+ +------->| Registry |<--------+
+------------------+ +------------------+
7.1. Add Destination Group 7.1. Add Destination Group
SSP2 adds a destination group to the Registry for use later. The SSP2 adds a destination group to the registry for use later. The
SSP2 SPPP client sets a unique transaction identifier 'tx_7777' for SSP2 SPPP client sets a unique transaction identifier 'tx_7777' for
tracking purposes. The name of the destination group is set to tracking purposes. The name of the destination group is set to
DEST_GRP_SSP2_1 DEST_GRP_SSP2_1
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<spppUpdateRequest <spppUpdateRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd" xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
xmlns="urn:ietf:params:xml:ns:sppp:base:1"> xmlns="urn:ietf:params:xml:ns:sppp:base:1">
<clientTransId>txid-5555</clientTransId> <clientTransId>txid-5555</clientTransId>
<rqst xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1" <rqst xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"
xsi:type="ns1:AddDestGrpRqstType"> xsi:type="ns1:AddDestGrpRqstType">
<destGrp> <destGrp>
<ns1:rant>iana-en:222</ns1:rant> <ns1:rant>iana-en:222</ns1:rant>
<dgName>DEST_GRP_SSP2_1</dgName> <dgName>DEST_GRP_SSP2_1</dgName>
</destGrp> </destGrp>
</rqst> </rqst>
</spppUpdateRequest> </spppUpdateRequest>
The Registry processes the request and return a favorable response The registry processes the request and return a favorable response
confirming successful creation of the named destination group. Also, confirming successful creation of the named destination group. Also,
besides returning a unique transaction identifier, Registry also besides returning a unique transaction identifier, Registry also
returns the matching client transaction identifier from the request returns the matching client transaction identifier from the request
message back to the SPPP client. message back to the SPPP client.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<spppUpdateResponse <spppUpdateResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd" xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
xmlns="urn:ietf:params:xml:ns:sppp:base:1"> xmlns="urn:ietf:params:xml:ns:sppp:base:1">
<clientTransId>tx_5555</clientTransId> <clientTransId>tx_5555</clientTransId>
<serverTransId>tx_id_12346</serverTransId> <serverTransId>tx_id_12346</serverTransId>
<overallResult> <overallResult>
<code>1000</code> <code>1000</code>
<msg>success</msg> <msg>success</msg>
</overallResult> </overallResult>
</spppUpdateResponse> </spppUpdateResponse>
7.2. Add Route Records 7.2. Add Route Records
SSP2 adds an ingress routes in the Registry. SSP2 adds an ingress routes in the registry.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<spppUpdateRequest <spppUpdateRequest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd" xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
xmlns="urn:ietf:params:xml:ns:sppp:base:1"> xmlns="urn:ietf:params:xml:ns:sppp:base:1">
<rqst xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1" <rqst xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"
xsi:type="ns1:AddRteRecRqstType"> xsi:type="ns1:AddRteRecRqstType">
<rteRec xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1" <rteRec xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"
xsi:type="ns1:NAPTRType"> xsi:type="ns1:NAPTRType">
skipping to change at page 56, line 27 skipping to change at page 56, line 27
<flags>u</flags> <flags>u</flags>
<svcs>E2U+sip</svcs> <svcs>E2U+sip</svcs>
<regx> <regx>
<ere>^(.*)$</ere> <ere>^(.*)$</ere>
<repl>sip:\1@sbe2.ssp2.example.com</repl> <repl>sip:\1@sbe2.ssp2.example.com</repl>
</regx> </regx>
</rteRec> </rteRec>
</rqst> </rqst>
</spppUpdateRequest> </spppUpdateRequest>
The Registry returns a success response. The registry returns a success response.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<spppUpdateResponse <spppUpdateResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd" xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
xmlns="urn:ietf:params:xml:ns:sppp:base:1"> xmlns="urn:ietf:params:xml:ns:sppp:base:1">
<serverTransId>tx_id_11145</serverTransId> <serverTransId>tx_id_11145</serverTransId>
<overallResult> <overallResult>
<code>1000</code> <code>1000</code>
<msg>Request successful</msg> <msg>Request successful</msg>
</overallResult> </overallResult>
</spppUpdateResponse> </spppUpdateResponse>
7.3. Add Route Records -- URIType 7.3. Add Route Records -- URIType
SSP2 adds another ingress routes in the Registry and makes use of SSP2 adds another ingress routes in the registry and makes use of
URIType URIType
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<spppUpdateRequest> <spppUpdateRequest>
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd" xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
xmlns="urn:ietf:params:xml:ns:sppp:base:1"> xmlns="urn:ietf:params:xml:ns:sppp:base:1">
<rqst xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1" <rqst xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"
xsi:type="ns1:AddRteRecRqstType"> xsi:type="ns1:AddRteRecRqstType">
<rteRec xsi:type="ns1:URIType"> <rteRec xsi:type="ns1:URIType">
<rant>iana-en:222</rant> <rant>iana-en:222</rant>
<rrName>RTE_SSP2_SBE4</rrName> <rrName>RTE_SSP2_SBE4</rrName>
<ere>^(.*)$</ere> <ere>^(.*)$</ere>
<uri>sip:\1;npdi@sbe4.ssp2.example.com</uri> <uri>sip:\1;npdi@sbe4.ssp2.example.com</uri>
</rteRec> </rteRec>
</rqst> </rqst>
</spppUpdateRequest> </spppUpdateRequest>
The Registry returns a success response. The registry returns a success response.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<spppUpdateResponse <spppUpdateResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd" xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
xmlns="urn:ietf:params:xml:ns:sppp:base:1"> xmlns="urn:ietf:params:xml:ns:sppp:base:1">
<serverTransId>tx_id_11145</serverTransId> <serverTransId>tx_id_11145</serverTransId>
<overallResult> <overallResult>
<code>1000</code> <code>1000</code>
<msg>Request successful</msg> <msg>Request successful</msg>
skipping to change at page 58, line 29 skipping to change at page 58, line 29
</rrKey> </rrKey>
<priority>100</priority> <priority>100</priority>
</rrRef> </rrRef>
<dgName>DEST_GRP_SSP2_1</dgName> <dgName>DEST_GRP_SSP2_1</dgName>
<isInSvc>true</isInSvc> <isInSvc>true</isInSvc>
<ns1:priority>10</ns1:priority> <ns1:priority>10</ns1:priority>
</rteGrp> </rteGrp>
</rqst> </rqst>
</spppUpdateRequest> </spppUpdateRequest>
To confirm successful processing of this request, Registry returns a To confirm successful processing of this request, registry returns a
well-known resolution code '1000' to the SSP2 client. well-known resolution code '1000' to the SSP2 client.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<spppUpdateResponse <spppUpdateResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd" xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
xmlns="urn:ietf:params:xml:ns:sppp:base:1"> xmlns="urn:ietf:params:xml:ns:sppp:base:1">
<serverTransId>tx_id_12345</serverTransId> <serverTransId>tx_id_12345</serverTransId>
<overallResult> <overallResult>
<code>1000</code> <code>1000</code>
skipping to change at page 59, line 24 skipping to change at page 59, line 24
<cDate>2010-05-30T09:30:10Z</cDate> <cDate>2010-05-30T09:30:10Z</cDate>
<dgName>DEST_GRP_SSP2_1</dgName> <dgName>DEST_GRP_SSP2_1</dgName>
<tn>+12025556666</tn> <tn>+12025556666</tn>
<corInfo> <corInfo>
<corClaim>true</corClaim> <corClaim>true</corClaim>
</corInfo> </corInfo>
</pi> </pi>
</rqst> </rqst>
</spppUpdateRequest> </spppUpdateRequest>
Assuming that the Registry has access to TN authority data and it Assuming that the registry has access to TN authority data and it
performs the required checks to verify that SSP2 is in fact the performs the required checks to verify that SSP2 is in fact the
service provider of record for the given TN, the request is processed service provider of record for the given TN, the request is processed
successfully. In the response message, the Registry sets the value successfully. In the response message, the registry sets the value
of <cor> to "true" in order to confirm SSP2 claim as the carrier of of <cor> to "true" in order to confirm SSP2 claim as the carrier of
record and the <corDate> reflects the time when the carrier of record record and the <corDate> reflects the time when the carrier of record
claim is processed. claim is processed.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<spppUpdateResponse <spppUpdateResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd" xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
xmlns="urn:ietf:params:xml:ns:sppp:base:1"> xmlns="urn:ietf:params:xml:ns:sppp:base:1">
<clientTransId>txid-5577</clientTransId> <clientTransId>txid-5577</clientTransId>
skipping to change at page 64, line 28 skipping to change at page 64, line 28
<offeredTo>iana-en:111</offeredTo> <offeredTo>iana-en:111</offeredTo>
</rteGrpOfferKey> </rteGrpOfferKey>
<status>offered</status> <status>offered</status>
<offerDateTime>2006-05-04T18:13:51.0Z</offerDateTime> <offerDateTime>2006-05-04T18:13:51.0Z</offerDateTime>
</rteGrpOffer> </rteGrpOffer>
</rqst> </rqst>
</spppUpdateRequest> </spppUpdateRequest>
Registry completes the request successfully and confirms that the Registry completes the request successfully and confirms that the
SSP1 will now have the opportunity to weigh in on the offer and SSP1 will now have the opportunity to weigh in on the offer and
either accept or reject it. The Registry may employ out-of-band either accept or reject it. The registry may employ out-of-band
notification mechanisms for quicker updates to SSP1 so they can act notification mechanisms for quicker updates to SSP1 so they can act
faster, though this topic is beyond the scope of this document. faster, though this topic is beyond the scope of this document.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<spppUpdateResponse <spppUpdateResponse
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd" xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
xmlns="urn:ietf:params:xml:ns:sppp:base:1"> xmlns="urn:ietf:params:xml:ns:sppp:base:1">
<serverTransId>tx_id_12277798</serverTransId> <serverTransId>tx_id_12277798</serverTransId>
<overallResult> <overallResult>
skipping to change at page 73, line 19 skipping to change at page 73, line 19
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"> xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd">
<serverTransId>txid-982543123</serverTransId> <serverTransId>txid-982543123</serverTransId>
<overallResult> <overallResult>
<code>1000</code> <code>1000</code>
<msg>Success</msg> <msg>Success</msg>
</overallResult> </overallResult>
</spppUpdateResponse> </spppUpdateResponse>
7.18. Delete Public Identity 7.18. Delete Public Identity
SSP2 choses to de-activate the TN and remove it from the Registry. SSP2 choses to de-activate the TN and remove it from the registry.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<spppUpdateRequest xmlns="urn:ietf:params:xml:ns:sppp:base:1" <spppUpdateRequest xmlns="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"> xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd">
<rqst xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1" <rqst xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"
xsi:type="ns1:DelPubIdRqstType"> xsi:type="ns1:DelPubIdRqstType">
<pi xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1" <pi xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"
xsi:type="ns1:TNType"> xsi:type="ns1:TNType">
<rant>iana-en:222</rant> <rant>iana-en:222</rant>
skipping to change at page 77, line 21 skipping to change at page 77, line 21
XML is case sensitive. Unless stated otherwise, XML specifications XML is case sensitive. Unless stated otherwise, XML specifications
and examples provided in this document MUST be interpreted in the and examples provided in this document MUST be interpreted in the
character case presented to develop a conforming implementation. character case presented to develop a conforming implementation.
This section discusses a small number of XML-related considerations This section discusses a small number of XML-related considerations
pertaining to SPPP. pertaining to SPPP.
8.1. Namespaces 8.1. Namespaces
All SPPP protocol elements are defined in the namespaces in the IANA All SPPP elements are defined in the namespaces in the IANA
Considerations section and in the Formal Protocol Specification Considerations section and in the Formal Protocol Specification
section of this document. section of this document.
8.2. Versioning and Character Encoding 8.2. Versioning and Character Encoding
All XML instances SHOULD begin with an <?xml?> declaration to All XML instances SHOULD begin with an <?xml?> declaration to
identify the version of XML that is being used, optionally identify identify the version of XML that is being used, optionally identify
use of the character encoding used, and optionally provide a hint to use of the character encoding used, and optionally provide a hint to
an XML parser that an external schema file is needed to validate the an XML parser that an external schema file is needed to validate the
XML instance. XML instance.
skipping to change at page 78, line 7 skipping to change at page 78, line 7
attribute in the XML declaration is OPTIONAL if UTF-8 encoding is attribute in the XML declaration is OPTIONAL if UTF-8 encoding is
used. SPPP clients and servers MUST accept a UTF-8 BOM if present, used. SPPP clients and servers MUST accept a UTF-8 BOM if present,
though emitting a UTF-8 BOM is NOT RECOMMENDED. though emitting a UTF-8 BOM is NOT RECOMMENDED.
Example XML declarations: Example XML declarations:
<?xml?> version="1.0" encoding="UTF-8" standalone="no"?> <?xml?> version="1.0" encoding="UTF-8" standalone="no"?>
9. Security Considerations 9. Security Considerations
SPPP implementations manage data that is considered confidential and Many SPPP implementations manage data that is considered confidential
critical. Furthermor, SPPP implementations can support provisioning and critical. Furthermore, SPPP implementations can support
activities for multiple registrars and registrants. As a result any provisioning activities for multiple registrars and registrants. As
SPPP implementation must address the requirements for a result any SPPP implementation must address the requirements for
confidentiality, authentication, and authorization. confidentiality, authentication, and authorization.
With respect to confidentiality and authentication, the transport With respect to confidentiality and authentication, the transport
protocol section contains some security properties that the transport protocol requirements section of this document contains security
protocol must provide so that authenticated endpoints can exchange properties that the transport protocol must provide so that
data confidentially and with integrity protection. authenticated endpoints can exchange data confidentially and with
integrity protection. Refer to that section and the resulting
transport protocol specification document for the specific solutions
to authentication and confidentiality.
With respect to authorization, the SPPP server implementation must With respect to authorization, the SPPP server implementation must
define and implement a set of authorization rules that precisely define and implement a set of authorization rules that precisely
address (1) which registrars will be authorized to create/modify/ address (1) which registrars will be authorized to create/modify/
delete each SPPP object type for given registrant(s) and (2) which delete each SPPP object type for given registrant(s) and (2) which
registrars will be authorized to view/get each SPPP object type for a registrars will be authorized to view/get each SPPP object type for
given registrant(s). These authorization rules are left as a matter given registrant(s). These authorization rules are a matter of
of policy and are not specified within the context of SPPP. However, policy and are not specified within the context of SPPP. However,
any SPPP implementation must specify these authorization rules in any SPPP implementation must specify these authorization rules in
order to function in a realiable and safe manner. order to function in a reliable and safe manner.
10. IANA Considerations 10. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688]. conforming to a registry mechanism described in [RFC3688].
Two URI assignments are requested. Two URI assignments are requested.
Registration request for the SPPP XML namespace: Registration request for the SPPP XML namespace:
urn:ietf:params:xml:ns:sppp:base:1 urn:ietf:params:xml:ns:sppp:base:1
skipping to change at page 80, line 7 skipping to change at page 80, line 7
known enterprise namespaces. known enterprise namespaces.
This document makes the following assignments for the OrgIdType This document makes the following assignments for the OrgIdType
namespaces: namespaces:
Namespace OrgIdType namespace string Namespace OrgIdType namespace string
---- ---------------------------- ---- ----------------------------
IANA Enterprise Numbers iana-en IANA Enterprise Numbers iana-en
11. Formal Specification 11. Formal Specification
This section provides the draft XML Schema Definition for the SPPP This section provides the draft XML Schema Definition for SPPP.
protocol.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<schema xmlns:spppb="urn:ietf:params:xml:ns:sppp:base:1" <schema xmlns:spppb="urn:ietf:params:xml:ns:sppp:base:1"
xmlns="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:sppp:base:1" targetNamespace="urn:ietf:params:xml:ns:sppp:base:1"
elementFormDefault="qualified" xml:lang="EN"> elementFormDefault="qualified" xml:lang="EN">
<annotation> <annotation>
<documentation> <documentation>
------------------ Object Type Definitions -------------- ------------------ Object Type Definitions --------------
</documentation> </documentation>
skipping to change at page 94, line 11 skipping to change at page 94, line 11
Alexander Mayrhofer, Deborah A Guyton, David Schwartz, Lisa Alexander Mayrhofer, Deborah A Guyton, David Schwartz, Lisa
Dusseault, Manjul Maharishi, Mickael Marrache, Otmar Lendl, Richard Dusseault, Manjul Maharishi, Mickael Marrache, Otmar Lendl, Richard
Shockey, Samuel Melloul, and Sumanth Channabasappa. Shockey, Samuel Melloul, and Sumanth Channabasappa.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-drinks-sppp-over-soap] [I-D.ietf-drinks-sppp-over-soap]
Cartwright, K., "SPPP Over SOAP and HTTP", Cartwright, K., "SPPP Over SOAP and HTTP",
draft-ietf-drinks-sppp-over-soap-02 (work in progress), draft-ietf-drinks-sppp-over-soap-04 (work in progress),
February 2011. July 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998. Languages", BCP 18, RFC 2277, January 1998.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
skipping to change at page 94, line 45 skipping to change at page 94, line 45
(work in progress), March 2011. (work in progress), March 2011.
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
10646", RFC 2781, February 2000. 10646", RFC 2781, February 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation [RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation
Architecture", RFC 4725, November 2006. Architecture", RFC 4725, November 2006.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia
Interconnect (SPEERMINT) Terminology", RFC 5486, Interconnect (SPEERMINT) Terminology", RFC 5486,
March 2009. March 2009.
[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)", RFC 6116,
March 2011.
Authors' Addresses Authors' Addresses
Jean-Francois Mule Jean-Francois Mule
CableLabs CableLabs
858 Coal Creek Circle 858 Coal Creek Circle
Louisville, CO 80027 Louisville, CO 80027
USA USA
Email: jfm@cablelabs.com Email: jfm@cablelabs.com
 End of changes. 129 change blocks. 
396 lines changed or deleted 408 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/