doc: Add RFC documents

1 files changed, 3195 insertions, 0 deletions

diff --git a/doc/rfc/rfc7877.txt b/doc/rfc/rfc7877.txt
new file mode 100644
index 0000000..596f055
--- /dev/null
+++ b/doc/rfc/rfc7877.txt
@@ -0,0 +1,3195 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     K. Cartwright
+Request for Comments: 7877                                     V. Bhatia
+Category: Standards Track                                            TNS
+ISSN: 2070-1721                                                   S. Ali
+                                                                 NeuStar
+                                                             D. Schwartz
+                                                                XConnect
+                                                             August 2016
+
+
+             Session Peering Provisioning Framework (SPPF)
+
+Abstract
+
+   This document specifies the data model and the overall structure for
+   a framework to provision Session Establishment Data (SED) into
+   Session Data Registries and SIP Service Provider (SSP) data stores.
+   The framework is called the "Session Peering Provisioning Framework"
+   (SPPF).  The provisioned data is typically used by network elements
+   for session establishment.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7877.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                    [Page 1]
+
+RFC 7877                          SSPF                       August 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
+   3.  Framework High-Level Design . . . . . . . . . . . . . . . . .   7
+     3.1.  Framework Data Model  . . . . . . . . . . . . . . . . . .   7
+     3.2.  Time Value  . . . . . . . . . . . . . . . . . . . . . . .  10
+     3.3.  Extensibility . . . . . . . . . . . . . . . . . . . . . .  10
+   4.  Substrate Protocol Requirements . . . . . . . . . . . . . . .  11
+     4.1.  Mandatory Substrate . . . . . . . . . . . . . . . . . . .  11
+     4.2.  Connection Oriented . . . . . . . . . . . . . . . . . . .  11
+     4.3.  Request and Response Model  . . . . . . . . . . . . . . .  11
+     4.4.  Connection Lifetime . . . . . . . . . . . . . . . . . . .  11
+     4.5.  Authentication  . . . . . . . . . . . . . . . . . . . . .  12
+     4.6.  Authorization . . . . . . . . . . . . . . . . . . . . . .  12
+     4.7.  Confidentiality and Integrity . . . . . . . . . . . . . .  12
+     4.8.  Near Real Time  . . . . . . . . . . . . . . . . . . . . .  12
+     4.9.  Request and Response Sizes  . . . . . . . . . . . . . . .  12
+     4.10. Request and Response Correlation  . . . . . . . . . . . .  13
+     4.11. Request Acknowledgement . . . . . . . . . . . . . . . . .  13
+   5.  Base Framework Data Structures and Response Codes . . . . . .  13
+     5.1.  Basic Object Type and Organization Identifiers  . . . . .  13
+     5.2.  Various Object Key Types  . . . . . . . . . . . . . . . .  14
+       5.2.1.  Generic Object Key Type . . . . . . . . . . . . . . .  14
+       5.2.2.  Derived Object Key Types  . . . . . . . . . . . . . .  15
+     5.3.  Response Message Types  . . . . . . . . . . . . . . . . .  16
+   6.  Framework Data Model Objects  . . . . . . . . . . . . . . . .  18
+     6.1.  Destination Group . . . . . . . . . . . . . . . . . . . .  18
+     6.2.  Public Identifier . . . . . . . . . . . . . . . . . . . .  19
+     6.3.  SED Group . . . . . . . . . . . . . . . . . . . . . . . .  25
+     6.4.  SED Record  . . . . . . . . . . . . . . . . . . . . . . .  29
+     6.5.  SED Group Offer . . . . . . . . . . . . . . . . . . . . .  33
+     6.6.  Egress Route  . . . . . . . . . . . . . . . . . . . . . .  35
+
+
+
+Cartwright, et al.           Standards Track                    [Page 2]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   7.  Framework Operations  . . . . . . . . . . . . . . . . . . . .  36
+     7.1.  Add Operation . . . . . . . . . . . . . . . . . . . . . .  37
+     7.2.  Delete Operation  . . . . . . . . . . . . . . . . . . . .  37
+     7.3.  Get Operations  . . . . . . . . . . . . . . . . . . . . .  38
+     7.4.  Accept Operations . . . . . . . . . . . . . . . . . . . .  38
+     7.5.  Reject Operations . . . . . . . . . . . . . . . . . . . .  39
+     7.6.  Get Server Details Operation  . . . . . . . . . . . . . .  39
+   8.  XML Considerations  . . . . . . . . . . . . . . . . . . . . .  40
+     8.1.  Namespaces  . . . . . . . . . . . . . . . . . . . . . . .  40
+     8.2.  Versioning and Character Encoding . . . . . . . . . . . .  40
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  41
+     9.1.  Confidentiality and Authentication  . . . . . . . . . . .  41
+     9.2.  Authorization . . . . . . . . . . . . . . . . . . . . . .  41
+     9.3.  Denial of Service . . . . . . . . . . . . . . . . . . . .  41
+       9.3.1.  DoS Issues Inherited from the Substrate Mechanism . .  42
+       9.3.2.  DoS Issues Specific to SPPF . . . . . . . . . . . . .  42
+     9.4.  Information Disclosure  . . . . . . . . . . . . . . . . .  43
+     9.5.  Non-repudiation . . . . . . . . . . . . . . . . . . . . .  43
+     9.6.  Replay Attacks  . . . . . . . . . . . . . . . . . . . . .  43
+     9.7.  Compromised or Malicious Intermediary . . . . . . . . . .  44
+   10. Internationalization Considerations . . . . . . . . . . . . .  44
+   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  44
+     11.1.  URN Assignments  . . . . . . . . . . . . . . . . . . . .  44
+     11.2.  Organization Identifier Namespace Registry . . . . . . .  45
+   12. Formal Specification  . . . . . . . . . . . . . . . . . . . .  45
+   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  54
+     13.1.  Normative References . . . . . . . . . . . . . . . . . .  54
+     13.2.  Informative References . . . . . . . . . . . . . . . . .  55
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  57
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  57
+
+1.  Introduction
+
+   Service Providers (SPs) and enterprises use routing databases known
+   as Registries to make session routing decisions for Voice over IP,
+   SMS, and Multimedia Messaging Service (MMS) traffic exchanges.  This
+   document is narrowly focused on the provisioning framework for these
+   Registries.  This framework prescribes a way for an entity to
+   provision session-related data into a Session Peering Provisioning
+   Protocol (SPPP) Registry (or "Registry").  The data being provisioned
+   can be optionally shared with other participating peering entities.
+   The requirements and use cases driving this framework have been
+   documented in [RFC6461].
+
+   Three types of provisioning flows have been described in the use case
+   document: client to Registry, Registry to local data repository, and
+   Registry to Registry.  This document addresses client-to-Registry
+   flow enabling the ability to provision Session Establishment Data
+
+
+
+Cartwright, et al.           Standards Track                    [Page 3]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   (SED).  The framework that supports the flow of messages to
+   facilitate client-to-Registry provisioning is referred to as the
+   "Session Peering Provisioning Framework" (SPPF).
+
+   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
+   entity that participates in a protocol exchange.  For example, a
+   Registry might also include a "client" when such a Registry initiates
+   a connection (for example, for data distribution to an SSP).
+
+   *--------*               *------------*               *------------*
+   |        | (1) Client   |             | (3) Registry  |            |
+   | Client | ------------> |  Registry  |<------------->|  Registry  |
+   |        |   to Registry |            |  to Registry  |            |
+   *--------*               *------------*               *------------*
+                                 /  \                          \
+                                /    \                          \
+                               /      \                          \
+                              /        \                          v
+                             /          \                         ...
+                            /            \
+                           / (2) Distrib  \
+                          / Registry data  \
+                         /  to local data   \
+                        V      store         V
+                       +----------+       +----------+
+                       |Local Data|       |Local Data|
+                       |Repository|       |Repository|
+                       +----------+       +----------+
+
+                Figure 1: Three Registry Provisioning Flows
+
+   A "terminating" SSP provisions SED into the Registry to be
+   selectively shared with other peer SSPs.
+
+   SED is typically used by various downstream SIP-signaling systems to
+   route a call to the next hop associated with the called domain.
+   These systems typically use a local data store ("Local Data
+   Repository") as their source of session routing information.  More
+   specifically, the SED is the set of parameters that the outgoing
+   Signaling Path Border Elements (SBEs) need to initiate the session.
+   See [RFC5486] for more details.
+
+   A Registry may distribute the provisioned data into local data
+   repositories or may additionally offer a central query-resolution
+   service (not shown in the above figure) for query purposes.
+
+
+
+
+
+Cartwright, et al.           Standards Track                    [Page 4]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   A key requirement for the SPPF is to be able to accommodate two basic
+   deployment scenarios:
+
+   1.  A resolution system returns a Lookup Function (LUF) that
+       identifies the target domain to assist in call routing (as
+       described in Section 4.3.3 of [RFC5486]).  In this case, the
+       querying entity may use other means to perform the Location
+       Routing Function (LRF), which in turn helps determine the actual
+       location of the Signaling Function in that domain.
+
+   2.  A resolution system returns an LRF that comprises the location
+       (address) of the Signaling Function in the target domain (as
+       described in [RFC5486]).
+
+   In terms of framework design, SPPF is agnostic to the substrate
+   protocol.  This document includes the specification of the data model
+   and identifies, but does not specify, the means to enable protocol
+   operations within a request and response structure.  That aspect of
+   the specification has been delegated to the "protocol" specification
+   for the framework.  To encourage interoperability, the framework
+   supports extensibility aspects.
+
+   In this document, an XML Schema is used to describe the building
+   blocks of the SPPF and to express the data types, semantic
+   relationships between the various data types, and various constraints
+   as a binding construct.  However, a "protocol" specification is free
+   to choose any data representation format as long as it meets the
+   requirements laid out in the SPPF XML Schema Definition (XSD).  As an
+   example, XML and JSON are two widely used data representation
+   formats.
+
+   This document is organized as follows:
+
+   o  Section 2 provides the terminology
+
+   o  Section 3 provides an overview of SPPF, including functional
+      entities and a data model
+
+   o  Section 4 specifies requirements for SPPF substrate protocols
+
+   o  Section 5 describes the base framework data structures, the
+      generic response types that MUST be supported by a conforming
+      substrate "protocol" specification, and the basic object type from
+      which most first-class objects extend
+
+   o  Section 6 provides a detailed description of the data model object
+      specifications
+
+
+
+
+Cartwright, et al.           Standards Track                    [Page 5]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   o  Section 7 describes the operations that are supported by the data
+      model
+
+   o  Section 8 defines XML considerations XML parsers must meet to
+      conform to this specification
+
+   o  Sections 9 - 11 discuss security, internationalization, and IANA
+      considerations, respectively
+
+   o  Section 12 normatively defines the SPPF using its XSD.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+   This document reuses terms from [RFC3261], [RFC5486], use cases and
+   requirements documented in [RFC6461], and the ENUM Validation
+   Architecture [RFC4725].
+
+   This document defines the following additional terms:
+
+   SPPF:   Session Peering Provisioning Framework, which is the
+      framework used by a substrate protocol to provision data into a
+      Registry (see arrow labeled "1" in Figure 1 of [RFC6461]).  It is
+      the primary scope of this document.
+
+   Client:   In the context of SPPF, this is an application that
+      initiates a provisioning request.  It is sometimes referred to as
+      a "Registry client".
+
+   Server:   In the context of SPPF, this is an application that
+      receives a provisioning request and responds accordingly.
+
+   Registry:   The Registry operates a master database of SED for one or
+      more Registrants.
+
+   Registrant:   The definition of a Registrant is based on [RFC4725].
+      It is the end user, person, or organization that is the "holder"
+      of the SED being provisioned into the Registry by a Registrar.
+      For example, in [RFC6461], a Registrant is pictured as an SP in
+      Figure 2.
+
+      Within the confines of a Registry, a Registrant is uniquely
+      identified by the "rant" element.
+
+
+
+
+Cartwright, et al.           Standards Track                    [Page 6]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   Registrar:   The definition of a Registrar is based on [RFC4725].  It
+      is an entity that performs provisioning operations on behalf of a
+      Registrant by interacting with the Registry via SPPF operations.
+      In other words, the Registrar is the SPPF client.  The Registrar
+      and Registrant roles are logically separate to allow, but not
+      require, a single Registrar to perform provisioning operations on
+      behalf of more than one Registrant.
+
+   Peering Organization:   A peering organization is an entity to which
+      a Registrant's SED Groups are made visible using the operations of
+      SPPF.
+
+3.  Framework High-Level Design
+
+   This section introduces the structure of the data model and provides
+   the information framework for the SPPF.  The data model is defined
+   along with all the objects manipulated by a conforming substrate
+   protocol and their relationships.
+
+3.1.  Framework Data Model
+
+   The data model illustrated and described in Figure 2 defines the
+   logical objects and the relationships between these objects supported
+   by SPPF.  SPPF defines protocol operations through which an SPPF
+   client populates a Registry with these logical objects.  SPPF clients
+   belonging to different Registrars may provision data into the
+   Registry using a conforming substrate protocol that implements these
+   operations
+
+   The logical structure presented below is consistent with the
+   terminology and requirements defined in [RFC6461].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                    [Page 7]
+
+RFC 7877                          SSPF                       August 2016
+
+
+       +-------------+                        +-----------------+
+       | All object  |                        |Egress Route:    |
+       | types       |                   0..n | rant,           |
+       +-------------+                     +--| egrRteName,     |
+             |0..n                        /   | pref,           |
+             |                           /    | regxRewriteRule,|
+             |2                         /     | ingrSedGrp,     |
+   +----------------------+            /      | svcs            |
+   |Organization:         |           /       +-----------------+
+   | orgId                |          /
+   +----------------------+         /
+          |0..n                    /
+          |                       /        ("rant" = Registrant)
+          |A SED Group is        /
+          |associated with      /
+          |zero or more        /              +---[abstract]----+
+          |peering            /               | SED Record:     |
+          |organizations     /                |  rant,          |
+          |                 /                 |  sedName,       |0..n
+          |0..n            /                  |  sedFunction,   |------|
+   +--------+--------------+0..n          0..n|  isInSvc,       |      |
+   |SED Group:             |------------------|  ttl            |      |
+   |  rant,                |                  +-----------------+      |
+   |  sedGrpName,          |                      ^ Various types      |
+   |  isInSvc,             |                      | of SED Records     |
+   |  sedRecRef,           |                      |                    |
+   |  peeringOrg,          |                +-----+------------+       |
+   |  sourceIdent,         |                |        |         |       |
+   |  priority,            |             +----+  +-------+  +----+     |
+   |  dgName               |             | URI|  | NAPTR |  | NS |     |
+   +-----------------------+             +----+  +-------+  +----+     |
+          |0..n                                                        |
+          |                                 +-----[abstract]------+    |
+          |0..n                             |Public Identifier:   |    |
+      +----------------------+0..n      0..n|  rant,              |    |
+      | Dest Group:          |--------------|  publicIdentifier,  |    |
+      |   rant,              |              |  dgName             |    |
+      |   dgName             |              |                     |    |
+      +----------------------+              +---------------------+    |
+                                                     ^ Various types   |
+                 +---------+-------+------+----------+ of Public       |
+                 |         |       |      |          | Identifiers     |
+              +------+  +-----+  +-----+ +-----+  +------+             |
+              |  URI |  | TNP |  | TNR | | RN  |  |  TN  |-------------|
+              +------+  +-----+  +-----+ +-----+  +------+  0..n
+
+                      Figure 2: Framework Data Model
+
+
+
+
+Cartwright, et al.           Standards Track                    [Page 8]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   The objects and attributes that comprise the data model can be
+   described as follows (objects listed from the bottom up):
+
+   o  Public Identifier:
+      From a broad perspective, a Public Identifier is a well-known
+      attribute that is used as the key to perform resolution lookups.
+      Within the context of SPPF, a Public Identifier object can be a
+      Telephone Number (TN), a range of TNs, a Public Switched Telephone
+      Network (PSTN) Routing Number (RN), a TN prefix, or a URI.
+
+      An SPPF Public Identifier may be a member of zero or more
+      Destination Groups to create logical groupings of Public
+      Identifiers that share a common set of SED (e.g., routes).
+
+      A TN Public Identifier may optionally be associated with zero or
+      more individual SED Records.  This ability for a Public Identifier
+      to be directly associated with a SED Record, as opposed to forcing
+      membership in one or more Destination Groups, supports use cases
+      where the SED Record contains data specifically tailored to an
+      individual TN Public Identifier.
+
+   o  Destination Group:
+      A named logical grouping of zero or more Public Identifiers that
+      can be associated with one or more SED Groups for the purpose of
+      facilitating the management of their common SED.
+
+   o  SED Group:
+      A SED Group contains a set of SED Record references, a set of
+      Destination Group references, and a set of peering organization
+      identifiers.  This is used to establish a three-part relationship
+      between a set of Public Identifiers, the SED shared across these
+      Public Identifiers, and the list of peering organizations whose
+      query responses from the resolution system may include the SED
+      contained in a given SED Group.  In addition, the sourceIdent
+      element within a SED Group, in concert with the set of peering
+      organization identifiers, enables fine-grained source-based
+      routing.  For further details about the SED Group and source-based
+      routing, refer to the definitions and descriptions in Section 6.1.
+
+   o  SED Record:
+      A SED Record contains the data that a resolution system returns in
+      response to a successful query for a Public Identifier.  SED
+      Records are generally associated with a SED Group when the SED
+      within is not specific to a Public Identifier.
+
+      To support the use cases defined in [RFC6461], the SPPF defines
+      three types of SED Records: URIType, NAPTRType, and NSType.  These
+      SED Records extend the abstract type SedRecType and inherit the
+
+
+
+Cartwright, et al.           Standards Track                    [Page 9]
+
+RFC 7877                          SSPF                       August 2016
+
+
+      common attribute "priority" that is meant for setting precedence
+      across the SED Records defined within a SED Group in a protocol-
+      agnostic fashion.
+
+   o  Egress Route:
+      In a high-availability environment, the originating SSP likely has
+      more than one egress path to the ingress SBE of the target SSP.
+      The Egress Route allows the originating SSP to choose a specific
+      egress SBE to be associated with the target ingress SBE.  The
+      "svcs" element specifies ENUM services (e.g., E2U+pstn:sip+sip)
+      that are used to identify the SED Records associated with the SED
+      Group that will be modified by the originating SSP.
+
+   o  Organization:
+      An Organization is an entity that may fulfill any combination of
+      three roles: Registrant, Registrar, and peering organization.  All
+      objects in SPPF are associated with two organization identifiers
+      to identify each object's Registrant and Registrar.  A SED Group
+      object is also associated with a set of zero or more organization
+      identifiers that identify the peering organization(s) whose
+      resolution query responses may include the SED defined in the SED
+      Records within that SED Group.  A peering organization is an
+      entity with which the Registrant intends to share the SED data.
+
+3.2.  Time Value
+
+   Some request and response messages in SPPF include a time value or
+   values defined as type xs:dateTime, a built-in W3C XML Schema
+   Datatype.  Use of an unqualified local time value is disallowed as it
+   can lead to interoperability issues.  The value of a time attribute
+   MUST be expressed in Coordinated Universal Time (UTC) format without
+   the time-zone digits.
+
+   "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 time
+   but is not acceptable for use in SPPF messages.
+
+3.3.  Extensibility
+
+   The framework contains various points of extensibility in the form of
+   the "ext" elements.  Extensions used beyond the scope of private SPPF
+   installations need to be documented in an RFC, and the first such
+   extension is expected to define an IANA registry, holding a list of
+   documented extensions.
+
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 10]
+
+RFC 7877                          SSPF                       August 2016
+
+
+4.  Substrate Protocol Requirements
+
+   This section provides requirements for substrate protocols suitable
+   to carry SPPF.  More specifically, this section specifies the
+   services, features, and assumptions that SPPF delegates to the chosen
+   substrate and envelope technologies.
+
+4.1.  Mandatory Substrate
+
+   None of the existing transport protocols carried directly over IP,
+   appearing as "Protocol" in the IPv4 headers or "Next Header" in the
+   IPv6 headers, meet the requirements listed in this section to carry
+   SPPF.
+
+   Therefore, one choice to carry SPPF has been provided in "Session
+   Peering Provisioning (SPP) Protocol over SOAP" [RFC7878], 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 comply with the requirements
+   discussed above.
+
+4.2.  Connection Oriented
+
+   The SPPF follows a model where a client establishes a connection to a
+   server in order to further exchange SPPF messages over such a point-
+   to-point connection.  Therefore, a substrate protocol for SPPF will
+   be connection oriented.
+
+4.3.  Request and Response Model
+
+   Provisioning operations in SPPF follow the request-response model,
+   where a client sends a request message to initiate a transaction and
+   the server sends a response.  Multiple subsequent request-response
+   exchanges MAY be performed over a single persistent connection.
+
+   Therefore, a substrate protocol for SPPF will follow the request-
+   response model by ensuring a response is sent to the request
+   initiator.
+
+4.4.  Connection Lifetime
+
+   Some use cases involve provisioning a single request to a network
+   element.  Connections supporting such provisioning requests might be
+   short-lived, and may be established only on demand, for the duration
+   of a few seconds.  Other use cases involve provisioning either a
+   large dataset or a constant stream of small updates, both of which
+   would likely require long-lived connections, spanning multiple hours
+   or even days.
+
+
+
+Cartwright, et al.           Standards Track                   [Page 11]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   Therefore, a protocol suitable for SPPF SHOULD be able to support
+   both short-lived and long-lived connections.
+
+4.5.  Authentication
+
+   All SPPF objects are associated with a Registrant identifier.  An
+   SPPF client provisions SPPF objects on behalf of Registrants.  An
+   authenticated SPP client is a Registrar.  Therefore, the SPPF
+   substrate protocol MUST provide means for an SPPF server to
+   authenticate an SPPF client.
+
+4.6.  Authorization
+
+   After successful authentication of the SPPF client as a Registrar,
+   the Registry performs authorization checks to determine if the
+   Registrar is authorized to act on behalf of the Registrant whose
+   identifier is included in the SPPF request.  Refer to Section 9 for
+   further guidance.
+
+4.7.  Confidentiality and Integrity
+
+   SPPF objects that the Registry manages can be private in nature.
+   Therefore, the substrate protocol MUST provide means for data
+   integrity protection.
+
+   If the data is compromised in-flight between the SPPF client and
+   Registry, it will seriously affect the stability and integrity of the
+   system.  Therefore, the substrate protocol MUST provide means for
+   data integrity protection.
+
+4.8.  Near Real Time
+
+   Many use cases require responses in near real time from the server
+   (in the range of a few multiples of round-trip time between the
+   server and client).  Therefore, a Data for Reachability of
+   Inter-/Intra-NetworK SIP (DRINKS) substrate protocol MUST support
+   near real-time responses to requests submitted by the client.
+
+4.9.  Request and Response Sizes
+
+   Use of SPPF may involve simple updates that may consist of a small
+   number of bytes, such as the update of a single Public Identifier.
+   Other provisioning operations may constitute a large dataset, as in
+   adding millions of records to a Registry.  As a result, a suitable
+   substrate protocol for SPPF SHOULD accommodate datasets of various
+   sizes.
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 12]
+
+RFC 7877                          SSPF                       August 2016
+
+
+4.10.  Request and Response Correlation
+
+   A substrate protocol suitable for SPPF MUST allow responses to be
+   correlated with requests.
+
+4.11.  Request Acknowledgement
+
+   Data transported in the SPPF is likely crucial for the operation of
+   the communication network that is being provisioned.  An SPPF client
+   responsible for provisioning SED to the Registry has a need to know
+   if the submitted requests have been processed correctly.
+
+   Failed transactions can lead to situations where a subset of Public
+   Identifiers or even SSPs might not be reachable or the provisioning
+   state of the network is inconsistent.
+
+   Therefore, a substrate protocol for SPPF MUST provide a response for
+   each request, so that a client can identify whether a request
+   succeeded or failed.
+
+5.  Base Framework Data Structures and Response Codes
+
+   SPPF contains some common data structures for most of the supported
+   object types.  This section describes these common data structures.
+
+5.1.  Basic Object Type and Organization Identifiers
+
+   All first-class objects extend the type BasicObjType.  It consists of
+   the Registrant organization, the Registrar organization, the date and
+   time of object creation, and the last date and time the object was
+   modified.  The Registry MUST store the date and time of the object
+   creation and modification, if applicable, for all Get operations (see
+   Section 7).  If the client passed in either date or time values, the
+   Registry MUST ignore it.  The Registrar performs the SPPF operations
+   on behalf of the Registrant, the organization that owns the object.
+
+   <complexType name="BasicObjType" abstract="true">
+    <sequence>
+     <element name="rant" type="sppfb:OrgIdType"/>
+     <element name="rar" type="sppfb:OrgIdType"/>
+     <element name="cDate" type="dateTime" minOccurs="0"/>
+     <element name="mDate" type="dateTime" minOccurs="0"/>
+     <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+    </sequence>
+   </complexType>
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 13]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   The identifiers used for Registrants (rant) and Registrars (rar) are
+   instances of OrgIdType.  The OrgIdType is defined as a string and all
+   OrgIdType instances MUST follow the textual convention:
+   "namespace:value" (for example, "iana-en:32473").  Specifically:
+
+   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
+
+   The SPPF data model contains various object relationships.  In some
+   cases, these object relationships are established by embedding the
+   unique identity of the related object inside the relating object.
+   Note that an object's unique identity is required to Delete or Get
+   the details of an object.  The following subsections normatively
+   define the various object keys in SPPF and the attributes of those
+   keys.
+
+   "Name" attributes that are used as components of object key types
+   MUST be compared using the toCasefold() function, as specified in
+   Section 3.13 of [Unicode6.1] (or a newer version of Unicode).  This
+   function performs case-insensitive comparisons.
+
+5.2.1.  Generic Object Key Type
+
+   Most objects in SPPF are uniquely identified by an object key that
+   has the object's name, type, and Registrant's organization ID as
+   attributes.  The abstract type called ObjKeyType is where this unique
+   identity is housed.  Any concrete representation of the ObjKeyType
+   MUST contain the following:
+
+      Object Name: The name of the object.
+
+      Registrant ID: The unique organization ID that identifies the
+      Registrant.
+
+      Type: The value that represents the type of SPPF object.  This is
+      required as different types of objects in SPPF, that belong to the
+      same Registrant, can have the same name.
+
+
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 14]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   The structure of abstract ObjKeyType is as follows:
+
+   <complexType name="ObjKeyType" abstract="true">
+    <annotation>
+     <documentation>
+     ---- Generic type that represents the
+          key for various objects in SPPF. ----
+     </documentation>
+    </annotation>
+   </complexType>
+
+5.2.2.  Derived Object Key Types
+
+   The SPPF data model contains certain objects that are uniquely
+   identified by attributes, different from or in addition to the
+   attributes in the generic object key described in the previous
+   section.  Object keys of this kind are derived from the abstract
+   ObjKeyType and defined in their own abstract key types.  Because
+   these object key types are abstract, they MUST be specified in a
+   concrete form in any SPPF-conforming substrate "protocol"
+   specification.  These are used in Delete and Get operations and may
+   also be used in Accept and Reject operations.
+
+   Following are the derived object keys in an SPPF data model:
+
+   o  SedGrpOfferKeyType: This uniquely identifies a SED Group object
+      offer.  This key type extends from ObjKeyType and MUST also have
+      the organization ID of the Registrant to whom the object is being
+      offered as one of its attributes.  In addition to the Delete and
+      Get operations, these key types are used in Accept and Reject
+      operations on a SED Group Offer object.  The structure of abstract
+      SedGrpOfferKeyType is as follows:
+
+   <complexType name="SedGrpOfferKeyType"
+   abstract="true">
+       <complexContent>
+           <extension base="sppfb:ObjKeyType">
+               <annotation>
+       <documentation>
+       ---- Generic type that represents
+            the key for an object offer. ----
+       </documentation>
+      </annotation>
+     </extension>
+    </complexContent>
+   </complexType>
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 15]
+
+RFC 7877                          SSPF                       August 2016
+
+
+      A SED Group Offer object MUST use SedGrpOfferKeyType.  Refer to
+      Section 6.5 for a description of the SED Group Offer object.
+
+   o  PubIdKeyType: This uniquely identifies a Public Identity object.
+      This key type extends from the abstract ObjKeyType.  Any concrete
+      definition of PubIdKeyType MUST contain the elements that identify
+      the value and type of Public Identity and also contain the
+      organization ID of the Registrant that is the owner of the Public
+      Identity object.  A Public Identity object in SPPF is uniquely
+      identified by the Registrant's organization ID, the value of the
+      Public Identity, and the type of the Public Identity object.
+      Consequently, any concrete representation of the PubIdKeyType MUST
+      contain the following attributes:
+
+      *  Registrant ID: The unique organization ID that identifies the
+         Registrant.
+
+      *  Value: The value of the Public Identity.
+
+      *  Type: The type of the Public Identity object.
+
+      The PubIdKeyType is used in Delete and Get operations on a Public
+      Identifier object.
+
+   o  The structure of abstract PubIdKeyType is as follows:
+
+   <complexType name="PubIdKeyType" abstract="true">
+    <complexContent>
+     <extension base="sppfb:ObjKeyType">
+      <annotation>
+       <documentation>
+       ---- Generic type that represents the key for a Pub ID. ----
+       </documentation>
+      </annotation>
+     </extension>
+    </complexContent>
+   </complexType>
+
+   A Public Identity object MUST use attributes of PubIdKeyType for its
+   unique identification.  Refer to Section 6 for a description of a
+   Public Identity object.
+
+5.3.  Response Message Types
+
+   The following table contains the list of response types that MUST be
+   defined for a substrate protocol used to carry SPPF.  An SPPF server
+   MUST implement all of the following at minimum.
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 16]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   +---------------------+---------------------------------------------+
+   | Response Type       | Description                                 |
+   +---------------------+---------------------------------------------+
+   | Request succeeded   | A given request succeeded.                  |
+   | Request syntax      | The syntax of a given request was found to  |
+   | invalid             | be invalid.                                 |
+   | Request too large   | The count of entities in the request is     |
+   |                     | larger than the server is willing or able   |
+   |                     | to process.                                 |
+   | Version not         | The server does not support the version of  |
+   | supported           | the SPPF protocol specified in the request. |
+   | Command invalid     | The operation and/or command being          |
+   |                     | requested by the client is invalid and/or   |
+   |                     | not supported by the server.                |
+   | System temporarily  | The SPPF server is temporarily not          |
+   | unavailable         | available to serve the client request.      |
+   | Unexpected internal | The SPPF server encountered an unexpected   |
+   | system or server    | error that prevented the server from        |
+   | error               | fulfilling the request.                     |
+   | Attribute value     | The SPPF server encountered an attribute or |
+   | invalid             | property in the request that had an         |
+   |                     | invalid/bad value.  Optionally, the         |
+   |                     | specification MAY provide a way to indicate |
+   |                     | the Attribute Name and the Attribute Value  |
+   |                     | to identify the object that was found to be |
+   |                     | invalid.                                    |
+   | Object does not     | An object present in the request does not   |
+   | exist               | exist on the SPPF server. Optionally, the   |
+   |                     | specification MAY provide a way to indicate |
+   |                     | the Attribute Name and the Attribute Value  |
+   |                     | that identifies the nonexistent object.     |
+   | Object status or    | The operation requested on an object        |
+   | ownership does not  | present in the request cannot be performed  |
+   | allow for operation | because the object is in a status that does |
+   |                     | not allow said operation, or the user       |
+   |                     | requesting the operation is not authorized  |
+   |                     | to perform said operation on the object.    |
+   |                     | Optionally, the specification MAY provide a |
+   |                     | way to indicate the Attribute Name and the  |
+   |                     | Attribute Value that identifies the object. |
+   +---------------------+---------------------------------------------+
+
+                          Table 1: Response Types
+
+
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 17]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   When the response messages are "parameterized" with the Attribute
+   Name and Attribute Value, then the use of these parameters MUST
+   adhere to the following rules:
+
+   o  Any value provided for the Attribute Name parameter MUST be an
+      exact XSD element name of the protocol data element to which the
+      response message is referring.  For example, valid values for
+      "attribute name" are "dgName", "sedGrpName", "sedRec", etc.
+
+   o  The value for Attribute Value MUST be the value of the data
+      element to which the preceding Attribute Name refers.
+
+   o  Response type "Attribute value invalid" MUST be used whenever an
+      element value does not adhere to data validation rules.
+
+   o  Response types "Attribute value invalid" and "Object does not
+      exist" MUST NOT be used interchangeably.  Response type "Object
+      does not exist" MUST be returned by an Update/Del/Accept/Reject
+      operation when the data element(s) used to uniquely identify a
+      preexisting object does not exist.  If the data elements used to
+      uniquely identify an object are malformed, then response type
+      "Attribute value invalid" MUST be returned.
+
+6.  Framework Data Model Objects
+
+   This section provides a description of the specification of each
+   supported data model object (the nouns) and identifies the commands
+   (the verbs) that MUST be supported for each data model object.
+   However, the specification of the data structures necessary to
+   support each command is delegated to an SPPF-conforming substrate
+   "protocol" specification.
+
+6.1.  Destination Group
+
+   A Destination Group represents a logical grouping of Public
+   Identifiers with common SED.  The substrate protocol MUST support the
+   ability to Add, Get, and Delete Destination Groups (refer to
+   Section 7 for a generic description of various operations).
+
+   A Destination Group object MUST be uniquely identified by attributes
+   as defined in the description of "ObjKeyType" in "Generic Object Key
+   Type" (Section 5.2.1 of this document).
+
+
+
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 18]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   The DestGrpType object structure is defined as follows:
+
+   <complexType name="DestGrpType">
+    <complexContent>
+     <extension base="sppfb:BasicObjType">
+      <sequence>
+       <element name="dgName" type="sppfb:ObjNameType"/>
+      </sequence>
+     </extension>
+    </complexContent>
+   </complexType>
+
+   The DestGrpType object is composed of the following elements:
+
+   o  base: All first-class objects extend BasicObjType (see
+      Section 5.1).
+
+   o  dgName: The character string that contains the name of the
+      Destination Group.
+
+   o  ext: Point of extensibility described in Section 3.3.
+
+6.2.  Public Identifier
+
+   A Public Identifier is the search key used for locating the SED.  In
+   many cases, a Public Identifier is attributed to the end user who has
+   a retail relationship with the SP or Registrant organization.  SPPF
+   supports the notion of the carrier-of-record as defined in [RFC5067].
+   Therefore, the Registrant under which the Public Identifier is being
+   created can optionally claim to be a carrier-of-record.
+
+   SPPF identifies three types of Public Identifiers: TNs, RNs, and
+   URIs.  SPPF provides structures to manage a single TN, a contiguous
+   range of TNs, and a TN prefix.  The substrate protocol MUST support
+   the ability to Add, Get, and Delete Public Identifiers (refer to
+   Section 7 for a generic description of various operations).
+
+   A Public Identity object MUST be uniquely identified by attributes as
+   defined in the description of "PubIdKeyType" in Section 5.2.2.
+
+
+
+
+
+
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 19]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   The abstract XSD type PubIdType is a generalization for the concrete
+   Public Identifier schema types.  The PubIdType element "dgName"
+   represents the name of a Destination Group of which a given Public
+   Identifier may be a member.  Note that this element may be present
+   multiple times so that a given Public Identifier may be a member of
+   multiple Destination Groups.  The PubIdType object structure is
+   defined as follows:
+
+   <complexType name="PubIdType" abstract="true">
+    <complexContent>
+     <extension base="sppfb:BasicObjType">
+      <sequence>
+       <element name="dgName" type="sppfb:ObjNameType"
+                minOccurs="0" maxOccurs="unbounded"/>
+      </sequence>
+     </extension>
+    </complexContent>
+   </complexType>
+
+   A Public Identifier may be a member of zero or more Destination
+   Groups.  When a Public Identifier is a member of a Destination Group,
+   it is intended to be associated with SED through the SED Group(s)
+   that is associated with the Destination Group.  When a Public
+   Identifier is not member of any Destination Group, it is intended to
+   be associated with SED through the SED Records that are directly
+   associated with the Public Identifier.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 20]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   A TN is provisioned using the TNType, an extension of PubIdType.
+   Each TNType object is uniquely identified by the combination of its
+   value contained within the <tn> element and its Registrant ID.
+   TNType is defined as follows:
+
+   <complexType name="TNType">
+    <complexContent>
+     <extension base="sppfb:PubIdType">
+      <sequence>
+       <element name="tn" type="sppfb:NumberValType"/>
+       <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
+       <element name="sedRecRef" type="sppfb:SedRecRefType"
+                minOccurs="0" maxOccurs="unbounded"/>
+      </sequence>
+     </extension>
+    </complexContent>
+   </complexType>
+
+   <complexType name="CORInfoType">
+    <sequence>
+      <element name="corClaim" type="boolean" default="true"/>
+      <element name="cor" type="boolean" default="false" minOccurs="0"/>
+      <element name="corDate" type="dateTime" minOccurs="0"/>
+    </sequence>
+   </complexType>
+
+   <simpleType name="NumberValType">
+    <restriction base="token">
+     <maxLength value="20"/>
+     <pattern value="\+?\d\d*"/>
+    </restriction>
+   </simpleType>
+
+   TNType consists of the following attributes:
+
+   o  tn: Telephone number to be added to the Registry.
+
+   o  sedRecRef: Optional reference to SED Records that are directly
+      associated with the TN Public Identifier.  Following the SPPF data
+      model, the SED Record could be a protocol-agnostic URIType or
+      another type.
+
+   o  corInfo: corInfo is an optional parameter of type CORInfoType that
+      allows the Registrant organization to set forth a claim to be the
+      carrier-of-record (see [RFC5067]).  This is done by setting the
+      value of the <corClaim> element of the CORInfoType object
+      structure to "true".  The other two parameters of the CORInfoType,
+      <cor> and <corDate>, are set by the Registry to describe the
+
+
+
+Cartwright, et al.           Standards Track                   [Page 21]
+
+RFC 7877                          SSPF                       August 2016
+
+
+      outcome of the carrier-of-record claim by the Registrant.  In
+      general, inclusion of the <corInfo> parameter is useful if the
+      Registry has the authority information, such as the number
+      portability data, etc., in order to qualify whether the Registrant
+      claim can be satisfied.  If the carrier-of-record claim disagrees
+      with the authority data in the Registry, whether or not a TN Add
+      operation fails is a matter of policy and is beyond the scope of
+      this document.
+
+   An RN is provisioned using the RNType, an extension of PubIDType.
+   The Registrant organization can add the RN and associate it with the
+   appropriate Destination Group(s) to share the route information.
+   This allows SSPs to use the RN search key to derive the Ingress
+   Routes for session establishment at the runtime resolution process
+   (see [RFC6116]).  Each RNType object is uniquely identified by the
+   combination of its value inside the <rn> element and its Registrant
+   ID.  RNType is defined as follows:
+
+   <complexType name="RNType">
+    <complexContent>
+     <extension base="sppfb:PubIdType">
+      <sequence>
+       <element name="rn" type="sppfb:NumberValType"/>
+       <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
+      </sequence>
+     </extension>
+    </complexContent>
+   </complexType>
+
+   RNType has the following attributes:
+
+   o  rn: The RN used as the search key.
+
+   o  corInfo: corInfo is an optional parameter of type CORInfoType that
+      allows the Registrant organization to set forth a claim to be the
+      carrier-of-record (see [RFC5067]).
+
+   TNRType structure is used to provision a contiguous range of TNs.
+   The object definition requires a starting TN and an ending TN that
+   together define the span of the TN range, including the starting and
+   ending TN.  Use of TNRType is particularly useful when expressing a
+   TN range that does not include all the TNs within a TN block or
+   prefix.  The TNRType definition accommodates the open number plan as
+   well such that the TNs that fall in the range between the start and
+   end TN may include TNs with different length variance.  Whether the
+   Registry can accommodate the open number plan semantics is a matter
+   of policy and is beyond the scope of this document.  Each TNRType
+   object is uniquely identified by the combination of its value that,
+
+
+
+Cartwright, et al.           Standards Track                   [Page 22]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   in turn, is a combination of the <startTn> and <endTn> elements and
+   its Registrant ID.  The TNRType object structure definition is as
+   follows:
+
+   <complexType name="TNRType">
+    <complexContent>
+     <extension base="sppfb:PubIdType">
+      <sequence>
+       <element name="range" type="sppfb:NumberRangeType"/>
+       <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
+      </sequence>
+     </extension>
+    </complexContent>
+   </complexType>
+
+   <complexType name="NumberRangeType">
+    <sequence>
+     <element name="startTn" type="sppfb:NumberValType"/>
+     <element name="endTn" type="sppfb:NumberValType"/>
+    </sequence>
+   </complexType>
+
+   TNRType has the following attributes:
+
+   o  startTn: The starting 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
+      allows the Registrant organization to set forth a claim to be the
+      carrier-of-record (see [RFC5067]).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 23]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   In some cases, it is useful to describe a set of TNs with the help of
+   the first few digits of the TN, also referred to as the TN prefix or
+   a block.  A given TN prefix may include TNs with different length
+   variance in support of the open number plan.  Once again, whether the
+   Registry supports the open number plan semantics is a matter of
+   policy, and it is beyond the scope of this document.  The TNPType
+   data structure is used to provision a TN prefix.  Each TNPType object
+   is uniquely identified by the combination of its value in the
+   <tnPrefix> element and its Registrant ID.  TNPType is defined as
+   follows:
+
+   <complexType name="TNPType">
+    <complexContent>
+     <extension base="sppfb:PubIdType">
+      <sequence>
+       <element name="tnPrefix" type="sppfb:NumberValType"/>
+       <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
+      </sequence>
+     </extension>
+    </complexContent>
+   </complexType>
+
+   TNPType consists of the following attributes:
+
+   o  tnPrefix: The TN prefix.
+
+   o  corInfo: corInfo is an optional parameter of type CORInfoType that
+      allows the Registrant organization to set forth a claim to be the
+      carrier-of-record (see [RFC5067]).
+
+   In some cases, a Public Identifier may be a URI, such as an email
+   address.  The URIPubIdType object is comprised of the data element
+   necessary to house such Public Identifiers.  Each URIPubIdType object
+   is uniquely identified by the combination of its value in the <uri>
+   element and its Registrant ID.  URIPubIdType is defined as follows:
+
+   <complexType name="URIPubIdType">
+    <complexContent>
+     <extension base="sppfb:PubIdType">
+      <sequence>
+       <element name="uri" type="anyURI"/>
+       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+      </sequence>
+     </extension>
+    </complexContent>
+   </complexType>
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 24]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   URIPubIdType consists of the following attributes:
+
+   o  uri: The value that acts as the Public Identifier.
+
+   o  ext: Point of extensibility described in Section 3.3.
+
+6.3.  SED Group
+
+   SED Group is a grouping of one or more Destination Groups, the common
+   SED Records, and the list of peer organizations with access to the
+   SED Records associated with a given SED Group.  It is this indirect
+   linking of Public Identifiers to their SED that significantly
+   improves the scalability and manageability of the peering data.
+   Additions and changes to SED information are reduced to a single
+   operation on a SED Group or SED Record rather than millions of data
+   updates to individual Public Identifier records that individually
+   contain their peering data.  The substrate protocol MUST support the
+   ability to Add, Get, and Delete SED Groups (refer to Section 7 for a
+   generic description of various operations).
+
+   A SED Group object MUST be uniquely identified by attributes as
+   defined in the description of "ObjKeyType" in "Generic Object Key
+   Type" (Section 5.2.1 of this document).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 25]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   The SedGrpType object structure is defined as follows:
+
+   <complexType name="SedGrpType">
+    <complexContent>
+     <extension base="sppfb:BasicObjType">
+      <sequence>
+       <element name="sedGrpName" type="sppfb:ObjNameType"/>
+       <element name="sedRecRef" type="sppfb:SedRecRefType"
+                minOccurs="0" maxOccurs="unbounded"/>
+       <element name="dgName" type="sppfb:ObjNameType"
+                minOccurs="0" maxOccurs="unbounded"/>
+       <element name="peeringOrg" type="sppfb:OrgIdType"
+                minOccurs="0" maxOccurs="unbounded"/>
+       <element name="sourceIdent" type="sppfb:SourceIdentType"
+                minOccurs="0" maxOccurs="unbounded"/>
+       <element name="isInSvc" type="boolean"/>
+       <element name="priority" type="unsignedShort"/>
+       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+      </sequence>
+     </extension>
+    </complexContent>
+   </complexType>
+
+   <complexType name="SedRecRefType">
+    <sequence>
+     <element name="sedKey" type="sppfb:ObjKeyType"/>
+     <element name="priority" type="unsignedShort"/>
+     <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+    </sequence>
+   </complexType>
+
+   The SedGrpType object is composed of the following elements:
+
+   o  base: All first-class objects extend BasicObjType (see
+      Section 5.1).
+
+   o  sedGrpName: The character string that contains the name of the SED
+      Group.  It uniquely identifies this object within the context of
+      the Registrant ID (a child element of the base element as
+      described above).
+
+   o  sedRecRef: Set of zero or more objects of type SedRecRefType that
+      house the unique keys of the SED Records (containing the SED) that
+      the SedGrpType object refers to and their relative priority within
+      the context of this SED Group.
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 26]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   o  dgName: Set of zero or more names of DestGrpType object instances.
+      Each dgName name, in association with this SED Group's Registrant
+      ID, uniquely identifies a DestGrpType object instance whose
+      associated Public Identifiers are reachable using the SED housed
+      in this SED Group.  An intended side effect of this is that a SED
+      Group cannot provide session establishment information for a
+      Destination Group belonging to another Registrant.
+
+   o  peeringOrg: Set of zero or more peering organization IDs that have
+      accepted an offer to receive this SED Group's information.  Note
+      that this identifier "peeringOrg" is an instance of OrgIdType.
+      The set of peering organizations in this list is not directly
+      settable or modifiable using the addSedGrpsRqst operation.  This
+      set is instead controlled using the SED Offer and Accept
+      operations.
+
+   o  sourceIdent: Set of zero or more SourceIdentType object instances.
+      These objects, described further below, house the source
+      identification schemes and identifiers that are applied at
+      resolution time as part of source-based routing algorithms for the
+      SED Group.
+
+   o  isInSvc: A boolean element that defines whether this SED Group is
+      in service.  The SED contained in a SED Group that is in service
+      is a candidate for inclusion in resolution responses for Public
+      Identities residing in the Destination Group associated with this
+      SED Group.  The session establishment information contained in a
+      SED Group that is not in service is not a candidate for inclusion
+      in resolution responses.
+
+   o  priority: Priority value that can be used to provide a relative
+      value weighting of one SED Group over another.  The manner in
+      which this value is used, perhaps in conjunction with other
+      factors, is a matter of policy.
+
+   o  ext: Point of extensibility described in Section 3.3.
+
+   As described above, the SED Group contains a set of references to SED
+   Record objects.  A SED Record object is based on an abstract type:
+   SedRecType.  The concrete types that use SedRecType as an extension
+   base are NAPTRType, NSType, and URIType.  The definitions of these
+   types are included in "SED Record" (Section 6.4 of this document).
+
+   The SedGrpType object provides support for source-based routing via
+   the peeringOrg data element and more granular source-based routing
+   via the source identity element.  The source identity element
+   provides the ability to specify zero or more of the following in
+   association with a given SED Group: a regular expression that is
+
+
+
+Cartwright, et al.           Standards Track                   [Page 27]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   matched against the resolution client IP address, a regular
+   expression that is 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, after identifying the visible SED Groups
+   whose associated Destination Group(s) contains the lookup key being
+   queried and whose peeringOrg list contains the querying
+   organization's organization ID, the resolution server will evaluate
+   the characteristics of the Source URI, Source IP address, and root
+   domain of the lookup key being queried.  The resolution server then
+   compares these criteria against the source identity criteria
+   associated with the SED Groups.  The SED contained in SED Groups that
+   have source-based routing criteria will only be included in the
+   resolution response if one or more of the criteria matches the source
+   criteria from the resolution request.  The source identity data
+   element is of type SourceIdentType, whose structure is defined as
+   follows:
+
+   <complexType name="SourceIdentType">
+    <sequence>
+     <element name="sourceIdentRegex" type="sppfb:RegexType"/>
+     <element name="sourceIdentScheme"
+              type="sppfb:SourceIdentSchemeType"/>
+     <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+    </sequence>
+   </complexType>
+
+   <simpleType name="SourceIdentSchemeType">
+    <restriction base="token">
+     <enumeration value="uri"/>
+     <enumeration value="ip"/>
+     <enumeration value="rootDomain"/>
+    </restriction>
+   </simpleType>
+
+   The SourceIdentType object is composed of the following data
+   elements:
+
+   o  sourceIdentScheme: The source identification scheme that this
+      source identification criteria applies to and that the associated
+      sourceIdentRegex should be matched against.
+
+   o  sourceIdentRegex: The regular expression that should be used to
+      test for a match against the portion of the resolution request
+      that is dictated by the associated sourceIdentScheme.
+
+   o  ext: Point of extensibility described in Section 3.3.
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 28]
+
+RFC 7877                          SSPF                       August 2016
+
+
+6.4.  SED Record
+
+   SED Group represents a combined grouping of SED Records that define
+   SED.  However, SED Records need not be 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 example, to the properties of
+   a network node used for multiple routes would necessitate just a
+   single update operation to change the properties of that node.  The
+   change would then be reflected in all the SED Groups whose SED Record
+   set contains a reference to that node.  The substrate protocol MUST
+   support the ability to Add, Get, and Delete SED Records (refer to
+   Section 7 for a generic description of various operations).
+
+   A SED Record object MUST be uniquely identified by attributes as
+   defined in the description of "ObjKeyType" in "Generic Object Key
+   Type" (Section 5.2.1 of this document).
+
+   The SedRecType object structure is defined as follows:
+
+   <complexType name="SedRecType" abstract="true">
+    <complexContent>
+     <extension base="sppfb:BasicObjType">
+      <sequence>
+       <element name="sedName" type="sppfb:ObjNameType"/>
+       <element name="sedFunction" type="sppfb:SedFunctionType"
+                minOccurs="0"/>
+       <element name="isInSvc" type="boolean"/>
+       <element name="ttl" type="positiveInteger" minOccurs="0"/>
+      </sequence>
+     </extension>
+    </complexContent>
+   </complexType>
+
+   <simpleType name="SedFunctionType">
+    <restriction base="token">
+     <enumeration value="routing"/>
+     <enumeration value="lookup"/>
+    </restriction>
+   </simpleType>
+
+   The SedRecType object is composed of the following elements:
+
+   o  base: All first-class objects extend BasicObjType (see
+      Section 5.1).
+
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 29]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   o  sedName: The character string that contains the name of the SED
+      Record.  It uniquely identifies this object within the context of
+      the Registrant ID (a child element of the base element as
+      described above).
+
+   o  sedFunction: As described in [RFC6461], SED falls primarily into
+      one of two categories or functions: LUF and LRF.  To remove any
+      ambiguity as to the function a SED Record is intended to provide,
+      this optional element allows the provisioning party to make its
+      intentions explicit.
+
+   o  isInSvc: A boolean element that defines whether or not this SED
+      Record is in service.  The session establishment information
+      contained in a SED Record that is in service is a candidate for
+      inclusion in resolution responses for TNs that are either directly
+      associated to this SED Record or for Public Identities residing in
+      a Destination Group that is associated to a SED Group, which, in
+      turn, has an association to this SED Record.
+
+   o  ttl: Number of seconds that an addressing server may cache a
+      particular SED Record.
+
+   As described above, SED Records are based on abstract type
+   SedRecType.  The concrete types that use SedRecType as an extension
+   base are NAPTRType, NSType, and URIType.  The definitions of these
+   types are included below.  The NAPTRType object is comprised of the
+   data elements necessary for a Naming Authority Pointer (NAPTR) (see
+   [RFC3403]) that contains routing information for a SED Group.  The
+   NSType object is comprised of the data elements necessary for a DNS
+   name server that points to another DNS server that contains the
+   desired routing information.  The NSType is relevant only when the
+   resolution protocol is ENUM (see [RFC6116]).  The URIType object is
+   comprised of the data elements necessary to house a URI.
+
+   The data provisioned in a Registry can be leveraged for many purposes
+   and queried using various protocols including SIP, ENUM, and others.
+   As such, the resolution data represented by the SED Records must be
+   in a form suitable for transport using one of these protocols.  In
+   the NAPTRType, for example, if the URI is associated with a
+   Destination Group, the user part of the replacement string <uri> that
+   may require the Public Identifier cannot be preset.  As a SIP
+   Redirect, the resolution server will apply <ere> pattern on the input
+   Public Identifier in the query and process the replacement string by
+   substituting any back references in the <uri> to arrive at the final
+   URI that is returned in the SIP Contact header.  For an ENUM query,
+   the resolution server will simply return the values of the <ere> and
+   <uri> members of the URI.
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 30]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   <complexType name="NAPTRType">
+    <complexContent>
+     <extension base="sppfb:SedRecType">
+      <sequence>
+       <element name="order" type="unsignedShort"/>
+       <element name="flags" type="sppfb:FlagsType" minOccurs="0"/>
+       <element name="svcs" type="sppfb:SvcType"/>
+       <element name="regx" type="sppfb:RegexParamType" minOccurs="0"/>
+       <element name="repl" type="sppfb:ReplType" minOccurs="0"/>
+       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+      </sequence>
+     </extension>
+    </complexContent>
+   </complexType>
+
+   <complexType name="NSType">
+    <complexContent>
+     <extension base="sppfb:SedRecType">
+      <sequence>
+       <element name="hostName" type="token"/>
+       <element name="ipAddr" type="sppfb:IPAddrType"
+                minOccurs="0" maxOccurs="unbounded"/>
+       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+      </sequence>
+     </extension>
+    </complexContent>
+   </complexType>
+
+   <complexType name="IPAddrType">
+    <sequence>
+     <element name="addr" type="sppfb:AddrStringType"/>
+     <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+    </sequence>
+    <attribute name="type" type="sppfb:IPType" default="IPv4"/>
+   </complexType>
+
+   <simpleType name="IPType">
+    <restriction base="token">
+     <enumeration value="IPv4"/>
+     <enumeration value="IPv6"/>
+    </restriction>
+   </simpleType>
+
+   <complexType name="URIType">
+    <complexContent>
+     <extension base="sppfb:SedRecType">
+      <sequence>
+       <element name="ere" type="token" default="^(.*)$"/>
+
+
+
+Cartwright, et al.           Standards Track                   [Page 31]
+
+RFC 7877                          SSPF                       August 2016
+
+
+       <element name="uri" type="anyURI"/>
+       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+      </sequence>
+     </extension>
+    </complexContent>
+   </complexType>
+
+   <simpleType name="flagsType">
+    <restriction base="token">
+     <length value="1"/>
+     <pattern value="[A-Z]|[a-z]|[0-9]"/>
+    </restriction>
+   </simpleType>
+
+   The NAPTRType object is composed of the following elements:
+
+   o  order: Order value in an ENUM NAPTR, relative to other NAPTRType
+      objects in the same SED Group.
+
+   o  svcs: ENUM service(s) that is served by the SBE.  This field's
+      value must be of the form specified in [RFC6116] (e.g.,
+      E2U+pstn:sip+sip).  The allowable values are a matter of policy
+      and are not limited by this protocol.
+
+   o  regx: NAPTR's regular expression field.  If this is not included,
+      then the repl field must be included.
+
+   o  repl: NAPTR replacement field; it should only be provided if the
+      regx field is not provided; otherwise, the server will ignore it.
+
+   o  ext: Point of extensibility described in Section 3.3.
+
+   The NSType object is composed of the following elements:
+
+   o  hostName: Root-relative host name of the name server.
+
+   o  ipAddr: Zero or more objects of type IpAddrType.  Each object
+      holds an IP Address and the IP Address type ("IPv4" or "IPv6").
+
+   o  ext: Point of extensibility described in Section 3.3.
+
+   The URIType object is composed of the following elements:
+
+   o  ere: The POSIX Extended Regular Expression (ere) as defined in
+      [RFC3986].
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 32]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   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
+      resolution server to arrive at the final usable URI.
+
+6.5.  SED Group Offer
+
+   The list of peer organizations whose resolution responses can include
+   the SED contained in a given SED Group is controlled by the
+   organization to which a SED Group object belongs (its Registrant) and
+   the peer organization that submits resolution requests (a data
+   recipient, also known as a peering organization).  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 until
+   access to a SED Group has been offered and accepted will the data
+   recipient's organization ID be included in the peeringOrg list in a
+   SED Group object, and that SED Group's peering information becomes a
+   candidate for inclusion in the responses to the resolution requests
+   submitted by that data recipient.  The substrate protocol MUST
+   support the ability to Add, Get, Delete, Accept, and Reject SED Group
+   Offers (refer to Section 7 for a generic description of various
+   operations).
+
+   A SED Group Offer object MUST be uniquely identified by attributes as
+   defined in the description of "SedGrpOfferKeyType" in "Derived Object
+   Key Types" (Section 5.2.2 of this document).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 33]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   The SedGrpOfferType object structure is defined as follows:
+
+   <complexType name="SedGrpOfferType">
+    <complexContent>
+     <extension base="sppfb:BasicObjType">
+      <sequence>
+       <element name="sedGrpOfferKey" type="sppfb:SedGrpOfferKeyType"/>
+       <element name="status" type="sppfb:SedGrpOfferStatusType"/>
+       <element name="offerDateTime" type="dateTime"/>
+       <element name="acceptDateTime" type="dateTime" minOccurs="0"/>
+       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+      </sequence>
+     </extension>
+    </complexContent>
+   </complexType>
+
+   <complexType name="SedGrpOfferKeyType" abstract="true">
+    <annotation>
+     <documentation>
+     -- Generic type that represents the key for a SED Group Offer. Must
+        be defined in concrete form in a substrate "protocol"
+        specification. --
+     </documentation>
+    </annotation>
+   </complexType>
+
+   <simpleType name="SedGrpOfferStatusType">
+    <restriction base="token">
+     <enumeration value="offered"/>
+     <enumeration value="accepted"/>
+    </restriction>
+   </simpleType>
+
+   The SedGrpOfferType object is composed of the following elements:
+
+   o  base: All first-class objects extend BasicObjType (see
+      Section 5.1).
+
+   o  sedGrpOfferKey: The object that identifies the SED that is or has
+      been offered and the organization to which it is or has been
+      offered.
+
+   o  status: The status of the offer, offered or accepted.  The server
+      controls the status.  It is automatically set to "offered"
+      whenever a new SED Group Offer is added and is automatically set
+      to "accepted" if and when that offer is accepted.  The value of
+      the element is ignored when passed in by the client.
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 34]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   o  offerDateTime: Date and time in UTC when the SED Group Offer was
+      added.
+
+   o  acceptDateTime: Date and time in UTC when the SED Group Offer was
+      accepted.
+
+6.6.  Egress Route
+
+   In a high-availability environment, the originating SSP likely has
+   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
+   specific egress SBE to be associated to the target ingress SBE, it
+   can do so using the EgrRteType object.
+
+   An Egress Route object MUST be uniquely identified by attributes as
+   defined in the description of "ObjKeyType" in "Generic Object Key
+   Type" (Section 5.2.1 of this document).
+
+   Assume that the target SSP has offered, as part of its SED, to share
+   one or more Ingress Routes and that the originating SSP has accepted
+   the offer.  In order to add the Egress Route to the Registry, the
+   originating SSP uses a valid regular expression to rewrite the
+   Ingress Route in order to include the egress SBE information.  Also,
+   more than one Egress Route can be associated with a given Ingress
+   Route in support of fault-tolerant configurations.  The supporting
+   SPPF structure provides a way to include route precedence information
+   to help manage traffic to more than one outbound egress SBE.
+
+   The substrate protocol MUST support the ability to Add, Get, and
+   Delete Egress Routes (refer to Section 7 for a generic description of
+   various operations).  The EgrRteType object structure is defined as
+   follows:
+
+   <complexType name="EgrRteType">
+    <complexContent>
+     <extension base="sppfb:BasicObjType">
+      <sequence>
+       <element name="egrRteName" type="sppfb:ObjNameType"/>
+       <element name="pref" type="unsignedShort"/>
+       <element name="regxRewriteRule" type="sppfb:RegexParamType"/>
+       <element name="ingrSedGrp" type="sppfb:ObjKeyType"
+                minOccurs="0" maxOccurs="unbounded"/>
+       <element name="svcs" type="sppfb:SvcType" minOccurs="0"/>
+       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+      </sequence>
+     </extension>
+    </complexContent>
+   </complexType>
+
+
+
+Cartwright, et al.           Standards Track                   [Page 35]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   The EgrRteType object is composed of the following elements:
+
+   o  base: All first-class objects extend BasicObjType (see
+      Section 5.1).
+
+   o  egrRteName: The name of the Egress Route.
+
+   o  pref: The preference of this Egress Route relative to other Egress
+      Routes that may get selected when responding to a resolution
+      request.
+
+   o  regxRewriteRule: The regular expression rewrite rule that should
+      be applied to the regular expression of the ingress NAPTR(s) that
+      belongs to the Ingress Route.
+
+   o  ingrSedGrp: The ingress SED Group that the Egress Route should be
+      used for.
+
+   o  svcs: ENUM service(s) that is served by an Egress Route.  This
+      element is used to identify the ingress NAPTRs associated with the
+      SED Group to which an Egress Route's regxRewriteRule should be
+      applied.  If no ENUM service(s) is associated with an Egress
+      Route, then the Egress Route's regxRewriteRule should be applied
+      to all the NAPTRs associated with the SED Group.  This field's
+      value must be of the form specified in [RFC6116] (e.g.,
+      E2U+pstn:sip+sip).  The allowable values are a matter of policy
+      and are not limited by this protocol.
+
+   o  ext: Point of extensibility described in Section 3.3.
+
+7.  Framework Operations
+
+   In addition to the operation-specific object types, all operations
+   MAY specify the minor version of the protocol that when used in
+   conjunction with the major version (which can be, for instance,
+   specified in the protocol Namespace) can serve to identify the
+   version of the SPPF protocol that the client is using.  If the minor
+   version is not specified, the latest minor version supported by the
+   SPPF server for the given major version will be used.  Additionally,
+   operations that may potentially modify persistent protocol objects
+   SHOULD include a transaction ID as well.
+
+
+
+
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 36]
+
+RFC 7877                          SSPF                       August 2016
+
+
+7.1.  Add Operation
+
+   Any conforming substrate "protocol" specification MUST provide a
+   definition for the operation that adds one or more SPPF objects into
+   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
+   MUST create the object.  If the object does exist, then the Registry
+   MUST replace the current properties of the object with the properties
+   passed in as part of the Add operation.
+
+   Note that this effectively allows modification of a preexisting
+   object.
+
+   If the entity that issued the command is not authorized to perform
+   this operation, an appropriate error message MUST be returned from
+   amongst the response messages defined in "Response Message Types"
+   (Section 5.3 of this document).
+
+7.2.  Delete Operation
+
+   Any conforming substrate "protocol" specification MUST provide a
+   definition for the operation that deletes one or more SPPF objects
+   from the Registry using the object's key.
+
+   If the entity that issued the command is not authorized to perform
+   this operation, an appropriate error message MUST be returned from
+   amongst the response messages defined in "Response Message Types"
+   (Section 5.3 of this document).
+
+   When an object is deleted, any references to that object must of
+   course also be removed as the SPPF server implementation fulfills the
+   deletion request.  Furthermore, the deletion of a composite object
+   must also result in the deletion of the objects it contains.  As a
+   result, the following rules apply to the deletion of SPPF object
+   types:
+
+   o  Destination Groups: When a Destination Group is deleted, any
+      cross-references between that destination group and any SED Group
+      must be automatically removed by the SPPF implementation as part
+      of fulfilling the deletion request.  Similarly, any cross-
+      references between that Destination Group and any Public
+      Identifier must be removed by the SPPF implementation.
+
+   o  SED Groups: When a SED Group is deleted, any references between
+      that SED Group and any Destination Group must be automatically
+      removed by the SPPF implementation as part of fulfilling the
+      deletion request.  Similarly, any cross-references between that
+      SED Group and any SED Records must be removed by the SPPF
+
+
+
+Cartwright, et al.           Standards Track                   [Page 37]
+
+RFC 7877                          SSPF                       August 2016
+
+
+      implementation as part of fulfilling the deletion request.
+      Furthermore, SED Group Offers relating to that SED Group must also
+      be deleted.
+
+   o  SED Records: When a SED Record is deleted, any cross-references
+      between that SED Record and any SED Group must be removed by the
+      SPPF implementation as part of fulfilling the deletion request.
+      Similarly, any reference between that SED Record and any Public
+      Identifier must be removed by the SPPF implementation.
+
+   o  Public Identifiers: When a Public Identifier is deleted, any
+      cross-references between that Public Identifier and any referenced
+      Destination Group must be removed by the SPPF implementation as
+      part of fulfilling the deletion request.  Any references to SED
+      Records associated directly to that Public Identifier must also be
+      deleted by the SPPF implementation.
+
+   Deletes MUST be atomic.
+
+7.3.  Get Operations
+
+   At times, on behalf of the Registrant, the Registrar may need to get
+   information about SPPF objects that were previously provisioned in
+   the Registry.  A few examples include logging, auditing, and pre-
+   provisioning dependency checking.  This query mechanism is limited to
+   aid provisioning scenarios and should not be confused with query
+   protocols provided as part of the resolution system (e.g., ENUM and
+   SIP).
+
+   Any conforming "protocol" specification MUST provide a definition for
+   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
+   the command is not authorized to perform this operation, an
+   appropriate error message MUST be returned from among the response
+   messages defined in Section 5.3.
+
+   If the response to the Get operation includes an object(s) that
+   extends the BasicObjType, the Registry MUST include the "cDate" and
+   "mDate", if applicable.
+
+7.4.  Accept Operations
+
+   In SPPF, a SED Group Offer can be accepted or rejected by, or on
+   behalf of, the Registrant to which the SED Group has been offered
+   (refer to Section 6.5 of this document for a description of the SED
+   Group Offer object).  The Accept operation is used to accept the SED
+   Group Offers.  Any conforming substrate "protocol" specification MUST
+   provide a definition for the operation to accept SED Group Offers by,
+
+
+
+Cartwright, et al.           Standards Track                   [Page 38]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   or on behalf of, the Registrant, using the SED Group Offer object
+   key.
+
+   Not until access to a SED Group has been offered and accepted will
+   the Registrant's organization ID be included in the peeringOrg list
+   in that SED Group object, and that SED Group's peering information
+   becomes a candidate for inclusion in the responses to the resolution
+   requests submitted by that Registrant.  A SED Group Offer that is in
+   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,
+   the SED Group Offer is moved to the "accepted" status and the data
+   recipient's organization ID is added into the list of peerOrgIds for
+   that SED Group.
+
+   If the entity that issued the command is not authorized to perform
+   this operation, an appropriate error message MUST be returned from
+   amongst the response messages defined in "Response Message Types"
+   (Section 5.3 of this document).
+
+7.5.  Reject Operations
+
+   In SPPF, a SED Group Offer object can be accepted or rejected by, or
+   on behalf of, the Registrant to which the SED Group has been offered
+   (refer to "Framework Data Model Objects", Section 6 of this document,
+   for a description of the SED Group Offer object).  Furthermore, that
+   offer may be rejected, regardless of whether or not it has been
+   previously accepted.  The Reject operation is used to reject the SED
+   Group Offer.  When the SED Group Offer is rejected, that SED Group
+   Offer is deleted, and, if appropriate, the data recipient's
+   organization ID is removed from the list of peeringOrg IDs for that
+   SED Group.  Any conforming substrate "protocol" specification MUST
+   provide a definition for the operation to reject SED Group Offers by,
+   or on behalf of, the Registrant, using the SED Group Offer object
+   key.
+
+   If the entity that issued the command is not authorized to perform
+   this operation, an appropriate error message MUST be returned from
+   among the response messages defined in "Response Message Types"
+   (Section 5.3 of this document).
+
+7.6.  Get Server Details Operation
+
+   In SPPF, the Get Server Details operation can be used to request
+   certain details about the SPPF server that include the SPPF server's
+   current status and the major/minor version of the SPPF protocol
+   supported by the SPPF server.
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 39]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   Any conforming substrate "protocol" specification MUST provide a
+   definition for the operation to request such details from the SPPF
+   server.  If the entity that issued the command is not authorized to
+   perform this operation, an appropriate error message MUST be returned
+   from among the response messages defined in "Response Message Types"
+   (Section 5.3 of this document).
+
+8.  XML Considerations
+
+   XML serves as the encoding format for SPPF, allowing complex
+   hierarchical data to be expressed in a text format that can be read,
+   saved, and manipulated with both traditional text tools and tools
+   specific to XML.
+
+   XML is case sensitive.  Unless stated otherwise, the character casing
+   of XML specifications in this document MUST be preserved to develop a
+   conforming specification.
+
+   This section discusses a small number of XML-related considerations
+   pertaining to SPPF.
+
+8.1.  Namespaces
+
+   All SPPF elements are defined in the Namespaces in the "IANA
+   Considerations" and "Formal Framework Specification" sections of this
+   document.
+
+8.2.  Versioning and Character Encoding
+
+   All XML instances SHOULD begin with an <?xml?> declaration to
+   identify the version of XML that is being used, optionally identify
+   use of the character encoding used, and optionally provide a hint to
+   an XML parser that an external schema file is needed to validate the
+   XML instance.
+
+   Conformant XML parsers recognize both UTF-8 (defined in [RFC3629])
+   and UTF-16 (defined in [RFC2781]); per [RFC2277], UTF-8 is the
+   RECOMMENDED character encoding for use with SPPF.
+
+   Character encodings other than UTF-8 and UTF-16 are allowed by XML.
+   UTF-8 is the default encoding assumed by XML in the absence of an
+   "encoding" attribute or a byte order mark (BOM); thus, the "encoding"
+   attribute in the XML declaration is OPTIONAL if UTF-8 encoding is
+   used.  SPPF clients and servers MUST accept a UTF-8 BOM if present,
+   though emitting a UTF-8 BOM is NOT RECOMMENDED.
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 40]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   Example XML declarations:
+
+   <?xml version="1.0" encoding="UTF-8" standalone="no"?>
+
+9.  Security Considerations
+
+   Many SPPF implementations manage data that is considered confidential
+   and critical.  Furthermore, SPPF implementations can support
+   provisioning activities for multiple Registrars and Registrants.  As
+   a result, any SPPF implementation must address the requirements for
+   confidentiality, authentication, and authorization.
+
+9.1.  Confidentiality and Authentication
+
+   With respect to confidentiality and authentication, the substrate
+   protocol requirements section of this document contains security
+   properties that the substrate protocol must provide, so that
+   authenticated endpoints can exchange data confidentially and with
+   integrity protection.  Refer to Section 4 of this document and
+   [RFC7878] for the specific solutions to authentication and
+   confidentiality.
+
+9.2.  Authorization
+
+   With respect to authorization, the SPPF server implementation must
+   define and implement a set of authorization rules that precisely
+   address (1) which Registrars will be authorized to create/modify/
+   delete each SPPF object type for a given Registrant(s) and (2) which
+   Registrars will be authorized to view/get each SPPF object type for a
+   given Registrant(s).  These authorization rules are a matter of
+   policy and are not specified within the context of SPPF.  However,
+   any SPPF implementation must specify these authorization rules in
+   order to function in a reliable and safe manner.
+
+9.3.  Denial of Service
+
+   In general, guidance on Denial-of-Service (DoS) issues is given in
+   "Internet Denial of Service Considerations" [RFC4732], which also
+   gives a general vocabulary for describing the DoS issue.
+
+   SPPF is a high-level client-server protocol that can be implemented
+   on lower-level mechanisms such as remote procedure call and web-
+   service API protocols.  As such, it inherits any Denial-of-Service
+   issues inherent to the specific lower-level mechanism used for any
+   implementation of SPPF.  SPPF also has its own set of higher-level
+   exposures that are likely to be independent of lower-layer mechanism
+   choices.
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 41]
+
+RFC 7877                          SSPF                       August 2016
+
+
+9.3.1.  DoS Issues Inherited from the Substrate Mechanism
+
+   In general, an SPPF implementation is dependent on the selection and
+   implementation of a lower-level substrate protocol and a binding
+   between that protocol and SPPF.  The archetypal SPPF implementation
+   uses XML [W3C.REC-xml-20081126] representation in a SOAP [SOAPREF]
+   request/response framework over HTTP [RFC7230], probably also uses
+   Transport Layer Security (TLS) [RFC5246] for on-the-wire data
+   integrity and participant authentication, and might use HTTP Digest
+   authentication [RFC2069].
+
+   The typical deployment scenario for SPPF is to have servers in a
+   managed facility; therefore, techniques such as Network Ingress
+   Filtering [RFC2827] are generally applicable.  In short, any DoS
+   mechanism affecting a typical HTTP implementation would affect such
+   an SPPF implementation; therefore, the mitigation tools for HTTP in
+   general also apply to SPPF.
+
+   SPPF does not directly specify an authentication mechanism; instead,
+   it relies on the lower-level substrate protocol to provide for
+   authentication.  In general, authentication is an expensive
+   operation, and one apparent attack vector is to flood an SPPF server
+   with repeated requests for authentication, thereby exhausting its
+   resources.  Therefore, SPPF implementations SHOULD be prepared to
+   handle authentication floods, perhaps by noting repeated failed login
+   requests from a given source address and blocking that source
+   address.
+
+9.3.2.  DoS Issues Specific to SPPF
+
+   The primary defense mechanism against DoS within SPPF is
+   authentication.  Implementations MUST tightly control access to the
+   SPPF service, SHOULD implement DoS and other policy control
+   screening, and MAY employ a variety of policy violation reporting and
+   response measures such as automatic blocking of specific users and
+   alerting of operations personnel.  In short, the primary SPPF
+   response to DoS-like activity by a user is to block that user or
+   subject their actions to additional review.
+
+   SPPF allows a client to submit multiple-element or "batch" requests
+   that may insert or otherwise affect a large amount of data with a
+   single request.  In the simplest case, the server progresses
+   sequentially through each element in a batch, completing one before
+   starting the next.  Mid-batch failures are handled by stopping the
+   batch and rolling back the data store to its pre-request state.  This
+   "stop and roll back" design provides a DoS opportunity.  A hostile
+   client could repeatedly issue large batch requests with one or more
+   failing elements, causing the server to repeatedly stop and roll back
+
+
+
+Cartwright, et al.           Standards Track                   [Page 42]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   large transactions.  The suggested response is to monitor clients for
+   such failures and take administrative action (such as blocking the
+   user) when an excessive number of rollbacks is reported.
+
+   An additional suggested response is for an implementer to set their
+   maximum allowable XML message size and their maximum allowable batch
+   size at a level that they feel protects their operational instance,
+   given the hardware sizing they have in place and the expected load
+   and size needs that their users expect.
+
+9.4.  Information Disclosure
+
+   It is not uncommon for the logging systems to document on-the-wire
+   messages for various purposes, such as debugging, auditing, and
+   tracking.  At the minimum, the various support and administration
+   staff will 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 information that is potentially deemed
+   confidential.  To manage information disclosure concerns beyond the
+   substrate level, SPPF implementations MAY provide support for
+   encryption at the SPPF object level.
+
+9.5.  Non-repudiation
+
+   In some situations, it may be required to protect against denial of
+   involvement (see [RFC4949]) and tackle non-repudiation concerns in
+   regard to SPPF messages.  This type of protection is useful to
+   satisfy authenticity concerns related to SPPF messages beyond the
+   end-to-end connection integrity, confidentiality, and authentication
+   protection that the substrate layer provides.  This is an optional
+   feature, and some SPPF implementations MAY provide support for it.
+
+9.6.  Replay Attacks
+
+   Anti-replay protection ensures that a given SPPF object replayed at a
+   later time won't affect the integrity of the system.  SPPF provides
+   at least one mechanism to fight against replay attacks.  Use of the
+   optional client transaction identifier allows the SPPF client to
+   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
+   of unique values for the client transaction identifier is highly
+   encouraged to avoid chance matches to a potential replay message.
+
+
+
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 43]
+
+RFC 7877                          SSPF                       August 2016
+
+
+9.7.  Compromised or Malicious Intermediary
+
+   The SPPF client or Registrar can be a separate entity acting on
+   behalf of the Registrant in facilitating provisioning transactions to
+   the Registry.  Therefore, even though the substrate layer provides
+   end-to-end protection for each specific SPPP connection between
+   client and server, data might be available in clear text before or
+   after it traverses an SPPP connection.  Therefore, a
+   man-in-the-middle attack by one of the intermediaries is a
+   possibility that could affect the integrity of the data that belongs
+   to the Registrant and/or expose peering data to unintended actors.
+
+10.  Internationalization Considerations
+
+   Character encodings to be used for SPPF elements are described in
+   Section 8.2.  The use of time elements in the protocol is specified
+   in Section 3.2.  Where human-readable messages that are presented to
+   an end user are used in the protocol, those messages SHOULD be tagged
+   according to [RFC5646], and the substrate protocol MUST support a
+   respective mechanism to transmit such tags together with those human-
+   readable messages.
+
+11.  IANA Considerations
+
+11.1.  URN Assignments
+
+   This document uses URNs to describe XML Namespaces and XML Schemas
+   conforming to a Registry mechanism described in [RFC3688].
+
+   Two URI assignments have been made:
+
+   Registration for the SPPF XML Namespace:
+   urn:ietf:params:xml:ns:sppf:base:1
+   Registrant Contact: The IESG
+   XML: None.  Namespace URIs do not represent an XML specification.
+
+   Registration request for the XML Schema:
+
+   URI: urn:ietf:params:xml:schema:sppf:1
+   Registrant Contact: IESG
+   XML: See "Formal Specification" (Section 12 of this document).
+
+
+
+
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 44]
+
+RFC 7877                          SSPF                       August 2016
+
+
+11.2.  Organization Identifier Namespace Registry
+
+   IANA has created and will maintain a registry titled "SPPF OrgIdType
+   Namespaces".  The formal syntax is described in Section 5.1.
+
+   Assignments consist of the OrgIdType Namespace string and the
+   definition of the associated Namespace.  This document makes the
+   following initial assignment for the OrgIdType Namespaces:
+
+         OrgIdType Namespace string                       Namespace
+         --------------------------                       ---------
+         IANA Enterprise Numbers                          iana-en
+
+   Future assignments are to be made through the well-known IANA Policy
+   "RFC Required" (see Section 4.1 of [RFC5226]).  Such assignments will
+   typically be requested when a new Namespace for identification of SPs
+   is defined.
+
+12.  Formal Specification
+
+   This section provides the XSD for the SPPF protocol.
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <schema xmlns:sppfb="urn:ietf:params:xml:ns:sppf:base:1"
+   xmlns="http://www.w3.org/2001/XMLSchema"
+   targetNamespace="urn:ietf:params:xml:ns:sppf:base:1"
+   elementFormDefault="qualified" xml:lang="EN">
+    <annotation>
+     <documentation>
+      ---- Generic object key types to be defined by specific
+           substrate/architecture.  The types defined here can
+           be extended by the specific architecture to
+           define the Object Identifiers. ----
+     </documentation>
+    </annotation>
+    <complexType name="ObjKeyType"
+     abstract="true">
+     <annotation>
+      <documentation>
+       ---- Generic type that represents the
+            key for various objects in SPPF. ----
+      </documentation>
+     </annotation>
+    </complexType>
+
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 45]
+
+RFC 7877                          SSPF                       August 2016
+
+
+    <complexType name="SedGrpOfferKeyType" abstract="true">
+     <complexContent>
+      <extension base="sppfb:ObjKeyType">
+       <annotation>
+        <documentation>
+        ---- Generic type that represents
+             the key for a SED Group Offer. ----
+        </documentation>
+       </annotation>
+      </extension>
+     </complexContent>
+    </complexType>
+
+    <complexType name="PubIdKeyType" abstract="true">
+     <complexContent>
+      <extension base="sppfb:ObjKeyType">
+       <annotation>
+        <documentation>
+         ----Generic type that
+         represents the key
+         for a Pub ID. ----
+        </documentation>
+       </annotation>
+      </extension>
+     </complexContent>
+    </complexType>
+
+    <annotation>
+     <documentation>
+       ---- Object Type Definitions ----
+     </documentation>
+    </annotation>
+
+    <complexType name="SedGrpType">
+     <complexContent>
+      <extension base="sppfb:BasicObjType">
+       <sequence>
+        <element name="sedGrpName" type="sppfb:ObjNameType"/>
+        <element name="sedRecRef" type="sppfb:SedRecRefType"
+                 minOccurs="0" maxOccurs="unbounded"/>
+        <element name="dgName" type="sppfb:ObjNameType"
+                 minOccurs="0" maxOccurs="unbounded"/>
+        <element name="peeringOrg" type="sppfb:OrgIdType"
+                 minOccurs="0" maxOccurs="unbounded"/>
+        <element name="sourceIdent" type="sppfb:SourceIdentType"
+                 minOccurs="0" maxOccurs="unbounded"/>
+        <element name="isInSvc" type="boolean"/>
+        <element name="priority" type="unsignedShort"/>
+
+
+
+Cartwright, et al.           Standards Track                   [Page 46]
+
+RFC 7877                          SSPF                       August 2016
+
+
+        <element name="ext"
+        type="sppfb:ExtAnyType" minOccurs="0"/>
+       </sequence>
+      </extension>
+     </complexContent>
+    </complexType>
+    <complexType name="DestGrpType">
+     <complexContent>
+      <extension base="sppfb:BasicObjType">
+       <sequence>
+        <element name="dgName"
+        type="sppfb:ObjNameType"/>
+       </sequence>
+      </extension>
+     </complexContent>
+    </complexType>
+    <complexType name="PubIdType" abstract="true">
+     <complexContent>
+      <extension base="sppfb:BasicObjType">
+       <sequence>
+        <element name="dgName" type="sppfb:ObjNameType"
+                 minOccurs="0" maxOccurs="unbounded"/>
+       </sequence>
+      </extension>
+     </complexContent>
+    </complexType>
+    <complexType name="TNType">
+     <complexContent>
+      <extension base="sppfb:PubIdType">
+       <sequence>
+        <element name="tn" type="sppfb:NumberValType"/>
+        <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
+        <element name="sedRecRef" type="sppfb:SedRecRefType"
+                 minOccurs="0" maxOccurs="unbounded"/>
+       </sequence>
+      </extension>
+     </complexContent>
+    </complexType>
+    <complexType name="TNRType">
+     <complexContent>
+      <extension base="sppfb:PubIdType">
+       <sequence>
+        <element name="range" type="sppfb:NumberRangeType"/>
+        <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
+       </sequence>
+      </extension>
+     </complexContent>
+    </complexType>
+
+
+
+Cartwright, et al.           Standards Track                   [Page 47]
+
+RFC 7877                          SSPF                       August 2016
+
+
+    <complexType name="TNPType">
+     <complexContent>
+      <extension base="sppfb:PubIdType">
+       <sequence>
+        <element name="tnPrefix" type="sppfb:NumberValType"/>
+        <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
+       </sequence>
+      </extension>
+     </complexContent>
+    </complexType>
+    <complexType name="RNType">
+     <complexContent>
+      <extension base="sppfb:PubIdType">
+       <sequence>
+        <element name="rn" type="sppfb:NumberValType"/>
+        <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
+       </sequence>
+      </extension>
+     </complexContent>
+    </complexType>
+     <complexType name="URIPubIdType">
+     <complexContent>
+      <extension base="sppfb:PubIdType">
+       <sequence>
+        <element name="uri" type="anyURI"/>
+        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+       </sequence>
+      </extension>
+     </complexContent>
+    </complexType>
+    <complexType name="SedRecType" abstract="true">
+     <complexContent>
+      <extension base="sppfb:BasicObjType">
+       <sequence>
+        <element name="sedName" type="sppfb:ObjNameType"/>
+        <element name="sedFunction" type="sppfb:SedFunctionType"
+                 minOccurs="0"/>
+        <element name="isInSvc" type="boolean"/>
+        <element name="ttl" type="positiveInteger" minOccurs="0"/>
+       </sequence>
+      </extension>
+     </complexContent>
+    </complexType>
+    <complexType name="NAPTRType">
+     <complexContent>
+      <extension base="sppfb:SedRecType">
+       <sequence>
+        <element name="order" type="unsignedShort"/>
+
+
+
+Cartwright, et al.           Standards Track                   [Page 48]
+
+RFC 7877                          SSPF                       August 2016
+
+
+        <element name="flags" type="sppfb:FlagsType" minOccurs="0"/>
+        <element name="svcs" type="sppfb:SvcType"/>
+        <element name="regx" type="sppfb:RegexParamType" minOccurs="0"/>
+        <element name="repl" type="sppfb:ReplType" minOccurs="0"/>
+        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+       </sequence>
+      </extension>
+     </complexContent>
+    </complexType>
+    <complexType name="NSType">
+     <complexContent>
+      <extension base="sppfb:SedRecType">
+       <sequence>
+        <element name="hostName" type="token"/>
+        <element name="ipAddr" type="sppfb:IPAddrType"
+                 minOccurs="0" maxOccurs="unbounded"/>
+        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+       </sequence>
+      </extension>
+     </complexContent>
+    </complexType>
+    <complexType name="URIType">
+     <complexContent>
+      <extension base="sppfb:SedRecType">
+       <sequence>
+        <element name="ere" type="token" default="^(.*)$"/>
+        <element name="uri" type="anyURI"/>
+        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+       </sequence>
+      </extension>
+     </complexContent>
+    </complexType>
+    <complexType name="SedGrpOfferType">
+     <complexContent>
+      <extension base="sppfb:BasicObjType">
+       <sequence>
+        <element name="sedGrpOfferKey" type="sppfb:SedGrpOfferKeyType"/>
+        <element name="status" type="sppfb:SedGrpOfferStatusType"/>
+        <element name="offerDateTime" type="dateTime"/>
+        <element name="acceptDateTime" type="dateTime" minOccurs="0"/>
+        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+       </sequence>
+      </extension>
+     </complexContent>
+    </complexType>
+    <complexType name="EgrRteType">
+     <complexContent>
+      <extension base="sppfb:BasicObjType">
+
+
+
+Cartwright, et al.           Standards Track                   [Page 49]
+
+RFC 7877                          SSPF                       August 2016
+
+
+       <sequence>
+        <element name="egrRteName" type="sppfb:ObjNameType"/>
+        <element name="pref" type="unsignedShort"/>
+        <element name="regxRewriteRule" type="sppfb:RegexParamType"/>
+        <element name="ingrSedGrp" type="sppfb:ObjKeyType"
+                 minOccurs="0" maxOccurs="unbounded"/>
+        <element name="svcs" type="sppfb:SvcType" minOccurs="0"/>
+        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+       </sequence>
+      </extension>
+     </complexContent>
+    </complexType>
+    <annotation>
+     <documentation>
+      ---- Abstract Object and Element Type Definitions ----
+     </documentation>
+    </annotation>
+    <complexType name="BasicObjType" abstract="true">
+     <sequence>
+      <element name="rant" type="sppfb:OrgIdType"/>
+      <element name="rar" type="sppfb:OrgIdType"/>
+      <element name="cDate" type="dateTime" minOccurs="0"/>
+      <element name="mDate" type="dateTime" minOccurs="0"/>
+      <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+     </sequence>
+    </complexType>
+    <complexType name="RegexParamType">
+     <sequence>
+      <element name="ere" type="sppfb:RegexType" default="^(.*)$"/>
+      <element name="repl" type="sppfb:ReplType"/>
+     </sequence>
+    </complexType>
+    <complexType name="IPAddrType">
+     <sequence>
+      <element name="addr" type="sppfb:AddrStringType"/>
+      <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+     </sequence>
+     <attribute name="type" type="sppfb:IPType" default="v4"/>
+    </complexType>
+    <complexType name="SedRecRefType">
+     <sequence>
+      <element name="sedKey" type="sppfb:ObjKeyType"/>
+      <element name="priority" type="unsignedShort"/>
+      <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+     </sequence>
+    </complexType>
+    <complexType name="SourceIdentType">
+     <sequence>
+
+
+
+Cartwright, et al.           Standards Track                   [Page 50]
+
+RFC 7877                          SSPF                       August 2016
+
+
+      <element name="sourceIdentRegex" type="sppfb:RegexType"/>
+      <element name="sourceIdentScheme"
+               type="sppfb:SourceIdentSchemeType"/>
+      <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
+     </sequence>
+    </complexType>
+    <complexType name="CORInfoType">
+     <sequence>
+      <element name="corClaim" type="boolean" default="true"/>
+      <element name="cor" type="boolean" default="false" minOccurs="0"/>
+      <element name="corDate" type="dateTime" minOccurs="0"/>
+     </sequence>
+    </complexType>
+    <complexType name="SvcMenuType">
+     <sequence>
+      <element name="serverStatus" type="sppfb:ServerStatusType"/>
+      <element name="majMinVersion" type="token" maxOccurs="unbounded"/>
+      <element name="objURI" type="anyURI" maxOccurs="unbounded"/>
+      <element name="extURI" type="anyURI"
+               minOccurs="0" maxOccurs="unbounded"/>
+     </sequence>
+    </complexType>
+    <complexType name="ExtAnyType">
+     <sequence>
+      <any namespace="##other" maxOccurs="unbounded"/>
+     </sequence>
+    </complexType>
+    <simpleType name="FlagsType">
+     <restriction base="token">
+      <length value="1"/>
+      <pattern value="[A-Z]|[a-z]|[0-9]"/>
+     </restriction>
+    </simpleType>
+    <simpleType name="SvcType">
+     <restriction base="token">
+      <minLength value="1"/>
+     </restriction>
+    </simpleType>
+    <simpleType name="RegexType">
+     <restriction base="token">
+      <minLength value="1"/>
+     </restriction>
+    </simpleType>
+    <simpleType name="ReplType">
+     <restriction base="token">
+      <minLength value="1"/>
+      <maxLength value="255"/>
+     </restriction>
+
+
+
+Cartwright, et al.           Standards Track                   [Page 51]
+
+RFC 7877                          SSPF                       August 2016
+
+
+    </simpleType>
+    <simpleType name="OrgIdType">
+     <restriction base="token"/>
+    </simpleType>
+    <simpleType name="ObjNameType">
+     <restriction base="token">
+      <minLength value="3"/>
+      <maxLength value="80"/>
+     </restriction>
+    </simpleType>
+    <simpleType name="TransIdType">
+     <restriction base="token">
+      <minLength value="3"/>
+      <maxLength value="120"/>
+     </restriction>
+    </simpleType>
+    <simpleType name="MinorVerType">
+     <restriction base="unsignedLong"/>
+    </simpleType>
+    <simpleType name="AddrStringType">
+     <restriction base="token">
+      <minLength value="3"/>
+      <maxLength value="45"/>
+     </restriction>
+    </simpleType>
+    <simpleType name="IPType">
+     <restriction base="token">
+      <enumeration value="v4"/>
+      <enumeration value="v6"/>
+     </restriction>
+    </simpleType>
+    <simpleType name="SourceIdentSchemeType">
+     <restriction base="token">
+      <enumeration value="uri"/>
+      <enumeration value="ip"/>
+      <enumeration value="rootDomain"/>
+     </restriction>
+    </simpleType>
+    <simpleType name="ServerStatusType">
+     <restriction base="token">
+      <enumeration value="inService"/>
+      <enumeration value="outOfService"/>
+     </restriction>
+    </simpleType>
+    <simpleType name="SedGrpOfferStatusType">
+     <restriction base="token">
+      <enumeration value="offered"/>
+      <enumeration value="accepted"/>
+
+
+
+Cartwright, et al.           Standards Track                   [Page 52]
+
+RFC 7877                          SSPF                       August 2016
+
+
+     </restriction>
+    </simpleType>
+    <simpleType name="NumberValType">
+     <restriction base="token">
+      <maxLength value="20"/>
+      <pattern value="\+?\d\d*"/>
+     </restriction>
+    </simpleType>
+    <simpleType name="NumberTypeEnum">
+     <restriction base="token">
+      <enumeration value="TN"/>
+      <enumeration value="TNPrefix"/>
+      <enumeration value="RN"/>
+     </restriction>
+    </simpleType>
+    <simpleType name="SedFunctionType">
+     <restriction base="token">
+      <enumeration value="routing"/>
+      <enumeration value="lookup"/>
+     </restriction>
+    </simpleType>
+    <complexType name="NumberType">
+     <sequence>
+      <element name="value" type="sppfb:NumberValType"/>
+      <element name="type" type="sppfb:NumberTypeEnum"/>
+     </sequence>
+    </complexType>
+    <complexType name="NumberRangeType">
+     <sequence>
+      <element name="startRange" type="sppfb:NumberValType"/>
+      <element name="endRange" type="sppfb:NumberValType"/>
+     </sequence>
+    </complexType>
+   </schema>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 53]
+
+RFC 7877                          SSPF                       August 2016
+
+
+13.  References
+
+13.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
+              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
+              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,
+              DOI 10.17487/RFC3688, January 2004,
+              <http://www.rfc-editor.org/info/rfc3688>.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              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
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              DOI 10.17487/RFC5226, May 2008,
+              <http://www.rfc-editor.org/info/rfc5226>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <http://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC7878]  Cartwright, K., Bhatia, V., Mule, J., and A. Mayrhofer,
+              "Session Peering Provisioning (SPP) Protocol over SOAP",
+              RFC 7878, DOI 10.17487/RFC7878, August 2016,
+              <http://www.rfc-editor.org/info/rfc7878>.
+
+   [W3C.REC-xml-20081126]
+              Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
+              F. Yergeau, "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>.
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 54]
+
+RFC 7877                          SSPF                       August 2016
+
+
+13.2.  Informative References
+
+   [RFC2069]  Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
+              Luotonen, A., Sink, E., and L. Stewart, "An Extension to
+              HTTP : Digest Access Authentication", RFC 2069,
+              DOI 10.17487/RFC2069, January 1997,
+              <http://www.rfc-editor.org/info/rfc2069>.
+
+   [RFC2781]  Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
+              10646", RFC 2781, DOI 10.17487/RFC2781, February 2000,
+              <http://www.rfc-editor.org/info/rfc2781>.
+
+   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
+              Defeating Denial of Service Attacks which employ IP Source
+              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
+              May 2000, <http://www.rfc-editor.org/info/rfc2827>.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              DOI 10.17487/RFC3261, June 2002,
+              <http://www.rfc-editor.org/info/rfc3261>.
+
+   [RFC3403]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
+              Part Three: The Domain Name System (DNS) Database",
+              RFC 3403, DOI 10.17487/RFC3403, October 2002,
+              <http://www.rfc-editor.org/info/rfc3403>.
+
+   [RFC4725]  Mayrhofer, A. and B. Hoeneisen, "ENUM Validation
+              Architecture", RFC 4725, DOI 10.17487/RFC4725, November
+              2006, <http://www.rfc-editor.org/info/rfc4725>.
+
+   [RFC4732]  Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
+              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",
+              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
+              Requirements", RFC 5067, DOI 10.17487/RFC5067, November
+              2007, <http://www.rfc-editor.org/info/rfc5067>.
+
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 55]
+
+RFC 7877                          SSPF                       August 2016
+
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <http://www.rfc-editor.org/info/rfc5246>.
+
+   [RFC5486]  Malas, D., Ed. and D. Meyer, Ed., "Session Peering for
+              Multimedia Interconnect (SPEERMINT) Terminology",
+              RFC 5486, DOI 10.17487/RFC5486, March 2009,
+              <http://www.rfc-editor.org/info/rfc5486>.
+
+   [RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
+              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
+              Uniform Resource Identifiers (URI) Dynamic Delegation
+              Discovery System (DDDS) Application (ENUM)", RFC 6116,
+              DOI 10.17487/RFC6116, March 2011,
+              <http://www.rfc-editor.org/info/rfc6116>.
+
+   [RFC6461]  Channabasappa, S., Ed., "Data for Reachability of Inter-
+              /Intra-NetworK SIP (DRINKS) Use Cases and Protocol
+              Requirements", RFC 6461, DOI 10.17487/RFC6461, January
+              2012, <http://www.rfc-editor.org/info/rfc6461>.
+
+   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+              Protocol (HTTP/1.1): Message Syntax and Routing",
+              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 REC REC-
+              SOAP12-part1-20030624, June 2003,
+              <http://www.w3.org/TR/soap12-part1/>.
+
+   [Unicode6.1]
+              The Unicode Consortium, "The Unicode Standard, Version
+              6.1.0", (Mountain View, CA: The Unicode Consortium,
+              2012. ISBN 978-1-936213-02-3),
+              <http://unicode.org/versions/Unicode6.1.0/>.
+
+
+
+
+
+
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 56]
+
+RFC 7877                          SSPF                       August 2016
+
+
+Acknowledgements
+
+   This document is a result of various discussions held in the DRINKS
+   working group and within the DRINKS protocol design team, with
+   contributions from the following individuals, in alphabetical order:
+   Syed Ali, Jeremy Barkan, Vikas Bhatia, Sumanth Channabasappa, Lisa
+   Dusseault, Deborah A.  Guyton, Otmar Lendl, Manjul Maharishi, Mickael
+   Marrache, Alexander Mayrhofer, Samuel Melloul, David Schwartz, and
+   Richard Shockey.
+
+Authors' Addresses
+
+   Kenneth Cartwright
+   TNS
+   1939 Roland Clarke Place
+   Reston, VA  20191
+   United States
+
+   Email: kcartwright@tnsi.com
+
+
+   Vikas Bhatia
+   TNS
+   1939 Roland Clarke Place
+   Reston, VA  20191
+   United States
+
+   Email: vbhatia@tnsi.com
+
+
+   Syed Wasim Ali
+   NeuStar
+   46000 Center Oak Plaza
+   Sterling, VA  20166
+   United States
+
+   Email: syed.ali@neustar.biz
+
+
+   David Schwartz
+   XConnect
+   316 Regents Park Road
+   London  N3 2XJ
+   United Kingdom
+
+   Email: dschwartz@xconnect.net
+
+
+
+
+
+Cartwright, et al.           Standards Track                   [Page 57]
+