< draft-ietf-drinks-spp-framework-10.txt   draft-ietf-drinks-spp-framework-11.txt >
DRINKS K. Cartwright DRINKS K. Cartwright
Internet-Draft V. Bhatia Internet-Draft V. Bhatia
Intended status: Standards Track TNS Intended status: Standards Track TNS
Expires: September 26, 2015 S. Ali Expires: January 23, 2016 S. Ali
NeuStar NeuStar
D. Schwartz D. Schwartz
XConnect XConnect
March 25, 2015 July 22, 2015
Session Peering Provisioning Framework (SPPF) Session Peering Provisioning Framework (SPPF)
draft-ietf-drinks-spp-framework-10 draft-ietf-drinks-spp-framework-11
Abstract Abstract
This document specifies the data model and the overall structure for This document specifies the data model and the overall structure for
a framework to provision session establishment data into Session Data a framework to provision session establishment data into Session Data
Registries and SIP Service Provider data stores. The framework is Registries and SIP Service Provider data stores. The framework is
called the Session Peering Provisioning Framework (SPPF). The called the Session Peering Provisioning Framework (SPPF). The
provisioned data is typically used by network elements for session provisioned data is typically used by network elements for session
establishment. establishment.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 September 26, 2015. This Internet-Draft will expire on January 23, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 18 skipping to change at page 2, line 18
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Framework High Level Design . . . . . . . . . . . . . . . . . 7 3. Framework High Level Design . . . . . . . . . . . . . . . . . 7
3.1. Framework Data Model . . . . . . . . . . . . . . . . . . 7 3.1. Framework Data Model . . . . . . . . . . . . . . . . . . 7
3.2. Time Value . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Time Value . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10
4. Transport Protocol Requirements . . . . . . . . . . . . . . . 11 4. Transport Substrate Protocol Requirements . . . . . . . . . . 11
4.1. Connection Oriented . . . . . . . . . . . . . . . . . . . 11 4.1. Mandatory Substrate . . . . . . . . . . . . . . . . . . . 11
4.2. Request and Response Model . . . . . . . . . . . . . . . 11 4.2. Connection Oriented . . . . . . . . . . . . . . . . . . . 11
4.3. Connection Lifetime . . . . . . . . . . . . . . . . . . . 11 4.3. Request and Response Model . . . . . . . . . . . . . . . 11
4.4. Authentication . . . . . . . . . . . . . . . . . . . . . 11 4.4. Connection Lifetime . . . . . . . . . . . . . . . . . . . 11
4.5. Authorization . . . . . . . . . . . . . . . . . . . . . . 12 4.5. Authentication . . . . . . . . . . . . . . . . . . . . . 12
4.6. Confidentiality and Integrity . . . . . . . . . . . . . . 12 4.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 12
4.7. Near Real Time . . . . . . . . . . . . . . . . . . . . . 12 4.7. Confidentiality and Integrity . . . . . . . . . . . . . . 12
4.8. Request and Response Sizes . . . . . . . . . . . . . . . 12 4.8. Near Real Time . . . . . . . . . . . . . . . . . . . . . 12
4.9. Request and Response Correlation . . . . . . . . . . . . 12 4.9. Request and Response Sizes . . . . . . . . . . . . . . . 12
4.10. Request Acknowledgement . . . . . . . . . . . . . . . . . 12 4.10. Request and Response Correlation . . . . . . . . . . . . 13
4.11. Mandatory Transport . . . . . . . . . . . . . . . . . . . 13 4.11. Request Acknowledgement . . . . . . . . . . . . . . . . . 13
5. Base Framework Data Structures and Response Codes . . . . . . 13 5. Base Framework Data Structures and Response Codes . . . . . . 13
5.1. Basic Object Type and Organization Identifiers . . . . . 13 5.1. Basic Object Type and Organization Identifiers . . . . . 13
5.2. Various Object Key Types . . . . . . . . . . . . . . . . 14 5.2. Various Object Key Types . . . . . . . . . . . . . . . . 14
5.2.1. Generic Object Key Type . . . . . . . . . . . . . . . 14 5.2.1. Generic Object Key Type . . . . . . . . . . . . . . . 14
5.2.2. Derived Object Key Types . . . . . . . . . . . . . . 15 5.2.2. Derived Object Key Types . . . . . . . . . . . . . . 15
5.3. Response Message Types . . . . . . . . . . . . . . . . . 16 5.3. Response Message Types . . . . . . . . . . . . . . . . . 16
6. Framework Data Model Objects . . . . . . . . . . . . . . . . 18 6. Framework Data Model Objects . . . . . . . . . . . . . . . . 18
6.1. Destination Group . . . . . . . . . . . . . . . . . . . . 18 6.1. Destination Group . . . . . . . . . . . . . . . . . . . . 18
6.2. Public Identifier . . . . . . . . . . . . . . . . . . . . 19 6.2. Public Identifier . . . . . . . . . . . . . . . . . . . . 19
6.3. SED Group . . . . . . . . . . . . . . . . . . . . . . . . 24 6.3. SED Group . . . . . . . . . . . . . . . . . . . . . . . . 24
skipping to change at page 3, line 9 skipping to change at page 3, line 9
7.4. Accept Operations . . . . . . . . . . . . . . . . . . . . 38 7.4. Accept Operations . . . . . . . . . . . . . . . . . . . . 38
7.5. Reject Operations . . . . . . . . . . . . . . . . . . . . 38 7.5. Reject Operations . . . . . . . . . . . . . . . . . . . . 38
7.6. Get Server Details Operation . . . . . . . . . . . . . . 39 7.6. Get Server Details Operation . . . . . . . . . . . . . . 39
8. XML Considerations . . . . . . . . . . . . . . . . . . . . . 39 8. XML Considerations . . . . . . . . . . . . . . . . . . . . . 39
8.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . . 39 8.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . . 39
8.2. Versioning and Character Encoding . . . . . . . . . . . . 39 8.2. Versioning and Character Encoding . . . . . . . . . . . . 39
9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
9.1. Confidentiality and Authentication . . . . . . . . . . . 40 9.1. Confidentiality and Authentication . . . . . . . . . . . 40
9.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 40 9.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 40
9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 40 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 40
9.3.1. DoS Issues Inherited from Transport Mechanism . . . . 41 9.3.1. DoS Issues Inherited from Substrate Mechanism . . . . 41
9.3.2. DoS Issues Specific to SPPF . . . . . . . . . . . . . 41 9.3.2. DoS Issues Specific to SPPF . . . . . . . . . . . . . 41
9.4. Information Disclosure . . . . . . . . . . . . . . . . . 42 9.4. Information Disclosure . . . . . . . . . . . . . . . . . 42
9.5. Non Repudiation . . . . . . . . . . . . . . . . . . . . . 42 9.5. Non-repudiation . . . . . . . . . . . . . . . . . . . . . 42
9.6. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 42 9.6. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 42
9.7. Man in the Middle . . . . . . . . . . . . . . . . . . . . 43 9.7. Man in the Middle . . . . . . . . . . . . . . . . . . . . 43
10. Internationalization Considerations . . . . . . . . . . . . . 43 10. Internationalization Considerations . . . . . . . . . . . . . 43
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
11.1. URN Assignments . . . . . . . . . . . . . . . . . . . . 43 11.1. URN Assignments . . . . . . . . . . . . . . . . . . . . 43
11.2. Organization Identifier Namespace Registry . . . . . . . 44 11.2. Organization Identifier Namespace Registry . . . . . . . 44
12. Formal Specification . . . . . . . . . . . . . . . . . . . . 44 12. Formal Specification . . . . . . . . . . . . . . . . . . . . 44
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
14.1. Normative References . . . . . . . . . . . . . . . . . . 53 14.1. Normative References . . . . . . . . . . . . . . . . . . 53
14.2. Informative References . . . . . . . . . . . . . . . . . 53 14.2. Informative References . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
Service providers and enterprises use routing databases known as Service providers and enterprises use routing databases known as
registries to make session routing decisions for Voice over IP, SMS Registries to make session routing decisions for Voice over IP, SMS
and MMS traffic exchanges. This document is narrowly focused on the and MMS traffic exchanges. This document is narrowly focused on the
provisioning framework for these registries. This framework provisioning framework for these registries. This framework
prescribes a way for an entity to provision session-related data into prescribes a way for an entity to provision session-related data into
a Registry. The data being provisioned can be optionally shared with a SPPP Registry (or "Registry"). The data being provisioned can be
other participating peering entities. The requirements and use cases optionally shared with other participating peering entities. The
driving this framework have been documented in [RFC6461]. requirements and use cases driving this framework have been
documented in [RFC6461].
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, Registry to local data repository and document: client to Registry, Registry to local data repository and
Registry to Registry. This document addresses client to Registry Registry to Registry. This document addresses client to Registry
flow enabling the need to provision Session Establishment Data (SED). flow enabling the ability to provision Session Establishment Data
The framework that supports flow of messages to facilitate client to (SED). The framework that supports flow of messages to facilitate
Registry provisioning is referred to as Session Peering Provisioning client to Registry provisioning is referred to as Session Peering
Framework (SPPF). Provisioning Framework (SPPF).
The role of the "client" and the "server" only applies to the The roles of the "client" and the "server" only apply to the
connection, and those roles are not related in any way to the type of connection, and those roles are not related in any way to the type of
entity that participates in a protocol exchange. For example, a entity that participates in a protocol exchange. For example, a
Registry might also include a "client" when such a Registry initiates Registry might also include a "client" when such a Registry initiates
a connection (for example, for data distribution to SSP). a connection (for example, for data distribution to SSP).
*--------* *------------* *------------* *--------* *------------* *------------*
| | (1). Client | | (3).Registry | | | | (1). Client | | (3).Registry | |
| Client | ------------> | Registry |<------------->| Registry | | Client | ------------> | Registry |<------------->| Registry |
| | to Registry | | to Registry | | | | to Registry | | to Registry | |
*--------* *------------* *------------* *--------* *------------* *------------*
skipping to change at page 4, line 49 skipping to change at page 4, line 49
See [RFC5486] for more details. See [RFC5486] for more details.
A Registry may distribute the provisioned data into local data A Registry may distribute the provisioned data into local data
repositories or may additionally offer a central query resolution repositories or may additionally offer a central query resolution
service (not shown in the above figure) for query purposes. service (not shown in the above figure) for query purposes.
A key requirement for the SPPF is to be able to accommodate two basic A key requirement for the SPPF is to be able to accommodate two basic
deployment scenarios: deployment scenarios:
1. A resolution system returns a Look-Up Function (LUF) that 1. A resolution system returns a Look-Up Function (LUF) that
comprises the target domain to assist in call routing (as identifies the target domain to assist in call routing (as
described in [RFC5486]). In this case, the querying entity may described in Section 4.3.3 of [RFC5486]). In this case, the
use other means to perform the Location Routing Function (LRF) querying entity may use other means to perform the Location
which in turn helps determine the actual location of the Routing Function (LRF) which in turn helps determine the actual
Signaling Function in that domain. location of the Signaling Function in that domain.
2. A resolution system returns a Location Routing Function (LRF) 2. A resolution system returns a Location Routing Function (LRF)
that comprises the location (address) of the signaling function that comprises the location (address) of the signaling function
in the target domain (as described in [RFC5486]). in the target domain (as described in [RFC5486]).
In terms of framework design, SPPF is agnostic to the transport In terms of framework design, SPPF is agnostic to the substrate
protocol. This document includes the specification of the data model protocol. This document includes the specification of the data model
and identifies, but does not specify, the means to enable protocol and identifies, but does not specify, the means to enable protocol
operations within a request and response structure. That aspect of operations within a request and response structure. That aspect of
the specification has been delegated to the "protocol" specification the specification has been delegated to the "protocol" specification
for the framework. To encourage interoperability, the framework for the framework. To encourage interoperability, the framework
supports extensibility aspects. supports extensibility aspects.
In this document, XML schema is used to describe the building blocks In this document, XML schema is used to describe the building blocks
of the SPPF and to express the data types, the semantic relationships of the SPPF and to express the data types, the semantic relationships
between the various data types, and the various constraints as a between the various data types, and the various constraints as a
skipping to change at page 5, line 35 skipping to change at page 5, line 35
example, XML and JSON are two widely used data representation example, XML and JSON are two widely used data representation
formats. formats.
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 SPPF, including functional o Section 3 provides an overview of SPPF, including functional
entities and data model entities and data model
o Section 4 specifies requirements for SPPF transport protocols o Section 4 specifies requirements for SPPF substrate protocols
o Section 5 describes the base framework data structures, the o Section 5 describes the base framework data structures, the
generic response types that MUST be supported by a conforming generic response types that MUST be supported by a conforming
transport "protocol" specification, and the basic object type most substrate "protocol" specification, and the basic object type most
first class objects extend from first class objects extend from
o Section 6 provides a detailed description of the data model object o Section 6 provides a detailed description of the data model object
specifications specifications
o Section 7 describes the operations that are supported by the data o Section 7 describes the operations that are supported by the data
model model
o Section 8 defines XML considerations XML parsers must meet to o Section 8 defines XML considerations XML parsers must meet to
conform to this specification conform to this specification
skipping to change at page 6, line 22 skipping to change at page 6, line 22
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
This document reuses terms from [RFC3261], [RFC5486], use cases and This document reuses terms from [RFC3261], [RFC5486], use cases and
requirements documented in [RFC6461] and the ENUM Validation requirements documented in [RFC6461] and the ENUM Validation
Architecture [RFC4725]. Architecture [RFC4725].
In addition, this document specifies the following additional terms: This document defines the following additional terms:
SPPF: Session Peering Provisioning Framework, the framework used by SPPF: Session Peering Provisioning Framework, the framework used by
a transport protocol to provision data into a Registry (see arrow a substrate protocol to provision data into a Registry (see arrow
labeled "1." in Figure 1 of [RFC6461]). It is the primary scope labeled "1." in Figure 1 of [RFC6461]). It is the primary scope
of this document. of this document.
Client: In the context of SPPF, this is an application that Client: In the context of SPPF, this is an application that
initiates a provisioning request. It is sometimes referred to as initiates a provisioning request. It is sometimes referred to as
a "Registry client". a "Registry client".
Server: In the context of SPPF, this is an application that Server: In the context of SPPF, this is an application that
receives a provisioning request and responds accordingly. It is receives a provisioning request and responds accordingly.
sometimes referred to as a Registry.
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.
Registrant: The definition of a Registrant is based on [RFC4725]. Registrant: The definition of a Registrant is based on [RFC4725].
It is the end-user, the person or organization that is the It is the end-user, the person or organization that is the
"holder" of the Session Establishment Data being provisioned into "holder" of the Session Establishment Data being provisioned into
the Registry by a Registrar. For example, in [RFC6461], a the Registry by a Registrar. For example, in [RFC6461], a
Registrant is pictured as a SIP Service Provider in Figure 2. Registrant is pictured as a Service Provider in Figure 2.
Within the confines of a Registry, a Registrant is uniquely Within the confines of a Registry, a Registrant is uniquely
identified by a well-known ID. identified by the 'rant' element.
Registrar: The definition of a Registrar is based on [RFC4725]. It Registrar: The definition of a Registrar is based on [RFC4725]. It
is an entity that performs provisioning operations on behalf of a is an entity that performs provisioning operations on behalf of a
Registrant by interacting with the Registry via SPPF operations. Registrant by interacting with the Registry via SPPF operations.
In other words the Registrar is the SPPF Client. The Registrar In other words the Registrar is the SPPF Client. The Registrar
and Registrant roles are logically separate to allow, but not and Registrant roles are logically separate to allow, but not
require, a single Registrar to perform provisioning operations on require, a single Registrar to perform provisioning operations on
behalf of more than one Registrant. behalf of more than one Registrant.
Peering Organization: A Peering Organization is an entity to which Peering Organization: A Peering Organization is an entity to which
a Registrant's SED Groups are made visible using the operations of a Registrant's SED Groups are made visible using the operations of
SPPF. SPPF.
3. Framework High Level Design 3. Framework 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 SPPF. The data model is defined the information framework for the SPPF. The data model is defined
along with all the objects manipulated by a conforming transport along with all the objects manipulated by a conforming substrate
protocol and their relationships. protocol and their relationships.
3.1. Framework Data Model 3.1. Framework Data Model
The data model illustrated and described in Figure 2 defines the The data model illustrated and described in Figure 2 defines the
logical objects and the relationships between these objects supported logical objects and the relationships between these objects supported
by SPPF. SPPF defines protocol operations through which an SPPF by SPPF. SPPF defines protocol operations through which an SPPF
client populates a Registry with these logical objects. SPPF clients client populates a Registry with these logical objects. SPPF clients
belonging to different Registrars may provision data into the belonging to different Registrars may provision data into the
Registry using a conforming transport protocol that implements these Registry using a conforming substrate protocol that implements these
operations operations
The logical structure presented below is consistent with the The logical structure presented below is consistent with the
terminology and requirements defined in [RFC6461]. terminology and requirements defined in [RFC6461].
+-------------+ +-----------------+ +-------------+ +-----------------+
| all object | |Egress Route: | | all object | |Egress Route: |
| types | 0..n | rant, | | types | 0..n | rant, |
+-------------+ +--| egrRteName, | +-------------+ +--| egrRteName, |
|0..n / | pref, | |0..n / | pref, |
| / | regxRewriteRule,| | / | regxRewriteRule,|
|2 / | ingrSedGrp, | |2 / | ingrSedGrp, |
+----------------------+ / | svcs | +----------------------+ / | svcs |
|Organization: | / +-----------------+ |Organization: | / +-----------------+
| orgId | / | orgId | /
+----------------------+ / +----------------------+ /
|0..n / |0..n /
| / | / ("rant" = Registrant)
|A SED Group is / |A SED Group is /
|associated with / |associated with /
|zero or more / +---[abstract]----+ |zero or more / +---[abstract]----+
|Peering / | SED Record: | |Peering / | SED Record: |
|Organizations / | rant, | |Organizations / | rant, |
| / | sedName, |0..n | / | sedName, |0..n
|0..n / | sedFunction, |------| |0..n / | sedFunction, |------|
+--------+--------------+0..n 0..n| isInSvc, | | +--------+--------------+0..n 0..n| isInSvc, | |
|SED Group: |------------------| ttl | | |SED Group: |------------------| ttl | |
| rant, | +-----------------+ | | rant, | +-----------------+ |
skipping to change at page 9, line 18 skipping to change at page 9, line 18
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 SPPF, a public identifier object can be a Within the context of SPPF, a public identifier object can be a
Telephone Number (TN), a range of Telephone Numbers, a PSTN Telephone Number (TN), a range of Telephone Numbers, a PSTN
Routing Number (RN), a TN prefix, or a URI. Routing Number (RN), a TN prefix, or a URI.
An SPPF Public Identifier may be a member of zero or more An SPPF Public Identifier may be a member of zero or more
Destination Groups to create logical groupings of Public Destination Groups to create logical groupings of Public
Identifiers that share a common set of Session Establishment Data Identifiers that share a common set of Session Establishment Data
(e.g. routes). (e.g., 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 SED Records. This ability for a Public Identifier more individual SED Records. This ability for a Public Identifier
to be directly associated with a SED Record, as opposed to forcing to be directly associated with a SED Record, as opposed to forcing
membership in one or more Destination Groups, supports use cases membership in one or more Destination Groups, supports use cases
where the SED Record contains data specifically tailored to an where the SED Record contains data specifically tailored to an
individual TN Public Identifier. individual TN Public Identifier.
o Destination Group: o Destination Group:
A named logical grouping of zero or more Public Identifiers that A named logical grouping of zero or more Public Identifiers that
skipping to change at page 9, line 43 skipping to change at page 9, line 43
o SED Group: o SED Group:
A SED Group contains a set of SED Record references, a set of A SED Group contains a set of SED Record references, a set 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, the session establishment between a set of Public Identifiers, the session establishment
information (SED) shared across these Public Identifiers, and the information (SED) shared across these Public Identifiers, and the
list of peering organizations whose query responses from the list of peering organizations whose query responses from the
resolution system may include the session establishment resolution system may include the session establishment
information contained in a given SED group. In addition, the information contained in a given SED group. In addition, the
sourceIdent element within a SED Group, in concert with the set of sourceIdent element within a SED Group, in concert with the set of
peering organization identifiers, enables fine-grained source peering organization identifiers, enables fine-grained source-
based routing. For further details about the SED Group and source based routing. For further details about the SED Group and
based routing, refer to the definitions and descriptions in source-based routing, refer to the definitions and descriptions in
Section 6.1. Section 6.1.
o SED Record: o SED Record:
A SED Record contains the data that a resolution system returns in A SED Record contains the data that a resolution system returns in
response to a successful query for a Public Identifier. SED response to a successful query for a Public Identifier. SED
Records are generally associated with a SED Group when the SED Records are generally associated with a SED Group when the SED
within is not specific to a Public Identifier. within is not specific to a Public Identifier.
To support the use cases defined in [RFC6461], SPPF framework To support the use cases defined in [RFC6461], SPPF framework
defines three type of SED Records: URIType, NAPTRType, and NSType. defines three type of SED Records: URIType, NAPTRType, and NSType.
skipping to change at page 10, line 38 skipping to change at page 10, line 38
resolution query responses may include the session establishment resolution query responses may include the session establishment
information (SED) defined in the SED Records within that SED information (SED) defined in the SED Records within that SED
Group. A peering organization is an entity that the Registrant Group. A peering organization is an entity that the Registrant
intends to share the SED data with. intends to share the SED data with.
3.2. Time Value 3.2. Time Value
Some request and response messages in SPPF include time value(s) Some request and response messages in SPPF include time value(s)
defined as type xs:dateTime, a built-in W3C XML Schema Datatype. Use defined as type xs:dateTime, a built-in W3C XML Schema Datatype. Use
of unqualified local time value is disallowed as it can lead to of unqualified local time value is disallowed as it can lead to
interoperability issues. The value of time attribute MUST be interoperability issues. The value of a time attribute MUST be
expressed in Coordinated Universal Time (UTC) format without the expressed in Coordinated Universal Time (UTC) format without the
timezone digits. timezone digits.
"2010-05-30T09:30:10Z" is an example of an acceptable time value for "2010-05-30T09:30:10Z" is an example of an acceptable time value for
use in SPPF messages. "2010-05-30T06:30:10+3:00" is a valid UTC use in SPPF messages. "2010-05-30T06:30:10+3:00" is a valid UTC
time, but it is not approved for use in SPPF messages. time, but MUST NOT be used in SPPF messages.
3.3. Extensibility 3.3. Extensibility
The framework contains various points of extensibility in form of the The framework contains various points of extensibility in form of the
"ext" elements. Extensions used beyond the scope of private SPPF "ext" elements. Extensions used beyond the scope of private SPPF
installations MUST be documented in an RFC, and the first such installations need to be documented in an RFC, and the first such
extension SHOULD define an IANA registry, holding a list of extension is expected to define an IANA registry, holding a list of
documented extensions. documented extensions.
4. Transport Protocol Requirements 4. Transport Substrate Protocol Requirements
This section provides requirements for transport protocols suitable This section provides requirements for substrate protocols suitable
for SPPF. More specifically, this section specifies the services, as "transports" for SPPF. More specifically, this section specifies
features, and assumptions that SPPF framework delegates to the chosen the services, features, and assumptions that SPPF framework delegates
transport and envelope technologies. to the chosen substrate and envelope technologies.
4.1. Connection Oriented 4.1. Mandatory Substrate
None of the existing transport protocols carried directly over IP,
appearing as "Protocol" in the IPv4 headers, of "Next Header" in the
IPv6 headers, meet the requirements for a "transport" listed in this
section.
Therefore, one choice of "transport" has been provided in the SPP
Protocol over SOAP document [I-D.ietf-drinks-spp-protocol-over-soap],
using SOAP as the substrate. To encourage interoperability, the SPPF
server MUST provide support for this protocol. With time, it is
possible that other choices may surface that agree with the
requirements discussed above.
4.2. Connection Oriented
The SPPF follows a model where a client establishes a connection to a The SPPF follows a model where a client establishes a connection to a
server in order to further exchange SPPF messages over such point-to- server in order to further exchange SPPF messages over such a point-
point connection. A transport protocol for SPPF MUST therefore be to-point connection. A substrate protocol for SPPF will therefore be
connection oriented. connection oriented.
4.2. Request and Response Model 4.3. Request and Response Model
Provisioning operations in SPPF follow the request-response model, Provisioning operations in SPPF follow the request-response model,
where a client sends a request message to initiate a transaction and where a client sends a request message to initiate a transaction and
the server responds with a response. Multiple subsequent request- the server responds with a response. Multiple subsequent request-
response exchanges MAY be performed over a single persistent response exchanges MAY be performed over a single persistent
connection. connection.
Therefore, a transport protocol for SPPF MUST follow the request- Therefore, a substrate protocol for SPPF will follow the request-
response model by allowing a response to be sent to the request response model by ensuring a response to be sent to the request
initiator. initiator.
4.3. Connection Lifetime 4.4. 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 may be established only on demand. Other use cases short-lived, and may be established only on demand, for the duration
involve either provisioning a large dataset, or a constant stream of of a few seconds. Other use cases involve either provisioning a
small updates, either of which would likely require long-lived large dataset, or a constant stream of small updates, either of which
connections. would likely require long-lived connections, spanning multiple hours
or even days.
Therefore, a protocol suitable for SPPF SHOULD be able to support Therefore, a protocol suitable for SPPF SHOULD be able to support
both short-lived as well as long-lived connections. both short-lived as well as long-lived connections.
4.4. Authentication 4.5. Authentication
All SPPF objects are associated with a Registrant identifier. An All SPPF objects are associated with a Registrant identifier. An
SPPF Client provisions SPPF objects on behalf of Registrants. An SPPF Client provisions SPPF objects on behalf of Registrants. An
authenticated SPP Client is a Registrar. Therefore, the SPPF authenticated SPP Client is a Registrar. Therefore, the SPPF
transport protocol MUST provide means for an SPPF server to substrate protocol MUST provide means for an SPPF server to
authenticate an SPPF Client. authenticate an SPPF Client.
4.5. Authorization 4.6. Authorization
After successful authentication of the SPPF client as a Registrar the After successful authentication of the SPPF client as a Registrar the
Registry performs authorization checks to determine if the Registrar Registry performs authorization checks to determine if the Registrar
is authorized to act on behalf of the Registrant whose identifier is is authorized to act on behalf of the Registrant whose identifier is
included in the SPPF request. Refer to the Security Considerations included in the SPPF request. Refer to Section 9 for further
section for further guidance. guidance.
4.6. Confidentiality and Integrity 4.7. Confidentiality and Integrity
SPPF objects that the Registry manages can be private in nature. SPPF objects that the Registry manages can be private in nature.
Therefore, the transport protocol MUST provide means for end-to-end Therefore, the substrate protocol MUST provide means for data
encryption between the SPPF client and Registry. integrity protection.
If the data is compromised in-flight between the SPPF client and If the data is compromised in-flight between the SPPF client and
Registry, it will seriously affect the stability and integrity of the Registry, it will seriously affect the stability and integrity of the
system. Therefore, the transport protocol MUST provide means for system. Therefore, the substrate protocol MUST provide means for
data integrity protection. data integrity protection.
4.7. Near Real Time 4.8. Near Real Time
Many use cases require near real-time responses from the server. Many use cases require near real-time responses from the server (in
Therefore, a DRINKS transport protocol MUST support near real-time the range of a few multiples of round-trip-time between server and
response to requests submitted by the client. client). Therefore, a DRINKS substrate protocol MUST support near
real-time response to requests submitted by the client.
4.8. Request and Response Sizes 4.9. Request and Response Sizes
Use of SPPF may involve simple updates that may consist of small Use of SPPF may involve simple updates that may consist of small
number of bytes, such as, update of a single public identifier. number of bytes, such as, update of a single public identifier.
Other provisioning operations may constitute large number of dataset Other provisioning operations may constitute large dataset as in
as in adding millions records to a Registry. As a result, a suitable adding millions of records to a Registry. As a result, a suitable
transport protocol for SPPF SHOULD accommodate dataset of various substrate protocol for SPPF SHOULD accommodate datasets of various
sizes. sizes.
4.9. Request and Response Correlation 4.10. Request and Response Correlation
A transport protocol suitable for SPPF MUST allow responses to be A substrate protocol suitable for SPPF MUST allow responses to be
correlated with requests. correlated with requests.
4.10. Request Acknowledgement 4.11. Request Acknowledgement
Data transported in the SPPF is likely crucial for the operation of Data transported in the SPPF is likely crucial for the operation of
the communication network that is being provisioned. A SPPF client the communication network that is being provisioned. An SPPF client
responsible for provisioning SED to the Registry has a need to know responsible for provisioning SED to the Registry has a need to know
if the submitted requests have been processed correctly. 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 the provisioning identifiers or even SSPs might not be reachable, or the provisioning
state of the network is inconsistent. state of the network is inconsistent.
Therefore, a transport protocol for SPPF MUST provide a response for Therefore, a substrate protocol for SPPF 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.11. Mandatory Transport
At the time of this writing, a choice of transport protocol has been
provided in SPP Protocol over SOAP document. To encourage
interoperability, the SPPF 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 Framework Data Structures and Response Codes 5. Base Framework Data Structures and Response Codes
SPPF contains some common data structures for most of the supported SPPF contains some common data structures for most of the supported
object types. This section describes these common data structures. object types. This section describes these common data structures.
5.1. Basic Object Type and Organization Identifiers 5.1. Basic Object Type and Organization Identifiers
All first class objects extend the type BasicObjType. It consists of All first class objects extend the type BasicObjType. It consists of
the Registrant organization, the Registrar organization, the date and the Registrant organization, the Registrar organization, the date and
time of object creation, and the last date and time the object was time of object creation, and the last date and time the object was
updated. The Registry MUST store the date and time of the object modified. The Registry MUST store the date and time of the object
creation and update, if applicable, for all Get operations (see creation and modification, if applicable, for all Get operations (see
Section 7). If the client passed in either date and time values, the Section 7). If the client passed in either date and time values, the
Registry MUST ignore it. The Registrar performs the SPPF operations Registry MUST ignore it. The Registrar performs the SPPF operations
on behalf of the Registrant, the organization that owns the object. on behalf of the Registrant, the organization that owns the object.
<complexType name="BasicObjType" abstract="true"> <complexType name="BasicObjType" abstract="true">
<sequence> <sequence>
<element name="rant" type="sppfb:OrgIdType"/> <element name="rant" type="sppfb:OrgIdType"/>
<element name="rar" type="sppfb:OrgIdType"/> <element name="rar" type="sppfb: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="sppfb:ExtAnyType" minOccurs="0"/> <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
</sequence> </sequence>
</complexType> </complexType>
The identifiers used for Registrants (rant) and Registrars (rar) are The identifiers used for Registrants (rant) and Registrars (rar) are
instances of OrgIdType. The OrgIdType is defined as a string and all instances of OrgIdType. The OrgIdType is defined as a string and all
OrgIdType instances MUST follow the textual convention: OrgIdType instances MUST follow the textual convention:
"namespace:value" (for example "iana-en:32473"). See the IANA "namespace:value" (for example "iana-en:32473"). Specifically:
Consideration section for more details.
Strings used as OrgIdType Namespace identifiers MUST conform to the
following syntax in the Augmented Backus-Naur Form (ABNF) [RFC5234]
namespace = ALPHA * (ALPHA/DIGIT/"-")
See Section 11 for the corresponding IANA Registry definition.
5.2. Various Object Key Types 5.2. Various Object Key Types
The SPPF data model contains various object relationships. In some The SPPF data model contains various object relationships. In some
cases, these object relationships are established by embedding the cases, these object relationships are established by embedding the
unique identity of the related object inside the relating object. unique identity of the related object inside the relating object.
Note that an object's unique identity is required to Delete or Get Note that an object's unique identity is required to Delete or Get
the details of an object. The following sub-sections normatively the details of an object. The following sub-sections normatively
define the various object keys in SPPF and the attributes of those define the various object keys in SPPF and the attributes of those
keys. keys.
"Name" attributes that are used as components of object key types "Name" attributes that are used as components of object key types
MUST be treated case insensitive, more specifically, comparison MUST be compared unsing the toCasefold() function, as specified in
operations MUST use the toCasefold() function, as specified in Section 3.13 of [Unicode6.1] (or a newer version of Unicode). This
Section 3.13 of [Unicode6.1]. function performs case-insensitive comparisons.
5.2.1. Generic Object Key Type 5.2.1. Generic Object Key Type
Most objects in SPPF are uniquely identified by an object key that Most objects in SPPF are uniquely identified by an object key that
has the object's name, object's type and its Registrant's has the object's name, object's type and its Registrant's
organization ID as its attributes. The abstract type called organization ID as its attributes. The abstract type called
ObjKeyType is where this unique identity is housed. Any concrete ObjKeyType is where this unique identity is housed. Any concrete
representation of the ObjKeyType MUST contain the following: representation of the ObjKeyType MUST contain the following:
Object Name: The name of the object. Object Name: The name of the object.
skipping to change at page 15, line 13 skipping to change at page 15, line 22
</complexType> </complexType>
5.2.2. Derived Object Key Types 5.2.2. Derived Object Key Types
The SPPF data model contains certain objects that are uniquely The SPPF data model contains certain objects that are uniquely
identified by attributes, different from or in addition to, the identified by attributes, different from or in addition to, the
attributes in the generic object key described in previous section. attributes in the generic object key described in previous section.
These kind of object keys are derived from the abstract ObjKeyType These kind of object keys are derived from the abstract ObjKeyType
and defined in their own abstract key types. Because these object and defined in their own abstract key types. Because these object
key types are abstract, they MUST be specified in a concrete form in key types are abstract, they MUST be specified in a concrete form in
any SPPF conforming transport protocol specification. These are used any SPPF conforming substrate protocol specification. These are used
in Delete and Get operations, and may also be used in Accept and in Delete and Get operations, and may also be used in Accept and
Reject operations. Reject operations.
Following are the derived object keys in SPPF data model: Following are the derived object keys in SPPF data model:
o SedGrpOfferKeyType: This uniquely identifies a SED Group object o SedGrpOfferKeyType: This uniquely identifies an SED Group object
offer. This key type extends from ObjKeyType and MUST also have offer. This key type extends from ObjKeyType and MUST also have
the organization ID of the Registrant to whom the object is being the organization ID of the Registrant to whom the object is being
offered, as one of its attributes. In addition to the Delete and offered, as one of its attributes. In addition to the Delete and
Get operations, these key types are used in Accept and Reject Get operations, these key types are used in Accept and Reject
operations on a SED Group Offer object. The structure of abstract operations on an SED Group Offer object. The structure of
SedGrpOfferKeyType is as follows: abstract SedGrpOfferKeyType is as follows:
<complexType name="SedGrpOfferKeyType" <complexType name="SedGrpOfferKeyType"
abstract="true"> abstract="true">
<complexContent> <complexContent>
<extension base="sppfb:ObjKeyType"> <extension base="sppfb:ObjKeyType">
<annotation> <annotation>
<documentation> <documentation>
---- Generic type that represents ---- Generic type that represents
the key for a object offer. ---- the key for an object offer. ----
</documentation> </documentation>
</annotation> </annotation>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
A SED Group Offer object MUST use SedGrpOfferKeyType. Refer to A SED Group Offer object MUST use SedGrpOfferKeyType. Refer to
the "Framework Data Model Objects" section of this document for Section 6.5 for a description of the SED Group Offer object.
description of SED Group Offer object.
o PubIdKeyType: This uniquely identifies a Public Identity object. o PubIdKeyType: This uniquely identifies a Public Identity object.
This key type extends from abstract ObjKeyType. Any concrete This key type extends from the abstract ObjKeyType. Any concrete
definition of PubIdKeyType MUST contain the elements that identify definition of PubIdKeyType MUST contain the elements that identify
the value and type of Public Identity and also contain the the value and type of Public Identity and also contain the
organization ID of the Registrant that is the owner of the Public organization ID of the Registrant that is the owner of the Public
Identity object. A Public Identity object in SPPF is uniquely Identity object. A Public Identity object in SPPF is uniquely
identified by the Registrant's organization ID, the value of the identified by the Registrant's organization ID, the value of the
public identity, and the type of the public identity object. public identity, and the type of the public identity object.
Consequently, any concrete representation of the PubIdKeyType MUST Consequently, any concrete representation of the PubIdKeyType MUST
contain the following attributes: contain the following attributes:
* Registrant Id: The unique organization ID that identifies the * Registrant Id: The unique organization ID that identifies the
Registrant. Registrant.
* Value: The value of the Public Identity. * Value: The value of the Public Identity.
* Type: The type of the Public Identity Object. * Type: The type of the Public Identity Object.
skipping to change at page 16, line 38 skipping to change at page 16, line 46
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
A Public Identity object MUST use attributes of PubIdKeyType for its A Public Identity object MUST use attributes of PubIdKeyType for its
unique identification . Refer to Section 6 for a description of unique identification . Refer to Section 6 for a description of
Public Identity object. Public Identity object.
5.3. Response Message Types 5.3. Response Message Types
This section contains the listing of response types that MUST be The following table contains the list of response types a "transport"
defined by the SPPF conforming transport protocol specification and definition for a substrate protocol MUST define. An SPPF server MUST
implemented by a conforming SPPF server. implement all of the following at minimum.
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Response Type | Description | | Response Type | Description |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Request Succeeded | Any conforming specification MUST define a | | Request Succeeded | A given request succeeded. |
| | response to indicate that a given request |
| | succeeded. |
| | | | | |
| Request syntax | Any conforming specification MUST define a | | Request syntax | The syntax of a given request was found |
| invalid | response to indicate that a syntax of a | | invalid | invalid. |
| | given request was found invalid. |
| | | | | |
| Request too large | Any conforming specification MUST define a | | Request too large | The count of entities in the request is |
| | response to indicate that the count of | | | larger than the server is willing or able |
| | entities in the request is larger than the | | | to process. |
| | server is willing or able to process. |
| | | | | |
| Version not | Any conforming specification MUST define a | | Version not | The server does not support the version of |
| supported | response to indicate that the server does | | supported | the SPPF protocol specified in the request. |
| | not support the version of the SPPF |
| | protocol specified in the request. |
| | | | | |
| Command invalid | Any conforming specification MUST define a | | Command invalid | The operation and/or command being |
| | response to indicate that the operation | | | requested by the client is invalid and/or |
| | and/or command being requested by the | | | not supported by the server. |
| | client is invalid and/or not supported by |
| | the server. |
| | | | | |
| System temporarily | Any conforming specification MUST define a | | System temporarily | The SPPF server is temporarily not |
| unavailable | response to indicate that the SPPF server | | unavailable | available to serve the client request. |
| | is temporarily not available to serve |
| | client request. |
| | | | | |
| Unexpected internal | Any conforming specification MUST define a | | Unexpected internal | The SPPF server encountered an unexpected |
| system or server | response to indicate that the SPPF server | | system or server | error that prevented the server from |
| error. | encountered an unexpected error that | | error. | fulfilling the request. |
| | prevented the server from fulfilling the |
| | request. |
| | | | | |
| Attribute value | Any conforming specification MUST define a | | Attribute value | The SPPF server encountered an attribute or |
| invalid | response to indicate that the SPPF server | | invalid | property in the request that had an |
| | encountered an attribute or property in the | | | invalid/bad value. Optionally, the |
| | request that had an invalid/bad value. | | | specification MAY provide a way to indicate |
| | Optionally, the specification MAY provide a | | | the Attribute Name and the Attribute Value |
| | way to indicate the Attribute Name and the | | | to identify the object that was found to be |
| | Attribute Value to identify the object that | | | invalid. |
| | was found to be invalid. |
| | | | | |
| Object does not | Any conforming specification MUST define a | | Object does not | An object present in the request does not |
| exist | response to indicate that an object present | | exist | exist on the SPPF server. Optionally, the |
| | in the request does not exist on the SPPF | | | specification MAY provide a way to indicate |
| | server. Optionally, the specification MAY | | | the Attribute Name and the Attribute Value |
| | provide a way to indicate the Attribute | | | that identifies the non-existent object. |
| | Name and the Attribute Value that |
| | identifies the non-existent object. |
| | | | | |
| Object status or | Any conforming specification MUST define a | | Object status or | The operation requested on an object |
| ownership does not | response to indicate that the operation | | ownership does not | present in the request cannot be performed |
| allow for | requested on an object present in the | | allow for | because the object is in a status that does |
| operation. | request cannot be performed because the | | operation. | not allow said operation, or the user |
| | object is in a status that does not allow | | | requesting the operation is not authorized |
| | the said operation or the user requesting | | | to perform said operation on the object. |
| | the operation is not authorized to perform |
| | the said operation on the object. |
| | Optionally, the specification MAY provide a | | | Optionally, the specification MAY provide a |
| | way to indicate the Attribute Name and the | | | way to indicate the Attribute Name and the |
| | Attribute Value that identifies the object. | | | Attribute Value that identifies the object. |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Table 1: Response Types Table 1: Response Types
When the response messages are "parameterized" with the Attribute When the response messages are "parameterized" with the Attribute
Name and Attribute Value, then the use of these parameters MUST Name and Attribute Value, then the use of these parameters MUST
adhere to the following rules: adhere to the following rules:
o Any value provided for the Attribute Name parameter MUST be an o Any value provided for the Attribute Name parameter MUST be an
exact XSD element name of the protocol data element that the exact XSD element name of the protocol data element that the
response message is referring to. For example, valid values for response message is referring to. For example, valid values for
"attribute name" are "dgName", "sedGrpName", "sedRec", etc. "attribute name" are "dgName", "sedGrpName", "sedRec", etc.
skipping to change at page 18, line 44 skipping to change at page 18, line 35
pre-existing object do not exist. If the data elements used to pre-existing object do not exist. If the data elements used to
uniquely identify an object are malformed, then response type uniquely identify an object are malformed, then response type
"Attribute value invalid" MUST be returned. "Attribute value invalid" MUST be returned.
6. Framework Data Model Objects 6. Framework Data Model Objects
This section provides a description of the specification of each This section provides a description of the specification of each
supported data model object (the nouns) and identifies the commands supported data model object (the nouns) and identifies the commands
(the verbs) that MUST be supported for each data model object. (the verbs) that MUST be supported for each data model object.
However, the specification of the data structures necessary to However, the specification of the data structures necessary to
support each command is delegated to an SPPF conforming transport support each command is delegated to an SPPF conforming substrate
protocol specification. protocol specification.
6.1. Destination Group 6.1. Destination Group
Destination Group represents a logical grouping of Public Identifiers Destination Group represents a logical grouping of Public Identifiers
with common session establishment information. The transport with common session establishment information. The substrate
protocol MUST support the ability to Add, Get, and Delete Destination protocol MUST support the ability to Add, Get, and Delete Destination
Groups (refer to the "Framework Operations" section of this document Groups (refer to Section 7 for a generic description of various
for a generic description of various operations). operations).
A Destination Group object MUST be uniquely identified by attributes A Destination Group object MUST be uniquely identified by attributes
as defined in the description of "ObjKeyType" in the section "Generic as defined in the description of "ObjKeyType" in the section "Generic
Object Key Type" of this document. Object Key Type" of this document.
The DestGrpType object structure is defined as follows: The DestGrpType object structure is defined as follows:
<complexType name="DestGrpType"> <complexType name="DestGrpType">
<complexContent> <complexContent>
<extension base="sppfb:BasicObjType"> <extension base="sppfb:BasicObjType">
skipping to change at page 19, line 40 skipping to change at page 19, line 32
o ext: Point of extensibility described in Section 3.3. o ext: Point of extensibility described in Section 3.3.
6.2. Public Identifier 6.2. Public Identifier
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. SPPF supports the service provider or Registrant organization. SPPF supports the
notion of the carrier-of-record as defined in [RFC5067]. Therefore, notion of the carrier-of-record as defined in [RFC5067]. Therefore,
the Registrant under whom the Public Identity is being created can the Registrant under which the Public Identifier is being created can
optionally claim to be a carrier-of-record. optionally claim to be a carrier-of-record.
SPPF identifies three types of Public Identifiers: telephone numbers SPPF identifies three types of Public Identifiers: telephone numbers
(TN), routing numbers (RN), and URI. SPPF provides structures to (TN), routing numbers (RN), and URIs. SPPF provides structures to
manage a single TN, a contiguous range of TNs, and a TN prefix. The manage a single TN, a contiguous range of TNs, and a TN prefix. The
transport protocol MUST support the ability to Add, Get, and Delete substrate protocol MUST support the ability to Add, Get, and Delete
Public Identifiers (refer to the "Framework Operations" section of Public Identifiers (refer to Section 7 for a generic description of
this document for a generic description of various operations). various operations).
A Public Identity object MUST be uniquely identified by attributes as A Public Identity object MUST be uniquely identified by attributes as
defined in the description of "PubIdKeyType" in the section defined in the description of "PubIdKeyType" in Section 5.2.2.
Section 5.2.2.
The abstract XML schema type definition PubIdType is a generalization The abstract XML schema type definition PubIdType is a generalization
for the concrete Public Identifier schema types. PubIdType element for the concrete Public Identifier schema types. The PubIdType
'dgName' represents the name of a destination group that a given element 'dgName' represents the name of a destination group that a
Public Identifier may be a member of. Note that this element may be given Public Identifier may be a member of. Note that this element
present multiple times so that a given Public Identifier may be a may be present multiple times so that a given Public Identifier may
member of multiple destination groups. The PubIdType object be a member of multiple destination groups. The PubIdType object
structure is defined as follows: structure is defined as follows:
<complexType name="PubIdType" abstract="true"> <complexType name="PubIdType" abstract="true">
<complexContent> <complexContent>
<extension base="sppfb:BasicObjType"> <extension base="sppfb:BasicObjType">
<sequence> <sequence>
<element name="dgName" type="sppfb:ObjNameType" <element name="dgName" type="sppfb:ObjNameType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
A Public Identifier may be a member of zero or more Destination A Public Identifier may be a member of zero or more Destination
Groups. When a Public Identifier is member of a Destination Group, Groups. When a Public Identifier is a member of a Destination Group,
it is intended to be associated with SED(s) through the SED Group(s) it is intended to be associated with SED through the SED Group(s)
that are associated with the Destination Group. When a Public that are associated with the Destination Group. When a Public
Identifier is not member of any Destination Group, it is intended to Identifier is not member of any Destination Group, it is intended to
be associated with SED through the SED Records that are directly be associated with SED through the SED Records that are directly
associated with the Public Identifier. associated with the Public 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 value contained within <tn> element, and its combination of its value contained within the <tn> element, and its
Registrant ID. TNType is defined as follows: Registrant ID. TNType is defined as follows:
<complexType name="TNType"> <complexType name="TNType">
<complexContent> <complexContent>
<extension base="sppfb:PubIdType"> <extension base="sppfb:PubIdType">
<sequence> <sequence>
<element name="tn" type="sppfb:NumberValType"/> <element name="tn" type="sppfb:NumberValType"/>
<element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/> <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
<element name="sedRecRef" type="sppfb:SedRecRefType" <element name="sedRecRef" type="sppfb:SedRecRefType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
skipping to change at page 21, line 45 skipping to change at page 21, line 45
o tn: Telephone number to be added to the Registry. o tn: Telephone number to be added to the Registry.
o sedRecRef: Optional reference to SED records that are directly o sedRecRef: Optional reference to SED records that are directly
associated with the TN Public Identifier. Following the SPPF data associated with the TN Public Identifier. Following the SPPF data
model, the SED record could be a protocol agnostic URIType or model, the SED record could be a protocol agnostic URIType or
another type. another type.
o corInfo: corInfo is an optional parameter of type CORInfoType that o corInfo: corInfo is an optional parameter of type CORInfoType that
allows the Registrant organization to set forth a claim to be the allows the Registrant organization to set forth a claim to be the
carrier-of-record (see [RFC5067]). This is done by setting the carrier-of-record (see [RFC5067]). This is done by setting the
value of <corClaim> element of the CORInfoType object structure to value of the <corClaim> element of the CORInfoType object
"true". The other two parameters of the CORInfoType, <cor> and structure to "true". The other two parameters of the CORInfoType,
<corDate> are set by the Registry to describe the outcome of the <cor> and <corDate> are set by the Registry to describe the
carrier-of-record claim by the Registrant. In general, inclusion outcome of the carrier-of-record claim by the Registrant. In
of <corInfo> parameter is useful if the Registry has the authority general, inclusion of <corInfo> parameter is useful if the
information, such as, the number portability data, etc., in order Registry has the authority information, such as, the number
to qualify whether the Registrant claim can be satisfied. If the portability data, etc., in order to qualify whether the Registrant
carrier-of-record claim disagrees with the authority data in the claim can be satisfied. If the carrier-of-record claim disagrees
Registry, whether the TN add operation fails or not is a matter of with the authority data in the Registry, whether a TN Add
policy and it is beyond the scope of this document. operation fails or not is a matter of policy and is beyond the
scope of this document.
A routing number is provisioned using the RNType, an extension of A routing number is provisioned using the RNType, an extension of
PubIDType. The Registrant organization can add the RN and associate PubIDType. The Registrant organization can add the RN and associate
it with the appropriate destination group(s) to share the route it with the appropriate destination group(s) to share the route
information. This allows SSPs to use the RN search key to derive the information. This allows SSPs to use the RN search key to derive the
ingress routes for session establishment at the runtime resolution ingress routes for session establishment at the runtime resolution
process (see [RFC6116]. Each RNType object is uniquely identified by process (see [RFC6116]. Each RNType object is uniquely identified by
the combination of its value inside the <rn> element, and its the combination of its value inside the <rn> element, and its
Registrant ID. RNType is defined as follows: Registrant ID. RNType is defined as follows:
skipping to change at page 22, line 38 skipping to change at page 22, line 39
RNType has the following attributes: RNType has the following attributes:
o rn: Routing Number used as the search key. o rn: Routing Number used as the search key.
o corInfo: corInfo is an optional parameter of type CORInfoType that o corInfo: corInfo is an optional parameter of type CORInfoType that
allows the Registrant organization to set forth a claim to be the allows the Registrant organization to set forth a claim to be the
carrier-of-record (see [RFC5067]) carrier-of-record (see [RFC5067])
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, including
TNRType is particularly useful when expressing a TN range that does the starting and ending TN. Use of TNRType is particularly useful
not include all the TNs within a TN block or prefix. The TNRType when expressing a TN range that does not include all the TNs within a
definition accommodates the open number plan as well such that the TN block or prefix. The TNRType definition accommodates the open
TNs that fall between the start and end TN range may include TNs with number plan as well such that the TNs that fall between the start and
different length variance. Whether the Registry can accommodate the end TN range may include TNs with different length variance. Whether
open number plan semantics is a matter of policy and is beyond the the Registry can accommodate the open number plan semantics is a
scope of this document. Each TNRType object is uniquely identified matter of policy and is beyond the scope of this document. Each
by the combination of its value that in turn is a combination of the TNRType object is uniquely identified by the combination of its value
<startTn> and <endTn> elements, and its Registrant ID. TNRType that in turn is a combination of the <startTn> and <endTn> elements,
object structure definition is as follows: and its Registrant ID. The TNRType object structure definition is as
follows:
<complexType name="TNRType"> <complexType name="TNRType">
<complexContent> <complexContent>
<extension base="sppfb:PubIdType"> <extension base="sppfb:PubIdType">
<sequence> <sequence>
<element name="range" type="sppfb:NumberRangeType"/> <element name="range" type="sppfb:NumberRangeType"/>
<element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/> <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
skipping to change at page 23, line 36 skipping to change at page 23, line 36
o endTn: The last TN in the TN range o endTn: The last TN in the TN range
o corInfo: corInfo is an optional parameter of type CORInfoType that o corInfo: corInfo is an optional parameter of type CORInfoType that
allows the Registrant organization to set forth a claim to be the allows the Registrant organization to set forth a claim to be the
carrier-of-record (see [RFC5067]) carrier-of-record (see [RFC5067])
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 the open number
Once again, whether the Registry supports the open number plan 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 value in the <tnPrefix> element, and its combination of its value in the <tnPrefix> element, and its
Registrant ID. TNPType is defined as follows: Registrant ID. TNPType is defined as follows:
<complexType name="TNPType"> <complexType name="TNPType">
<complexContent> <complexContent>
<extension base="sppfb:PubIdType"> <extension base="sppfb:PubIdType">
<sequence> <sequence>
skipping to change at page 24, line 43 skipping to change at page 24, line 43
<sequence> <sequence>
<element name="uri" type="anyURI"/> <element name="uri" type="anyURI"/>
<element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/> <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
URIPubIdType consists of the following attributes: URIPubIdType consists of the following attributes:
o uri: The value that acts a Public Identifier. o uri: The value that acts as Public Identifier.
o ext: Point of extensibility described in Section 3.3. o ext: Point of extensibility described in Section 3.3.
6.3. SED Group 6.3. SED Group
SED Group is a grouping of one or more Destination Group, the common SED Group is a grouping of one or more Destination Group, the common
SED Records, and the list of peer organizations with access to the SED Records, and the list of peer organizations with access to the
SED Records associated with a given SED Group. It is this indirect SED Records associated with a given SED Group. It is this indirect
linking of public identifiers to their Session Establishment Data linking of public identifiers to their Session Establishment Data
that significantly improves the scalability and manageability of the that significantly improves the scalability and manageability of the
peering data. Additions and changes to SED information are reduced peering data. Additions and changes to SED information are reduced
to a single operation on a SED Group or SED Record , rather than to a single operation on a SED Group or SED Record , rather than
millions of data updates to individual public identifier records that millions of data updates to individual public identifier records that
individually contain their peering data. The transport protocol MUST individually contain their peering data. The substrate protocol MUST
support the ability to Add, Get, and Delete SED Groups (refer to the support the ability to Add, Get, and Delete SED Groups (refer to
"Framework Operations" section of this document for a generic Section 7 for a generic description of various operations).
description of various operations).
A SED Group object MUST be uniquely identified by attributes as A SED Group object MUST be uniquely identified by attributes as
defined in the description of "ObjKeyType" in the section "Generic defined in the description of "ObjKeyType" in the section "Generic
Object Key Type" of this document. Object Key Type" of this document.
The SedGrpType object structure is defined as follows: The SedGrpType object structure is defined as follows:
<complexType name="SedGrpType"> <complexType name="SedGrpType">
<complexContent> <complexContent>
<extension base="sppfb:BasicObjType"> <extension base="sppfb:BasicObjType">
skipping to change at page 26, line 20 skipping to change at page 26, line 20
o sedRecRef: Set of zero or more objects of type SedRecRefType that o sedRecRef: Set of zero or more objects of type SedRecRefType that
house the unique keys of the SED Records (containing the session house the unique keys of the SED Records (containing the session
establishment data) that the SedGrpType object refers to and their establishment data) that the SedGrpType object refers to and their
relative priority within the context of this SED Group. relative priority within the context of this SED Group.
o dgName: Set of zero or more names of DestGrpType object instances. o dgName: Set of zero or more names of DestGrpType object instances.
Each dgName name, in association with this SED Group's Registrant Each dgName name, in association with this SED Group's Registrant
ID, uniquely identifies a DestGrpType object instance whose ID, uniquely identifies a DestGrpType object instance whose
associated public identifiers are reachable using the session associated public identifiers are reachable using the session
establishment information housed in this SED Group. An intended establishment information housed in this SED Group. An intended
side affect of this is that a SED Group cannot provide session side effect of this is that a SED Group cannot provide session
establishment information for a Destination Group belonging to establishment information for a Destination Group belonging to
another Registrant. another Registrant.
o peeringOrg: Set of zero or more peering organization IDs that have o peeringOrg: Set of zero or more peering organization IDs that have
accepted an offer to receive this SED Group's information. Note accepted an offer to receive this SED Group's information. Note
that this identifier "peeringOrg" is an instance of OrgIdType. that this identifier "peeringOrg" is an instance of OrgIdType.
The set of peering organizations in this list is not directly The set of peering organizations in this list is not directly
settable or modifiable using the addSedGrpsRqst operation. This settable or modifiable using the addSedGrpsRqst operation. This
set is instead controlled using the SED offer and accept set is instead controlled using the SED offer and accept
operations. operations.
o sourceIdent: Set of zero or more SourceIdentType object instances. o sourceIdent: Set of zero or more SourceIdentType object instances.
These objects, described further below, house the source These objects, described further below, house the source
identification schemes and identifiers that are applied at identification schemes and identifiers that are applied at
resolution time as part of source based routing algorithms for the resolution time as part of source-based routing algorithms for the
SED Group. SED Group.
o isInSvc: A boolean element that defines whether this SED Group is o isInSvc: A boolean element that defines whether this SED Group is
in service. The session establishment information contained in a in service. The session establishment information contained in a
SED Group that is in service is a candidate for inclusion in SED Group that is in service is a candidate for inclusion in
resolution responses for public identities residing in the resolution responses for public identities residing in the
Destination Group associated with this SED Group. The session Destination Group associated with this SED Group. The session
establishment information contained in a SED Group that is not in establishment information contained in a SED Group that is not in
service is not a candidate for inclusion in resolution responses. service is not a candidate for inclusion in resolution responses.
skipping to change at page 27, line 21 skipping to change at page 27, line 21
The SedGrpType object provides support for source-based routing via The SedGrpType object provides support for source-based routing via
the peeringOrg data element and more granular source base routing via the peeringOrg data element and more granular source base routing via
the source identity element. The source identity element provides the source identity element. The source identity element provides
the ability to specify zero or more of the following in association the ability to specify zero or more of the following in association
with a given SED Group: a regular expression that is matched against with a given SED Group: a regular expression that is matched against
the resolution client IP address, a regular expression that is the resolution client IP address, a regular expression that is
matched against the root domain name(s), and/or a regular expression matched against the root domain name(s), and/or a regular expression
that is matched against the calling party URI(s). The result will be that is matched against the calling party URI(s). The result will be
that, after identifying the visible SED Groups whose associated that, after identifying the visible SED Groups whose associated
Destination Group(s) contain the lookup key being queried and whose Destination Group(s) contain the lookup key being queried and whose
peeringOrg list contains the querying organizations organization ID, peeringOrg list contains the querying organization's organization ID,
the resolution server will evaluate the characteristics of the Source the resolution server will evaluate the characteristics of the Source
URI, and Source IP address, and root domain of the lookup key being URI, and Source IP address, and root domain of the lookup key being
queried. The resolution server then compares these criteria against queried. The resolution server then compares these criteria against
the source identity criteria associated with the SED Groups. The the source identity criteria associated with the SED Groups. The
session establishment information contained in SED Groups that have session establishment information contained in SED Groups that have
source based routing criteria will only be included in the resolution source-based routing criteria will only be included in the resolution
response if one or more of the criteria matches the source criteria response if one or more of the criteria matches the source criteria
from the resolution request. The Source Identity data element is of from the resolution request. The Source Identity data element is of
type SourceIdentType, whose structure is defined as follows: type SourceIdentType, whose structure is defined as follows:
<complexType name="SourceIdentType"> <complexType name="SourceIdentType">
<sequence> <sequence>
<element name="sourceIdentRegex" type="sppfb:RegexType"/> <element name="sourceIdentRegex" type="sppfb:RegexType"/>
<element name="sourceIdentScheme" <element name="sourceIdentScheme"
type="sppfb:SourceIdentSchemeType"/> type="sppfb:SourceIdentSchemeType"/>
<element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/> <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
skipping to change at page 28, line 25 skipping to change at page 28, line 25
6.4. SED Record 6.4. SED Record
SED Group represents a combined grouping of SED Records that define SED Group represents a combined grouping of SED Records that define
session establishment information. However, SED Records need not be session establishment information. However, SED Records need not be
created to just serve a single SED Group. SED Records can be created created to just serve a single SED Group. SED Records can be created
and managed to serve multiple SED Groups. As a result, a change for and managed to serve multiple SED Groups. As a result, a change for
example to the properties of a network node used for multiple routes, example to the properties of a network node used for multiple routes,
would necessitate just a single update operation to change the would necessitate just a single update operation to change the
properties of that node. The change would then be reflected in all properties of that node. The change would then be reflected in all
the SED Groups whose SED record set contains a reference to that the SED Groups whose SED record set contains a reference to that
node. The transport protocol MUST support the ability to Add, Get, node. The substrate protocol MUST support the ability to Add, Get,
and Delete SED Records (refer to the "Framework Operations" section and Delete SED Records (refer to Section 7 for a generic description
of this document for a generic description of various operations). of various operations).
A SED Record object MUST be uniquely identified by attributes as A SED Record object MUST be uniquely identified by attributes as
defined in the description of "ObjKeyType" in the section "Generic defined in the description of "ObjKeyType" in the section "Generic
Object Key Type" of this document. Object Key Type" of this document.
The SedRecType object structure is defined as follows: The SedRecType object structure is defined as follows:
<complexType name="SedRecType" abstract="true"> <complexType name="SedRecType" abstract="true">
<complexContent> <complexContent>
<extension base="sppfb:BasicObjType"> <extension base="sppfb:BasicObjType">
skipping to change at page 29, line 40 skipping to change at page 29, line 40
o sedName: The character string that contains the name of the SED o sedName: The character string that contains the name of the SED
Record. It uniquely identifies this object within the context of Record. 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
described above). described above).
o sedFunction: As described in [RFC6461], SED or Session o sedFunction: As described in [RFC6461], SED or Session
Establishment Data falls primarily into one of two categories or Establishment Data falls primarily into one of two categories or
functions, LUF and LRF. To remove any ambiguity as to the functions, LUF and LRF. To remove any ambiguity as to the
function a SED record is intended to provide, this optional function a SED record is intended to provide, this optional
element allows the provisioning party to make his or her element allows the provisioning party to make its intentions
intentions explicit. explicit.
o isInSvc: A boolean element that defines whether this SED Record is o isInSvc: A boolean element that defines whether this SED Record is
in service or not. The session establishment information in service or not. The session establishment information
contained in a SED Record which is in service is a candidate for contained in a SED Record which is in service is a candidate for
inclusion in resolution responses for Telephone Numbers that are inclusion in resolution responses for Telephone Numbers that are
either directly associated to this SED Record, or for Public either directly associated to this SED Record, or for Public
Identities residing in a Destination Group that is associated to a Identities residing in a Destination Group that is associated to a
SED Group which in turn has an association to this SED Record. SED Group which in turn has an association to this SED Record.
o ttl: Number of seconds that an addressing server may cache a o ttl: Number of seconds that an addressing server may cache a
skipping to change at page 31, line 16 skipping to change at page 31, line 16
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
<complexType name="IPAddrType"> <complexType name="IPAddrType">
<sequence> <sequence>
<element name="addr" type="sppfb:AddrStringType"/> <element name="addr" type="sppfb:AddrStringType"/>
<element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/> <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
</sequence> </sequence>
<attribute name="type" type="sppfb:IPType" default="v4"/> <attribute name="type" type="sppfb:IPType" default="IPv4"/>
</complexType> </complexType>
<simpleType name="IPType"> <simpleType name="IPType">
<restriction base="token"> <restriction base="token">
<enumeration value="IPv4"/> <enumeration value="IPv4"/>
<enumeration value="IPv6"/> <enumeration value="IPv6"/>
</restriction> </restriction>
</simpleType> </simpleType>
<complexType name="URIType"> <complexType name="URIType">
skipping to change at page 32, line 8 skipping to change at page 32, line 8
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 SED Group. objects in the same SED 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 [RFC6116] (e.g., value must be of the form specified in [RFC6116] (e.g.,
E2U+pstn:sip+sip). The allowable values are a matter of policy E2U+pstn:sip+sip). The allowable values are a matter of policy
and not limited by this protocol. and 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 regx
Regex field is not provided, otherwise the server will ignore it field is not provided, otherwise the server will ignore it
o ext: Point of extensibility described in Section 3.3. o ext: Point of extensibility described in Section 3.3.
The NSType object is composed of the following elements: The NSType object is composed of the following elements:
o hostName: Root-relative host name of the name server. o hostName: Root-relative 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 "IPv6").
o ext: Point of extensibility described in Section 3.3. o ext: Point of extensibility described in Section 3.3.
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
serve as the replacement string and it will be left to the serve as the replacement string and it will be left to the
resolution server to arrive at the final usable URI. resolution server to arrive at the final usable URI.
6.5. SED Group Offer 6.5. SED Group Offer
The list of peer organizations whose resolution responses can include The list of peer organizations whose resolution responses can include
the session establishment information contained in a given SED Group the session establishment information contained in a given SED Group
is controlled by the organization to which a SED Group object belongs is controlled by the organization to which a SED Group object belongs
(its Registrant), and the peer organization that submits resolution (its Registrant), and the peer organization that submits resolution
requests (a data recipient, also know as a peering organization). requests (a data recipient, also known as a peering organization).
The Registrant offers access to a SED Group by submitting a SED Group The Registrant offers access to a SED Group by submitting a SED Group
Offer. The data recipient can then accept or reject that offer. Not Offer. The data recipient can then accept or reject that offer. Not
until access to a SED Group has been offered and accepted will the until access to a SED Group has been offered and accepted will the
data recipient's organization ID be included in the peeringOrg list data recipient's organization ID be included in the peeringOrg list
in a SED Group object, and that SED Group's peering information in a SED Group object, and that SED Group's peering information
become a candidate for inclusion in the responses to the resolution become a candidate for inclusion in the responses to the resolution
requests submitted by that data recipient. The transport protocol requests submitted by that data recipient. The substrate protocol
MUST support the ability to Add, Get, Delete, Accept and Reject SED MUST support the ability to Add, Get, Delete, Accept and Reject SED
Group Offers (refer to the "Framework Operations" section of this Group Offers (refer to Section 7 for a generic description of various
document for a generic description of various operations). operations).
A SED Group Offer object MUST be uniquely identified by attributes as A SED Group Offer object MUST be uniquely identified by attributes as
defined in the description of "SedGrpOfferKeyType" in the section defined in the description of "SedGrpOfferKeyType" in the section
"Derived Object Key Types" of this document. "Derived Object Key Types" of this document.
The SedGrpOfferType object structure is defined as follows: The SedGrpOfferType object structure is defined as follows:
<complexType name="SedGrpOfferType"> <complexType name="SedGrpOfferType">
<complexContent> <complexContent>
<extension base="sppfb:BasicObjType"> <extension base="sppfb:BasicObjType">
skipping to change at page 33, line 29 skipping to change at page 33, line 29
<element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/> <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
<complexType name="SedGrpOfferKeyType" abstract="true"> <complexType name="SedGrpOfferKeyType" abstract="true">
<annotation> <annotation>
<documentation> <documentation>
-- Generic type that represents the key for a SED group offer. Must -- Generic type that represents the key for a SED group offer. Must
be defined in concrete form in the transport specification. -- be defined in concrete form in the substrate specification. --
</documentation> </documentation>
</annotation> </annotation>
</complexType> </complexType>
<simpleType name="SedGrpOfferStatusType"> <simpleType name="SedGrpOfferStatusType">
<restriction base="token"> <restriction base="token">
<enumeration value="offered"/> <enumeration value="offered"/>
<enumeration value="accepted"/> <enumeration value="accepted"/>
</restriction> </restriction>
</simpleType> </simpleType>
skipping to change at page 33, line 51 skipping to change at page 33, line 51
The SedGrpOfferType object is composed of the following elements: The SedGrpOfferType object is composed of the following elements:
o base: All first class objects extend BasicObjType (see o base: All first class objects extend BasicObjType (see
Section 5.1). Section 5.1).
o sedGrpOfferKey: The object that identifies the SED that is or has o sedGrpOfferKey: The object that identifies the SED that is or has
been offered and the organization that it is or has been offered been offered and the organization that it is or has been offered
to. to.
o status: The status of the offer, offered or accepted. The server o status: The status of the offer, offered or accepted. The server
controls the status. It is automatically set to "offered" when controls the status. It is automatically set to "offered"
ever a new SED Group Offer is added, and is automatically set to whenever a new SED Group Offer is added, and is automatically set
"accepted" if and when that offer is accepted. The value of the to "accepted" if and when that offer is accepted. The value of
element is ignored when passed in by the client. the element is ignored when passed in by the client.
o offerDateTime: Date and time in UTC when the SED Group Offer was o offerDateTime: Date and time in UTC when the SED Group Offer was
added. added.
o acceptDateTime: Date and time in UTC when the SED Group Offer was o acceptDateTime: Date and time in UTC when the SED Group Offer was
accepted. accepted.
6.6. Egress Route 6.6. Egress Route
In a high-availability environment, the originating SSP likely has In a high-availability environment, the originating SSP likely has
more than one egress path to the ingress SBE of the target SSP. If more than one egress path 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 EgrRteType object. can do so using the EgrRteType object.
An Egress Route object MUST be uniquely identified by attributes as An Egress Route object MUST be uniquely identified by attributes as
defined in the description of "ObjKeyType" in the section "Generic defined in the description of "ObjKeyType" in the section "Generic
Object Key Type" of this document. Object Key Type" of this document.
Lets assume that the target SSP has offered as part of his session Assume that the target SSP has offered as part of its session
establishment data, to share one or more ingress routes and that the establishment data, to share one or more ingress routes and that the
originating SSP has accepted the offer. In order to add the egress originating SSP has accepted the offer. In order to add the egress
route to the Registry, the originating SSP uses a valid regular route to the Registry, the originating SSP uses a valid regular
expression to rewrite ingress route in order to include the egress expression to rewrite the ingress route in order to include the
SBE information. Also, more than one egress route can be associated egress SBE information. Also, more than one egress route can be
with a given ingress route in support of fault-tolerant associated with a given ingress route in support of fault-tolerant
configurations. The supporting SPPF structure provides a way to configurations. The supporting SPPF structure provides a way to
include route precedence information to help manage traffic to more include route precedence information to help manage traffic to more
than one outbound egress SBE. than one outbound egress SBE.
The transport protocol MUST support the ability to Add, Get, and The substrate protocol MUST support the ability to Add, Get, and
Delete Egress Routes (refer to the "Framework Operations" section of Delete Egress Routes (refer to Section 7 for a generic description of
this document for a generic description of various operations). The various operations). The EgrRteType object structure is defined as
EgrRteType object structure is defined as follows: follows:
<complexType name="EgrRteType"> <complexType name="EgrRteType">
<complexContent> <complexContent>
<extension base="sppfb:BasicObjType"> <extension base="sppfb:BasicObjType">
<sequence> <sequence>
<element name="egrRteName" type="sppfb:ObjNameType"/> <element name="egrRteName" type="sppfb:ObjNameType"/>
<element name="pref" type="unsignedShort"/> <element name="pref" type="unsignedShort"/>
<element name="regxRewriteRule" type="sppfb:RegexParamType"/> <element name="regxRewriteRule" type="sppfb:RegexParamType"/>
<element name="ingrSedGrp" type="sppfb:ObjKeyType" <element name="ingrSedGrp" type="sppfb:ObjKeyType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
skipping to change at page 36, line 7 skipping to change at page 36, line 7
Route, then the Egress Route's regxRewriteRule should be applied Route, then the Egress Route's regxRewriteRule should be applied
to all the NAPTRs associated with the SED Group. This field's to all the NAPTRs associated with the SED Group. This field's
value must be of the form specified in [RFC6116] (e.g., value must be of the form specified in [RFC6116] (e.g.,
E2U+pstn:sip+sip). The allowable values are a matter of policy E2U+pstn:sip+sip). The allowable values are a matter of policy
and not limited by this protocol. and not limited by this protocol.
o ext: Point of extensibility described in Section 3.3. o ext: Point of extensibility described in Section 3.3.
7. Framework Operations 7. Framework Operations
In addition to the operation specific object types, all operations In addition to the operation-specific object types, all operations
MAY specify the minor version of the protocol that when used in MAY specify the minor version of the protocol that when used in
conjunction with the major version (that can be for instance conjunction with the major version (which can be for instance
specified in the protocol namespace) can serve to identify the specified in the protocol namespace) can serve to identify the
version of the SPPF protocol that the client is using. If the minor version of the SPPF protocol that the client is using. If the minor
version is not specified, the latest minor version supported by the version is not specified, the latest minor version supported by the
SPPF server for the given major version will be used. Additionally, SPPF server for the given major version will be used. Additionally,
operations that may potentially modify persistent protocol objects operations that may potentially modify persistent protocol objects
SHOULD include a transaction ID as well. SHOULD include a transaction ID as well.
7.1. Add Operation 7.1. Add Operation
Any conforming transport protocol specification MUST provide a Any conforming substrate protocol specification MUST provide a
definition for the operation that adds one or more SPPF objects into definition for the operation that adds one or more SPPF objects into
the Registry. If the object, as identified by the request attributes the Registry. If the object, as identified by the request attributes
that form part of the object's key, does not exist, then the Registry that form part of the object's key, does not exist, then the Registry
MUST create the object. If the object does exist, then the Registry MUST create the object. If the object does exist, then the Registry
MUST replace the current properties of the object with the properties MUST replace the current properties of the object with the properties
passed in as part of the Add operation. passed in as part of the Add operation.
Note that this effectively allows to modify a pre-existing object. Note that this effectively allows to modify a pre-existing object.
If the entity that issued the command is not authorized to perform If the entity that issued the command is not authorized to perform
this operation an appropriate error message MUST be returned from this operation an appropriate error message MUST be returned from
amongst the response messages defined in "Response Message Types" amongst the response messages defined in the "Response Message Types"
section of the document. section of the document.
7.2. Delete Operation 7.2. Delete Operation
Any conforming transport protocol specification MUST provide a Any conforming substrate protocol specification MUST provide a
definition for the operation that deletes one or more SPPF objects definition for the operation that deletes one or more SPPF objects
from the Registry using the object's key. from the Registry using the object's key.
If the entity that issued the command is not authorized to perform If the entity that issued the command is not authorized to perform
this operation an appropriate error message MUST be returned from this operation an appropriate error message MUST be returned from
amongst the response messages defined in "Response Message Types" amongst the response messages defined in "Response Message Types"
section of the document. section of the document.
When an object is deleted, any references to that object must of When an object is deleted, any references to that object must of
course also be removed as the SPPF server implementation fulfills the course also be removed as the SPPF server implementation fulfills the
deletion request. Furthermore, the deletion of a composite object deletion request. Furthermore, the deletion of a composite object
must also result in the deletion of the objects it contains. As a must also result in the deletion of the objects it contains. As a
result, the following rules apply to the deletion of SPPF object result, the following rules apply to the deletion of SPPF object
types: types:
o Destination Groups: When a destination group is deleted any o Destination Groups: When a destination group is deleted any
references between that destination group and any SED group must references between that destination group and any SED group must
be automatically removed by the SPPF implementation as part of be automatically removed by the SPPF implementation as part of
fulfilling the deletion request. Similarly, any references fulfilling the deletion request. Similarly, any references
between that destination group and any Public Identifier must be between that destination group and any Public Identifier must be
removed by the SPPF implementation as part of fulfilling the removed by the SPPF implementation.
deletion request.
o SED Groups: When a SED group is deleted any references between o SED Groups: When a SED group is deleted any references between
that SED group and any destination group must be automatically that SED group and any destination group must be automatically
removed by the SPPF implementation as part of fulfilling the removed by the SPPF implementation as part of fulfilling the
deletion request. Similarly any references between that SED group deletion request. Similarly any references between that SED group
and any SED records must be removed by the SPPF implementation as and any SED records must be removed by the SPPF implementation as
part of fulfilling the deletion request. Furthermore, SED group part of fulfilling the deletion request. Furthermore, SED group
offers relating that SED group must also be deleted as part of offers relating to that SED group must also be deleted.
fulfilling the deletion request.
o SED Records: When a SED record is deleted any references between o SED Records: When a SED record is deleted any references between
that SED record and any SED group must be removed by the SPPF that SED record and any SED group must be removed by the SPPF
implementation as part of fulfilling the deletion request. implementation as part of fulfilling the deletion request.
Similarly, any reference between that SED record and any Public Similarly, any reference between that SED record and any Public
Identifier must be removed by the SPPF implementation as part of Identifier must be removed by the SPPF implementation.
fulfilling the deletion request.
o Public Identifiers: When a public identifier is deleted any o Public Identifiers: When a public identifier is deleted any
references between that public identifier and any referenced references between that public identifier and any referenced
destination group must be removed by the SPPF implementation as destination group must be removed by the SPPF implementation as
part of fulfilling the deletion request. Any references to SED part of fulfilling the deletion request. Any references to SED
records associated directly to that Public Identifier must also be records associated directly to that Public Identifier must also be
deleted by the SPPF implementation as part of fulfilling the deleted by the SPPF implementation.
deletion request.
Deletes MUST be atomic
7.3. Get Operations 7.3. Get Operations
At times, on behalf of the Registrant, the Registrar may need to get At times, on behalf of the Registrant, the Registrar may need to get
information about SPPF objects that were previously provisioned in information about SPPF objects that were previously provisioned in
the Registry. A few examples include logging, auditing, and pre- the Registry. A few examples include logging, auditing, and pre-
provisioning dependency checking. This query mechanism is limited to provisioning dependency checking. This query mechanism is limited to
aid provisioning scenarios and should not be confused with query aid provisioning scenarios and should not be confused with query
protocols provided as part of the resolution system (e.g. ENUM and protocols provided as part of the resolution system (e.g., ENUM and
SIP). SIP).
Any conforming "protocol" specification MUST provide a definition for Any conforming "protocol" specification MUST provide a definition for
the operation that queries the details of one or more SPPF objects the operation that queries the details of one or more SPPF objects
from the Registry using the object's key. If the entity that issued from the Registry using the object's key. 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 message MUST be returned from amongst the response appropriate error message MUST be returned from amongst the response
messages defined in Section 5.3. messages defined in Section 5.3.
If the response to the Get operation includes object(s) that extend If the response to the Get operation includes object(s) that extend
the BasicObjType, the Registry MUST include the 'cDate' and 'mDate', the BasicObjType, the Registry MUST include the 'cDate' and 'mDate',
if applicable. if applicable.
7.4. Accept Operations 7.4. Accept Operations
In SPPF, a SED Group Offer can be accepted or rejected by, or on In SPPF, a SED Group Offer can be accepted or rejected by, or on
behalf of, the Registrant to whom the SED Group has been offered behalf of, the Registrant to which the SED Group has been offered
(refer "Framework Data Model Objects" section of this document for a (refer to Section 7 of this document for a description of the SED
description of the SED Group Offer object). The Accept operation is Group Offer object). The Accept operation is used to accept the SED
used to accept the SED Group Offers. Any conforming transport Group Offers. Any conforming substrate protocol specification MUST
protocol specification MUST provide a definition for the operation to provide a definition for the operation to accept SED Group Offers by,
accept SED Group Offers by, or on behalf of the Registrant, using the or on behalf of the Registrant, using the SED Group Offer object key.
SED Group Offer object key.
Not until access to a SED Group has been offered and accepted will Not until access to a SED Group has been offered and accepted will
the Registrant's organization ID be included in the peeringOrg list the Registrant's organization ID be included in the peeringOrg list
in that SED Group object, and that SED Group's peering information in that SED Group object, and that SED Group's peering information
become a candidate for inclusion in the responses to the resolution become a candidate for inclusion in the responses to the resolution
requests submitted by that Registrant. A SED Group Offer that is in requests submitted by that Registrant. A SED Group Offer that is in
the "offered" status is accepted by, or on behalf of, the Registrant the "offered" status is accepted by, or on behalf of, the Registrant
to which it has been offered. When the SED Group Offer is accepted to which it has been offered. When the SED Group Offer is accepted
the the SED Group Offer is moved to the "accepted" status and adds the SED Group Offer is moved to the "accepted" status and adds that
that data recipient's organization ID into the list of peerOrgIds for data recipient's organization ID into the list of peerOrgIds for that
that SED Group. SED Group.
If the entity that issued the command is not authorized to perform If the entity that issued the command is not authorized to perform
this operation an appropriate error message MUST be returned from this operation an appropriate error message MUST be returned from
amongst the response messages defined in "Response Message Types" amongst the response messages defined in "Response Message Types"
section of the document. section of the document.
7.5. Reject Operations 7.5. Reject Operations
In SPPF, a SED Group Offer object can be accepted or rejected by, or In SPPF, a SED Group Offer object can be accepted or rejected by, or
on behalf of, the Registrant to whom the SED Group has been offered on behalf of, the Registrant to which the SED Group has been offered
(refer "Framework Data Model Objects" section of this document for a (refer "Framework Data Model Objects" section of this document for a
description of the SED Group Offer object). Furthermore, that offer description of the SED Group Offer object). Furthermore, that offer
may be rejected, regardless of whether or not it has been previously may be rejected, regardless of whether or not it has been previously
accepted. The Reject operation is used to reject the SED Group accepted. The Reject operation is used to reject the SED Group
Offers. When the SED Group Offer is rejected that SED Group Offer is Offer. When the SED Group Offer is rejected that SED Group Offer is
deleted, and, if appropriate, the data recipient's organization ID is deleted, and, if appropriate, the data recipient's organization ID is
removed from the list of peeringOrg IDs for that SED Group. Any removed from the list of peeringOrg IDs for that SED Group. Any
conforming transport protocol specification MUST provide a definition conforming substrate protocol specification MUST provide a definition
for the operation to reject SED Group Offers by, or on behalf of the for the operation to reject SED Group Offers by, or on behalf of the
Registrant, using the SED Group Offer object key. Registrant, using the SED Group Offer object key.
If the entity that issued the command is not authorized to perform If the entity that issued the command is not authorized to perform
this operation an appropriate error message MUST be returned from this operation an appropriate error message MUST be returned from
amongst the response messages defined in "Response Message Types" amongst the response messages defined in "Response Message Types"
section of the document. section of the document.
7.6. Get Server Details Operation 7.6. Get Server Details Operation
In SPPF, Get Server Details operation can be used to request certain In SPPF, the Get Server Details operation can be used to request
details about the SPPF server that include the SPPF server's current certain details about the SPPF server that include the SPPF server's
status, the major/minor version of the SPPF protocol supported by the current status and the major/minor version of the SPPF protocol
SPPF server. supported by the SPPF server.
Any conforming transport protocol specification MUST provide a Any conforming substrate protocol specification MUST provide a
definition for the operation to request such details from the SPPF definition for the operation to request such details from the SPPF
server. If the entity that issued the command is not authorized to server. If the entity that issued the command is not authorized to
perform this operation an appropriate error message MUST be returned perform this operation an appropriate error message MUST be returned
from amongst the response messages defined in "Response Message from amongst the response messages defined in the "Response Message
Types" section of the document. Types" section of the document.
8. XML Considerations 8. XML Considerations
XML serves as the encoding format for SPPF, allowing complex XML serves as the encoding format for SPPF, allowing complex
hierarchical data to be expressed in a text format that can be read, hierarchical data to be expressed in a text format that can be read,
saved, and manipulated with both traditional text tools and tools saved, and manipulated with both traditional text tools and tools
specific to XML. specific to XML.
XML is case sensitive. Unless stated otherwise, XML specifications XML is case sensitive. Unless stated otherwise, XML specifications
skipping to change at page 40, line 26 skipping to change at page 40, line 26
9. Security Considerations 9. Security Considerations
Many SPPF implementations manage data that is considered confidential Many SPPF implementations manage data that is considered confidential
and critical. Furthermore, SPPF implementations can support and critical. Furthermore, SPPF implementations can support
provisioning activities for multiple Registrars and Registrants. As provisioning activities for multiple Registrars and Registrants. As
a result any SPPF implementation must address the requirements for a result any SPPF implementation must address the requirements for
confidentiality, authentication, and authorization. confidentiality, authentication, and authorization.
9.1. Confidentiality and Authentication 9.1. Confidentiality and Authentication
With respect to confidentiality and authentication, the transport With respect to confidentiality and authentication, the substrate
protocol requirements section of this document contains security protocol requirements section of this document contains security
properties that the transport protocol must provide so that properties that the substrate protocol must provide so that
authenticated endpoints can exchange data confidentially and with authenticated endpoints can exchange data confidentially and with
integrity protection. Refer to that section and the resulting integrity protection. Refer to that section and
transport protocol specification document for the specific solutions [I-D.ietf-drinks-spp-protocol-over-soap] for the specific solutions
to authentication and confidentiality. to authentication and confidentiality.
9.2. Authorization 9.2. Authorization
With respect to authorization, the SPPF server implementation must With respect to authorization, the SPPF 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 SPPF object type for given Registrant(s) and (2) which delete each SPPF object type for given Registrant(s) and (2) which
Registrars will be authorized to view/get each SPPF object type for Registrars will be authorized to view/get each SPPF object type for
given Registrant(s). These authorization rules are a matter of given Registrant(s). These authorization rules are a matter of
skipping to change at page 41, line 13 skipping to change at page 41, line 13
gives a general vocabulary for describing the DoS issue. gives a general vocabulary for describing the DoS issue.
SPPF is a high-level client-server protocol that can be implemented SPPF is a high-level client-server protocol that can be implemented
on lower-level mechanisms such as remote procedure call and web- on lower-level mechanisms such as remote procedure call and web-
service API protocols. As such, it inherits any Denial-of-Service service API protocols. As such, it inherits any Denial-of-Service
issues inherent to the specific lower-level mechanism used for any issues inherent to the specific lower-level mechanism used for any
implementation of SPPF. SPPF also has its own set of higher-level implementation of SPPF. SPPF also has its own set of higher-level
exposures that are likely to be independent of lower-layer mechanism exposures that are likely to be independent of lower-layer mechanism
choices. choices.
9.3.1. DoS Issues Inherited from Transport Mechanism 9.3.1. DoS Issues Inherited from Substrate Mechanism
SPPF implementation is in general dependent on the selection and An SPPF implementation is in general dependent on the selection and
implementation of a lower-level transport protocol and a binding implementation of a lower-level substrate protocol and a binding
between that protocol and SPPF. The archetypal SPPF implementation between that protocol and SPPF. The archetypal SPPF implementation
uses XML (http://www.w3.org/TR/xml/) representation in a SOAP uses XML [W3C.REC-xml-20081126] representation in a SOAP [SOAPREF]
(http://www.w3.org/TR/soap/) request/response framework over HTTP request/response framework over HTTP ([RFC7230]), and probably also
([RFC7230]), and probably also uses TLS ([RFC5246]) for on-the wire uses TLS ([RFC5246]) for on-the-wire data integrity and participant
data integrity and participant authentication, and might use HTTP authentication, and might use HTTP Digest authentication ([RFC2609]).
Digest authentication ([RFC2609]).
The typical deployment scenario for SPPF is to have servers in a The typical deployment scenario for SPPF is to have servers in a
managed facility, and therefore techniques such as Network Ingress managed facility, and therefore techniques such as Network Ingress
Filtering ([RFC2609]) are generally applicable. In short, any DoS Filtering ([RFC2609]) are generally applicable. In short, any DoS
mechanism affecting a typical HTTP implementation would affect such mechanism affecting a typical HTTP implementation would affect such
an SPPF implementation, and the mitigation tools for HTTP in general an SPPF implementation, and the mitigation tools for HTTP in general
also therefore apply to SPPF. also therefore apply to SPPF.
SPPF does not directly specify an authentication mechanism, instead SPPF does not directly specify an authentication mechanism, instead
relying on the lower-level transport protocol to provide for relying on the lower-level substrate protocol to provide for
authentication. In general, authentication is an expensive authentication. In general, authentication is an expensive
operation, and one apparent attack vector is to flood an SPPF server operation, and one apparent attack vector is to flood an SPPF server
with repeated requests for authentication, thereby exhausting its with repeated requests for authentication, thereby exhausting its
resources. SPPF implementations SHOULD therefore be prepared to resources. SPPF implementations SHOULD therefore be prepared to
handle authentication floods, perhaps by noting repeated failed login handle authentication floods, perhaps by noting repeated failed login
requests from a given source address and blocking that source requests from a given source address and blocking that source
address. address.
9.3.2. DoS Issues Specific to SPPF 9.3.2. DoS Issues Specific to SPPF
skipping to change at page 42, line 8 skipping to change at page 42, line 5
SPPF service, SHOULD implement DoS and other policy control SPPF service, SHOULD implement DoS and other policy control
screening, and MAY employ a variety of policy violation reporting and screening, and MAY employ a variety of policy violation reporting and
response measures such as automatic blocking of specific users and response measures such as automatic blocking of specific users and
alerting of operations personnel. In short, the primary SPPF alerting of operations personnel. In short, the primary SPPF
response to DoS-like activity by a user is to block that user or response to DoS-like activity by a user is to block that user or
subject their actions to additional review. subject their actions to additional review.
SPPF allows a client to submit multiple-element or "batch" requests SPPF allows a client to submit multiple-element or "batch" requests
that may insert or otherwise affect a large amount of data with a that may insert or otherwise affect a large amount of data with a
single request. In the simplest case, the server progresses single request. In the simplest case, the server progresses
sequentially through each element in a batch, completing one and sequentially through each element in a batch, completing one before
before starting the next. Mid-batch failures are handled by stopping starting the next. Mid-batch failures are handled by stopping the
the batch and rolling-back the data store to its pre-request state. batch and rolling-back the data store to its pre-request state. This
This "stop and roll-back" design provides a DoS opportunity. A "stop and roll-back" design provides a DoS opportunity. A hostile
hostile client could repeatedly issue large batch requests with one client could repeatedly issue large batch requests with one or more
or more failing elements, causing the server to repeatedly stop and failing elements, causing the server to repeatedly stop and roll-back
roll-back large transactions. The suggested response is to monitor large transactions. The suggested response is to monitor clients for
clients for such failures, and take administrative action (such as such failures, and take administrative action (such as blocking the
blocking the user) when an excessive number of roll-backs is user) when an excessive number of roll-backs is reported.
reported.
An additional suggested response is for an implementer to set their An additional suggested response is for an implementer to set their
maximum allowable XML message size, and their maximum allowable batch maximum allowable XML message size, and their maximum allowable batch
size at a level that they feel protects their operational instance, size at a level that they feel protects their operational instance,
given the hardware sizing they have in place and the expected load given the hardware sizing they have in place and the expected load
and size needs that their users expect. and size needs that their users expect.
9.4. Information Disclosure 9.4. Information Disclosure
It is not uncommon for the logging systems to document on-the-wire It is not uncommon for the logging systems to document on-the-wire
messages for various purposes, such as, debug, audit, and tracking. messages for various purposes, such as, debug, audit, and tracking.
At the minimum, the various support and administration staff will At the minimum, the various support and administration staff will
have access to these logs. Also, if an unprivileged user gains have access to these logs. Also, if an unprivileged user gains
access to the SPPF deployments and/or support systems, it will have access to the SPPF deployments and/or support systems, it will have
access to the information that is potentially deemed confidential. access to the information that is potentially deemed confidential.
To manage information disclosure concerns beyond the transport level, To manage information disclosure concerns beyond the substrate level,
SPPF implementations MAY provide support for encryption at the SPPF SPPF implementations MAY provide support for encryption at the SPPF
object level. object level.
9.5. Non Repudiation 9.5. Non-repudiation
In some situations, it may be required to protect against denial of In some situations, it may be required to protect against denial of
involvement (see [RFC4949]) and tackle non-repudiation concerns in involvement (see [RFC4949]) and tackle non-repudiation concerns in
regards to SPPF messages. This type of protection is useful to regards to SPPF messages. This type of protection is useful to
satisfy authenticity concerns related to SPPF messages beyond the satisfy authenticity concerns related to SPPF messages beyond the
end-to-end connection integrity, confidentiality, and authentication end-to-end connection integrity, confidentiality, and authentication
protection that the transport layer provides. This is an optional protection that the substrate layer provides. This is an optional
feature and some SPPF implementations MAY provide support for it. feature and some SPPF implementations MAY provide support for it.
9.6. Replay Attacks 9.6. Replay Attacks
Anti-replay protection ensures that a given SPPF object replayed at a Anti-replay protection ensures that a given SPPF object replayed at a
later time doesn't affect the integrity of the system. SPPF provides later time doesn't affect the integrity of the system. SPPF provides
at least one mechanism to fight against replay attacks. Use of the at least one mechanism to fight against replay attacks. Use of the
optional client transaction identifier allows the SPPF client to optional client transaction identifier allows the SPPF client to
correlate the request message with the response and to be sure that correlate the request message with the response and to be sure that
it is not a replay of a server response from earlier exchanges. Use it is not a replay of a server response from earlier exchanges. Use
of unique values for the client transaction identifier is highly of unique values for the client transaction identifier is highly
encouraged to avoid chance matches to a potential replay message. encouraged to avoid chance matches to a potential replay message.
9.7. Man in the Middle 9.7. Man in the Middle
The SPPF client or Registrar can be a separate entity acting on The SPPF client or Registrar can be a separate entity acting on
behalf of the Registrant in facilitating provisioning transactions to behalf of the Registrant in facilitating provisioning transactions to
the Registry. Further, the transport layer provides end-to-end the Registry. Therefore, even though the substrate layer provides
connection protection between SPPF client and the SPPF server. end-to-end protection for each specific SPPP connection between
Therefore, man-in-the-middle attack is a possibility that may affect client and server, data might be available in clear text before or
the integrity of the data that belongs to the Registrant and/or after it traverses a SPPP connection. Therefore, a man-in-the-middle
expose peer data to unintended actors in case well-established attack by one of the actors is a possibility that could affect the
peering relationships already exist. integrity of the data that belongs to the Registrant and/or expose
peering data to unintended actors.
10. Internationalization Considerations 10. Internationalization Considerations
Character encodings to be used for SPPF elements are described in Character encodings to be used for SPPF elements are described in
Section 8.2. The use of time elements in the protocol is specified Section 8.2. The use of time elements in the protocol is specified
in Section 3.2. Where human-readable languages are used in the in Section 3.2. Where human-readable messages that are presented to
protocol, those messages SHOULD be tagged according to [RFC5646], and an end user are used in the protocol, those messages SHOULD be tagged
the transport protocol MUST support a respective mechanism to according to [RFC5646], and the substrate protocol MUST support a
transmit such tags together with those human-readable messages. If respective mechanism to transmit such tags together with those human-
tags are absent, the language of the message defaults to "en" readable messages.
(English).
11. IANA Considerations 11. IANA Considerations
11.1. URN Assignments 11.1. URN Assignments
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.
skipping to change at page 44, line 8 skipping to change at page 44, line 8
Registration request for the XML schema: Registration request for the XML schema:
URI: urn:ietf:params:xml:schema:sppf:1 URI: urn:ietf:params:xml:schema:sppf:1
Registrant Contact: IESG Registrant Contact: IESG
XML: See the "Formal Specification" section of this document XML: See the "Formal Specification" section of this document
(Section 12). (Section 12).
11.2. Organization Identifier Namespace Registry 11.2. Organization Identifier Namespace Registry
IANA is requested to create and maintain a Registry entitled "SPPF IANA is requested to create and maintain a Registry entitled "SPPF
OrgIdType Namespaces". Strings used as OrgIdType Namespace OrgIdType Namespaces". The formal syntax is described in
identifiers MUST conform to the following syntax in the Augmented Section 5.1.
Backus-Naur Form (ABNF) [RFC5234]
namespace = ALPHA * (ALPHA/DIGIT/"-")
Assignments consist of the OrgIdType namespace string, and the Assignments consist of the OrgIdType namespace string and the
definition of the associated namespace. This document makes the definition of the associated namespace. This document makes the
following initial assignment for the OrgIdType Namespaces: following initial assignment for the OrgIdType Namespaces:
OrgIdType namespace string Namespace OrgIdType namespace string Namespace
-------------------------- --------- -------------------------- ---------
IANA Enterprise Numbers iana-en IANA Enterprise Numbers iana-en
Future assignments are to be made through the well known IANA Policy Future assignments are to be made through the well-known IANA Policy
"RFC Required" (see section 4.1 of [RFC5226]) "RFC Required" (see section 4.1 of [RFC5226]). Such assignments will
typically be requested when a new namespace for identification of
service providers is defined.
12. Formal Specification 12. Formal Specification
This section provides the draft XML Schema Definition for SPPF This section provides the draft XML Schema Definition for SPPF
Protocol. Protocol.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<schema xmlns:sppfb="urn:ietf:params:xml:ns:sppf:base:1" <schema xmlns:sppfb="urn:ietf:params:xml:ns:sppf:base:1"
xmlns="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:sppf:base:1" targetNamespace="urn:ietf:params:xml:ns:sppf:base:1"
elementFormDefault="qualified" xml:lang="EN"> elementFormDefault="qualified" xml:lang="EN">
<annotation> <annotation>
<documentation> <documentation>
---- Generic Object key types to be defined by specific ---- Generic Object key types to be defined by specific
Transport/Architecture. The types defined here can Substrate/Architecture. The types defined here can
be extended by the specific architecture to be extended by the specific architecture to
define the Object Identifiers ---- define the Object Identifiers ----
</documentation> </documentation>
</annotation> </annotation>
<complexType name="ObjKeyType" <complexType name="ObjKeyType"
abstract="true"> abstract="true">
<annotation> <annotation>
<documentation> <documentation>
---- Generic type that represents the ---- Generic type that represents the
key for various objects in SPPF. ---- key for various objects in SPPF. ----
skipping to change at page 52, line 48 skipping to change at page 52, line 47
</schema> </schema>
13. Acknowledgments 13. Acknowledgments
This document is a result of various discussions held in the DRINKS This document is a result of various discussions held in the DRINKS
working group and within the DRINKS protocol design team, with working group and within the DRINKS protocol design team, with
contributions from the following individuals, in alphabetical order: contributions from the following individuals, in alphabetical order:
Alexander Mayrhofer, David Schwartz, Deborah A Guyton, Lisa Alexander Mayrhofer, David Schwartz, Deborah A Guyton, Lisa
Dusseault, Manjul Maharishi, Mickael Marrache, Otmar Lendl, Richard Dusseault, Manjul Maharishi, Mickael Marrache, Otmar Lendl, Richard
Shockey, Samuel Melloul, Sumanth Channabasappa, Syed Ali, Vikas Shockey, Samuel Melloul, Sumanth Channabasappa, Syed Ali, Vikas
Bhatia, and Jeremy Barkan Bhatia, and Jeremy Barkan.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-drinks-spp-protocol-over-soap]
Cartwright, K., Bhatia, V., Mule, J., and A. Mayrhofer,
"Session Peering Provisioning (SPP) Protocol over SOAP",
draft-ietf-drinks-spp-protocol-over-soap-07 (work in
progress), October 2014.
[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, DOI 10.17487/RFC2277,
January 1998, <http://www.rfc-editor.org/info/rfc2277>.
[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, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66,
3986, January 2005. RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[W3C.REC-xml-20081126]
Sperberg-McQueen, C., Yergeau, F., Bray, T., Maler, E.,
and J. Paoli, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>.
14.2. Informative References 14.2. Informative References
[RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates
and Service: Schemes", RFC 2609, June 1999. and Service: Schemes", RFC 2609, DOI 10.17487/RFC2609,
June 1999, <http://www.rfc-editor.org/info/rfc2609>.
[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, DOI 10.17487/RFC2781, February 2000,
<http://www.rfc-editor.org/info/rfc2781>.
[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. DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database", RFC Part Three: The Domain Name System (DNS) Database",
3403, October 2002. RFC 3403, DOI 10.17487/RFC3403, October 2002,
<http://www.rfc-editor.org/info/rfc3403>.
[RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation [RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation
Architecture", RFC 4725, November 2006. Architecture", RFC 4725, DOI 10.17487/RFC4725, November
2006, <http://www.rfc-editor.org/info/rfc4725>.
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
Service Considerations", RFC 4732, December 2006. Denial-of-Service Considerations", RFC 4732,
DOI 10.17487/RFC4732, December 2006,
<http://www.rfc-editor.org/info/rfc4732>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
4949, August 2007. FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>.
[RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM [RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM
Requirements", RFC 5067, November 2007. Requirements", RFC 5067, DOI 10.17487/RFC5067, November
2007, <http://www.rfc-editor.org/info/rfc5067>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia [RFC5486] Malas, D., Ed. and D. Meyer, Ed., "Session Peering for
Interconnect (SPEERMINT) Terminology", RFC 5486, March Multimedia Interconnect (SPEERMINT) Terminology",
2009. RFC 5486, DOI 10.17487/RFC5486, March 2009,
<http://www.rfc-editor.org/info/rfc5486>.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009. Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <http://www.rfc-editor.org/info/rfc5646>.
[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
Uniform Resource Identifiers (URI) Dynamic Delegation Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)", RFC 6116, Discovery System (DDDS) Application (ENUM)", RFC 6116,
March 2011. DOI 10.17487/RFC6116, March 2011,
<http://www.rfc-editor.org/info/rfc6116>.
[RFC6461] Channabasappa, S., "Data for Reachability of Inter-/Intra- [RFC6461] Channabasappa, S., Ed., "Data for Reachability of Inter-
NetworK SIP (DRINKS) Use Cases and Protocol Requirements", /Intra-NetworK SIP (DRINKS) Use Cases and Protocol
RFC 6461, January 2012. Requirements", RFC 6461, DOI 10.17487/RFC6461, January
2012, <http://www.rfc-editor.org/info/rfc6461>.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June Protocol (HTTP/1.1): Message Syntax and Routing",
2014. RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[SOAPREF] Gudgin, M., Hadley, M., Moreau, J., and H. Nielsen, "SOAP
Version 1.2 Part 1: Messaging Framework", W3C
Recommendation REC-SOAP12-part1-20030624, June 2002.
[Unicode6.1] [Unicode6.1]
The Unicode Consortium, "The Unicode Standard - Version The Unicode Consortium, "The Unicode Standard - Version
6.1", Unicode 6.1, January 2012. 6.1", Unicode 6.1, January 2012.
Authors' Addresses Authors' Addresses
Kenneth Cartwright Kenneth Cartwright
TNS TNS
1939 Roland Clarke Place 1939 Roland Clarke Place
 End of changes. 166 change blocks. 
363 lines changed or deleted 390 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35