idnits 2.17.1
draft-ietf-drinks-spp-framework-11.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 22, 2015) is 3202 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Unused Reference: 'RFC3403' is defined on line 2458, but no explicit
reference was found in the text
== Outdated reference: A later version (-09) exists of
draft-ietf-drinks-spp-protocol-over-soap-07
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
-- Obsolete informational reference (is this intentional?): RFC 5246
(Obsoleted by RFC 8446)
-- Obsolete informational reference (is this intentional?): RFC 7230
(Obsoleted by RFC 9110, RFC 9112)
Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 DRINKS K. Cartwright
3 Internet-Draft V. Bhatia
4 Intended status: Standards Track TNS
5 Expires: January 23, 2016 S. Ali
6 NeuStar
7 D. Schwartz
8 XConnect
9 July 22, 2015
11 Session Peering Provisioning Framework (SPPF)
12 draft-ietf-drinks-spp-framework-11
14 Abstract
16 This document specifies the data model and the overall structure for
17 a framework to provision session establishment data into Session Data
18 Registries and SIP Service Provider data stores. The framework is
19 called the Session Peering Provisioning Framework (SPPF). The
20 provisioned data is typically used by network elements for session
21 establishment.
23 Status of This Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at http://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on January 23, 2016.
40 Copyright Notice
42 Copyright (c) 2015 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
59 3. Framework High Level Design . . . . . . . . . . . . . . . . . 7
60 3.1. Framework Data Model . . . . . . . . . . . . . . . . . . 7
61 3.2. Time Value . . . . . . . . . . . . . . . . . . . . . . . 10
62 3.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10
63 4. Transport Substrate Protocol Requirements . . . . . . . . . . 11
64 4.1. Mandatory Substrate . . . . . . . . . . . . . . . . . . . 11
65 4.2. Connection Oriented . . . . . . . . . . . . . . . . . . . 11
66 4.3. Request and Response Model . . . . . . . . . . . . . . . 11
67 4.4. Connection Lifetime . . . . . . . . . . . . . . . . . . . 11
68 4.5. Authentication . . . . . . . . . . . . . . . . . . . . . 12
69 4.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 12
70 4.7. Confidentiality and Integrity . . . . . . . . . . . . . . 12
71 4.8. Near Real Time . . . . . . . . . . . . . . . . . . . . . 12
72 4.9. Request and Response Sizes . . . . . . . . . . . . . . . 12
73 4.10. Request and Response Correlation . . . . . . . . . . . . 13
74 4.11. Request Acknowledgement . . . . . . . . . . . . . . . . . 13
75 5. Base Framework Data Structures and Response Codes . . . . . . 13
76 5.1. Basic Object Type and Organization Identifiers . . . . . 13
77 5.2. Various Object Key Types . . . . . . . . . . . . . . . . 14
78 5.2.1. Generic Object Key Type . . . . . . . . . . . . . . . 14
79 5.2.2. Derived Object Key Types . . . . . . . . . . . . . . 15
80 5.3. Response Message Types . . . . . . . . . . . . . . . . . 16
81 6. Framework Data Model Objects . . . . . . . . . . . . . . . . 18
82 6.1. Destination Group . . . . . . . . . . . . . . . . . . . . 18
83 6.2. Public Identifier . . . . . . . . . . . . . . . . . . . . 19
84 6.3. SED Group . . . . . . . . . . . . . . . . . . . . . . . . 24
85 6.4. SED Record . . . . . . . . . . . . . . . . . . . . . . . 28
86 6.5. SED Group Offer . . . . . . . . . . . . . . . . . . . . . 32
87 6.6. Egress Route . . . . . . . . . . . . . . . . . . . . . . 34
88 7. Framework Operations . . . . . . . . . . . . . . . . . . . . 36
89 7.1. Add Operation . . . . . . . . . . . . . . . . . . . . . . 36
90 7.2. Delete Operation . . . . . . . . . . . . . . . . . . . . 36
91 7.3. Get Operations . . . . . . . . . . . . . . . . . . . . . 37
92 7.4. Accept Operations . . . . . . . . . . . . . . . . . . . . 38
93 7.5. Reject Operations . . . . . . . . . . . . . . . . . . . . 38
94 7.6. Get Server Details Operation . . . . . . . . . . . . . . 39
95 8. XML Considerations . . . . . . . . . . . . . . . . . . . . . 39
96 8.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . . 39
97 8.2. Versioning and Character Encoding . . . . . . . . . . . . 39
98 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
99 9.1. Confidentiality and Authentication . . . . . . . . . . . 40
100 9.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 40
101 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 40
102 9.3.1. DoS Issues Inherited from Substrate Mechanism . . . . 41
103 9.3.2. DoS Issues Specific to SPPF . . . . . . . . . . . . . 41
104 9.4. Information Disclosure . . . . . . . . . . . . . . . . . 42
105 9.5. Non-repudiation . . . . . . . . . . . . . . . . . . . . . 42
106 9.6. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 42
107 9.7. Man in the Middle . . . . . . . . . . . . . . . . . . . . 43
108 10. Internationalization Considerations . . . . . . . . . . . . . 43
109 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
110 11.1. URN Assignments . . . . . . . . . . . . . . . . . . . . 43
111 11.2. Organization Identifier Namespace Registry . . . . . . . 44
112 12. Formal Specification . . . . . . . . . . . . . . . . . . . . 44
113 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
114 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
115 14.1. Normative References . . . . . . . . . . . . . . . . . . 53
116 14.2. Informative References . . . . . . . . . . . . . . . . . 54
117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
119 1. Introduction
121 Service providers and enterprises use routing databases known as
122 Registries to make session routing decisions for Voice over IP, SMS
123 and MMS traffic exchanges. This document is narrowly focused on the
124 provisioning framework for these registries. This framework
125 prescribes a way for an entity to provision session-related data into
126 a SPPP Registry (or "Registry"). The data being provisioned can be
127 optionally shared with other participating peering entities. The
128 requirements and use cases driving this framework have been
129 documented in [RFC6461].
131 Three types of provisioning flows have been described in the use case
132 document: client to Registry, Registry to local data repository and
133 Registry to Registry. This document addresses client to Registry
134 flow enabling the ability to provision Session Establishment Data
135 (SED). The framework that supports flow of messages to facilitate
136 client to Registry provisioning is referred to as Session Peering
137 Provisioning Framework (SPPF).
139 The roles of the "client" and the "server" only apply to the
140 connection, and those roles are not related in any way to the type of
141 entity that participates in a protocol exchange. For example, a
142 Registry might also include a "client" when such a Registry initiates
143 a connection (for example, for data distribution to SSP).
145 *--------* *------------* *------------*
146 | | (1). Client | | (3).Registry | |
147 | Client | ------------> | Registry |<------------->| Registry |
148 | | to Registry | | to Registry | |
149 *--------* *------------* *------------*
150 / \ \
151 / \ \
152 / \ \
153 / \ v
154 / \ ...
155 / \
156 / (2). Distrib \
157 / Registry data \
158 / to local data \
159 V store V
160 +----------+ +----------+
161 |Local Data| |Local Data|
162 |Repository| |Repository|
163 +----------+ +----------+
165 Three Registry Provisioning Flows
167 Figure 1
169 A "terminating" SIP Service Provider (SSP) provisions Session
170 Establishment Data or SED into the Registry to be selectively shared
171 with other peer SSPs.
173 SED is typically used by various downstream SIP signaling systems to
174 route a call to the next hop associated with the called domain.
175 These systems typically use a local data store ("Local Data
176 Repository") as their source of session routing information. More
177 specifically, the SED data is the set of parameters that the outgoing
178 signaling path border elements (SBEs) need to initiate the session.
179 See [RFC5486] for more details.
181 A Registry may distribute the provisioned data into local data
182 repositories or may additionally offer a central query resolution
183 service (not shown in the above figure) for query purposes.
185 A key requirement for the SPPF is to be able to accommodate two basic
186 deployment scenarios:
188 1. A resolution system returns a Look-Up Function (LUF) that
189 identifies the target domain to assist in call routing (as
190 described in Section 4.3.3 of [RFC5486]). In this case, the
191 querying entity may use other means to perform the Location
192 Routing Function (LRF) which in turn helps determine the actual
193 location of the Signaling Function in that domain.
195 2. A resolution system returns a Location Routing Function (LRF)
196 that comprises the location (address) of the signaling function
197 in the target domain (as described in [RFC5486]).
199 In terms of framework design, SPPF is agnostic to the substrate
200 protocol. This document includes the specification of the data model
201 and identifies, but does not specify, the means to enable protocol
202 operations within a request and response structure. That aspect of
203 the specification has been delegated to the "protocol" specification
204 for the framework. To encourage interoperability, the framework
205 supports extensibility aspects.
207 In this document, XML schema is used to describe the building blocks
208 of the SPPF and to express the data types, the semantic relationships
209 between the various data types, and the various constraints as a
210 binding construct. However, the "protocol" specification is free to
211 choose any data representation format as long as it meets the
212 requirements laid out in the SPPF XML schema definition. As an
213 example, XML and JSON are two widely used data representation
214 formats.
216 This document is organized as follows:
218 o Section 2 provides the terminology
220 o Section 3 provides an overview of SPPF, including functional
221 entities and data model
223 o Section 4 specifies requirements for SPPF substrate protocols
225 o Section 5 describes the base framework data structures, the
226 generic response types that MUST be supported by a conforming
227 substrate "protocol" specification, and the basic object type most
228 first class objects extend from
230 o Section 6 provides a detailed description of the data model object
231 specifications
233 o Section 7 describes the operations that are supported by the data
234 model
236 o Section 8 defines XML considerations XML parsers must meet to
237 conform to this specification
239 o Sections 9 - 11 discuss security, internationalization and IANA
240 considerations
242 o Section 12 normatively defines the SPPF using its XML Schema
243 Definition.
245 2. Terminology
247 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
248 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
249 "OPTIONAL" in this document are to be interpreted as described in
250 [RFC2119].
252 This document reuses terms from [RFC3261], [RFC5486], use cases and
253 requirements documented in [RFC6461] and the ENUM Validation
254 Architecture [RFC4725].
256 This document defines the following additional terms:
258 SPPF: Session Peering Provisioning Framework, the framework used by
259 a substrate protocol to provision data into a Registry (see arrow
260 labeled "1." in Figure 1 of [RFC6461]). It is the primary scope
261 of this document.
263 Client: In the context of SPPF, this is an application that
264 initiates a provisioning request. It is sometimes referred to as
265 a "Registry client".
267 Server: In the context of SPPF, this is an application that
268 receives a provisioning request and responds accordingly.
270 Registry: The Registry operates a master database of Session
271 Establishment Data for one or more Registrants.
273 Registrant: The definition of a Registrant is based on [RFC4725].
274 It is the end-user, the person or organization that is the
275 "holder" of the Session Establishment Data being provisioned into
276 the Registry by a Registrar. For example, in [RFC6461], a
277 Registrant is pictured as a Service Provider in Figure 2.
279 Within the confines of a Registry, a Registrant is uniquely
280 identified by the 'rant' element.
282 Registrar: The definition of a Registrar is based on [RFC4725]. It
283 is an entity that performs provisioning operations on behalf of a
284 Registrant by interacting with the Registry via SPPF operations.
285 In other words the Registrar is the SPPF Client. The Registrar
286 and Registrant roles are logically separate to allow, but not
287 require, a single Registrar to perform provisioning operations on
288 behalf of more than one Registrant.
290 Peering Organization: A Peering Organization is an entity to which
291 a Registrant's SED Groups are made visible using the operations of
292 SPPF.
294 3. Framework High Level Design
296 This section introduces the structure of the data model and provides
297 the information framework for the SPPF. The data model is defined
298 along with all the objects manipulated by a conforming substrate
299 protocol and their relationships.
301 3.1. Framework Data Model
303 The data model illustrated and described in Figure 2 defines the
304 logical objects and the relationships between these objects supported
305 by SPPF. SPPF defines protocol operations through which an SPPF
306 client populates a Registry with these logical objects. SPPF clients
307 belonging to different Registrars may provision data into the
308 Registry using a conforming substrate protocol that implements these
309 operations
311 The logical structure presented below is consistent with the
312 terminology and requirements defined in [RFC6461].
314 +-------------+ +-----------------+
315 | all object | |Egress Route: |
316 | types | 0..n | rant, |
317 +-------------+ +--| egrRteName, |
318 |0..n / | pref, |
319 | / | regxRewriteRule,|
320 |2 / | ingrSedGrp, |
321 +----------------------+ / | svcs |
322 |Organization: | / +-----------------+
323 | orgId | /
324 +----------------------+ /
325 |0..n /
326 | / ("rant" = Registrant)
327 |A SED Group is /
328 |associated with /
329 |zero or more / +---[abstract]----+
330 |Peering / | SED Record: |
331 |Organizations / | rant, |
332 | / | sedName, |0..n
333 |0..n / | sedFunction, |------|
334 +--------+--------------+0..n 0..n| isInSvc, | |
335 |SED Group: |------------------| ttl | |
336 | rant, | +-----------------+ |
337 | sedGrpName, | ^ Various types |
338 | isInSvc, | | of SED Records |
339 | sedRecRef, | | |
340 | peeringOrg, | +-----+------------+ |
341 | sourceIdent, | | | | |
342 | priority, | +----+ +-------+ +----+ |
343 | dgName | | URI| | NAPTR | | NS | |
344 +-----------------------+ +----+ +-------+ +----+ |
345 |0..n |
346 | +-----[abstract]------+ |
347 |0..n |Public Identifier: | |
348 +----------------------+0..n 0..n| rant, | |
349 | Dest Group: |--------------| publicIdentifier, | |
350 | rant, | | dgName | |
351 | dgName | | | |
352 +----------------------+ +---------------------+ |
353 ^ Various types |
354 +---------+-------+------+----------+ of Public |
355 | | | | | Identifiers |
356 +------+ +-----+ +-----+ +-----+ +------+ |
357 | URI | | TNP | | TNR | | RN | | TN |-------------|
358 +------+ +-----+ +-----+ +-----+ +------+ 0..n
360 Figure 2
362 The objects and attributes that comprise the data model can be
363 described as follows (objects listed from the bottom up):
365 o Public Identifier:
366 From a broad perspective a public identifier is a well-known
367 attribute that is used as the key to perform resolution lookups.
368 Within the context of SPPF, a public identifier object can be a
369 Telephone Number (TN), a range of Telephone Numbers, a PSTN
370 Routing Number (RN), a TN prefix, or a URI.
372 An SPPF Public Identifier may be a member of zero or more
373 Destination Groups to create logical groupings of Public
374 Identifiers that share a common set of Session Establishment Data
375 (e.g., routes).
377 A TN Public Identifier may optionally be associated with zero or
378 more individual SED Records. This ability for a Public Identifier
379 to be directly associated with a SED Record, as opposed to forcing
380 membership in one or more Destination Groups, supports use cases
381 where the SED Record contains data specifically tailored to an
382 individual TN Public Identifier.
384 o Destination Group:
385 A named logical grouping of zero or more Public Identifiers that
386 can be associated with one or more SED Groups for the purpose of
387 facilitating the management of their common session establishment
388 information.
390 o SED Group:
391 A SED Group contains a set of SED Record references, a set of
392 Destination Group references, and a set of peering organization
393 identifiers. This is used to establish a three part relationships
394 between a set of Public Identifiers, the session establishment
395 information (SED) shared across these Public Identifiers, and the
396 list of peering organizations whose query responses from the
397 resolution system may include the session establishment
398 information contained in a given SED group. In addition, the
399 sourceIdent element within a SED Group, in concert with the set of
400 peering organization identifiers, enables fine-grained source-
401 based routing. For further details about the SED Group and
402 source-based routing, refer to the definitions and descriptions in
403 Section 6.1.
405 o SED Record:
406 A SED Record contains the data that a resolution system returns in
407 response to a successful query for a Public Identifier. SED
408 Records are generally associated with a SED Group when the SED
409 within is not specific to a Public Identifier.
411 To support the use cases defined in [RFC6461], SPPF framework
412 defines three type of SED Records: URIType, NAPTRType, and NSType.
413 These SED Records extend the abstract type SedRecType and inherit
414 the common attribute 'priority' that is meant for setting
415 precedence across the SED records defined within a SED Group in a
416 protocol agnostic fashion.
418 o Egress Route:
419 In a high-availability environment, the originating SSP likely has
420 more than one egress paths to the ingress SBE of the target SSP.
421 The Egress Route allows the originating SSP to choose a specific
422 egress SBE to be associated with the target ingress SBE. the
423 'svcs' element specifies ENUM services ((e.g.,E2U+pstn:sip+sip)
424 that are used to identify the SED records associated with the SED
425 Group that will be modified by the originating SSP.
427 o Organization:
428 An Organization is an entity that may fulfill any combination of
429 three roles: Registrant, Registrar, and Peering Organization. All
430 objects in SPPF are associated with two organization identifiers
431 to identify each object's Registrant and Registrar. A SED Group
432 object is also associated with a set of zero or more organization
433 identifiers that identify the peering organization(s) whose
434 resolution query responses may include the session establishment
435 information (SED) defined in the SED Records within that SED
436 Group. A peering organization is an entity that the Registrant
437 intends to share the SED data with.
439 3.2. Time Value
441 Some request and response messages in SPPF include time value(s)
442 defined as type xs:dateTime, a built-in W3C XML Schema Datatype. Use
443 of unqualified local time value is disallowed as it can lead to
444 interoperability issues. The value of a time attribute MUST be
445 expressed in Coordinated Universal Time (UTC) format without the
446 timezone digits.
448 "2010-05-30T09:30:10Z" is an example of an acceptable time value for
449 use in SPPF messages. "2010-05-30T06:30:10+3:00" is a valid UTC
450 time, but MUST NOT be used in SPPF messages.
452 3.3. Extensibility
454 The framework contains various points of extensibility in form of the
455 "ext" elements. Extensions used beyond the scope of private SPPF
456 installations need to be documented in an RFC, and the first such
457 extension is expected to define an IANA registry, holding a list of
458 documented extensions.
460 4. Transport Substrate Protocol Requirements
462 This section provides requirements for substrate protocols suitable
463 as "transports" for SPPF. More specifically, this section specifies
464 the services, features, and assumptions that SPPF framework delegates
465 to the chosen substrate and envelope technologies.
467 4.1. Mandatory Substrate
469 None of the existing transport protocols carried directly over IP,
470 appearing as "Protocol" in the IPv4 headers, of "Next Header" in the
471 IPv6 headers, meet the requirements for a "transport" listed in this
472 section.
474 Therefore, one choice of "transport" has been provided in the SPP
475 Protocol over SOAP document [I-D.ietf-drinks-spp-protocol-over-soap],
476 using SOAP as the substrate. To encourage interoperability, the SPPF
477 server MUST provide support for this protocol. With time, it is
478 possible that other choices may surface that agree with the
479 requirements discussed above.
481 4.2. Connection Oriented
483 The SPPF follows a model where a client establishes a connection to a
484 server in order to further exchange SPPF messages over such a point-
485 to-point connection. A substrate protocol for SPPF will therefore be
486 connection oriented.
488 4.3. Request and Response Model
490 Provisioning operations in SPPF follow the request-response model,
491 where a client sends a request message to initiate a transaction and
492 the server responds with a response. Multiple subsequent request-
493 response exchanges MAY be performed over a single persistent
494 connection.
496 Therefore, a substrate protocol for SPPF will follow the request-
497 response model by ensuring a response to be sent to the request
498 initiator.
500 4.4. Connection Lifetime
502 Some use cases involve provisioning a single request to a network
503 element. Connections supporting such provisioning requests might be
504 short-lived, and may be established only on demand, for the duration
505 of a few seconds. Other use cases involve either provisioning a
506 large dataset, or a constant stream of small updates, either of which
507 would likely require long-lived connections, spanning multiple hours
508 or even days.
510 Therefore, a protocol suitable for SPPF SHOULD be able to support
511 both short-lived as well as long-lived connections.
513 4.5. Authentication
515 All SPPF objects are associated with a Registrant identifier. An
516 SPPF Client provisions SPPF objects on behalf of Registrants. An
517 authenticated SPP Client is a Registrar. Therefore, the SPPF
518 substrate protocol MUST provide means for an SPPF server to
519 authenticate an SPPF Client.
521 4.6. Authorization
523 After successful authentication of the SPPF client as a Registrar the
524 Registry performs authorization checks to determine if the Registrar
525 is authorized to act on behalf of the Registrant whose identifier is
526 included in the SPPF request. Refer to Section 9 for further
527 guidance.
529 4.7. Confidentiality and Integrity
531 SPPF objects that the Registry manages can be private in nature.
532 Therefore, the substrate protocol MUST provide means for data
533 integrity protection.
535 If the data is compromised in-flight between the SPPF client and
536 Registry, it will seriously affect the stability and integrity of the
537 system. Therefore, the substrate protocol MUST provide means for
538 data integrity protection.
540 4.8. Near Real Time
542 Many use cases require near real-time responses from the server (in
543 the range of a few multiples of round-trip-time between server and
544 client). Therefore, a DRINKS substrate protocol MUST support near
545 real-time response to requests submitted by the client.
547 4.9. Request and Response Sizes
549 Use of SPPF may involve simple updates that may consist of small
550 number of bytes, such as, update of a single public identifier.
551 Other provisioning operations may constitute large dataset as in
552 adding millions of records to a Registry. As a result, a suitable
553 substrate protocol for SPPF SHOULD accommodate datasets of various
554 sizes.
556 4.10. Request and Response Correlation
558 A substrate protocol suitable for SPPF MUST allow responses to be
559 correlated with requests.
561 4.11. Request Acknowledgement
563 Data transported in the SPPF is likely crucial for the operation of
564 the communication network that is being provisioned. An SPPF client
565 responsible for provisioning SED to the Registry has a need to know
566 if the submitted requests have been processed correctly.
568 Failed transactions can lead to situations where a subset of public
569 identifiers or even SSPs might not be reachable, or the provisioning
570 state of the network is inconsistent.
572 Therefore, a substrate protocol for SPPF MUST provide a response for
573 each request, so that a client can identify whether a request
574 succeeded or failed.
576 5. Base Framework Data Structures and Response Codes
578 SPPF contains some common data structures for most of the supported
579 object types. This section describes these common data structures.
581 5.1. Basic Object Type and Organization Identifiers
583 All first class objects extend the type BasicObjType. It consists of
584 the Registrant organization, the Registrar organization, the date and
585 time of object creation, and the last date and time the object was
586 modified. The Registry MUST store the date and time of the object
587 creation and modification, if applicable, for all Get operations (see
588 Section 7). If the client passed in either date and time values, the
589 Registry MUST ignore it. The Registrar performs the SPPF operations
590 on behalf of the Registrant, the organization that owns the object.
592
593
594
595
596
597
598
599
600
602 The identifiers used for Registrants (rant) and Registrars (rar) are
603 instances of OrgIdType. The OrgIdType is defined as a string and all
604 OrgIdType instances MUST follow the textual convention:
605 "namespace:value" (for example "iana-en:32473"). Specifically:
607 Strings used as OrgIdType Namespace identifiers MUST conform to the
608 following syntax in the Augmented Backus-Naur Form (ABNF) [RFC5234]
610 namespace = ALPHA * (ALPHA/DIGIT/"-")
612 See Section 11 for the corresponding IANA Registry definition.
614 5.2. Various Object Key Types
616 The SPPF data model contains various object relationships. In some
617 cases, these object relationships are established by embedding the
618 unique identity of the related object inside the relating object.
619 Note that an object's unique identity is required to Delete or Get
620 the details of an object. The following sub-sections normatively
621 define the various object keys in SPPF and the attributes of those
622 keys.
624 "Name" attributes that are used as components of object key types
625 MUST be compared unsing the toCasefold() function, as specified in
626 Section 3.13 of [Unicode6.1] (or a newer version of Unicode). This
627 function performs case-insensitive comparisons.
629 5.2.1. Generic Object Key Type
631 Most objects in SPPF are uniquely identified by an object key that
632 has the object's name, object's type and its Registrant's
633 organization ID as its attributes. The abstract type called
634 ObjKeyType is where this unique identity is housed. Any concrete
635 representation of the ObjKeyType MUST contain the following:
637 Object Name: The name of the object.
639 Registrant Id: The unique organization ID that identifies the
640 Registrant.
642 Type: The value that represents the type of SPPF object. This is
643 required as different types of objects in SPPF, that belong to the
644 same Registrant, can have the same name.
646 The structure of abstract ObjKeyType is as follows:
648
649
650
651 ---- Generic type that represents the
652 key for various objects in SPPF. ----
653
654
655
657 5.2.2. Derived Object Key Types
659 The SPPF data model contains certain objects that are uniquely
660 identified by attributes, different from or in addition to, the
661 attributes in the generic object key described in previous section.
662 These kind of object keys are derived from the abstract ObjKeyType
663 and defined in their own abstract key types. Because these object
664 key types are abstract, they MUST be specified in a concrete form in
665 any SPPF conforming substrate protocol specification. These are used
666 in Delete and Get operations, and may also be used in Accept and
667 Reject operations.
669 Following are the derived object keys in SPPF data model:
671 o SedGrpOfferKeyType: This uniquely identifies an SED Group object
672 offer. This key type extends from ObjKeyType and MUST also have
673 the organization ID of the Registrant to whom the object is being
674 offered, as one of its attributes. In addition to the Delete and
675 Get operations, these key types are used in Accept and Reject
676 operations on an SED Group Offer object. The structure of
677 abstract SedGrpOfferKeyType is as follows:
679
681
682
683
684
685 ---- Generic type that represents
686 the key for an object offer. ----
687
688
689
690
691
693 A SED Group Offer object MUST use SedGrpOfferKeyType. Refer to
694 Section 6.5 for a description of the SED Group Offer object.
696 o PubIdKeyType: This uniquely identifies a Public Identity object.
697 This key type extends from the abstract ObjKeyType. Any concrete
698 definition of PubIdKeyType MUST contain the elements that identify
699 the value and type of Public Identity and also contain the
700 organization ID of the Registrant that is the owner of the Public
701 Identity object. A Public Identity object in SPPF is uniquely
702 identified by the Registrant's organization ID, the value of the
703 public identity, and the type of the public identity object.
704 Consequently, any concrete representation of the PubIdKeyType MUST
705 contain the following attributes:
707 * Registrant Id: The unique organization ID that identifies the
708 Registrant.
710 * Value: The value of the Public Identity.
712 * Type: The type of the Public Identity Object.
714 The PubIdKeyType is used in Delete and Get operations on a Public
715 Identifier object.
717 o The structure of abstract PubIdKeyType is as follows:
719
720
721
722
723
724 ---- Generic type that represents the key for a Pub Id. ----
725
726
727
728
729
731 A Public Identity object MUST use attributes of PubIdKeyType for its
732 unique identification . Refer to Section 6 for a description of
733 Public Identity object.
735 5.3. Response Message Types
737 The following table contains the list of response types a "transport"
738 definition for a substrate protocol MUST define. An SPPF server MUST
739 implement all of the following at minimum.
741 +---------------------+---------------------------------------------+
742 | Response Type | Description |
743 +---------------------+---------------------------------------------+
744 | Request Succeeded | A given request succeeded. |
745 | | |
746 | Request syntax | The syntax of a given request was found |
747 | invalid | invalid. |
748 | | |
749 | Request too large | The count of entities in the request is |
750 | | larger than the server is willing or able |
751 | | to process. |
752 | | |
753 | Version not | The server does not support the version of |
754 | supported | the SPPF protocol specified in the request. |
755 | | |
756 | Command invalid | The operation and/or command being |
757 | | requested by the client is invalid and/or |
758 | | not supported by the server. |
759 | | |
760 | System temporarily | The SPPF server is temporarily not |
761 | unavailable | available to serve the client request. |
762 | | |
763 | Unexpected internal | The SPPF server encountered an unexpected |
764 | system or server | error that prevented the server from |
765 | error. | fulfilling the request. |
766 | | |
767 | Attribute value | The SPPF server encountered an attribute or |
768 | invalid | property in the request that had an |
769 | | invalid/bad value. Optionally, the |
770 | | specification MAY provide a way to indicate |
771 | | the Attribute Name and the Attribute Value |
772 | | to identify the object that was found to be |
773 | | invalid. |
774 | | |
775 | Object does not | An object present in the request does not |
776 | exist | exist on the SPPF server. Optionally, the |
777 | | specification MAY provide a way to indicate |
778 | | the Attribute Name and the Attribute Value |
779 | | that identifies the non-existent object. |
780 | | |
781 | Object status or | The operation requested on an object |
782 | ownership does not | present in the request cannot be performed |
783 | allow for | because the object is in a status that does |
784 | operation. | not allow said operation, or the user |
785 | | requesting the operation is not authorized |
786 | | to perform said operation on the object. |
787 | | Optionally, the specification MAY provide a |
788 | | way to indicate the Attribute Name and the |
789 | | Attribute Value that identifies the object. |
790 +---------------------+---------------------------------------------+
791 Table 1: Response Types
793 When the response messages are "parameterized" with the Attribute
794 Name and Attribute Value, then the use of these parameters MUST
795 adhere to the following rules:
797 o Any value provided for the Attribute Name parameter MUST be an
798 exact XSD element name of the protocol data element that the
799 response message is referring to. For example, valid values for
800 "attribute name" are "dgName", "sedGrpName", "sedRec", etc.
802 o The value for Attribute Value MUST be the value of the data
803 element to which the preceding Attribute Name refers.
805 o Response type "Attribute value invalid" MUST be used whenever an
806 element value does not adhere to data validation rules.
808 o Response types "Attribute value invalid" and "Object does not
809 exist" MUST NOT be used interchangeably. Response type "Object
810 does not exist" MUST be returned by an Update/Del/Accept/Reject
811 operation when the data element(s) used to uniquely identify a
812 pre-existing object do not exist. If the data elements used to
813 uniquely identify an object are malformed, then response type
814 "Attribute value invalid" MUST be returned.
816 6. Framework Data Model Objects
818 This section provides a description of the specification of each
819 supported data model object (the nouns) and identifies the commands
820 (the verbs) that MUST be supported for each data model object.
821 However, the specification of the data structures necessary to
822 support each command is delegated to an SPPF conforming substrate
823 protocol specification.
825 6.1. Destination Group
827 Destination Group represents a logical grouping of Public Identifiers
828 with common session establishment information. The substrate
829 protocol MUST support the ability to Add, Get, and Delete Destination
830 Groups (refer to Section 7 for a generic description of various
831 operations).
833 A Destination Group object MUST be uniquely identified by attributes
834 as defined in the description of "ObjKeyType" in the section "Generic
835 Object Key Type" of this document.
837 The DestGrpType object structure is defined as follows:
839
840
841
842
843
844
845
846
847
849 The DestGrpType object is composed of the following elements:
851 o base: All first class objects extend BasicObjType (see
852 Section 5.1).
854 o dgName: The character string that contains the name of the
855 Destination Group.
857 o ext: Point of extensibility described in Section 3.3.
859 6.2. Public Identifier
861 A Public Identifier is the search key used for locating the session
862 establishment data (SED). In many cases, a Public Identifier is
863 attributed to the end user who has a retail relationship with the
864 service provider or Registrant organization. SPPF supports the
865 notion of the carrier-of-record as defined in [RFC5067]. Therefore,
866 the Registrant under which the Public Identifier is being created can
867 optionally claim to be a carrier-of-record.
869 SPPF identifies three types of Public Identifiers: telephone numbers
870 (TN), routing numbers (RN), and URIs. SPPF provides structures to
871 manage a single TN, a contiguous range of TNs, and a TN prefix. The
872 substrate protocol MUST support the ability to Add, Get, and Delete
873 Public Identifiers (refer to Section 7 for a generic description of
874 various operations).
876 A Public Identity object MUST be uniquely identified by attributes as
877 defined in the description of "PubIdKeyType" in Section 5.2.2.
879 The abstract XML schema type definition PubIdType is a generalization
880 for the concrete Public Identifier schema types. The PubIdType
881 element 'dgName' represents the name of a destination group that a
882 given Public Identifier may be a member of. Note that this element
883 may be present multiple times so that a given Public Identifier may
884 be a member of multiple destination groups. The PubIdType object
885 structure is defined as follows:
887
888
889
890
891
893
894
895
896
898 A Public Identifier may be a member of zero or more Destination
899 Groups. When a Public Identifier is a member of a Destination Group,
900 it is intended to be associated with SED through the SED Group(s)
901 that are associated with the Destination Group. When a Public
902 Identifier is not member of any Destination Group, it is intended to
903 be associated with SED through the SED Records that are directly
904 associated with the Public Identifier.
906 A telephone number is provisioned using the TNType, an extension of
907 PubIdType. Each TNType object is uniquely identified by the
908 combination of its value contained within the element, and its
909 Registrant ID. TNType is defined as follows:
911
912
913
914
915
916
917
919
920
921
922
924
925
926
927
928
929
930
932
933
934
935
936
937
939 TNType consists of the following attributes:
941 o tn: Telephone number to be added to the Registry.
943 o sedRecRef: Optional reference to SED records that are directly
944 associated with the TN Public Identifier. Following the SPPF data
945 model, the SED record could be a protocol agnostic URIType or
946 another type.
948 o corInfo: corInfo is an optional parameter of type CORInfoType that
949 allows the Registrant organization to set forth a claim to be the
950 carrier-of-record (see [RFC5067]). This is done by setting the
951 value of the element of the CORInfoType object
952 structure to "true". The other two parameters of the CORInfoType,
953 and are set by the Registry to describe the
954 outcome of the carrier-of-record claim by the Registrant. In
955 general, inclusion of parameter is useful if the
956 Registry has the authority information, such as, the number
957 portability data, etc., in order to qualify whether the Registrant
958 claim can be satisfied. If the carrier-of-record claim disagrees
959 with the authority data in the Registry, whether a TN Add
960 operation fails or not is a matter of policy and is beyond the
961 scope of this document.
963 A routing number is provisioned using the RNType, an extension of
964 PubIDType. The Registrant organization can add the RN and associate
965 it with the appropriate destination group(s) to share the route
966 information. This allows SSPs to use the RN search key to derive the
967 ingress routes for session establishment at the runtime resolution
968 process (see [RFC6116]. Each RNType object is uniquely identified by
969 the combination of its value inside the element, and its
970 Registrant ID. RNType is defined as follows:
972
973
974
975
976
977
978
979
980
981
983 RNType has the following attributes:
985 o rn: Routing Number used as the search key.
987 o corInfo: corInfo is an optional parameter of type CORInfoType that
988 allows the Registrant organization to set forth a claim to be the
989 carrier-of-record (see [RFC5067])
991 TNRType structure is used to provision a contiguous range of
992 telephone numbers. The object definition requires a starting TN and
993 an ending TN that together define the span of the TN range, including
994 the starting and ending TN. Use of TNRType is particularly useful
995 when expressing a TN range that does not include all the TNs within a
996 TN block or prefix. The TNRType definition accommodates the open
997 number plan as well such that the TNs that fall between the start and
998 end TN range may include TNs with different length variance. Whether
999 the Registry can accommodate the open number plan semantics is a
1000 matter of policy and is beyond the scope of this document. Each
1001 TNRType object is uniquely identified by the combination of its value
1002 that in turn is a combination of the and elements,
1003 and its Registrant ID. The TNRType object structure definition is as
1004 follows:
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1017
1018
1019
1020
1021
1022
1024 TNRType has the following attributes:
1026 o startTn: Starting TN in the TN range
1028 o endTn: The last TN in the TN range
1030 o corInfo: corInfo is an optional parameter of type CORInfoType that
1031 allows the Registrant organization to set forth a claim to be the
1032 carrier-of-record (see [RFC5067])
1034 In some cases, it is useful to describe a set of TNs with the help of
1035 the first few digits of the telephone number, also referred to as the
1036 telephone number prefix or a block. A given TN prefix may include
1037 TNs with different length variance in support of the open number
1038 plan. Once again, whether the Registry supports the open number plan
1039 semantics is a matter of policy and it is beyond the scope of this
1040 document. The TNPType data structure is used to provision a TN
1041 prefix. Each TNPType object is uniquely identified by the
1042 combination of its value in the element, and its
1043 Registrant ID. TNPType is defined as follows:
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1056 TNPType consists of the following attributes:
1058 o tnPrefix: The telephone number prefix
1060 o corInfo: corInfo is an optional parameter of type CORInfoType that
1061 allows the Registrant organization to set forth a claim to be the
1062 carrier-of-record (see [RFC5067])
1064 In some cases, a Public Identifier may be a URI, such as an email
1065 address. The URIPubIdType object is comprised of the data element
1066 necessary to house such Public Identifiers. Each URIPubIdType object
1067 is uniquely identified by the combination of its value in the
1068 element, and its Registrant ID. URIPubIdType is defined as follows:
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1081 URIPubIdType consists of the following attributes:
1083 o uri: The value that acts as Public Identifier.
1085 o ext: Point of extensibility described in Section 3.3.
1087 6.3. SED Group
1089 SED Group is a grouping of one or more Destination Group, the common
1090 SED Records, and the list of peer organizations with access to the
1091 SED Records associated with a given SED Group. It is this indirect
1092 linking of public identifiers to their Session Establishment Data
1093 that significantly improves the scalability and manageability of the
1094 peering data. Additions and changes to SED information are reduced
1095 to a single operation on a SED Group or SED Record, rather than
1096 millions of data updates to individual public identifier records that
1097 individually contain their peering data. The substrate protocol MUST
1098 support the ability to Add, Get, and Delete SED Groups (refer to
1099 Section 7 for a generic description of various operations).
1101 A SED Group object MUST be uniquely identified by attributes as
1102 defined in the description of "ObjKeyType" in the section "Generic
1103 Object Key Type" of this document.
1105 The SedGrpType object structure is defined as follows:
1107
1108
1109
1110
1111
1112
1114
1116
1118
1120
1121
1122
1123
1124
1125
1126
1128
1129
1130
1131
1132
1133
1134
1136 The SedGrpType object is composed of the following elements:
1138 o base: All first class objects extend BasicObjType (see
1139 Section 5.1).
1141 o sedGrpName: The character string that contains the name of the SED
1142 Group. It uniquely identifies this object within the context of
1143 the Registrant ID (a child element of the base element as
1144 described above).
1146 o sedRecRef: Set of zero or more objects of type SedRecRefType that
1147 house the unique keys of the SED Records (containing the session
1148 establishment data) that the SedGrpType object refers to and their
1149 relative priority within the context of this SED Group.
1151 o dgName: Set of zero or more names of DestGrpType object instances.
1152 Each dgName name, in association with this SED Group's Registrant
1153 ID, uniquely identifies a DestGrpType object instance whose
1154 associated public identifiers are reachable using the session
1155 establishment information housed in this SED Group. An intended
1156 side effect of this is that a SED Group cannot provide session
1157 establishment information for a Destination Group belonging to
1158 another Registrant.
1160 o peeringOrg: Set of zero or more peering organization IDs that have
1161 accepted an offer to receive this SED Group's information. Note
1162 that this identifier "peeringOrg" is an instance of OrgIdType.
1163 The set of peering organizations in this list is not directly
1164 settable or modifiable using the addSedGrpsRqst operation. This
1165 set is instead controlled using the SED offer and accept
1166 operations.
1168 o sourceIdent: Set of zero or more SourceIdentType object instances.
1169 These objects, described further below, house the source
1170 identification schemes and identifiers that are applied at
1171 resolution time as part of source-based routing algorithms for the
1172 SED Group.
1174 o isInSvc: A boolean element that defines whether this SED Group is
1175 in service. The session establishment information contained in a
1176 SED Group that is in service is a candidate for inclusion in
1177 resolution responses for public identities residing in the
1178 Destination Group associated with this SED Group. The session
1179 establishment information contained in a SED Group that is not in
1180 service is not a candidate for inclusion in resolution responses.
1182 o priority: Priority value that can be used to provide a relative
1183 value weighting of one SED Group over another. The manner in
1184 which this value is used, perhaps in conjunction with other
1185 factors, is a matter of policy.
1187 o ext: Point of extensibility described in Section 3.3.
1189 As described above, the SED Group contains a set of references to SED
1190 record objects. A SED record object is based on an abstract type:
1191 SedRecType. The concrete types that use SedRecType as an extension
1192 base are NAPTRType, NSType, and URIType. The definitions of these
1193 types are included the SED Record section of this document.
1195 The SedGrpType object provides support for source-based routing via
1196 the peeringOrg data element and more granular source base routing via
1197 the source identity element. The source identity element provides
1198 the ability to specify zero or more of the following in association
1199 with a given SED Group: a regular expression that is matched against
1200 the resolution client IP address, a regular expression that is
1201 matched against the root domain name(s), and/or a regular expression
1202 that is matched against the calling party URI(s). The result will be
1203 that, after identifying the visible SED Groups whose associated
1204 Destination Group(s) contain the lookup key being queried and whose
1205 peeringOrg list contains the querying organization's organization ID,
1206 the resolution server will evaluate the characteristics of the Source
1207 URI, and Source IP address, and root domain of the lookup key being
1208 queried. The resolution server then compares these criteria against
1209 the source identity criteria associated with the SED Groups. The
1210 session establishment information contained in SED Groups that have
1211 source-based routing criteria will only be included in the resolution
1212 response if one or more of the criteria matches the source criteria
1213 from the resolution request. The Source Identity data element is of
1214 type SourceIdentType, whose structure is defined as follows:
1216
1217
1218
1219
1221
1222
1223
1225
1226
1227
1228
1229
1230
1231
1233 The SourceIdentType object is composed of the following data
1234 elements:
1236 o sourceIdentScheme: The source identification scheme that this
1237 source identification criteria applies to and that the associated
1238 sourceIdentRegex should be matched against.
1240 o sourceIdentRegex: The regular expression that should be used to
1241 test for a match against the portion of the resolution request
1242 that is dictated by the associated sourceIdentScheme.
1244 o ext: Point of extensibility described in Section 3.3.
1246 6.4. SED Record
1248 SED Group represents a combined grouping of SED Records that define
1249 session establishment information. However, SED Records need not be
1250 created to just serve a single SED Group. SED Records can be created
1251 and managed to serve multiple SED Groups. As a result, a change for
1252 example to the properties of a network node used for multiple routes,
1253 would necessitate just a single update operation to change the
1254 properties of that node. The change would then be reflected in all
1255 the SED Groups whose SED record set contains a reference to that
1256 node. The substrate protocol MUST support the ability to Add, Get,
1257 and Delete SED Records (refer to Section 7 for a generic description
1258 of various operations).
1260 A SED Record object MUST be uniquely identified by attributes as
1261 defined in the description of "ObjKeyType" in the section "Generic
1262 Object Key Type" of this document.
1264 The SedRecType object structure is defined as follows:
1266
1267
1268
1269
1270
1271
1273
1274
1275
1276
1277
1278
1280
1281
1282
1283
1284
1285
1287 The SedRecType object is composed of the following elements:
1289 o base: All first class objects extend BasicObjType (see
1290 Section 5.1).
1292 o sedName: The character string that contains the name of the SED
1293 Record. It uniquely identifies this object within the context of
1294 the Registrant ID (a child element of the base element as
1295 described above).
1297 o sedFunction: As described in [RFC6461], SED or Session
1298 Establishment Data falls primarily into one of two categories or
1299 functions, LUF and LRF. To remove any ambiguity as to the
1300 function a SED record is intended to provide, this optional
1301 element allows the provisioning party to make its intentions
1302 explicit.
1304 o isInSvc: A boolean element that defines whether this SED Record is
1305 in service or not. The session establishment information
1306 contained in a SED Record which is in service is a candidate for
1307 inclusion in resolution responses for Telephone Numbers that are
1308 either directly associated to this SED Record, or for Public
1309 Identities residing in a Destination Group that is associated to a
1310 SED Group which in turn has an association to this SED Record.
1312 o ttl: Number of seconds that an addressing server may cache a
1313 particular SED Record.
1315 As described above, SED records are based on an abstract type:
1316 SedRecType. The concrete types that use SedRecType as an extension
1317 base are NAPTRType, NSType, and URIType. The definitions of these
1318 types are included below. The NAPTRType object is comprised of the
1319 data elements necessary for a NAPTR (see [RFC3403]that contains
1320 routing information for a SED Group. The NSType object is comprised
1321 of the data elements necessary for a DNS name server that points to
1322 another DNS server that contains the desired routing information.
1323 The NSType is relevant only when the resolution protocol is ENUM (see
1324 [RFC6116]). The URIType object is comprised of the data elements
1325 necessary to house a URI.
1327 The data provisioned in a Registry can be leveraged for many purposes
1328 and queried using various protocols including SIP, ENUM and others.
1329 As such, the resolution data represented by the SED records must be
1330 in a form suitable for transport using one of these protocols. In
1331 the NAPTRType for example, if the URI is associated with a
1332 destination group, the user part of the replacement string that
1333 may require the Public Identifier cannot be preset. As a SIP
1334 Redirect, the resolution server will apply pattern on the input
1335 Public Identifier in the query and process the replacement string by
1336 substituting any back reference(s) in the to arrive at the
1337 final URI that is returned in the SIP Contact header. For an ENUM
1338 query, the resolution server will simply return the values of the
1339 and members of the URI.
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1356
1357
1358
1359
1360
1361
1364
1365
1366
1367
1368
1370
1371
1372
1373
1374
1375
1376
1378
1379
1380
1381
1382
1383
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1397
1398
1399
1400
1401
1402
1404 The NAPTRType object is composed of the following elements:
1406 o order: Order value in an ENUM NAPTR, relative to other NAPTRType
1407 objects in the same SED Group.
1409 o svcs: ENUM service(s) that are served by the SBE. This field's
1410 value must be of the form specified in [RFC6116] (e.g.,
1411 E2U+pstn:sip+sip). The allowable values are a matter of policy
1412 and not limited by this protocol.
1414 o regx: NAPTR's regular expression field. If this is not included
1415 then the repl field must be included.
1417 o repl: NAPTR replacement field, should only be provided if the regx
1418 field is not provided, otherwise the server will ignore it
1420 o ext: Point of extensibility described in Section 3.3.
1422 The NSType object is composed of the following elements:
1424 o hostName: Root-relative host name of the name server.
1426 o ipAddr: Zero or more objects of type IpAddrType. Each object
1427 holds an IP Address and the IP Address type ("IPv4" or "IPv6").
1429 o ext: Point of extensibility described in Section 3.3.
1431 The URIType object is composed of the following elements:
1433 o ere: The POSIX Extended Regular Expression (ere) as defined in
1434 [RFC3986].
1436 o uri: the URI as defined in [RFC3986]. In some cases, this will
1437 serve as the replacement string and it will be left to the
1438 resolution server to arrive at the final usable URI.
1440 6.5. SED Group Offer
1442 The list of peer organizations whose resolution responses can include
1443 the session establishment information contained in a given SED Group
1444 is controlled by the organization to which a SED Group object belongs
1445 (its Registrant), and the peer organization that submits resolution
1446 requests (a data recipient, also known as a peering organization).
1447 The Registrant offers access to a SED Group by submitting a SED Group
1448 Offer. The data recipient can then accept or reject that offer. Not
1449 until access to a SED Group has been offered and accepted will the
1450 data recipient's organization ID be included in the peeringOrg list
1451 in a SED Group object, and that SED Group's peering information
1452 become a candidate for inclusion in the responses to the resolution
1453 requests submitted by that data recipient. The substrate protocol
1454 MUST support the ability to Add, Get, Delete, Accept and Reject SED
1455 Group Offers (refer to Section 7 for a generic description of various
1456 operations).
1458 A SED Group Offer object MUST be uniquely identified by attributes as
1459 defined in the description of "SedGrpOfferKeyType" in the section
1460 "Derived Object Key Types" of this document.
1462 The SedGrpOfferType object structure is defined as follows:
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1478
1479
1480
1481 -- Generic type that represents the key for a SED group offer. Must
1482 be defined in concrete form in the substrate specification. --
1483
1484
1485
1487
1488
1489
1490
1491
1492
1494 The SedGrpOfferType object is composed of the following elements:
1496 o base: All first class objects extend BasicObjType (see
1497 Section 5.1).
1499 o sedGrpOfferKey: The object that identifies the SED that is or has
1500 been offered and the organization that it is or has been offered
1501 to.
1503 o status: The status of the offer, offered or accepted. The server
1504 controls the status. It is automatically set to "offered"
1505 whenever a new SED Group Offer is added, and is automatically set
1506 to "accepted" if and when that offer is accepted. The value of
1507 the element is ignored when passed in by the client.
1509 o offerDateTime: Date and time in UTC when the SED Group Offer was
1510 added.
1512 o acceptDateTime: Date and time in UTC when the SED Group Offer was
1513 accepted.
1515 6.6. Egress Route
1517 In a high-availability environment, the originating SSP likely has
1518 more than one egress path to the ingress SBE of the target SSP. If
1519 the originating SSP wants to exercise greater control and choose a
1520 specific egress SBE to be associated to the target ingress SBE, it
1521 can do so using the EgrRteType object.
1523 An Egress Route object MUST be uniquely identified by attributes as
1524 defined in the description of "ObjKeyType" in the section "Generic
1525 Object Key Type" of this document.
1527 Assume that the target SSP has offered as part of its session
1528 establishment data, to share one or more ingress routes and that the
1529 originating SSP has accepted the offer. In order to add the egress
1530 route to the Registry, the originating SSP uses a valid regular
1531 expression to rewrite the ingress route in order to include the
1532 egress SBE information. Also, more than one egress route can be
1533 associated with a given ingress route in support of fault-tolerant
1534 configurations. The supporting SPPF structure provides a way to
1535 include route precedence information to help manage traffic to more
1536 than one outbound egress SBE.
1538 The substrate protocol MUST support the ability to Add, Get, and
1539 Delete Egress Routes (refer to Section 7 for a generic description of
1540 various operations). The EgrRteType object structure is defined as
1541 follows:
1543
1544
1545
1546
1547
1548
1549
1550
1552
1553
1554
1555
1556
1557
1559 The EgrRteType object is composed of the following elements:
1561 o base: All first class objects extend BasicObjType (see
1562 Section 5.1).
1564 o egrRteName: The name of the egress route.
1566 o pref: The preference of this egress route relative to other egress
1567 routes that may get selected when responding to a resolution
1568 request.
1570 o regxRewriteRule: The regular expression re-write rule that should
1571 be applied to the regular expression of the ingress NAPTR(s) that
1572 belong to the ingress route.
1574 o ingrSedGrp: The ingress SED group that the egress route should be
1575 used for.
1577 o svcs: ENUM service(s) that are served by an Egress Route. This
1578 element is used to identify the ingress NAPTRs associated with the
1579 SED Group to which an Egress Route's regxRewriteRule should be
1580 applied. If no ENUM service(s) are associated with an Egress
1581 Route, then the Egress Route's regxRewriteRule should be applied
1582 to all the NAPTRs associated with the SED Group. This field's
1583 value must be of the form specified in [RFC6116] (e.g.,
1584 E2U+pstn:sip+sip). The allowable values are a matter of policy
1585 and not limited by this protocol.
1587 o ext: Point of extensibility described in Section 3.3.
1589 7. Framework Operations
1591 In addition to the operation-specific object types, all operations
1592 MAY specify the minor version of the protocol that when used in
1593 conjunction with the major version (which can be for instance
1594 specified in the protocol namespace) can serve to identify the
1595 version of the SPPF protocol that the client is using. If the minor
1596 version is not specified, the latest minor version supported by the
1597 SPPF server for the given major version will be used. Additionally,
1598 operations that may potentially modify persistent protocol objects
1599 SHOULD include a transaction ID as well.
1601 7.1. Add Operation
1603 Any conforming substrate protocol specification MUST provide a
1604 definition for the operation that adds one or more SPPF objects into
1605 the Registry. If the object, as identified by the request attributes
1606 that form part of the object's key, does not exist, then the Registry
1607 MUST create the object. If the object does exist, then the Registry
1608 MUST replace the current properties of the object with the properties
1609 passed in as part of the Add operation.
1611 Note that this effectively allows to modify a pre-existing object.
1613 If the entity that issued the command is not authorized to perform
1614 this operation an appropriate error message MUST be returned from
1615 amongst the response messages defined in the "Response Message Types"
1616 section of the document.
1618 7.2. Delete Operation
1620 Any conforming substrate protocol specification MUST provide a
1621 definition for the operation that deletes one or more SPPF objects
1622 from the Registry using the object's key.
1624 If the entity that issued the command is not authorized to perform
1625 this operation an appropriate error message MUST be returned from
1626 amongst the response messages defined in "Response Message Types"
1627 section of the document.
1629 When an object is deleted, any references to that object must of
1630 course also be removed as the SPPF server implementation fulfills the
1631 deletion request. Furthermore, the deletion of a composite object
1632 must also result in the deletion of the objects it contains. As a
1633 result, the following rules apply to the deletion of SPPF object
1634 types:
1636 o Destination Groups: When a destination group is deleted any
1637 references between that destination group and any SED group must
1638 be automatically removed by the SPPF implementation as part of
1639 fulfilling the deletion request. Similarly, any references
1640 between that destination group and any Public Identifier must be
1641 removed by the SPPF implementation.
1643 o SED Groups: When a SED group is deleted any references between
1644 that SED group and any destination group must be automatically
1645 removed by the SPPF implementation as part of fulfilling the
1646 deletion request. Similarly any references between that SED group
1647 and any SED records must be removed by the SPPF implementation as
1648 part of fulfilling the deletion request. Furthermore, SED group
1649 offers relating to that SED group must also be deleted.
1651 o SED Records: When a SED record is deleted any references between
1652 that SED record and any SED group must be removed by the SPPF
1653 implementation as part of fulfilling the deletion request.
1654 Similarly, any reference between that SED record and any Public
1655 Identifier must be removed by the SPPF implementation.
1657 o Public Identifiers: When a public identifier is deleted any
1658 references between that public identifier and any referenced
1659 destination group must be removed by the SPPF implementation as
1660 part of fulfilling the deletion request. Any references to SED
1661 records associated directly to that Public Identifier must also be
1662 deleted by the SPPF implementation.
1664 Deletes MUST be atomic
1666 7.3. Get Operations
1668 At times, on behalf of the Registrant, the Registrar may need to get
1669 information about SPPF objects that were previously provisioned in
1670 the Registry. A few examples include logging, auditing, and pre-
1671 provisioning dependency checking. This query mechanism is limited to
1672 aid provisioning scenarios and should not be confused with query
1673 protocols provided as part of the resolution system (e.g., ENUM and
1674 SIP).
1676 Any conforming "protocol" specification MUST provide a definition for
1677 the operation that queries the details of one or more SPPF objects
1678 from the Registry using the object's key. If the entity that issued
1679 the command is not authorized to perform this operation an
1680 appropriate error message MUST be returned from amongst the response
1681 messages defined in Section 5.3.
1683 If the response to the Get operation includes object(s) that extend
1684 the BasicObjType, the Registry MUST include the 'cDate' and 'mDate',
1685 if applicable.
1687 7.4. Accept Operations
1689 In SPPF, a SED Group Offer can be accepted or rejected by, or on
1690 behalf of, the Registrant to which the SED Group has been offered
1691 (refer to Section 7 of this document for a description of the SED
1692 Group Offer object). The Accept operation is used to accept the SED
1693 Group Offers. Any conforming substrate protocol specification MUST
1694 provide a definition for the operation to accept SED Group Offers by,
1695 or on behalf of the Registrant, using the SED Group Offer object key.
1697 Not until access to a SED Group has been offered and accepted will
1698 the Registrant's organization ID be included in the peeringOrg list
1699 in that SED Group object, and that SED Group's peering information
1700 become a candidate for inclusion in the responses to the resolution
1701 requests submitted by that Registrant. A SED Group Offer that is in
1702 the "offered" status is accepted by, or on behalf of, the Registrant
1703 to which it has been offered. When the SED Group Offer is accepted
1704 the SED Group Offer is moved to the "accepted" status and adds that
1705 data recipient's organization ID into the list of peerOrgIds for that
1706 SED Group.
1708 If the entity that issued the command is not authorized to perform
1709 this operation an appropriate error message MUST be returned from
1710 amongst the response messages defined in "Response Message Types"
1711 section of the document.
1713 7.5. Reject Operations
1715 In SPPF, a SED Group Offer object can be accepted or rejected by, or
1716 on behalf of, the Registrant to which the SED Group has been offered
1717 (refer "Framework Data Model Objects" section of this document for a
1718 description of the SED Group Offer object). Furthermore, that offer
1719 may be rejected, regardless of whether or not it has been previously
1720 accepted. The Reject operation is used to reject the SED Group
1721 Offer. When the SED Group Offer is rejected that SED Group Offer is
1722 deleted, and, if appropriate, the data recipient's organization ID is
1723 removed from the list of peeringOrg IDs for that SED Group. Any
1724 conforming substrate protocol specification MUST provide a definition
1725 for the operation to reject SED Group Offers by, or on behalf of the
1726 Registrant, using the SED Group Offer object key.
1728 If the entity that issued the command is not authorized to perform
1729 this operation an appropriate error message MUST be returned from
1730 amongst the response messages defined in "Response Message Types"
1731 section of the document.
1733 7.6. Get Server Details Operation
1735 In SPPF, the Get Server Details operation can be used to request
1736 certain details about the SPPF server that include the SPPF server's
1737 current status and the major/minor version of the SPPF protocol
1738 supported by the SPPF server.
1740 Any conforming substrate protocol specification MUST provide a
1741 definition for the operation to request such details from the SPPF
1742 server. If the entity that issued the command is not authorized to
1743 perform this operation an appropriate error message MUST be returned
1744 from amongst the response messages defined in the "Response Message
1745 Types" section of the document.
1747 8. XML Considerations
1749 XML serves as the encoding format for SPPF, allowing complex
1750 hierarchical data to be expressed in a text format that can be read,
1751 saved, and manipulated with both traditional text tools and tools
1752 specific to XML.
1754 XML is case sensitive. Unless stated otherwise, XML specifications
1755 and examples provided in this document MUST be interpreted in the
1756 character case presented to develop a conforming implementation.
1758 This section discusses a small number of XML-related considerations
1759 pertaining to SPPF.
1761 8.1. Namespaces
1763 All SPPF elements are defined in the namespaces in the IANA
1764 Considerations section and in the Formal Framework Specification
1765 section of this document.
1767 8.2. Versioning and Character Encoding
1769 All XML instances SHOULD begin with an declaration to
1770 identify the version of XML that is being used, optionally identify
1771 use of the character encoding used, and optionally provide a hint to
1772 an XML parser that an external schema file is needed to validate the
1773 XML instance.
1775 Conformant XML parsers recognize both UTF-8 (defined in [RFC3629])
1776 and UTF-16 (defined in [RFC2781]); per [RFC2277] UTF-8 is the
1777 RECOMMENDED character encoding for use with SPPF.
1779 Character encodings other than UTF-8 and UTF-16 are allowed by XML.
1780 UTF-8 is the default encoding assumed by XML in the absence of an
1781 "encoding" attribute or a byte order mark (BOM); thus, the "encoding"
1782 attribute in the XML declaration is OPTIONAL if UTF-8 encoding is
1783 used. SPPF clients and servers MUST accept a UTF-8 BOM if present,
1784 though emitting a UTF-8 BOM is NOT RECOMMENDED.
1786 Example XML declarations:
1788
1790 9. Security Considerations
1792 Many SPPF implementations manage data that is considered confidential
1793 and critical. Furthermore, SPPF implementations can support
1794 provisioning activities for multiple Registrars and Registrants. As
1795 a result any SPPF implementation must address the requirements for
1796 confidentiality, authentication, and authorization.
1798 9.1. Confidentiality and Authentication
1800 With respect to confidentiality and authentication, the substrate
1801 protocol requirements section of this document contains security
1802 properties that the substrate protocol must provide so that
1803 authenticated endpoints can exchange data confidentially and with
1804 integrity protection. Refer to that section and
1805 [I-D.ietf-drinks-spp-protocol-over-soap] for the specific solutions
1806 to authentication and confidentiality.
1808 9.2. Authorization
1810 With respect to authorization, the SPPF server implementation must
1811 define and implement a set of authorization rules that precisely
1812 address (1) which Registrars will be authorized to create/modify/
1813 delete each SPPF object type for given Registrant(s) and (2) which
1814 Registrars will be authorized to view/get each SPPF object type for
1815 given Registrant(s). These authorization rules are a matter of
1816 policy and are not specified within the context of SPPF. However,
1817 any SPPF implementation must specify these authorization rules in
1818 order to function in a reliable and safe manner.
1820 9.3. Denial of Service
1822 Guidance on Denial-of-Service (DoS) issues in general is given in
1823 [RFC4732], "Internet Denial of Service Considerations", which also
1824 gives a general vocabulary for describing the DoS issue.
1826 SPPF is a high-level client-server protocol that can be implemented
1827 on lower-level mechanisms such as remote procedure call and web-
1828 service API protocols. As such, it inherits any Denial-of-Service
1829 issues inherent to the specific lower-level mechanism used for any
1830 implementation of SPPF. SPPF also has its own set of higher-level
1831 exposures that are likely to be independent of lower-layer mechanism
1832 choices.
1834 9.3.1. DoS Issues Inherited from Substrate Mechanism
1836 An SPPF implementation is in general dependent on the selection and
1837 implementation of a lower-level substrate protocol and a binding
1838 between that protocol and SPPF. The archetypal SPPF implementation
1839 uses XML [W3C.REC-xml-20081126] representation in a SOAP [SOAPREF]
1840 request/response framework over HTTP ([RFC7230]), and probably also
1841 uses TLS ([RFC5246]) for on-the-wire data integrity and participant
1842 authentication, and might use HTTP Digest authentication ([RFC2609]).
1844 The typical deployment scenario for SPPF is to have servers in a
1845 managed facility, and therefore techniques such as Network Ingress
1846 Filtering ([RFC2609]) are generally applicable. In short, any DoS
1847 mechanism affecting a typical HTTP implementation would affect such
1848 an SPPF implementation, and the mitigation tools for HTTP in general
1849 also therefore apply to SPPF.
1851 SPPF does not directly specify an authentication mechanism, instead
1852 relying on the lower-level substrate protocol to provide for
1853 authentication. In general, authentication is an expensive
1854 operation, and one apparent attack vector is to flood an SPPF server
1855 with repeated requests for authentication, thereby exhausting its
1856 resources. SPPF implementations SHOULD therefore be prepared to
1857 handle authentication floods, perhaps by noting repeated failed login
1858 requests from a given source address and blocking that source
1859 address.
1861 9.3.2. DoS Issues Specific to SPPF
1863 The primary defense mechanism against DoS within SPPF is
1864 authentication. Implementations MUST tightly control access to the
1865 SPPF service, SHOULD implement DoS and other policy control
1866 screening, and MAY employ a variety of policy violation reporting and
1867 response measures such as automatic blocking of specific users and
1868 alerting of operations personnel. In short, the primary SPPF
1869 response to DoS-like activity by a user is to block that user or
1870 subject their actions to additional review.
1872 SPPF allows a client to submit multiple-element or "batch" requests
1873 that may insert or otherwise affect a large amount of data with a
1874 single request. In the simplest case, the server progresses
1875 sequentially through each element in a batch, completing one before
1876 starting the next. Mid-batch failures are handled by stopping the
1877 batch and rolling-back the data store to its pre-request state. This
1878 "stop and roll-back" design provides a DoS opportunity. A hostile
1879 client could repeatedly issue large batch requests with one or more
1880 failing elements, causing the server to repeatedly stop and roll-back
1881 large transactions. The suggested response is to monitor clients for
1882 such failures, and take administrative action (such as blocking the
1883 user) when an excessive number of roll-backs is reported.
1885 An additional suggested response is for an implementer to set their
1886 maximum allowable XML message size, and their maximum allowable batch
1887 size at a level that they feel protects their operational instance,
1888 given the hardware sizing they have in place and the expected load
1889 and size needs that their users expect.
1891 9.4. Information Disclosure
1893 It is not uncommon for the logging systems to document on-the-wire
1894 messages for various purposes, such as, debug, audit, and tracking.
1895 At the minimum, the various support and administration staff will
1896 have access to these logs. Also, if an unprivileged user gains
1897 access to the SPPF deployments and/or support systems, it will have
1898 access to the information that is potentially deemed confidential.
1899 To manage information disclosure concerns beyond the substrate level,
1900 SPPF implementations MAY provide support for encryption at the SPPF
1901 object level.
1903 9.5. Non-repudiation
1905 In some situations, it may be required to protect against denial of
1906 involvement (see [RFC4949]) and tackle non-repudiation concerns in
1907 regards to SPPF messages. This type of protection is useful to
1908 satisfy authenticity concerns related to SPPF messages beyond the
1909 end-to-end connection integrity, confidentiality, and authentication
1910 protection that the substrate layer provides. This is an optional
1911 feature and some SPPF implementations MAY provide support for it.
1913 9.6. Replay Attacks
1915 Anti-replay protection ensures that a given SPPF object replayed at a
1916 later time doesn't affect the integrity of the system. SPPF provides
1917 at least one mechanism to fight against replay attacks. Use of the
1918 optional client transaction identifier allows the SPPF client to
1919 correlate the request message with the response and to be sure that
1920 it is not a replay of a server response from earlier exchanges. Use
1921 of unique values for the client transaction identifier is highly
1922 encouraged to avoid chance matches to a potential replay message.
1924 9.7. Man in the Middle
1926 The SPPF client or Registrar can be a separate entity acting on
1927 behalf of the Registrant in facilitating provisioning transactions to
1928 the Registry. Therefore, even though the substrate layer provides
1929 end-to-end protection for each specific SPPP connection between
1930 client and server, data might be available in clear text before or
1931 after it traverses a SPPP connection. Therefore, a man-in-the-middle
1932 attack by one of the actors is a possibility that could affect the
1933 integrity of the data that belongs to the Registrant and/or expose
1934 peering data to unintended actors.
1936 10. Internationalization Considerations
1938 Character encodings to be used for SPPF elements are described in
1939 Section 8.2. The use of time elements in the protocol is specified
1940 in Section 3.2. Where human-readable messages that are presented to
1941 an end user are used in the protocol, those messages SHOULD be tagged
1942 according to [RFC5646], and the substrate protocol MUST support a
1943 respective mechanism to transmit such tags together with those human-
1944 readable messages.
1946 11. IANA Considerations
1948 11.1. URN Assignments
1950 This document uses URNs to describe XML namespaces and XML schemas
1951 conforming to a Registry mechanism described in [RFC3688].
1953 Two URI assignments are requested.
1955 Registration request for the SPPF XML namespace:
1956 urn:ietf:params:xml:ns:sppf:base:1
1957 Registrant Contact: IESG
1958 XML: None. Namespace URIs do not represent an XML specification.
1960 Registration request for the XML schema:
1961 URI: urn:ietf:params:xml:schema:sppf:1
1962 Registrant Contact: IESG
1963 XML: See the "Formal Specification" section of this document
1964 (Section 12).
1966 11.2. Organization Identifier Namespace Registry
1968 IANA is requested to create and maintain a Registry entitled "SPPF
1969 OrgIdType Namespaces". The formal syntax is described in
1970 Section 5.1.
1972 Assignments consist of the OrgIdType namespace string and the
1973 definition of the associated namespace. This document makes the
1974 following initial assignment for the OrgIdType Namespaces:
1976 OrgIdType namespace string Namespace
1977 -------------------------- ---------
1978 IANA Enterprise Numbers iana-en
1980 Future assignments are to be made through the well-known IANA Policy
1981 "RFC Required" (see section 4.1 of [RFC5226]). Such assignments will
1982 typically be requested when a new namespace for identification of
1983 service providers is defined.
1985 12. Formal Specification
1987 This section provides the draft XML Schema Definition for SPPF
1988 Protocol.
1990
1991
1995
1996
1997 ---- Generic Object key types to be defined by specific
1998 Substrate/Architecture. The types defined here can
1999 be extended by the specific architecture to
2000 define the Object Identifiers ----
2001
2002
2003
2005
2006
2007 ---- Generic type that represents the
2008 key for various objects in SPPF. ----
2009
2010
2011
2013
2014
2015
2016
2017
2018 ---- Generic type that represents
2019 the key for a SED group offer. ----
2020
2021
2022
2023
2024
2026
2027
2028
2029
2030
2031 ----Generic type that
2032 represents the key
2033 for a Pub Id. ----
2034
2035
2036
2037
2038
2040
2041
2042 ---- Object Type Definitions ----
2043
2044
2046
2047
2048
2049
2050
2051
2053
2055
2057
2059
2060
2061
2063
2064
2065
2066
2067
2068
2069
2070
2071
2073
2074
2075
2076
2077
2078
2079
2080
2081
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2211
2212
2213
2214
2215
2216
2217
2218
2219 ---- Abstract Object and Element Type Definitions ----
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2385 13. Acknowledgments
2387 This document is a result of various discussions held in the DRINKS
2388 working group and within the DRINKS protocol design team, with
2389 contributions from the following individuals, in alphabetical order:
2390 Alexander Mayrhofer, David Schwartz, Deborah A Guyton, Lisa
2391 Dusseault, Manjul Maharishi, Mickael Marrache, Otmar Lendl, Richard
2392 Shockey, Samuel Melloul, Sumanth Channabasappa, Syed Ali, Vikas
2393 Bhatia, and Jeremy Barkan.
2395 14. References
2397 14.1. Normative References
2399 [I-D.ietf-drinks-spp-protocol-over-soap]
2400 Cartwright, K., Bhatia, V., Mule, J., and A. Mayrhofer,
2401 "Session Peering Provisioning (SPP) Protocol over SOAP",
2402 draft-ietf-drinks-spp-protocol-over-soap-07 (work in
2403 progress), October 2014.
2405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2406 Requirement Levels", BCP 14, RFC 2119, March 1997.
2408 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
2409 Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277,
2410 January 1998, .
2412 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
2413 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2414 2003, .
2416 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
2417 DOI 10.17487/RFC3688, January 2004,
2418 .
2420 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2421 Resource Identifier (URI): Generic Syntax", STD 66,
2422 RFC 3986, DOI 10.17487/RFC3986, January 2005,
2423 .
2425 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
2426 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
2427 DOI 10.17487/RFC5226, May 2008,
2428 .
2430 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
2431 Specifications: ABNF", STD 68, RFC 5234,
2432 DOI 10.17487/RFC5234, January 2008,
2433 .
2435 [W3C.REC-xml-20081126]
2436 Sperberg-McQueen, C., Yergeau, F., Bray, T., Maler, E.,
2437 and J. Paoli, "Extensible Markup Language (XML) 1.0 (Fifth
2438 Edition)", World Wide Web Consortium Recommendation REC-
2439 xml-20081126, November 2008,
2440 .
2442 14.2. Informative References
2444 [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates
2445 and Service: Schemes", RFC 2609, DOI 10.17487/RFC2609,
2446 June 1999, .
2448 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
2449 10646", RFC 2781, DOI 10.17487/RFC2781, February 2000,
2450 .
2452 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
2453 A., Peterson, J., Sparks, R., Handley, M., and E.
2454 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
2455 DOI 10.17487/RFC3261, June 2002,
2456 .
2458 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
2459 Part Three: The Domain Name System (DNS) Database",
2460 RFC 3403, DOI 10.17487/RFC3403, October 2002,
2461 .
2463 [RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation
2464 Architecture", RFC 4725, DOI 10.17487/RFC4725, November
2465 2006, .
2467 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
2468 Denial-of-Service Considerations", RFC 4732,
2469 DOI 10.17487/RFC4732, December 2006,
2470 .
2472 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
2473 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
2474 .
2476 [RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM
2477 Requirements", RFC 5067, DOI 10.17487/RFC5067, November
2478 2007, .
2480 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
2481 (TLS) Protocol Version 1.2", RFC 5246,
2482 DOI 10.17487/RFC5246, August 2008,
2483 .
2485 [RFC5486] Malas, D., Ed. and D. Meyer, Ed., "Session Peering for
2486 Multimedia Interconnect (SPEERMINT) Terminology",
2487 RFC 5486, DOI 10.17487/RFC5486, March 2009,
2488 .
2490 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
2491 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
2492 September 2009, .
2494 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
2495 Uniform Resource Identifiers (URI) Dynamic Delegation
2496 Discovery System (DDDS) Application (ENUM)", RFC 6116,
2497 DOI 10.17487/RFC6116, March 2011,
2498 .
2500 [RFC6461] Channabasappa, S., Ed., "Data for Reachability of Inter-
2501 /Intra-NetworK SIP (DRINKS) Use Cases and Protocol
2502 Requirements", RFC 6461, DOI 10.17487/RFC6461, January
2503 2012, .
2505 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
2506 Protocol (HTTP/1.1): Message Syntax and Routing",
2507 RFC 7230, DOI 10.17487/RFC7230, June 2014,
2508 .
2510 [SOAPREF] Gudgin, M., Hadley, M., Moreau, J., and H. Nielsen, "SOAP
2511 Version 1.2 Part 1: Messaging Framework", W3C
2512 Recommendation REC-SOAP12-part1-20030624, June 2002.
2514 [Unicode6.1]
2515 The Unicode Consortium, "The Unicode Standard - Version
2516 6.1", Unicode 6.1, January 2012.
2518 Authors' Addresses
2520 Kenneth Cartwright
2521 TNS
2522 1939 Roland Clarke Place
2523 Reston, VA 20191
2524 USA
2526 Email: kcartwright@tnsi.com
2528 Vikas Bhatia
2529 TNS
2530 1939 Roland Clarke Place
2531 Reston, VA 20191
2532 USA
2534 Email: vbhatia@tnsi.com
2535 Syed Wasim Ali
2536 NeuStar
2537 46000 Center Oak Plaza
2538 Sterling, VA 20166
2539 USA
2541 Email: syed.ali@neustar.biz
2543 David Schwartz
2544 XConnect
2545 316 Regents Park Road
2546 London N3 2XJ
2547 United Kingdom
2549 Email: dschwartz@xconnect.net