idnits 2.17.1 draft-ietf-drinks-spprov-10.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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: In some deployments, the SPPP objects that an SPPP registry manages can be private in nature. As a result it MAY NOT be appropriate to for transmission in plain text over a connection to the SPPP registry. Therefore, the transport protocol SHOULD provide means for end-to-end encryption between the SPPP client and server. -- The document date (September 9, 2011) is 4585 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) == Outdated reference: A later version (-07) exists of draft-ietf-drinks-sppp-over-soap-05 ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Downref: Normative reference to an Informational RFC: RFC 5067 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRINKS J-F. Mule 3 Internet-Draft CableLabs 4 Intended status: Standards Track K. Cartwright 5 Expires: March 12, 2012 TNS 6 S. Ali 7 NeuStar 8 A. Mayrhofer 9 enum.at GmbH 10 September 9, 2011 12 Session Peering Provisioning Protocol 13 draft-ietf-drinks-spprov-10 15 Abstract 17 This document defines a protocol for provisioning session 18 establishment data into Session Data Registries and SIP Service 19 Provider data stores. The provisioned data is typically used by 20 various network elements for session peering. 22 This document describes the Session Peering Provisioning Protocol 23 used by clients to provision registries. The document provides a set 24 of guiding principles for the design of this protocol including 25 extensibility and independent transport definitions, a basic data 26 model and an XML Schema Document. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 12, 2012. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3. Protocol High Level Design . . . . . . . . . . . . . . . . . . 9 65 3.1. Protocol Layering . . . . . . . . . . . . . . . . . . . . 9 66 3.2. Protocol Data Model . . . . . . . . . . . . . . . . . . . 10 67 3.3. Time Value . . . . . . . . . . . . . . . . . . . . . . . . 13 68 4. Transport Protocol Requirements . . . . . . . . . . . . . . . 14 69 4.1. Connection Oriented . . . . . . . . . . . . . . . . . . . 14 70 4.2. Request and Response Model . . . . . . . . . . . . . . . . 14 71 4.3. Connection Lifetime . . . . . . . . . . . . . . . . . . . 14 72 4.4. Authentication . . . . . . . . . . . . . . . . . . . . . . 14 73 4.5. Authorization . . . . . . . . . . . . . . . . . . . . . . 15 74 4.6. Confidentiality and Integrity . . . . . . . . . . . . . . 15 75 4.7. Near Real Time . . . . . . . . . . . . . . . . . . . . . . 15 76 4.8. Request and Response Sizes . . . . . . . . . . . . . . . . 15 77 4.9. Request and Response Correlation . . . . . . . . . . . . . 15 78 4.10. Request Acknowledgement . . . . . . . . . . . . . . . . . 15 79 4.11. Mandatory Transport . . . . . . . . . . . . . . . . . . . 16 80 5. Base Protocol Data Structures . . . . . . . . . . . . . . . . 17 81 5.1. Request and Response Structures . . . . . . . . . . . . . 17 82 5.1.1. Update Request and Response Structures . . . . . . . . 17 83 5.1.2. Query Request and Response Structures . . . . . . . . 20 84 5.2. Response Codes and Messages . . . . . . . . . . . . . . . 23 85 5.3. Basic Object Type and Organization Identifiers . . . . . . 25 86 6. Protocol Commands . . . . . . . . . . . . . . . . . . . . . . 26 87 6.1. Add Destination Group Operation . . . . . . . . . . . . . 26 88 6.2. Get Destination Groups Operation . . . . . . . . . . . . . 27 89 6.3. Add Public Identifier Operation . . . . . . . . . . . . . 28 90 6.4. Get Public Identifiers Operation . . . . . . . . . . . . . 33 91 6.5. Add Route Group Operation . . . . . . . . . . . . . . . . 33 92 6.6. Get Route Groups Operation . . . . . . . . . . . . . . . . 38 93 6.7. Add Route Record Operation . . . . . . . . . . . . . . . . 39 94 6.8. Get Route Records Operation . . . . . . . . . . . . . . . 43 95 6.9. Add Route Group Offer Operation . . . . . . . . . . . . . 44 96 6.10. Accept Route Group Offer Operation . . . . . . . . . . . . 46 97 6.11. Reject Route Group Offer Operation . . . . . . . . . . . . 47 98 6.12. Get Route Group Offers Operation . . . . . . . . . . . . . 48 99 6.13. Egress Route Operations . . . . . . . . . . . . . . . . . 50 100 6.14. Delete Operation . . . . . . . . . . . . . . . . . . . . . 52 101 7. SPPP Examples . . . . . . . . . . . . . . . . . . . . . . . . 54 102 7.1. Add Destination Group . . . . . . . . . . . . . . . . . . 54 103 7.2. Add Route Records . . . . . . . . . . . . . . . . . . . . 55 104 7.3. Add Route Records -- URIType . . . . . . . . . . . . . . . 56 105 7.4. Add Route Group . . . . . . . . . . . . . . . . . . . . . 57 106 7.5. Add Public Identity -- Successful COR claim . . . . . . . 58 107 7.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . . 60 108 7.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . . 61 109 7.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . . 62 110 7.9. Enable Peering -- Route Group Offer . . . . . . . . . . . 63 111 7.10. Enable Peering -- Route Group Offer Accept . . . . . . . . 64 112 7.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . . 65 113 7.12. Get Destination Group . . . . . . . . . . . . . . . . . . 66 114 7.13. Get Public Identity . . . . . . . . . . . . . . . . . . . 67 115 7.14. Get Route Group Request . . . . . . . . . . . . . . . . . 68 116 7.15. Get Route Group Offers Request . . . . . . . . . . . . . . 70 117 7.16. Get Egress Route . . . . . . . . . . . . . . . . . . . . . 71 118 7.17. Delete Destination Group . . . . . . . . . . . . . . . . . 72 119 7.18. Delete Public Identity . . . . . . . . . . . . . . . . . . 73 120 7.19. Delete Route Group Request . . . . . . . . . . . . . . . . 74 121 7.20. Delete Route Group Offers Request . . . . . . . . . . . . 75 122 7.21. Delete Egress Route . . . . . . . . . . . . . . . . . . . 75 123 8. XML Considerations . . . . . . . . . . . . . . . . . . . . . . 77 124 8.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 77 125 8.2. Versioning and Character Encoding . . . . . . . . . . . . 77 126 9. Security Considerations . . . . . . . . . . . . . . . . . . . 78 127 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 128 11. Formal Specification . . . . . . . . . . . . . . . . . . . . . 81 129 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 94 130 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 95 131 13.1. Normative References . . . . . . . . . . . . . . . . . . . 95 132 13.2. Informative References . . . . . . . . . . . . . . . . . . 95 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 97 135 1. Introduction 137 Service providers and enterprises use registries to make session 138 routing decisions for Voice over IP, SMS and MMS traffic exchanges. 139 This document is narrowly focused on the provisioning protocol for 140 these registries. This protocol prescribes a way for an entity to 141 provision session-related data into a registry. The data being 142 provisioned can be optionally shared with other participating peering 143 entities. The requirements and use cases driving this protocol have 144 been documented in [I-D.ietf-drinks-usecases-requirements]. The 145 reader is expected to be familiar with the terminology defined in the 146 previously mentioned document. 148 Three types of provisioning flows have been described in the use case 149 document: client to registry provisioning, registry to local data 150 repository and registry to registry. This document addresses client 151 to registry aspect to fulfill the need to provision Session 152 Establishment Data (SED). The protocol that supports flow of 153 messages to facilitate client to registry provisioning is referred to 154 as Session Peering Provisioning Protocol (SPPP). 156 Please note that the role of the "client" and the "server" only 157 applies to the connection, and those roles are not related in any way 158 to the type of entity that participates in a protocol exchange. For 159 example, a registry might also include a "client" when such a 160 registry initiates a connection (for example, for data distribution 161 to SSP). 163 *--------* *------------* *------------* 164 | | (1). Client | | (3).Registry | | 165 | Client | ------------> | Registry |<------------->| Registry | 166 | | to Registry | | to Registry | | 167 *--------* *------------* *------------* 168 / \ \ 169 / \ \ 170 / \ \ 171 / \ v 172 / \ ... 173 / \ 174 / (2). Distrib \ 175 / Registry data \ 176 / to local data \ 177 V store V 178 +----------+ +----------+ 179 |Local Data| |Local Data| 180 |Repository| |Repository| 181 +----------+ +----------+ 183 Three Registry Provisioning Flows 185 Figure 1 187 The data provisioned for session establishment is typically used by 188 various downstream SIP signaling systems to route a call to the next 189 hop associated with the called domain. These systems typically use a 190 local data store ("Local Data Repository") as their source of session 191 routing information. More specifically, the SED data is the set of 192 parameters that the outgoing signaling path border elements (SBEs) 193 need to initiate the session. See [RFC5486] for more details. 195 A "terminating" SIP Service Provider (SSP) provisions SED into the 196 registry to be selectively shared with other peer SSPs. 197 Subsequently, a registry may distribute the provisioned data into 198 local data repositories used for look-up queries (identifier -> URI) 199 or for lookup and location resolution (identifier -> URI -> ingress 200 SBE of terminating SSP). In some cases, the registry may 201 additionally offer a central query resolution service (not shown in 202 the above figure). 204 A key requirement for the SPPP protocol is to be able to accommodate 205 two basic deployment scenarios: 207 1. A resolution system returns a Look-Up Function (LUF) that 208 comprises of the target domain to assist in call routing (as 209 described in [RFC5486]). In this case, the querying entity may 210 use other means to perform the Location Routing Function (LRF) 211 which in turn helps determine the actual location of the 212 Signaling Function in that domain. 214 2. A resolution system returns both a Look-Up function (LUF) and 215 Location Routing Function (LRF) to locate the SED data fully. 217 In terms of protocol design, SPPP is agnostic to the transport. This 218 document includes the description of the data model and the means to 219 enable protocol operations within a request and response structure. 220 To encourage interoperability, the protocol supports extensibility 221 aspects. 223 Transport requirements are provided in this document to help with the 224 selection of the optimum transport mechanism. 225 ([I-D.ietf-drinks-sppp-over-soap]) identifies a SOAP transport 226 mechanism for SPPP. 228 This document is organized as follows: 230 o Section 2 provides the terminology; 232 o Section 3 provides an overview of the SPPP, including the 233 layering approach, functional entities and data model; 235 o Section 4 specifies requirements for SPPP transport protocols; 237 o Section 5 describes the base protocol data structures including 238 the request and response elements (Section 5.1), the response 239 codes and messages (Section 5.2) and the basic object type most 240 first class objects extend from; 242 o Section 6 and Section 7 describe the main protocol commands and 243 examples; 245 o Section 8 defines XML considerations that XML parsers must meet 246 to conform to this specification; 248 o Section 11 normatively defines the SPPP protocol using its XML 249 Schema Definition. 251 2. Terminology 253 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 254 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 255 document are to be interpreted as described in [RFC2119]. 257 This document reuses terms from [RFC3261], [RFC5486], use cases and 258 requirements documented in [I-D.ietf-drinks-usecases-requirements] 259 and the ENUM Validation Architecture [RFC4725]. 261 In addition, this document specifies the following additional terms: 263 SPPP: Session Peering Provisioning Protocol, the protocol used to 264 provision data into a Registry (see arrow labeled "1." in Figure 1 265 of [I-D.ietf-drinks-usecases-requirements]). It is the primary 266 scope of this document. 268 SPDP: Session Peering Distribution Protocol, the protocol used to 269 distribute data to Local Data Repository (see arrow labeled "2." 270 in Figure 1 of [I-D.ietf-drinks-usecases-requirements]). 272 Client: An application that supports an SPPP client; it is 273 sometimes referred to as a "registry client". 275 Registry: The Registry operates a master database of Session 276 Establishment Data for one or more Registrants. 278 A Registry acts as an SPPP server. 280 Registrant: In this document we extend the definition of a 281 Registrant based on [RFC4725]. The Registrant is the end-user, 282 the person or organization that is the "holder" of the Session 283 Establishment Data being provisioned into the Registry by a 284 Registrar. For example, in 285 [I-D.ietf-drinks-usecases-requirements], a Registrant is pictured 286 as a SIP Service Provider in Figure 2. 288 Within the confines of a Registry, a Registrant is uniquely 289 identified by a well-known ID. 291 Registrar: In this document we extend the definition of a Registrar 292 from [RFC4725]. A Registrar is an entity that performs 293 provisioning operations on behalf of a Registrant by interacting 294 with the Registry via SPPP operations. In other words the 295 Registrar is the SPPP Client. The Registrar and Registrant roles 296 are logically separate to allow, but not require, a single 297 Registrar to perform provisioning operations on behalf of more 298 than one Registrant. 300 Peering Organization: A Peering Organization is an entity to which 301 a Registrant's Route Groups are made visible using the operations 302 of SPPP. 304 3. Protocol High Level Design 306 This section introduces the structure of the data model and provides 307 the information framework for the SPPP. An overview of the protocol 308 operations is first provided with a typical deployment scenario. The 309 data model is then defined along with all the objects manipulated by 310 the protocol and their relationships. 312 3.1. Protocol Layering 314 SPPP is a simple request/reply protocol that allows a client 315 application to submit provisioning data and query requests to a 316 server. The SPPP data structures are designed to be protocol 317 agnostic. Concerns regarding encryption, non-repudiation, and 318 authentication are beyond the scope of this document. For more 319 details, please refer to the Transport Protocol Requirements section. 321 Layer Example 322 +-------------+ +-----------------------------+ 323 (5) |Data Objects | | RteGrpType, etc. | 324 +-------------+ +-----------------------------+ 325 | | 326 +-------------+ +-----------------------------+ 327 (4) | Operations | | AddRteGrpRqstType, etc. | 328 +-------------+ +-----------------------------+ 329 | | 330 +-------------+ +-----------------------------+ 331 (3) | Message | | spppUpdateRequest, | 332 | | | spppUpdateResponse, | 333 | | | spppQueryRequest, | 334 | | | spppQueryResponse | 335 +-------------+ +-----------------------------+ 336 | | 337 +-------------+ +-----------------------------+ 338 (2) | Message | | HTTP, SOAP, None, etc. | 339 | Envelope | | | 340 +-------------+ +-----------------------------+ 341 | | 342 +-------------+ +-----------------------------+ 343 (1) | Transport | | TCP, TLS, BEEP, etc. | 344 | Protocol | | | 345 +-------------+ +-----------------------------+ 347 SPPP Layering 349 Figure 2 351 SPPP can be viewed as a set of layers that collectively define the 352 structure of an SPPP request and response. Layers 1 and 2, as 353 detailed below, are left to separate specifications to allow for 354 potentially multiple SPPP transport, envelope, and authentication 355 technologies. This document defines layers 3, 4, and 5 below. 357 1. The transport protocol layer provides a communication mechanism 358 between the client and server. SPPP can be layered over any 359 transport protocol that provides a set of basic requirements 360 defined in the Transport Protocol Requirements section. 362 2. The message envelope layer is optional, but can provide features 363 that are above the transport technology layer but below the 364 application messaging layer. Technologies such as HTTP and SOAP 365 are examples of messaging envelope technologies. 367 3. The message layer provides a simple, envelope-independent and 368 transport-independent, SPPP wrapper for SPPP request and response 369 messages. 371 4. The operation layer defines the set of base SPPP actions that can 372 be invoked for a given object data type using an SPPP message. 373 Operations are encoded using XML encoded actions and objects. 375 5. The data object layer defines the base set of SPPP data objects 376 that can be included in update operations or returned in 377 operation responses. 379 3.2. Protocol Data Model 381 The data model illustrated and described in Figure 3 defines the 382 logical objects and the relationships between these objects that the 383 SPPP protocol supports. SPPP defines the protocol operations through 384 which an SPPP client populates a registry with these logical objects. 385 Various clients belonging to different registrars may use the 386 protocol for populating the registry's data. 388 The logical structure presented below is consistent with the 389 terminology and requirements defined in 390 [I-D.ietf-drinks-usecases-requirements]. 392 +-------------+ +------------------+ 393 | all object | |Organization: | 394 | types |----->|orgId | 395 +------+------+ | | 396 All objects are +------------------+ 397 associated with an ^ 398 organization to |A Route Group is 399 identify the |associated with +-----[abstract]-+ 400 object's registrant |zero or more Peering | Route Record: | 401 |Organizations | rrName, | 402 | | priority, | 403 +--------+--------------+ | extension | 404 |Route Group: |------->| | 405 | rant, | +----------------+ 406 | rgName, | ^ 407 | destGrpRef, | | 408 | isInSvc, | |Various types 409 | rrRef, | |of Route 410 | peeringOrg, | |Records... 411 | sourceIdent, | +-----+------------+ 412 | priority, | | | | 413 | extension | +----+ +-------+ +----+ 414 +-----------------------+ | URI| | NAPTR | | NS | 415 | +----+ +-------+ +----+ 416 | 417 | +----------[abstract]-+ 418 | |Public Identifier: | 419 | | | 420 | | rant, | 421 v | publicIdentifier, | 422 +----------------------+ | destGrpRef, | 423 | Dest Group: |<----| rrRef, | 424 | rant, | | extension | 425 | dgName, | +---------------------+ 426 | extension | ^ 427 +----------------------+ |Various types 428 |of Public 429 |Identifiers... 430 +---------+-------+------------... 431 | | | | 432 +------+ +-----+ +-----+ +-----+ 433 | TN | | TNP | | TNR | | RN | 434 +------+ +-----+ +-----+ +-----+ 436 SPPP Data Model 438 Figure 3 440 The objects and attributes that comprise the data model can be 441 described as follows (objects listed from the bottom up): 443 o Public Identifier: 444 From a broad perspective a public identifier is a well-known 445 attribute that is used as the key to perform resolution lookups. 446 Within the context of SPPP, a public identifier object can be a 447 telephone number, a range of telephone numbers, a PSTN Routing 448 Number (RN), or a TN prefix. 450 An SPPP Public Identifier is associated with a Destination Group 451 to create a logical grouping of Public Identifiers that share a 452 common set of Routes. 454 A TN Public Identifier may optionally be associated with zero or 455 more individual Route Records. This ability for a Public 456 Identifier to be directly associated with a set of Route Records 457 (e.g. target URI), as opposed to being associated with a 458 Destination Group, supports the use cases where the target URI 459 contains data specifically tailored to an individual TN Public 460 Identifier. 462 o Destination Group: 463 A named collection of zero or more Public Identifiers that can be 464 associated with one or more Route Groups for the purpose of 465 facilitating the management of their common routing information. 467 o Route Group: 468 A Route Group contains a set of Route Record references, a set of 469 Destination Group references, and a set of peering organization 470 identifiers. This is used to establish a three part relationships 471 between a set of Public Identifiers, the routing information (SED) 472 shared across the Public Identifiers, and the list of peering 473 organizations whose query responses from the resolution system may 474 include the routing information from a given route group. In 475 addition, the sourceIdent element within a Route Group, in concert 476 with the set of peering organization identifiers, enables fine- 477 grained source based routing. For further details about the Route 478 Group and source based routing, refer to the definitions and 479 descriptions of the Route Group operations found later in this 480 document. 482 o Route Record: 483 A Route Record contains the data that a resolution system returns 484 in response to a successful query for a Public Identifier. Route 485 Records are generally associated with a Route Group when the SED 486 within is not specific to a Public Identifier. 487 To support the use cases defined in 489 [I-D.ietf-drinks-usecases-requirements], SPPP defines three type 490 of Route Records: URIType, NAPTRType, and NSType. These Route 491 Records extend the abstract type RteRecType and inherit the common 492 attribute 'priority' that is meant for setting precedence across 493 the route records defined within a Route Group in a protocol 494 agnostic fashion. 496 o Organization: 497 An Organization is an entity that may fulfill the role of a 498 registrant or a peering organization. All SPPP objects are 499 associated with an organization identifier to identify each 500 object's registrant, while tracking the identity of the registrar 501 that provisioned each SPPP object is left as a matter of policy 502 for an SPPP implementation. A Route Group object is also 503 associated with a set of zero or more organization identifiers 504 that identify the peering organization(s) whose resolution query 505 responses may include the routing information (SED) defined in the 506 Route Records within that Route Group. A peering organization is 507 an entity that the registrant intends to share the SED data with. 508 A route group SPPP object is associated with a set of zero or more 509 organization identifiers that identify the peering organizations 510 whose resolution query responses may include the routing 511 information (SED) defined in the route records within that route 512 group. 514 3.3. Time Value 516 Some SPPP request and response messages include time value(s) defined 517 as type xs:dateTime, a built-in W3C XML Schema Datatype. Use of 518 unqualified local time value is discouraged as it can lead to 519 interoperability issues. The value of time attribute MUST BE 520 expressed in Coordinated Universal Time (UTC) format without the 521 timezone digits. 523 "2010-05-30T09:30:10Z" is an example of an acceptable time value for 524 use in SPPP messages. "2010-05-30T06:30:10+3:00" is a valid UTC time, 525 but it is not approved for use in SPPP messages. 527 4. Transport Protocol Requirements 529 This section provides requirements for transport protocols suitable 530 for SPPP. More specifically, this section specifies the services, 531 features, and assumptions that SPPP delegates to the chosen transport 532 and envelope technologies. 534 4.1. Connection Oriented 536 The SPPP follows a model where a client establishes a connection to a 537 server in order to further exchange SPPP messages over such point-to- 538 point connection. A transport protocol for SPPP MUST therefore be 539 connection oriented. 541 4.2. Request and Response Model 543 Provisioning operations in SPPP follow the request-response model, 544 where a client sends a request message to initiate a transaction and 545 the server responds with a response. Multiple subsequent request- 546 response exchanges MAY be performed over a single persistent 547 connection. 549 Therefore, a transport protocol for SPPP MUST follow the request- 550 response model by allowing a response to be sent to the request 551 initiator. 553 4.3. Connection Lifetime 555 Some use cases involve provisioning a single request to a network 556 element. Connections supporting such provisioning requests might be 557 short-lived, and may be established only on demand. Other use cases 558 involve either provisioning a large dataset, or a constant stream of 559 small updates, either of which would likely require long-lived 560 connections. 562 Therefore, a protocol suitable for SPPP SHOULD be able to support 563 both short-lived as well as long-lived connections. 565 4.4. Authentication 567 All SPPP objects are associated with a registrant identifier. SPPP 568 Clients provisions SPPP objects on behalf of registrants. An 569 authenticated SPP Client is a registrar. Therefore, the SPPP 570 transport protocol MUST provide means for an SPPP server to 571 authenticate an SPPP Client. 573 4.5. Authorization 575 After successful authentication of the SPPP client as a registrar the 576 registry performs authorization checks to determine if the registrar 577 is authorized to act on behalf of the Registrant whose identifier is 578 included in the SPPP request. Refer to the Security Considerations 579 section for further guidance. 581 4.6. Confidentiality and Integrity 583 In some deployments, the SPPP objects that an SPPP registry manages 584 can be private in nature. As a result it MAY NOT be appropriate to 585 for transmission in plain text over a connection to the SPPP 586 registry. Therefore, the transport protocol SHOULD provide means for 587 end-to-end encryption between the SPPP client and server. 589 For some SPPP implementations, it may be acceptable for the data to 590 be transmitted in plain text, but the failure to detect a change in 591 data after it leaves the SPPP client and before it is received at the 592 server, either by accident or with a malicious intent, will adversely 593 affect the stability and integrity of the registry. Therefore, the 594 transport protocol SHOULD provide means for data integrity 595 protection. 597 4.7. Near Real Time 599 Many use cases require near real-time responses from the server. 600 Therefore, a DRINKS transport protocol MUST support near real-time 601 response to requests submitted by the client. 603 4.8. Request and Response Sizes 605 Use of SPPP may involve simple updates that may consist of small 606 number of bytes, such as, update of a single public identifier. 607 Other provisioning operations may constitute large number of datasets 608 as in adding millions records to a registry. As a result, a suitable 609 transport protocol for SPPP SHOULD accommodate datasets of various 610 sizes. 612 4.9. Request and Response Correlation 614 A transport protocol suitable for SPPP MUST allow responses to be 615 correlated with requests. 617 4.10. Request Acknowledgement 619 Data transported in the SPPP is likely crucial for the operation of 620 the communication network that is being provisioned. A SPPP client 621 responsible for provisioning SED to the registry has a need to know 622 if the submitted requests have been processed correctly. 624 Failed transactions can lead to situations where a subset of public 625 identifiers or even SSPs might not be reachable, or the provisioning 626 state of the network is inconsistent. 628 Therefore, a transport protocol for SPPP MUST provide a response for 629 each request, so that a client can identify whether a request 630 succeeded or failed. 632 4.11. Mandatory Transport 634 At the time of this writing, a choice of transport protocol has been 635 provided in [I-D.ietf-drinks-sppp-over-soap]. To encourage 636 interoperability, the SPPP server MUST provide support for this 637 transport protocol. With time, it is possible that other transport 638 layer choices may surface that agree with the requirements discussed 639 above. 641 5. Base Protocol Data Structures 643 SPPP uses a common model and a common set of data structures for most 644 of the supported operations and object types. This section describes 645 these common data structures. 647 5.1. Request and Response Structures 649 An SPPP client interacts with an SPPP server by using one of the 650 supported transport mechanisms to send one or more requests to the 651 server and receive corresponding replies from the server. There are 652 two generalized types of operations that an SPPP client can submit to 653 an SPPP server, updates and queries. The following two sub-sections 654 describe the generalized data structures that are used for each of 655 these two types of operations. 657 5.1.1. Update Request and Response Structures 659 An SPPP update request is wrapped within the 660 element while an SPPP update response is wrapped within an 661 element. The following two sub-sections 662 describe these two elements. 664 5.1.1.1. Update Request 666 An SPPP update request object is contained within the generic 667 element. 669 670 671 672 674 676 678 679 680 682 683 684 685 686 687 689 The data elements within the element are 690 described as follows: 692 o clientTransId: Zero or one client-generated transaction ID that, 693 within the context of the SPPP client, identifies this request. 694 This value can be used at the discretion of the SPPP client to 695 track, log or correlate requests and their responses. SPPP 696 server MUST echo back this value to the client in the 697 corresponding response to the incoming request. SPPP server 698 will not check this value for uniqueness. 700 o minorVer: Zero or one minor version identifier, indicating the 701 minor version of the SPPP API that the client is attempting to 702 use. This is used in conjunction with the major version 703 identifier in the XML namespace to identify the version of SPPP 704 that the client is using. If the element is not present, the 705 server assumes that the client is using the latest minor version 706 supported by the SPPP server for the given major version. The 707 versions supported by a given SPPP server can be retrieved by 708 the client using the SPPP server menu operation described later 709 in the document. 711 o rqst: One or more BasicUpdateRqstType objects. These are the 712 actions that the client is requesting the SPPP server perform. 713 They are processed by the SPPP server in the order in which they 714 are included in the request. And with respect to handling error 715 conditions, it is a matter of policy whether the objects are 716 processed in a "stop and rollback" fashion or in a "stop and 717 commit" fashion. In the "stop and rollback" scenario, the SPPP 718 server would stop processing BasicUpdateRqstType object 719 instances in the request at the first error and roll back any 720 BasicUpdateRqstType object instances that had already been 721 processed for that update request. In the "stop and commit" 722 scenario the SPPP server would stop processing 723 BasicUpdateRqstType object instances in the request at the first 724 error but commit any BasicUpdateRqstType object instances that 725 had already been processed for that update request. 727 All update request objects extend the base type BasicUpdateRqstType. 728 This base type is defined as follows: 730 731 732 733 734 736 The BasicUpdateRqstType object primarily acts as an abstract base 737 type, and its only data element is described as follows: 739 o ext: This is the standard extension element for this object. 740 Refer to the Extensibility section of this document for more 741 details. 743 5.1.1.2. Update Response 745 An SPPP update response object is contained within the generic 746 element. 748 749 750 751 752 754 756 757 758 759 761 762 763 764 765 766 768 769 770 771 772 773 774 776 777 779 An contains the elements necessary for the SPPP 780 client to precisely determine the overall result of the request, and 781 if an error occurred, it provides information about the specific 782 object, data element, or condition caused the error. 784 The data elements within the SPPP update response are described as 785 follows: 787 o clientTransId: Zero or one client transaction ID. This value is 788 simply an echo of the client transaction ID that SPPP client 789 passed into the SPPP update request. When included in the 790 request, the SPPP server MUST return it in the corresponding 791 response message. 793 o serverTransId: Exactly one server transaction ID that identifies 794 this request for tracking purposes. This value MUST be unique 795 for a given SPPP server. 797 o overallResult: Exactly one response code and message pair that 798 explicitly identifies the result of the request. See the 799 Response Code section for further details. 801 o rqstObjResult: An optional response code, response message, and 802 BasicRqstObject triplet. This element will be present only if 803 an object level error has occurred. It indicates the error 804 condition and the exact request object that contributed to the 805 error. The response code will reflect the exact error. See the 806 Response Code section for further details. 808 o ext: This is the standard extension element for this object. 809 Refer to the Extensibility section for more details. 811 5.1.2. Query Request and Response Structures 813 At times, on behalf of the registrant, the registrar may need to have 814 access to SPPP objects that were previously provisioned in the 815 registry. A few examples include logging, auditing, and pre- 816 provisioning dependency checking. This query mechanism is limited to 817 aid provisioning scenarios and should not be confused with query 818 protocols provided as part of the resolution system (e.g. ENUM and 819 SIP). 821 An SPPP query request is wrapped within the 822 element while an SPPP query response is wrapped within an 823 element. The following two sub-sections describe 824 these two element structures. 826 5.1.2.1. Query Request 828 An SPPP query request object is contained within the generic 829 element. 831 832 833 834 836 837 838 839 841 The data elements within the element are described 842 as follows: 844 o minorVer: Zero or one minor version identifier, indicating the 845 minor version of the SPPP API that the client is attempting to 846 use. This is used in conjunction with the major version 847 identifier in the XML namespace to identify the version of SPPP 848 that the client is using. If the element is not present, the 849 server assumes that the client is using the latest minor version 850 supported by the SPPP server for the given major version. The 851 versions supported by a given SPPP server can be retrieved by 852 the client using the SPPP server menu operation described later 853 in the document. 855 o rqst: One BasicQueryRqstType objects. This is the query that 856 the client is requesting the SPPP server perform. 858 All query request objects extend the base type BasicQueryRqstType. 859 This base type is defined as follows: 861 862 863 864 866 868 The BasicQueryRqstType object primarily acts as an abstract base 869 type, and its only data element is described as follows: 871 o ext: This is the standard extension element for this object. 872 Refer to the Extensibility section of this document for more 873 details. 875 5.1.2.2. Query Response 877 An SPPP query response object is contained within the generic 878 element. 880 881 882 883 884 886 887 888 890 An contains the elements necessary for the SPPP 891 client to precisely determine the overall result of the query, and if 892 an error occurred, exactly what condition caused the error. 894 The data elements within the SPPP query response are described as 895 follows: 897 o overallResult: Exactly one response code and message pair that 898 explicitly identifies the result of the request. See the 899 Response Code section for further details. 901 o resultSet: The set of zero or more objects that matched the 902 query criteria. If no objects matched the query criteria then 903 this result set MUST be empty and the overallResult value MUST 904 indicate success (if no matches are found for the query 905 criteria, the response is considered a success). 907 5.2. Response Codes and Messages 909 This section contains the listing of response codes and their 910 corresponding human-readable text. 912 The response code numbering scheme generally adheres to the theory 913 formalized in section 4.2.1 of [RFC5321]: 915 o The first digit of the response code can only be 1 or 2: 1 = a 916 positive result, 2 = a negative result. 918 o The second digit of the response code indicates the category: 0 919 = Protocol Syntax, 1 = Implementation Specific Business Rule, 2 920 = Security, 3 = Server System. 922 o The third and fourth digits of the response code indicate the 923 individual message event within the category defines by the 924 first two digits. 926 The response codes are also categorized as to whether they are 927 overall response codes that may only be returned in the 928 "overallResult" data element in SPPP responses, of object level 929 response codes that may only be returned in the "rqstObjResult" 930 element of the SPPP responses. 932 +--------+--------------------------+-------------------------------+ 933 | Result | Result Message | Overall or Object Level | 934 | Code | | | 935 +--------+--------------------------+-------------------------------+ 936 | 1000 | Request Succeeded. | Overall Response Code | 937 | | | | 938 | 2001 | Request syntax invalid. | Overall Response Code | 939 | | | | 940 | 2002 | Request too large. | Overall Response Code | 941 | | | | 942 | 2003 | Version not supported. | Overall Response Code | 943 | | | | 944 | 2103 | Command invalid. | Overall Response Code | 945 | | | | 946 | 2301 | System temporarily | Overall Response Code | 947 | | unavailable. | | 948 | | | | 949 | 2302 | Unexpected internal | Overall Response Code | 950 | | system or server error. | | 951 | | | | 952 | 2104 | Attribute value invalid. | Object Level Response Code | 953 | | | | 954 | | AttrName:[AttributeName] | | 955 | | AttrVal:[AttributeValue] | | 956 | | | | 957 | 2105 | Object does not exist. | Object Level Response Code | 958 | | AttrName:[AttributeName] | | 959 | | AttrVal:[AttributeValue] | | 960 | | | | 961 | 2106 | Object status or | Object Level Response Code | 962 | | ownership does not allow | | 963 | | for operation. | | 964 | | AttrName:[AttributeName] | | 965 | | AttrVal:[AttributeValue] | | 966 +--------+--------------------------+-------------------------------+ 968 Table 1: Response Codes Numbering Scheme and Messages 970 Each of the object level response messages are "parameterized" with 971 the following parameters: "AttributeName" and "AttributeValue". 973 The use of these parameters MUST adhere to the following rules: 975 o All parameters within a response message are mandatory and MUST 976 be present. 978 o Any value provided for the "AttributeName" parameter MUST be an 979 exact XSD element name of the protocol data element that the 980 response message is referring to. For example, valid values for 981 "attribute name" are "dgName", "rgName", "rteRec", etc. 983 o The value for "AttributeValue" MUST be the value of the data 984 element to which the preceding "AttributeName" refers. 986 o Result code 2104 SHOULD be used whenever an element value does 987 not adhere to data validation rules. 989 o Result codes 2104 and 2105 MUST NOT be used interchangeably. 990 Response code 2105 SHOULD be returned by an update operation 991 when the data element(s) used to uniquely identify a pre- 992 existing object do not exist. If the data elements used to 993 uniquely identify an object are malformed, then response code 994 2104 SHOULD be returned. 996 5.3. Basic Object Type and Organization Identifiers 998 This section introduces the basic object type that most first class 999 objects derive from. 1001 All first class objects extend the basic object type BasicObjType 1002 that contains the identifier of the registrant organization that owns 1003 this object, the date and time that the object was created by the 1004 server, and the date and time that the object was last modified. 1006 1007 1008 1009 1010 1011 1012 1013 1015 The identifiers used for registrants (rant) and peering organizations 1016 (peeringOrg) are instances of OrgIdType. The OrgIdType is defined as 1017 a string and all OrgIdType instances SHOULD follow the textual 1018 convention: "namespace:value" (for example "iana-en:32473"). See the 1019 IANA Consideration section for more details. 1021 6. Protocol Commands 1023 This section provides a description of each supported protocol 1024 command. 1026 6.1. Add Destination Group Operation 1028 As described in the introductory sections, a Destination Group 1029 represents a set of Public Identifiers with common routing 1030 information. 1032 The AddDestGrpRqstType operation creates or overwrites a Destination 1033 Group object. If a Destination Group with the given name and 1034 registrant ID (which together comprise the unique key for a 1035 Destination Group) does not exist, then the server MUST create the 1036 Destination Group. If a Destination Group with the given name and 1037 registrant ID does exist, then the server MUST replace the current 1038 properties of the Destination Group with the properties passed into 1039 the AddDestGrpsRqstType operation. The XSD declarations of the 1040 operation request object are as follows: 1042 1043 1044 1045 1046 1047 1048 1049 1050 1052 The element passed into the spppUpdateRequest element for this 1053 operation is an element of type AddDestGrpRqsttype, which extends 1054 BasicUpdateRqstType and contains a DestGrpType object. The 1055 DestGrpType object structure is defined as follows: 1057 1058 1059 1060 1061 1062 1063 1065 1066 1068 The DestGrpType object is composed of the following elements: 1070 o base: All first class objects extend BasicObjType that contains 1071 the ID of the registrant organization that owns this object, the 1072 date and time that the object was created by the server, and the 1073 date and time that the object was last modified. If the client 1074 passed in either the created date or the modification date, the 1075 server will ignore them. The server sets these two date/time 1076 values. 1078 o dgName: The character string that contains the name of the 1079 Destination Group. This uniquely identifies this object within 1080 the context of the registrant ID (a child element of the base 1081 element as described above). 1083 o ext: Point of extensibility described in a previous section of 1084 this document. 1086 As with the responses to all update operations, the result of the 1087 AddDestGrpRqstType operation is contained in the generic 1088 spppUpdateResponse data structure described in an earlier sections of 1089 this document. For a detailed description of the spppUpdateResponse 1090 data structure refer to that section of the document. 1092 6.2. Get Destination Groups Operation 1094 The getDestGrpsRqst operation allows an SPPP client to get the 1095 properties of Destination Group objects that a registrar is 1096 authorized to view on behalf of the registrant. The server will 1097 attempt to find a Destination Group object that has the registrant ID 1098 and destination group name pair contained in each ObjKeyType object 1099 instance. If there are no matching Destination Groups found then an 1100 empty result set will be returned. If no ObjKeyType objects are 1101 found in the request then the server will return the list of all 1102 Destination Group objects in the registry. If no matching records 1103 can be located then an empty result set will be returned. 1105 The element passed into the spppQueryRequest element for this 1106 operation is an instance of type GetDestGrpsRqstType, which extends 1107 BasicQueryRqstType and contains zero or more ObjKeyType objects. Any 1108 limitation on the maximum number of objects that may be passed into 1109 or returned by this operation is a policy decision and not limited by 1110 the protocol. The XSD declaration of the operation is as follows: 1112 1113 1114 1115 1116 1118 1119 1120 1121 1123 As described in an earlier section of this document, the result of 1124 any spppQueryRequest operation is an spppQueryResponse element that 1125 contains the overall response code and the query result set, if any. 1126 Refer to that section of the document for a detailed description of 1127 the spppQueryResponse element. 1129 6.3. Add Public Identifier Operation 1131 A Public Identifier is the search key used for locating the session 1132 establishment data (SED). In many cases, a Public Identifier is 1133 attributed to the end user who has a retail relationship with the 1134 service provider or registrant organization. SPPP supports the 1135 notion of the carrier-of-record as defined in [RFC5067]. Therefore, 1136 the registrant under whom the Public Identity is being created can 1137 optionally claim to be a carrier-of-record. 1139 SPPP identifies two types of Public Identifiers: telephone numbers 1140 (TN), and the routing numbers (RN). SPPP provides structures to 1141 manage a single TN, a contiguous range of TNs, and a TN prefix. 1143 The abstract XML schema type definition PubIDType is a generalization 1144 for the concrete the Public Identifier schema types. PubIDType 1145 element 'dgName' represents the name of the destination group that a 1146 given Public Identifier is a member of. Because a Destination Group 1147 is uniquely identified by its composite business key, which is 1148 comprised of its registrant ID, rantId, and its name, dgName, the 1149 Public Identity's containing Destination Group is identified by the 1150 Public Identity's dgName element and the Public Identity's registrant 1151 ID, rantId, element. The PubIDType object structure is defined as 1152 follows: 1154 1155 1156 1157 1158 1159 1160 1161 1162 1164 A registrant can add a Public Identifier using the AddPubIdRqstType 1165 operation. To complete the add request, AddPubIdRqstType XML 1166 instance is populated into the element. A Public 1167 Identifier may be provisioned as a member of a Destination Group or 1168 provisioned outside of a Destination Group. A Public Identifier that 1169 is provisioned as a member of a Destination Group is intended to be 1170 associated with its SED through the Route Group(s) that are 1171 associated with its containing Destination Group. A Public 1172 Identifier that is not provisioned as a member of a Destination Group 1173 is intended to be associated with its SED through the Route Records 1174 that are directly associated with the Public Identifier. If a Public 1175 Identifier being added already exists then that Public Identifier 1176 will be replaced with the newly provisioned Public Identifier. 1178 A telephone number is provisioned using the TNType, an extension of 1179 PubIDType. Each TNType object is uniquely identified by the 1180 combination of its element, and the unique key of its parent 1181 Destination Group (dgName and rantId). In other words a given 1182 telephone number string may exist within one or more Destination 1183 Groups, but must not exist more than once within a Destination Group. 1184 TNType is defined as follows: 1186 1187 1188 1189 1190 1191 1193 1195 1196 1197 1198 1200 TNType consists of the following attributes: 1202 o tn: Telephone number to be added to the registry. 1204 o rrRef: Optional reference to route records that are directly 1205 associated with the TN Public Identifier. Following the SPPP 1206 data model, the route record could be a protocol agnostic 1207 URIType or another type. 1209 o corInfo: corInfo is an optional parameter of type CORInfoType 1210 that allows the registrant organization to set forth a claim to 1211 be the carrier-of-record (see [RFC5067]). This is done by 1212 setting the value of element of the CORInfoType 1213 object structure to "true". The other two parameters of the 1214 CORInfoType, and are set by the registry to 1215 describe the outcome of the carrier-of-record claim by the 1216 registrant. In general, inclusion of parameter is 1217 useful if the registry has the authority information, such as, 1218 the number portability data, etc., in order to qualify whether 1219 the registrant claim can be satisfied. If the carrier-of-record 1220 claim disagrees with the authority data in the registry, whether 1221 the TN add operation fails or not is a matter of policy and it 1222 is beyond the scope of this document. In the response message 1223 , the SPPP server must include the 1224 parameter of the element to let the registrant know 1225 the outcome of the claim. 1227 A routing number is provisioned using the RNType, an extension of 1228 PubIDType. SSPs that possess the number portability data may be able 1229 to leverage the RN search key to discover the ingress routes for 1230 session establishment. Therefore, the registrant organization can 1231 add the RN and associate it with the appropriate destination group to 1232 share the route information. Each RNType object is uniquely 1233 identified by the combination of its element, and the unique key 1234 of its parent Destination Group (dgName and rantId). In other words 1235 a given routing number string may exist within one or more 1236 Destination Groups, but must not exist more than once within a 1237 Destination Group. RNType is defined as follows: 1239 1240 1241 1242 1243 1244 1246 1247 1248 1249 1251 RNType has the following attributes: 1253 o rn: Routing Number used as the search key 1255 o corInfo: Optional element of type CORInfoType. 1257 TNRType structure is used to provision a contiguous range of 1258 telephone numbers. The object definition requires a starting TN and 1259 an ending TN that together define the span of the TN range. Use of 1260 TNRType is particularly useful when expressing a TN range that does 1261 not include all the TNs within a TN block or prefix. The TNRType 1262 definition accommodates the open number plan as well such that the 1263 TNs that fall between the start and end TN range may include TNs with 1264 different length variance. Whether the registry can accommodate the 1265 open number plan semantics is a matter of policy and is beyond the 1266 scope of this document. Each TNRType object is uniquely identified 1267 by the combination of its and elements, and the 1268 unique key of its parent Destination Group (dgName and rantId). In 1269 other words a given TN Range may exist within one or more Destination 1270 Groups, but must not exist more than once within a Destination Group. 1271 TNRType object structure definition is as follows: 1273 1274 1275 1276 1277 1278 1279 1281 1282 1283 1285 1287 TNRType has the following attributes: 1289 o startTn: Starting TN in the TN range 1291 o endTn: The last TN in the TN range 1293 o corInfo: Optional element of type CORInfoType 1295 In some cases, it is useful to describe a set of TNs with the help of 1296 the first few digits of the telephone number, also referred to as the 1297 telephone number prefix or a block. A given TN prefix may include 1298 TNs with different length variance in support of open number plan. 1299 Once again, whether the registry supports the open number plan 1300 semantics is a matter of policy and it is beyond the scope of this 1301 document. The TNPType data structure is used to provision a TN 1302 prefix. Each TNPType object is uniquely identified by the 1303 combination of its element, and the unique key of its 1304 parent Destination Group (dgName and rantId). TNPType is defined as 1305 follows: 1307 1308 1309 1310 1311 1312 1314 1315 1316 1317 1319 TNPType consists of the following attributes: 1321 o tnPrefix: The telephone number prefix 1323 o corInfo: Optional element of type CORInfoType. 1325 The object structure of AddPubIdRqstType is used to add Public 1326 Identifiers is as follows 1327 1328 1329 1330 1331 1332 1333 1334 1335 1337 6.4. Get Public Identifiers Operation 1339 The SPPP client can use the GetPubIdsRqstType in the 1340 structure to obtain information about one or more 1341 objects. If no matching Public Identifiers are found, then an 1342 empty result set is returned. 1344 GetPubIdsRqstType object structure is as follows: 1346 1347 1348 1349 1350 1352 1353 1354 1355 1357 As described earlier in the document, the result of any 1358 spppQueryRequest operation is a spppQueryResponse that contains the 1359 response code and the query result set, if any. 1361 6.5. Add Route Group Operation 1363 As described in the introductory sections, a Route Group represents a 1364 combined grouping of Route Records that define route information, 1365 Destination Groups that contain a set of Public Identifiers with 1366 common routing information, and the list of peer organizations that 1367 have access to these public identifiers using this route information. 1368 It is this indirect linking of public identifiers to their route 1369 information that significantly improves the scalability and 1370 manageability of the peering data. Additions and changes to routing 1371 information are reduced to a single operation on a Route Group or 1372 Route Record , rather than millions of data updates to individual 1373 public identifier records that individually contain their peering 1374 data. 1376 The AddRteGrpRqstType operation creates or overwrites a Route Group 1377 object. If a Route Group with the given name and registrant ID 1378 (which together comprise the unique key or a Route Group) does not 1379 exist, then the server MUST create the Route Group. If a Route Group 1380 with the given name and registrant ID does exist, then the server 1381 MUST replace the current properties of the Route Group with the 1382 properties passed into the AddRteGrpRqstType operation. The XSD 1383 declarations of the AddRteGrpRqstType operation request object are as 1384 follows: 1386 1387 1388 1389 1390 1391 1392 1393 1394 1396 The element passed into the spppUpdateRequest element for this 1397 operation is an instance of AddRteGrpRqstType, which extends 1398 BasicUpdateRqstType and contains one RteGrpType object. The 1399 RteGrpType object structure is defined as follows: 1401 1402 1403 1404 1405 1406 1408 1410 1412 1414 1415 1416 1417 1418 1419 1420 1422 1423 1424 1425 1426 1427 1428 1430 The RteGrpType object is composed of the following elements: 1432 o base: All first class objects extend BasicObjType that contains 1433 the ID of the registrant organization that owns this object, the 1434 date and time that the object was created by the server, and the 1435 date and time that the object was last modified. If the client 1436 passes in either the created date or the modification date, the 1437 server will ignore them. The server sets these two date/time 1438 values. 1440 o rgName: The character string that contains the name of the Route 1441 Group. It uniquely identifies this object within the context of 1442 the registrant ID (a child element of the base element as 1443 described above). 1445 o rrRef: Set of zero or more objects of type RteRecRefType that 1446 house the unique keys of the Route Records that the RteGrpType 1447 object refers to and their relative priority within the context 1448 of a given route group. The associated Route Records contain 1449 the routing information, sometimes called SED, associated with 1450 this Route Group. 1452 o dgName: Set of zero or more names of DestGrpType object 1453 instances. Each dgName name, in association with this Route 1454 Group's registrant ID, uniquely identifies a DestGrpType object 1455 instance whose public identifiers are reachable using the 1456 routing information housed in this Route Group. An intended 1457 side affect of this is that a Route Group cannot provide routing 1458 information for a Destination Group belonging to another 1459 registrant. 1461 o peeringOrg: Set of zero or more peering organization IDs that 1462 have accepted an offer to receive this Route Group's 1463 information. The set of peering organizations in this list is 1464 not directly settable or modifiable using the addRteGrpsRqst 1465 operation. This set is instead controlled using the route offer 1466 and accept operations. 1468 o sourceIdent: Set of zero or more SourceIdentType object 1469 instances. These objects, described further below, house the 1470 source identification schemes and identifiers that are applied 1471 at resolution time as part of source based routing algorithms 1472 for the Route Group. 1474 o isInSvc: A boolean element that defines whether this Route Group 1475 is in service. The routing information contained in a Route 1476 Group that is in service is a candidate for inclusion in 1477 resolution responses for public identities residing in the 1478 Destination Group associated with this Route Group. The routing 1479 information contained in a Route Group that is not in service is 1480 not a candidate for inclusion in resolution responses. 1482 o priority: Zero or one priority value that can be used to provide 1483 a relative value weighting of one Route Group over another. The 1484 manner in which this value is used, perhaps in conjunction with 1485 other factors, is a matter of policy. 1487 o ext: Point of extensibility described in a previous section of 1488 this document. 1490 As described above, the Route Group contains a set of references to 1491 route record objects. A route record object is based on an abstract 1492 type: RteRecType. The concrete types that use RteRecType as an 1493 extension base are NAPTRType, NSType, and URIType. The definitions 1494 of these types are included the Route Record section of this 1495 document. 1497 The RteGrpType object provides support for source-based routing via 1498 the peeringOrg data element and more granular source base routing via 1499 the source identity element. The source identity element provides 1500 the ability to specify zero or more of the following in association 1501 with a given Route Group: a regular expression that is matched 1502 against the resolution client IP address, a regular expression that 1503 is matched against the root domain name(s), and/or a regular 1504 expression that is matched against the calling party URI(s). The 1505 result will be that, after identifying the visible Route Groups whose 1506 associated Destination Group(s) contain the lookup key being queried 1507 and whose peeringOrg list contains the querying organizations 1508 organization ID, the resolution server will evaluate the 1509 characteristics of the Source URI, and Source IP address, and root 1510 domain of the lookup key being queried. The resolution server then 1511 compares these criteria against the source identity criteria 1512 associated with the Route Groups. The routing information contained 1513 in Route Groups that have source based routing criteria will only be 1514 included in the resolution response if one or more of the criteria 1515 matches the source criteria from the resolution request. The Source 1516 Identity data element is of type SourceIdentType, whose structure is 1517 defined as follows: 1519 1520 1521 1522 1524 1525 1526 1528 1529 1530 1531 1532 1533 1534 1536 The SourceIdentType object is composed of the following data 1537 elements: 1539 o sourceIdentScheme: The source identification scheme that this 1540 source identification criteria applies to and that the 1541 associated sourceIdentRegex should be matched against. 1543 o sourceIdentRegex: The regular expression that should be used to 1544 test for a match against the portion of the resolution request 1545 that is dictated by the associated sourceIdentScheme. 1547 o ext: Point of extensibility described in a previous section of 1548 this document. 1550 As with the responses to all update operations, the result of the 1551 AddRteGrpRqstType operation is contained in the generic 1552 spppUpdateResponse data structure described in an earlier sections of 1553 this document. For a detailed description of the spppUpdateResponse 1554 data structure refer to that section of the document. 1556 6.6. Get Route Groups Operation 1558 The getRteGrpsRqst operation allows an SPPP client to get the 1559 properties of Route Group objects that the registrar is authorized to 1560 view on behalf of the registrant. The server will attempt to find a 1561 Route Group object that has the registrant ID and route group name 1562 pair contained in each ObjKeyType object instance. If no ObjKeyType 1563 objects are found in the request then the server will return the list 1564 of all Route Group objects that belongs to the registrant. If there 1565 are no matching Route Groups found then an empty result set will be 1566 returned. 1568 The element passed into the spppQueryRequest element for this 1569 operation is an instance of type GetRteGrpsRqstType, which extends 1570 BasicUpdateRqstType and contains zero or more ObjKeyType objects. 1571 Any limitation on the maximum number of objects that may be passed 1572 into or returned by this operation is a policy decision and not 1573 limited by the protocol. The XSD declaration of the operation is as 1574 follows: 1576 1577 1578 1579 1580 1582 1583 1584 1585 1587 As described in an earlier section of this document, the result of 1588 any spppQueryRequest operation is an spppQueryResponse element that 1589 contains the overall response code and the query result set, if any. 1590 Refer to that section of the document for a detailed description of 1591 the spppQueryResponse element. 1593 6.7. Add Route Record Operation 1595 As described in the introductory sections, a Route Group represents a 1596 combined grouping of Route Records that define route information. 1597 However, Route Records need not be created to just serve a single 1598 Route Group. Route Records can be created and managed to serve 1599 multiple Route Groups. As a result, a change to the properties of a 1600 network node used for multiple routes, would necessitate just a 1601 single update operation to change the properties of that node. The 1602 change would then be reflected in all the Route Groups whose route 1603 record set contains a reference to that node. 1605 The AddRteRecRqstType operation creates or overwrites a Route Record 1606 object. If a Route Record with the given name and registrant ID 1607 (which together comprise the unique key or a Route Record) does not 1608 exist, then the server MUST create the Route Record. If a Route 1609 Record with the given name and registrant ID does exist, then the 1610 server MUST replace the current properties of the Route Record with 1611 the properties passed into the AddRteRecRqstType operation. The XSD 1612 declarations of the AddRteRecRqstType operation request object are as 1613 follows: 1615 1616 1617 1618 1619 1620 1621 1622 1623 1625 The element passed into the spppUpdateRequest element for this 1626 operation is an instance of AddRteRecRqstType, which extends 1627 BasicUpdateRqstType and contains one RteRecType object. The 1628 RteRecType object structure is defined as follows: 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1641 The RteRecType object is composed of the following elements: 1643 o base: All first class objects extend BasicObjType that contains 1644 the ID of the registrant organization that owns this object, the 1645 date and time that the object was created by the server, and the 1646 date and time that the object was last modified. If the client 1647 passes in either the created date or the modification date, the 1648 server will ignore them. The server sets these two date/time 1649 values. 1651 o rrName: The character string that contains the name of the Route 1652 Record. It uniquely identifies this object within the context 1653 of the registrant ID (a child element of the base element as 1654 described above). 1656 o priority: Zero or one priority value that can be used to provide 1657 a relative value weighting of one Route Record over another. 1658 The manner in which this value is used, perhaps in conjunction 1659 with other factors, is a matter of policy. 1661 As described above, route records are based on an abstract type: 1662 RteRecType. The concrete types that use RteRecType as an extension 1663 base are NAPTRType, NSType, and URIType. The definitions of these 1664 types are included below. The NAPTRType object is comprised of the 1665 data elements necessary for a NAPTR that contains routing information 1666 for a Route Group. The NSType object is comprised of the data 1667 elements necessary for a DNS name server that points to another DNS 1668 server that contains the desired routing information. The NSType is 1669 relevant only when the resolution protocol is ENUM. The URIType 1670 object is comprised of the data elements necessary to house a URI. 1672 The data provisioned in a registry can be leveraged for many purposes 1673 and queried using various protocols including SIP, ENUM and others. 1674 It is for this reason that a route record type offers a choice of URI 1675 and DNS resource record types. URIType fulfills the need for both 1676 SIP and ENUM protocols. When a given URIType is associated to a 1677 destination group, the user part of the replacement string that 1678 may require the Public Identifier cannot be preset. As a SIP 1679 Redirect, the resolution server will apply pattern on the input 1680 Public Identifier in the query and process the replacement string by 1681 substituting any back reference(s) in the to arrive at the 1682 final URI that is returned in the SIP Contact header. For an ENUM 1683 query, the resolution server will simply return the value of the 1684 and members of the URIType in the NAPTR REGEX parameter. 1686 1687 1688 1689 1690 1691 1692 1693 1695 1696 1697 1698 1699 1700 1701 1703 1704 1705 1706 1707 1708 1710 1711 1712 1713 1714 1715 1717 1718 1719 1720 1721 1722 1724 1726 1727 1728 1729 1730 1731 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1745 The NAPTRType object is composed of the following elements: 1747 o order: Order value in an ENUM NAPTR, relative to other NAPTRType 1748 objects in the same Route Group. 1750 o svcs: ENUM service(s) that are served by the SBE. This field's 1751 value must be of the form specified in [RFC6116] (e.g., E2U+ 1752 pstn:sip+sip). The allowable values are a matter of policy and 1753 not limited by this protocol. 1755 o regx: NAPTR's regular expression field. If this is not included 1756 then the Repl field must be included. 1758 o repl: NAPTR replacement field, should only be provided if the 1759 Regex field is not provided, otherwise the server will ignore it 1761 o ttl: Number of seconds that an addressing server may cache this 1762 NAPTR. 1764 o ext: Point of extensibility described in a previous section of 1765 this document. 1767 The NSType object is composed of the following elements: 1769 o hostName: Fully qualified host name of the name server. 1771 o ipAddr: Zero or more objects of type IpAddrType. Each object 1772 holds an IP Address and the IP Address type, IPv4 or IP v6. 1774 o ttl: Number of seconds that an addressing server may cache this 1775 DNS name server. 1777 o ext: Point of extensibility described in a previous section of 1778 this document. 1780 The URIType object is composed of the following elements: 1782 o ere: The POSIX Extended Regular Expression (ere) as defined in 1783 [RFC3986]. 1785 o uri: the URI as defined in [RFC3986]. In some cases, this will 1786 serve as the replacement string and it will be left to the 1787 resolution server to arrive at the final usable URI. 1789 As with the responses to all update operations, the result of the 1790 AddRteRecRqstType operation is contained in the generic 1791 spppUpdateResponse data structure described in an earlier sections of 1792 this document. For a detailed description of the spppUpdateResponse 1793 data structure refer to that section of the document. 1795 6.8. Get Route Records Operation 1797 The getRteRecsRqst operation allows an SPPP client to get the 1798 properties of Route Record objects that a registrar is authorized to 1799 view on behalf of the registrant. The server will attempt to find a 1800 Route Record object that has the registrant ID and route record name 1801 pair contained in each ObjKeyType object instance. If no ObjKeyType 1802 objects are found in the request then the server will return the list 1803 of all Route Record that belongs to the registrant. If there are no 1804 matching Route Record found then an empty result set will be 1805 returned. 1807 The element passed into the spppQueryRequest element for this 1808 operation is an instance of type GetRteRecsRqstType, which extends 1809 BasicUpdateRqstType and contains zero or more ObjKeyType objects. 1810 Any limitation on the maximum number of objects that may be passed 1811 into or returned by this operation is a policy decision and not 1812 limited by the protocol. The XSD declaration of the operation is as 1813 follows: 1815 1816 1817 1818 1819 1821 1822 1823 1824 1826 As described in an earlier section of this document, the result of 1827 any spppQueryRequest operation is an spppQueryResponse element that 1828 contains the overall response code and the query result set, if any. 1829 Refer to that section of the document for a detailed description of 1830 the spppQueryResponse element. 1832 6.9. Add Route Group Offer Operation 1834 The list of peer organizations whose resolution responses can include 1835 the routing information contained in a given Route Group is 1836 controlled by the organization to which a Route Group object belongs 1837 (its registrant), and the peer organization that submits resolution 1838 requests (a data recipient, also know as a peering organization). 1839 The registrant offers access to a Route Group by submitting a Route 1840 Group Offer. The data recipient can then accept or reject that 1841 offer. Not until access to a Route Group has been offered and 1842 accepted will the data recipient's organization ID be included in the 1843 peeringOrg list in a Route Group object, and that Route Group's 1844 peering information become a candidate for inclusion in the responses 1845 to the resolution requests submitted by that data recipient. The 1846 AddRteGrpOffersRqstType operation creates or overwrites one or more 1847 Route Group Offer objects. If a Route Group Offer for the given 1848 Route Group object key and the Org ID does not exist, 1849 then the server creates the Route Group Offer object. If a such a 1850 Route Group Offer does exist, then the server replaces the current 1851 object with the new object. The XSD declarations of the operation 1852 request object are as follows: 1854 1855 1856 1857 1858 1859 1860 1861 1862 1864 The element passed into the spppUpdateRequest element for this 1865 operation is an instance of AddRteGrpOfferRqstType, which extends 1866 BasicUpdateRqstType and contains a RteGrpOfferType object. The XSD 1867 declaration of the RteGrpOfferType is as follows: 1869 1870 1871 1872 1873 1875 1876 1877 1878 1879 1880 1881 1882 1884 1885 1886 1887 1888 1889 1891 1892 1893 1894 1895 1896 1897 The RteGrpOfferType object is composed of the following elements: 1899 o base: All first class objects extend BasicObjType that contains 1900 the ID of the registrant organization that owns this object, the 1901 date and time that the object was created by the server, and the 1902 date and time that the object was last modified. If the client 1903 passed in either the created date or the modification date, the 1904 will ignore them. The server sets these two date/time values. 1906 o rteGrpOfferKey: The object that identifies the route that is or 1907 has been offered and the organization that it is or has been 1908 offered to. The combination of these three data elements 1909 uniquely identify a Route Group Offer. 1911 o status: The status of the offer, offered or accepted. The 1912 server controls the status. It is automatically set to 1913 "offered" when ever a new Route Group Offer is added, and is 1914 automatically set to "accepted" if and when that offer is 1915 accepted. The value of the element is ignored when passed in by 1916 the client. 1918 o offerDateTime: Date and time in UTC when the Route Group Offer 1919 was added. 1921 o acceptDateTime: Date and time in UTC when the Route Group Offer 1922 was accepted. 1924 As with the responses to all update operations, the result of the 1925 AddRteGrpOfferRqstType operation is contained in the generic 1926 spppUpdateResponse data structure described in an earlier sections of 1927 this document. For a detailed description of the spppUpdateResponse 1928 data structure refer to that section of the document. 1930 6.10. Accept Route Group Offer Operation 1932 Not until access to a Route Group has been offered and accepted will 1933 the data recipient's organization ID will it be included in the 1934 peeringOrg list in that Route Group object, and that Route Group's 1935 peering information become a candidate for inclusion in the responses 1936 to the resolution requests submitted by that data recipient. The 1937 AcceptRteGrpOffersRqstType operation is called by, or on behalf of, 1938 the data recipient to accept a Route Group Offer that is pending in 1939 the "offered" status for the data recipient's organization ID. If a 1940 Route Group Offer for the given Route Group Offer key (route name, 1941 route registrant ID, data recipient's organization ID) exists, then 1942 the server moves the Route Group Offer to the "accepted" status and 1943 adds that data recipient's organization ID into the list of 1944 peerOrgIds for that Route Group. If a such a Route Group Offer does 1945 not exist, then the server returns the appropriate error code, 2105. 1946 The XSD declarations for the operation request object are as follows: 1948 1949 1950 1951 1952 1953 1954 1955 1956 1958 The element passed into the spppUpdateRequest element for this 1959 operation is an instance of AcceptRteGrpOffersRqstType, which extends 1960 BasicUpdateRqstType and contains a RteGrpOfferKeyType object. 1962 As with the responses to all update operations, the result of the 1963 AcceptRteGrpOfferRqstType operation is contained in the generic 1964 spppUpdateResponse data structure described in an earlier sections of 1965 this document. For a detailed description of the spppUpdateResponse 1966 data structure refer to that section of the document. 1968 6.11. Reject Route Group Offer Operation 1970 The data recipient to which a Route Group has been offered has the 1971 option of rejecting a Route Group Offer. Furthermore, that offer may 1972 be rejected, regardless of whether or not it has been previously 1973 accepted. The RejectRteGrpOffersRqstType operation is used for these 1974 purposes and is called by, or on behalf of, the data recipient to 1975 accept a Route Group Offer that is pending in the "offered" status or 1976 is in the "accepted" status for the data recipient's organization ID. 1977 If a Route Group Offer for the given Route Group Offer key (route 1978 name, route registrant ID, data recipient's organization ID) exists 1979 in either the offered or accepted status, then the server deletes 1980 that Route Group Offer object, and, if appropriate, removes the data 1981 recipient's organization ID from the list of peeringOrg IDs for that 1982 Route Group. If the Route Group Offer does not exist, then the 1983 server returns the appropriate error code, 2105. The XSD 1984 declarations for the operation request object are as follows: 1986 1987 1988 1989 1990 1991 1992 1993 1994 1996 The element passed into the spppUpdateRequest element for this 1997 operation is an instance of RejectRteGrpOffersRqstType, which extends 1998 BasicUpdateRqstType and contains a RteGrpOfferKeyType object. 2000 As with the responses to all update operations, the result of the 2001 RejectRteGrpOfferRqstType operation is contained in the generic 2002 spppUpdateResponse data structure described in an earlier sections of 2003 this document. For a detailed description of the spppUpdateResponse 2004 data structure refer to that section of the document. 2006 6.12. Get Route Group Offers Operation 2008 The getRteGrpOffersRqst operation allows an SPPP client to get the 2009 properties of zero or more Route Group Offer objects that registrar 2010 is authorized to view on behalf of the registrant. The server will 2011 attempt to find Route Group Offer objects that have all the 2012 properties specified in the criteria passed into the operation. If 2013 no criteria is passed in then the server will return the list of 2014 Route Group Offer objects that belongs to the registrant. If there 2015 are no matching Route Group Offers found then an empty result set 2016 will be returned. 2018 The element passed into the spppQueryRequest element for this 2019 operation is an instance of GetRteGrpOffersRqstType, which extends 2020 BasicQueryRqstType and contains the criteria that the returned Route 2021 Group Offer objects must match. Any limitation on the maximum number 2022 of objects that may be returned by this operation is a policy 2023 decision and not limited by the protocol. The XSD declaration of the 2024 operation is as follows: 2026 2027 2028 2029 2030 2032 2034 2036 2039 2040 2041 2042 2044 The GetRteGrpOffersRqstType object is composed of the following 2045 elements: 2047 o offeredBy: Zero or more organization IDs. Only offers that are 2048 offered to the organization IDs in this list should be included 2049 in the result set. The result set is also subject to other 2050 query criteria in the request. 2052 o offeredTo: Zero or more organization IDs. Only offers that are 2053 offered by the organization IDs in this list should be included 2054 in the result set. The result set is also subject to other 2055 query criteria in the request. 2057 o status: The status of the offer, offered or accepted. Only 2058 offers in the specified status should be included in the result 2059 set. If this element is not present then the status of the 2060 offer should not be considered in the query. The result set is 2061 also subject to other query criteria in the request. 2063 o rteGrpOfferKey: Zero or more Route Group Offer Keys. Only 2064 offers having one of these keys should be included in the result 2065 set. The result set is also subject to other query criteria in 2066 the request. 2068 As described in an earlier section of this document, the result of 2069 any spppQueryRequest operation is an spppQueryResponse element that 2070 contains the overall response code and the query result set, if any. 2071 Refer to that section of the document for a detailed description of 2072 the spppQueryResponse element. 2074 6.13. Egress Route Operations 2076 In a high-availability environment, the originating SSP likely has 2077 more than one egress paths to the ingress SBE of the target SSP. If 2078 the originating SSP wants to exercise greater control and choose a 2079 specific egress SBE to be associated to the target ingress SBE, it 2080 can do so using the AddEgrRteRqstType object. 2082 Lets assume that the target SSP has offered to share one or more 2083 ingress route information and that the originating SSP has accepted 2084 the offer. In order to add the egress route to the registry, the 2085 originating SSP uses a valid regular expression to rewrite ingress 2086 route in order to include the egress SBE information. Also, more 2087 than one egress route can be associated with a given ingress route in 2088 support of fault-tolerant configurations. The supporting SPPP 2089 structure provides a way to include route precedence information to 2090 help manage traffic to more than one outbound egress SBE. 2092 An egress route is identified by type EgrRteType and its object 2093 structure is shown below: 2095 2096 2097 2098 2099 2100 2101 2102 2104 2105 2106 2107 2108 2110 The EgrRteType object is composed of the following elements: 2112 o base: All first class objects extend BasicObjType that contains 2113 the ID of the registrant organization that owns this object, the 2114 date and time that the object was created by the server, and the 2115 date and time that the object was last modified. If the client 2116 passes in either the created date or the modification date, the 2117 server will ignore them. The server sets these two date/time 2118 values. 2120 o egrRteName: The name of the egress route. 2122 o pref: The preference of this egress route relative to other 2123 egress routes that may get selected when responding to a 2124 resolution request. 2126 o regxRewriteRule: The regular expression re-write rule that 2127 should be applied to the regular expression of the ingress 2128 NAPTR(s) that belong to the ingress route. 2130 o ingrRteRec: The ingress route records that the egress route 2131 should be used for. 2133 o ext: Point of extensibility described in a previous section of 2134 this document. 2136 The AddEgrRteRqstType request is used to create or overwrite an 2137 egress route. 2139 2140 2141 2142 2143 2144 2145 2146 2147 2149 An instance of AddEgrRtesRqstType is added in the spppUpdateRequest 2150 element in order to send a valid request to the server. Any 2151 limitation on the maximum number of AddEgrRteRqstType instances is a 2152 matter of policy and is not limited by the specification. 2154 The response from the server is returned in addEgrRteRspns element, 2155 which is defined as the element of type BasicRspnsType. 2157 The GetEgrRtesRqstType is used by an authorized entity to fetch the 2158 well-known egress route data. 2160 2161 2162 2163 2164 2166 2167 2168 2169 2171 6.14. Delete Operation 2173 In order to remove an object from the registry, an authorized entity 2174 can send the to the registry with a corresponding 2175 delete BasicUpdateRqstType object. Each 'Add' operation in SPPP has 2176 a corresponding 'Del' operation, which is used to delete the 2177 respective object type from the registry. If the entity that issued 2178 the command is not authorized to perform this operation an 2179 appropriate error code will be returned in the 2180 message. 2182 As an example, DelPubIdRqstType is used to delete Public Identifiers 2183 The DelPubIdsRqstType object definition is shown below: 2185 2186 2187 2188 2189 2190 2191 2192 2193 2195 When an object is deleted, any references to that object must of 2196 course also be removed as the SPPP server implementation fulfills the 2197 deletion request. Furthermore, the deletion of a composite object 2198 must also result in the deletion of the objects it contains. As a 2199 result, the following rules apply to the deletion of SPPP object 2200 types: 2202 o Destination Groups: When a destination group is deleted all 2203 public identifiers within that destination group must also be 2204 automatically deleted by the SPPP implementation as part of 2205 fulfilling the deletion request. And any references between 2206 that destination group and any route group must be automatically 2207 removed by the SPPP implementation as part of fulfilling the 2208 deletion request. 2210 o Route Groups: When a route group is deleted any references 2211 between that route group and any destination group must be 2212 automatically removed by the SPPP implementation as part of 2213 fulfilling the deletion request. Similarly any references 2214 between that route group and any route records must be removed 2215 by the SPPP implementation as part of fulfilling the deletion 2216 request. Furthermore, route group offers relating that route 2217 group must also be deleted as part of fulfilling the deletion 2218 request. 2220 o Route Records: When a route record is deleted any references 2221 between that route record and any route group must be removed by 2222 the SPPP implementation as part of fulfilling the deletion 2223 request. 2225 o Public Identifiers: When a public identifier is deleted any 2226 references between that public identifier and its containing 2227 destination group must be removed by the SPPP implementation as 2228 part of fulfilling the deletion request. And any route records 2229 contained directly within that Public Identifier must be deleted 2230 by the SPPP implementation as part of fulfilling the deletion 2231 request. 2233 7. SPPP Examples 2235 This section shows XML message exchange between two SIP Service 2236 Providers (SSP) and a registry. For the sake of simplicity, the 2237 transport wrapper for the SPPP is left out. The SPPP messages in 2238 this section are valid XML instances that conform to the SPPP schema 2239 version within this document. 2241 In this sample use case scenario, SSP1 and SSP2 provision resource 2242 data in the registry and use SPPP constructs to selectively share the 2243 route groups. In the figure below, SSP2 has two ingress SBE 2244 instances that are associated with the public identities that SSP2 2245 has the retail relationship with. Also, the two SBE instances for 2246 SSP1 are used to show how to use SPPP to associate route preferences 2247 for the destination ingress routes and exercise greater control on 2248 outbound traffic to the peer's ingress SBEs. 2250 ---------------+ +------------------ 2251 | | 2252 +------+ +------+ 2253 | sbe1 | | sbe2 | 2254 +------+ +------+ 2255 SSP1 | | SSP2 2256 +------+ +------+ 2257 | sbe3 | | sbe4 | 2258 +------+ +------+ 2259 iana-en:111 | | iana-en:222 2260 ---------------+ +------------------ 2261 | | 2262 | | 2263 | SPPP +------------------+ SPPP | 2264 +------->| Registry |<--------+ 2265 +------------------+ 2267 7.1. Add Destination Group 2269 SSP2 adds a destination group to the registry for use later. The 2270 SSP2 SPPP client sets a unique transaction identifier 'tx_7777' for 2271 tracking purposes. The name of the destination group is set to 2272 DEST_GRP_SSP2_1 2273 2274 2278 txid-5555 2279 2281 2282 iana-en:222 2283 DEST_GRP_SSP2_1 2284 2285 2286 2288 The registry processes the request and return a favorable response 2289 confirming successful creation of the named destination group. Also, 2290 besides returning a unique transaction identifier, Registry also 2291 returns the matching client transaction identifier from the request 2292 message back to the SPPP client. 2294 2295 2299 tx_5555 2300 tx_id_12346 2301 2302 1000 2303 success 2304 2305 2307 7.2. Add Route Records 2309 SSP2 adds an ingress routes in the registry. 2311 2312 2316 2318 2320 iana-en:222 2321 RTE_SSP2_SBE2 2322 10 2323 u 2324 E2U+sip 2325 2326 ^(.*)$ 2327 sip:\1@sbe2.ssp2.example.com 2328 2329 2330 2331 2333 The registry returns a success response. 2335 2336 2340 tx_id_11145 2341 2342 1000 2343 Request successful 2344 2345 2347 7.3. Add Route Records -- URIType 2349 SSP2 adds another ingress routes in the registry and makes use of 2350 URIType 2351 2352 2353 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 2354 xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd" 2355 xmlns="urn:ietf:params:xml:ns:sppp:base:1"> 2356 2358 2359 iana-en:222 2360 RTE_SSP2_SBE4 2361 ^(.*)$ 2362 sip:\1;npdi@sbe4.ssp2.example.com 2363 2364 2365 2367 The registry returns a success response. 2369 2370 2374 tx_id_11145 2375 2376 1000 2377 Request successful 2378 2379 2381 7.4. Add Route Group 2383 SSP2 creates the grouping of the ingress routes and choses higher 2384 precedence for RTE_SSP2_SBE2 by setting a lower number for the 2385 "priority" attribute, a protocol agnostic precedence indicator. 2387 2388 2392 2394 2395 iana-en:222 2396 RTE_GRP_SSP2_1 2397 2398 2399 iana-en:222 2400 RTE_SSP2_SBE2 2401 2402 100 2403 2404 DEST_GRP_SSP2_1 2405 true 2406 10 2407 2408 2409 2411 To confirm successful processing of this request, registry returns a 2412 well-known resolution code '1000' to the SSP2 client. 2414 2415 2419 tx_id_12345 2420 2421 1000 2422 Request successful 2423 2424 2426 7.5. Add Public Identity -- Successful COR claim 2428 SSP2 activates a TN public identity by associating it with a valid 2429 destination group. Further, SSP2 puts forth a claim that it is the 2430 carrier-of-record for the TN. 2432 2433 2436 txid-5577 2437 2439 2440 iana-en:222 2441 2010-05-30T09:30:10Z 2442 DEST_GRP_SSP2_1 2443 +12025556666 2444 2445 true 2446 2447 2448 2449 2451 Assuming that the registry has access to TN authority data and it 2452 performs the required checks to verify that SSP2 is in fact the 2453 service provider of record for the given TN, the request is processed 2454 successfully. In the response message, the registry sets the value 2455 of to "true" in order to confirm SSP2 claim as the carrier of 2456 record and the reflects the time when the carrier of record 2457 claim is processed. 2459 2460 2464 txid-5577 2465 tx_id_12345 2466 2467 1000 2468 success 2469 2470 2471 1000 2472 success 2473 2475 2476 iana-en:222 2477 2010-05-30T09:30:10Z 2478 DEST_GRP_SSP2_1 2479 +12025556666 2480 2481 true 2482 true 2483 2010-05-30T09:30:11Z 2484 2485 2486 2487 2488 2490 7.6. Add LRN 2492 If another entity that SSP2 shares the routes with has access to 2493 Number Portability data, it may choose to perform route lookups by 2494 routing number. Therefore, SSP2 associates a routing number to a 2495 destination group in order to facilitate ingress route discovery. 2497 2498 2501 2503 2505 iana-en:222 2506 DEST_GRP_SSP2_1 2507 2025550000 2508 2509 2510 2512 Registry completes the request successfully and returns a favorable 2513 response to the SPPP client. 2515 2516 2520 tx_id_12345 2521 2522 1000 2523 Request successful 2524 2525 2527 7.7. Add TN Range 2529 Next, SSP2 activates a block of ten thousand TNs and associate it to 2530 a destination group. 2532 2533 2536 2538 2539 iana-en:222 2540 DEST_GRP_SSP2_1 2541 +12026660000 2542 +12026669999 2543 2544 2545 2547 Registry completes the request successfully and returns a favorable 2548 response. 2550 2551 2555 tx_id_12244498 2556 2557 1000 2558 Request successful 2559 2560 2562 7.8. Add TN Prefix 2564 Next, SSP2 activates a block of ten thousand TNs using the TNPType 2565 structure and identifying a TN prefix. 2567 2568 2571 2573 2574 iana-en:222 2575 DEST_GRP_SSP2_1 2576 +1202777 2577 2578 2579 2581 Registry completes the request successfully and returns a favorable 2582 response. 2584 2585 2589 tx_id_12387698 2590 2591 1000 2592 Request successful 2593 2594 2596 7.9. Enable Peering -- Route Group Offer 2598 In order for SSP1 to complete session establishment for a destination 2599 TN where the target subscriber has a retail relationship with SSP2, 2600 it first requires an asynchronous bi-directional handshake to show 2601 mutual consent. To start the process, SSP2 initiates the peering 2602 handshake by offering SSP1 access to its route group. 2604 2605 2608 2610 2611 iana-en:222 2612 2613 2614 iana-en:222 2615 RTE_GRP_SSP2_1 2616 2617 iana-en:111 2618 2619 offered 2620 2006-05-04T18:13:51.0Z 2621 2622 2623 2625 Registry completes the request successfully and confirms that the 2626 SSP1 will now have the opportunity to weigh in on the offer and 2627 either accept or reject it. The registry may employ out-of-band 2628 notification mechanisms for quicker updates to SSP1 so they can act 2629 faster, though this topic is beyond the scope of this document. 2631 2632 2636 tx_id_12277798 2637 2638 1000 2639 Request successful 2640 2641 2643 7.10. Enable Peering -- Route Group Offer Accept 2645 SSP1 responds to the offer from SSP2 and agrees to have visibility to 2646 SSP2 ingress routes. 2648 2649 2652 2654 2655 2656 iana-en:222 2657 RTE_GRP_SSP2_1 2658 2659 iana-en:111 2660 2661 2662 2664 Registry confirms that the request has been processed successfully. 2665 From this point forward, if SSP1 looks up a public identity through 2666 the query resolution server, where the public identity is part of the 2667 destination group by way of "RTE_GRP_SSP2_1" route association, SSP2 2668 ingress SBE information will be shared with SSP1. 2670 2671 2675 tx_id_12333798 2676 2677 1000 2678 success 2679 2680 2682 7.11. Add Egress Route 2684 SSP1 wants to prioritize all outbound traffic to routes associated 2685 with "RTE_GRP_SSP2_1" route group through "sbe1.ssp1.example.com". 2687 2688 2691 tx_9000 2692 2694 2695 iana-en:111 2696 EGR_RTE_01 2697 50 2698 2699 ^(.*@)(.*)$ 2700 \1\2?route=sbe1.ssp1.example.com 2701 2702 2703 iana-en:222 2704 SSP2_RTE_REC_3 2705 2706 2707 2708 2710 Since peering has already been established, the request to add the 2711 egress route has been successfully completed. 2713 2714 2718 tx_9000 2719 tx_id_12388898 2720 2721 1000 2722 Request successful 2723 2724 2726 7.12. Get Destination Group 2728 SSP2 uses the 'GetDestGrpsRqstType' operation to tally the last 2729 provisioned record for destination group DEST_GRP_SSP2_1. 2731 2732 2735 2737 2738 iana-en:222 2739 DEST_GRP_SSP2_1 2740 2741 2742 2744 Registry completes the request successfully and returns a favorable 2745 response. 2747 2748 2751 2752 1000 2753 success 2754 2755 2757 iana-en:222 2758 DEST_GRP_SSP2_1 2759 2760 2762 7.13. Get Public Identity 2764 SSP2 obtains the last provisioned record associated with a given TN. 2766 2767 2770 2772 2774 iana-en:222 2775 +12025556666 2776 2777 2778 2780 Registry completes the request successfully and returns a favorable 2781 response. 2783 2784 2787 2788 1000 2789 success 2790 2791 2793 iana-en:222 2794 DEST_GRP_1 2795 +12025556666 2796 2797 true 2798 true 2799 2010-05-30T09:30:10Z 2800 2801 2802 2804 7.14. Get Route Group Request 2806 SSP2 obtains the last provisioned record for the route group 2807 RTE_GRP_SSP2_1. 2809 2810 2813 2815 2816 iana-en:222 2817 RTE_GRP_SSP2_1 2818 2819 2820 2822 Registry completes the request successfully and returns a favorable 2823 response. 2825 2826 2829 2830 1000 2831 success 2832 2833 2835 iana-en:222 2836 RTE_GRP_SSP2_1 2837 2838 2839 iana-en:222 2840 RTE_SSP2_SBE2 2841 2842 100 2843 2844 2845 2846 iana-en:222 2847 RTE_SSP2_SBE4 2848 2849 101 2850 2851 DEST_GRP_SSP2_1 2852 true 2853 10 2855 2856 2858 7.15. Get Route Group Offers Request 2860 SSP2 fetches the last provisioned route group offer to the 2861 SSP1. 2863 2864 2867 2869 iana-en:111 2870 2871 2873 Registry processes the request successfully and returns a favorable 2874 response. 2876 2877 2880 2881 1000 2882 success 2883 2884 2886 iana-en:222 2887 2888 2889 iana-en:222 2890 RTE_GRP_SSP2_1 2891 2892 iana-en:111 2893 2894 offered 2895 2006-05-04T18:13:51.0Z 2896 2898 2900 7.16. Get Egress Route 2902 SSP1 wants to verify the last provisioned record for the egress route 2903 called EGR_RTE_01. 2905 2906 2909 2911 2912 iana-en:111 2913 EGR_RTE_01 2914 2915 2916 2918 Registry completes the request successfully and returns a favorable 2919 response. 2921 2922 2925 2926 1000 2927 success 2928 2929 2931 iana-en:111 2932 EGR_RTE_01 2933 50 2934 E2U+sip 2935 2936 ^(.*)$ 2937 sip:\1@sbe1.ssp1.example.com 2938 2939 2940 iana-en:222 2941 RTE_GRP_SSP2_1 2942 2943 2944 2946 7.17. Delete Destination Group 2948 SSP2 initiates a request to delete the destination group 2949 DEST_GRP_SSP2_1. 2951 2952 2955 2957 2958 iana-en:222 2959 DEST_GRP_SSP2_1 2960 2961 2962 2964 Registry completes the request successfully and returns a favorable 2965 response. 2967 2968 2971 txid-982543123 2972 2973 1000 2974 Success 2975 2976 2978 7.18. Delete Public Identity 2980 SSP2 choses to de-activate the TN and remove it from the registry. 2982 2983 2986 2988 2990 iana-en:222 2991 +12025556666 2992 2993 2994 2996 Registry completes the request successfully and returns a favorable 2997 response. 2999 3000 3003 txid-98298273123 3004 3005 1000 3006 success 3007 3008 3010 7.19. Delete Route Group Request 3012 SSP2 removes the route group called RTE_GRP_SSP2_1. 3014 3015 3018 3020 3021 iana-en:222 3022 RTE_GRP_SSP2_1 3023 3024 3025 3027 Registry completes the request successfully and returns a favorable 3028 response. 3030 3031 3034 txid-982543123 3035 3036 1000 3037 msg 3038 3039 3041 7.20. Delete Route Group Offers Request 3043 SSP2 no longer wants to share route group RTE_GRP_SSP2_1 with SSP1. 3045 3046 3049 3051 3052 3053 iana-en:222 3054 RTE_GRP_SSP2_1 3055 3056 iana-en:111 3057 3058 3059 3061 Registry completes the request successfully and returns a favorable 3062 response. Restoring this resource sharing will require a new route 3063 group offer from SSP2 to SSP1 followed by a successful route group 3064 accept request from SSP1. 3066 3067 3070 txid-982543123 3071 3072 1000 3073 Success 3074 3075 3077 7.21. Delete Egress Route 3079 SSP1 decides to remove the egress route with the label EGR_RTE_01. 3081 3082 3085 3087 3088 iana-en:111 3089 EGR_RTE_01 3090 3091 3092 3094 Registry completes the request successfully and returns a favorable 3095 response. 3097 3098 3101 txid-982543123 3102 3103 1000 3104 Success 3105 3106 3108 8. XML Considerations 3110 XML serves as the encoding format for SPPP, allowing complex 3111 hierarchical data to be expressed in a text format that can be read, 3112 saved, and manipulated with both traditional text tools and tools 3113 specific to XML. 3115 XML is case sensitive. Unless stated otherwise, XML specifications 3116 and examples provided in this document MUST be interpreted in the 3117 character case presented to develop a conforming implementation. 3119 This section discusses a small number of XML-related considerations 3120 pertaining to SPPP. 3122 8.1. Namespaces 3124 All SPPP elements are defined in the namespaces in the IANA 3125 Considerations section and in the Formal Protocol Specification 3126 section of this document. 3128 8.2. Versioning and Character Encoding 3130 All XML instances SHOULD begin with an declaration to 3131 identify the version of XML that is being used, optionally identify 3132 use of the character encoding used, and optionally provide a hint to 3133 an XML parser that an external schema file is needed to validate the 3134 XML instance. 3136 Conformant XML parsers recognize both UTF-8 (defined in [RFC3629]) 3137 and UTF-16 (defined in [RFC2781]); per [RFC2277] UTF-8 is the 3138 RECOMMENDED character encoding for use with SPPP. 3140 Character encodings other than UTF-8 and UTF-16 are allowed by XML. 3141 UTF-8 is the default encoding assumed by XML in the absence of an 3142 "encoding" attribute or a byte order mark (BOM); thus, the "encoding" 3143 attribute in the XML declaration is OPTIONAL if UTF-8 encoding is 3144 used. SPPP clients and servers MUST accept a UTF-8 BOM if present, 3145 though emitting a UTF-8 BOM is NOT RECOMMENDED. 3147 Example XML declarations: 3149 3151 9. Security Considerations 3153 Many SPPP implementations manage data that is considered confidential 3154 and critical. Furthermore, SPPP implementations can support 3155 provisioning activities for multiple registrars and registrants. As 3156 a result any SPPP implementation must address the requirements for 3157 confidentiality, authentication, and authorization. 3159 With respect to confidentiality and authentication, the transport 3160 protocol requirements section of this document contains security 3161 properties that the transport protocol must provide so that 3162 authenticated endpoints can exchange data confidentially and with 3163 integrity protection. Refer to that section and the resulting 3164 transport protocol specification document for the specific solutions 3165 to authentication and confidentiality. 3167 With respect to authorization, the SPPP server implementation must 3168 define and implement a set of authorization rules that precisely 3169 address (1) which registrars will be authorized to create/modify/ 3170 delete each SPPP object type for given registrant(s) and (2) which 3171 registrars will be authorized to view/get each SPPP object type for 3172 given registrant(s). These authorization rules are a matter of 3173 policy and are not specified within the context of SPPP. However, 3174 any SPPP implementation must specify these authorization rules in 3175 order to function in a reliable and safe manner. 3177 In some situations, it may be required to protect against denial of 3178 involvement (see [RFC4949]) and tackle non-repudiation concerns in 3179 regards to SPPP messages. This type of protection is useful to 3180 satisfy authenticity concerns related to SPPP messages beyond the 3181 end-to-end connection integrity, confidentiality, and authentication 3182 protection that the transport layer provides. This is an optional 3183 feature and some SPPP implementations MAY provide support for it. 3185 It is not uncommon for the logging systems to document on-the-wire 3186 messages for various purposes, such as, debug, audit, and tracking. 3187 At the minimum, the various support and administration staff will 3188 have access to these logs. Also, if an unprivileged user gains 3189 access to the SPPP deployments and/or support systems, it will have 3190 access to the information that is potentially deemed confidential. 3191 To manage information disclosure concerns beyond the transport level, 3192 SPPP implementations MAY provide support for encryption at the SPPP 3193 object level. 3195 Anti-replay protection ensures that a given SPPP object replayed at a 3196 later time doesn't affect the integrity of the system. SPPP provides 3197 at least one mechanism to fight against replay attacks. Use of the 3198 optional client transaction identifier allows the SPPP client to 3199 correlate the request message with the response and to be sure that 3200 it is not a replay of a server response from earlier exchanges. Use 3201 of unique values for the client transaction identifier is highly 3202 encouraged to avoid chance matches to a potential replay message. 3204 The SPPP client or registrar can be a separate entity acting on 3205 behalf of the registrant in facilitating provisioning transactions to 3206 the registry. Further, the transport layer provides end-to-end 3207 connection protection between SPPP client and the SPPP server. 3208 Therefore, man-in-the-middle attack is a possibility that may affect 3209 the integrity of the data that belongs to the registrant and/or 3210 expose peer data to unintended actors in case well-established 3211 peering relationships already exist. 3213 10. IANA Considerations 3215 This document uses URNs to describe XML namespaces and XML schemas 3216 conforming to a registry mechanism described in [RFC3688]. 3218 Two URI assignments are requested. 3220 Registration request for the SPPP XML namespace: 3221 urn:ietf:params:xml:ns:sppp:base:1 3222 Registrant Contact: IESG 3223 XML: None. Namespace URIs do not represent an XML specification. 3225 Registration request for the XML schema: 3226 URI: urn:ietf:params:xml:schema:sppp:1 3227 Registrant Contact: IESG 3228 XML: See the "Formal Specification" section of this document 3229 (Section 11). 3231 IANA is requested to create a new SPPP registry for Organization 3232 Identifiers that will indicate valid strings to be used for well- 3233 known enterprise namespaces. 3234 This document makes the following assignments for the OrgIdType 3235 namespaces: 3237 Namespace OrgIdType namespace string 3238 ---- ---------------------------- 3239 IANA Enterprise Numbers iana-en 3241 11. Formal Specification 3243 This section provides the draft XML Schema Definition for SPPP. 3245 3246 3250 3251 3252 ------------------ Object Type Definitions -------------- 3253 3254 3255 3256 3257 3258 3259 3260 3262 3264 3266 3268 3269 3270 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3300 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3314 3315 3316 3317 3318 3319 3320 3321 3322 3323 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3336 3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 3347 3348 3349 3350 3351 3352 3353 3354 3355 3356 3357 3359 3360 3361 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3413 3414 3415 3416 3417 3418 3419 ------------------ Abstract Object and Element 3420 Type Definitions -------------- 3421 3422 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3495 3496 3497 3498 3499 3500 3501 3503 3504 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3531 3532 -------------- Operation Request and Response 3533 Object Type Definitions ------------ 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3551 3552 3553 3554 3555 3556 3557 3558 3559 3560 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3577 3578 3579 3580 3581 3582 3583 3584 3585 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3615 3616 3617 3618 3620 3621 3622 3623 3624 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642 3643 3645 3646 3647 3648 3649 3650 3651 3652 3653 3654 3655 3656 3657 3658 3659 3660 3661 3662 3663 3664 3665 3666 3667 3668 3669 3670 3671 3673 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3693 3694 3695 3696 3697 3698 3699 3700 3701 3703 3704 3705 3706 3707 3708 3709 3710 3711 3713 3714 3715 3716 3717 3718 3719 3720 3721 3724 3726 3728 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 3751 3752 3753 3754 3755 3756 3757 3759 3760 3761 3762 3763 3764 -------- Generic Request and Response Definitions 3765 --------------- 3766 3767 3768 3769 3770 3773 3775 3777 3778 3779 3780 3781 3782 3783 3785 3786 3787 3790 3791 3792 3793 3794 3795 3796 3798 3799 3800 3801 3802 3803 3804 3805 3806 3808 3809 3810 3811 3812 3813 3814 3816 3817 3818 3819 3820 3821 3822 3823 3824 3825 3826 3827 3828 12. Acknowledgments 3830 This document is a result of various discussions held in the DRINKS 3831 working group and within the DRINKS protocol design team, which is 3832 comprised of the following individuals, in alphabetical order: 3833 Alexander Mayrhofer, Deborah A Guyton, David Schwartz, Lisa 3834 Dusseault, Manjul Maharishi, Mickael Marrache, Otmar Lendl, Richard 3835 Shockey, Samuel Melloul, and Sumanth Channabasappa. 3837 13. References 3839 13.1. Normative References 3841 [I-D.ietf-drinks-sppp-over-soap] 3842 Cartwright, K., "SPPP Over SOAP and HTTP", 3843 draft-ietf-drinks-sppp-over-soap-05 (work in progress), 3844 September 2011. 3846 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3847 Requirement Levels", BCP 14, RFC 2119, March 1997. 3849 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 3850 Languages", BCP 18, RFC 2277, January 1998. 3852 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 3853 10646", STD 63, RFC 3629, November 2003. 3855 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3856 January 2004. 3858 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3859 Resource Identifier (URI): Generic Syntax", STD 66, 3860 RFC 3986, January 2005. 3862 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 3863 RFC 4949, August 2007. 3865 [RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM 3866 Requirements", RFC 5067, November 2007. 3868 13.2. Informative References 3870 [I-D.ietf-drinks-usecases-requirements] 3871 Channabasappa, S., "Data for Reachability of Inter/ 3872 tra-NetworK SIP (DRINKS) Use cases and Protocol 3873 Requirements", draft-ietf-drinks-usecases-requirements-06 3874 (work in progress), August 2011. 3876 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 3877 10646", RFC 2781, February 2000. 3879 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3880 A., Peterson, J., Sparks, R., Handley, M., and E. 3881 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3882 June 2002. 3884 [RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation 3885 Architecture", RFC 4725, November 2006. 3887 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 3888 October 2008. 3890 [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia 3891 Interconnect (SPEERMINT) Terminology", RFC 5486, 3892 March 2009. 3894 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 3895 Uniform Resource Identifiers (URI) Dynamic Delegation 3896 Discovery System (DDDS) Application (ENUM)", RFC 6116, 3897 March 2011. 3899 Authors' Addresses 3901 Jean-Francois Mule 3902 CableLabs 3903 858 Coal Creek Circle 3904 Louisville, CO 80027 3905 USA 3907 Email: jfm@cablelabs.com 3909 Kenneth Cartwright 3910 TNS 3911 1939 Roland Clarke Place 3912 Reston, VA 20191 3913 USA 3915 Email: kcartwright@tnsi.com 3917 Syed Wasim Ali 3918 NeuStar 3919 46000 Center Oak Plaza 3920 Sterling, VA 20166 3921 USA 3923 Email: syed.ali@neustar.biz 3925 Alexander Mayrhofer 3926 enum.at GmbH 3927 Karlsplatz 1/9 3928 Wien, A-1010 3929 Austria 3931 Email: alexander.mayrhofer@enum.at