idnits 2.17.1 draft-ietf-drinks-spp-protocol-over-soap-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 22, 2014) is 3650 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) == Missing Reference: 'THISDOCUMENT' is mentioned on line 3351, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-drinks-spp-framework-06 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. 'SOAPREF' -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRINKS K. Cartwright 3 Internet-Draft V. Bhatia 4 Intended status: Standards Track TNS 5 Expires: October 24, 2014 J-F. Mule 6 CableLabs 7 A. Mayrhofer 8 enum.at GmbH 9 April 22, 2014 11 Session Peering Provisioning (SPP) Protocol over SOAP 12 draft-ietf-drinks-spp-protocol-over-soap-06 14 Abstract 16 The Session Peering Provisioning Framework (SPPF) specifies the data 17 model and the overall structure to provision session establishment 18 data into Session Data Registries and SIP Service Provider data 19 stores. To utilize this framework one needs a transport protocol. 20 Given that Simple Object Access Protocol (SOAP) is currently widely 21 used for messaging between elements of such provisioning systems, 22 this document specifies the usage of SOAP (via HTTPS) as the 23 transport protocol for SPPF. The benefits include leveraging 24 prevalent expertise, and a higher probability that existing 25 provisioning systems will be able to easily migrate to using an SPPF 26 based protocol. 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 October 24, 2014. 45 Copyright Notice 47 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. SOAP Features and Protocol Layering . . . . . . . . . . . . . 4 65 4. HTTP(s) Features and SPP Protocol over SOAP . . . . . . . . . 7 66 5. Authentication, Integrity and Confidentiality . . . . . . . . 7 67 6. Language Identification . . . . . . . . . . . . . . . . . . . 7 68 7. SPP Protocol SOAP Data Structures . . . . . . . . . . . . . . 7 69 7.1. Concrete Object Key Types . . . . . . . . . . . . . . . . 8 70 7.1.1. Generic Object Key . . . . . . . . . . . . . . . . . 8 71 7.1.2. Public Identity Object Key . . . . . . . . . . . . . 9 72 7.1.3. SED Group Offer Key . . . . . . . . . . . . . . . . . 10 73 7.2. Operation Request and Response Structures . . . . . . . . 10 74 7.2.1. Add Operation Structure . . . . . . . . . . . . . . . 11 75 7.2.2. Delete Operation Structure . . . . . . . . . . . . . 14 76 7.2.3. Accept Operation Structure . . . . . . . . . . . . . 17 77 7.2.4. Reject Operation Structure . . . . . . . . . . . . . 20 78 7.2.5. Batch Operation Structure . . . . . . . . . . . . . . 23 79 7.2.6. Get Operation Structure . . . . . . . . . . . . . . . 26 80 7.2.7. Get SED Group Offers Operation Structure . . . . . . 28 81 7.2.8. Generic Query Response . . . . . . . . . . . . . . . 29 82 7.2.9. Get Server Details Operation Structure . . . . . . . 30 83 7.3. Response Codes and Messages . . . . . . . . . . . . . . . 31 84 8. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 34 85 9. SPP Protocol over SOAP WSDL Definition . . . . . . . . . . . 34 86 10. SPP Protocol over SOAP Examples . . . . . . . . . . . . . . . 45 87 10.1. Add Destination Group . . . . . . . . . . . . . . . . . 46 88 10.2. Add SED Records . . . . . . . . . . . . . . . . . . . . 47 89 10.3. Add SED Records -- URIType . . . . . . . . . . . . . . . 49 90 10.4. Add SED Group . . . . . . . . . . . . . . . . . . . . . 50 91 10.5. Add Public Identity -- Successful COR claim . . . . . . 52 92 10.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . 54 93 10.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . 55 94 10.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . 56 95 10.9. Enable Peering -- SED Group Offer . . . . . . . . . . . 58 96 10.10. Enable Peering -- SED Group Offer Accept . . . . . . . . 59 97 10.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . 60 98 10.12. Remove Peering -- SED Group Offer Reject . . . . . . . . 62 99 10.13. Get Destination Group . . . . . . . . . . . . . . . . . 63 100 10.14. Get Public Identity . . . . . . . . . . . . . . . . . . 65 101 10.15. Get SED Group Request . . . . . . . . . . . . . . . . . 66 102 10.16. Get SED Group Offers Request . . . . . . . . . . . . . . 68 103 10.17. Get Egress Route . . . . . . . . . . . . . . . . . . . . 70 104 10.18. Delete Destination Group . . . . . . . . . . . . . . . . 72 105 10.19. Delete Public Identity . . . . . . . . . . . . . . . . . 73 106 10.20. Delete SED Group Request . . . . . . . . . . . . . . . . 74 107 10.21. Delete SED Group Offers Request . . . . . . . . . . . . 75 108 10.22. Delete Egress Route . . . . . . . . . . . . . . . . . . 77 109 10.23. Batch Request . . . . . . . . . . . . . . . . . . . . . 78 110 11. Security Considerations . . . . . . . . . . . . . . . . . . . 80 111 11.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . . 81 112 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 113 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 81 114 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 82 115 14.1. Normative References . . . . . . . . . . . . . . . . . . 82 116 14.2. Informative References . . . . . . . . . . . . . . . . . 82 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83 119 1. Introduction 121 SPPF, defined in [I-D.draft-ietf-drinks-spp-framework], is best 122 supported by a transport and messaging infrastructure that is 123 connection oriented, request-response oriented, easily secured, 124 supports propagation through firewalls in a standard fashion, and 125 that is easily integrated into back-office systems. This is due to 126 the fact that the client side of SPPF is likely to be integrated with 127 organizations' operational support systems that facilitate 128 transactional provisioning of user addresses and their associated 129 session establishment data. While the server side of SPPF is likely 130 to reside in a separate organization's network, resulting in the SPPF 131 provisioning transactions traversing the Internet as they are 132 propagated from the SPPF client to the SPPF server. Given the 133 current state of industry practice and technologies, SOAP and HTTP(S) 134 are well suited for this type of environment. This document 135 describes the specification for transporting SPPF XML structures over 136 SOAP and HTTP(S). 138 The specification in this document for transporting SPPF XML 139 structures over SOAP and HTTP(s) is primarily comprised of five 140 subjects: (1) a description of any applicable SOAP features, (2) any 141 applicable HTTP features, (3) security considerations, and perhaps 142 most importantly, (4) the Web Services Description Language (WSDL) 143 definition for SPP Protocol over SOAP, and (5) "transport" specific 144 XML Schema type definitions 146 2. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. 152 3. SOAP Features and Protocol Layering 154 The list of SOAP features that are explicitly used and required for 155 SPP Protocol over SOAP are limited. Most SOAP features are not 156 necessary for SPPF. SPP Protocol over SOAP primarily uses SOAP 157 simply as a standard message envelope technology. The SOAP message 158 envelope is comprised of the SOAP header and body. As described in 159 the SOAP specifications [SOAPREF], the SOAP header can contain 160 optional, application specific, information about the message. The 161 SOAP body contains the SPPF message itself, whose structure is 162 defined by the combination of one of the WSDL operations defined in 163 this document and the SPPF XML data structures defined in this 164 document and the SPPF document. SPPF does not rely on any data 165 elements in the SOAP header. All relevant data elements are defined 166 in the SPPF XML schema described in 167 [I-D.draft-ietf-drinks-spp-framework] and the SPPF WSDL types 168 specification described in this document and in 169 [I-D.draft-ietf-drinks-spp-framework]. 171 WSDL is a widely standardized and adopted technology for defining the 172 top-level structures of the messages that are transported within the 173 body of a SOAP message. The WSDL definition for the SPPF SOAP 174 messages is defined later in this document, which imports by 175 reference the XML data types contained in the SPPF schema. The IANA 176 registry where the SPPF schema resides is described in the IETF XML 177 Registry [RFC3688]. 179 There are multiple structural styles that WSDL allows. The best 180 practice for this type of application is what is sometimes referred 181 to as the "document/literal wrapped style". This style is generally 182 regarded as an optimal approach that enhances maintainability, 183 comprehension, portability, and, to a certain extent, performance. 184 It is characterized by setting the soapAction binding style as 185 "document", the soapAction encoding style as "literal", and then 186 defining the SOAP messages to simply contain a single data element 187 that "wraps" a data structure containing all the required input or 188 output data elements. The figure below illustrates this high level 189 technical structure as conceptual layers 3 through 6. 191 +-------------+ 192 (1) | Transport |Example: 193 | Protocol | TCP, TLS, BEEP, etc. 194 +-------------+ 195 | 196 V 197 +-------------+ 198 (2) | Message |Example: 199 | Envelope | HTTP, SOAP, None, etc. 200 +-------------+ 201 | 202 V 203 +--------------+ 204 +----| SOAP |---+ 205 |(3) | Operation | | 206 Contains | +--------------+ | Contains 207 | Example: | 208 V submitAddRqst V 209 +--------------+ +-------------+ 210 |SOAP Request | |SOAP Response| 211 Example: | Message | (4) | Message | Example: 212 spppAdd | (Operation | | (Operation | spppAdd 213 RequestMsg | Input) | | Output) | ResponseMsg 214 +--------------+ +-------------+ 215 | | 216 Contains | | Contains 217 | | 218 V V 219 +---------------+ +---------------+ 220 Example: | Wrapped | (5) | Wrapped | Example: 221 spppAdd |Request Object | |Response Object| spppAdd 222 Request +---------------+ +---------------+ Response 223 | | 224 Contains | | Contains 225 | | 226 V V 227 +-------------+ +---------------+ 228 | SPPF | | SPPF | 229 |XML Types | (6) | XML Types | 230 +-------------+ +---------------+ 232 Figure 1: Layering and Technical Structure of the SPP Protocol over 233 SOAP Messages 235 The operations supported by SPP Protocol over SOAP are normatively 236 defined later in this document. Each SOAP operation defines a 237 request/input message and a response/output message. Each such 238 request and response message then contains a single object that wraps 239 the SPPF XML data types that comprise the inputs and the outputs, 240 respectively, of the SOAP operation. 242 SOAP faults are not used by the SPP Protocol over SOAP. All success 243 and error responses are specified in Section 7.3 of this document. 244 However, if a SOAP fault were to occur, perhaps due to failures in 245 the SOAP message handling layer of a SOAP library, the client 246 application should capture and handle the fault. Specifics on how to 247 handle such SOAP faults, if they should occur, will be specific to 248 the chosen SOAP implementation. 250 This document RECOMMENDS SOAP 1.2 [SOAPREF] or higher, and WSDL 1.1 251 [WSDLREF] or higher. 253 SPPF is a request/reply framework that allows a client application to 254 submit provisioning data and query requests to a server. The SPPF 255 data structures are designed to be protocol agnostic. Concerns 256 regarding encryption, non-repudiation, and authentication are beyond 257 the scope of this document. For more details, please refer to 258 Section 4 ("Transport Protocol Requirements") of 259 [I-D.draft-ietf-drinks-spp-framework]. 261 As illustrated in the previous diagram, SPPF can be viewed as a set 262 of layers that collectively define the structure of an SPPF request 263 and response. Layers 1 and 2 represent the transport, envelope, and 264 authentication technologies. This document defines layers 3, 4, 5, 265 and 6 for SPP Protocol over SOAP. 267 1. Layer 1: The transport protocol layer represents the 268 communication mechanism between the client and server. SPPF can 269 be layered over any transport protocol that provides a set of 270 basic requirements defined in Section 4 of 271 [I-D.draft-ietf-drinks-spp-framework]. 273 2. Layer 2: The message envelope layer is optional, but can provide 274 features that are above the transport technology layer but below 275 the application messaging layer. Technologies such as HTTP and 276 SOAP are examples of messaging envelope technologies. 278 3. Layers 3,4,5,6: The operation and message layers provide an 279 envelope-independent and transport-independent wrapper for the 280 SPPF data model objects that are being acted on (created, 281 modified, queried). 283 4. HTTP(s) Features and SPP Protocol over SOAP 285 While SOAP is not tied to HTTP(S), for reasons described in the 286 introduction, HTTP(S) is a good choice as the transport mechanism for 287 the SPP Protocol SOAP messages. HTTP 1.1 includes the "persistent 288 connection" feature, which allows multiple HTTP request/response 289 pairs to be transported across a single HTTP connection. This is an 290 important performance optimization feature, particularly when the 291 connections is an HTTPS connection where the relatively time 292 consuming SSL handshake has occurred. 294 Implementations compliant with this document MUST use HTTP 1.1 295 [RFC2616] or higher. Also, implementations SHOULD use persistent 296 connections. 298 5. Authentication, Integrity and Confidentiality 300 To accomplish authentication, conforming SPP Protocol over SOAP 301 Clients and Servers MUST use HTTP Digest Authentication as defined in 302 [RFC2617]. 304 To achieve integrity and privacy, conforming SPP Protocol over SOAP 305 Clients and Servers MUST support Transport Layer Security (TLS) as 306 defined in [RFC5246] as the secure transport mechanism. 308 6. Language Identification 310 Section 9 of [I-D.draft-ietf-drinks-spp-framework] requires transport 311 protocols to provide a mechanism to transmit language tags together 312 with human-readable messages. When conforming SPP Protocol SOAP 313 servers use such tagging, the XML "lang" attribute 314 ([W3C.REC-xml-20081126], Section 2.12) MUST be used. Clients MAY use 315 the HTTP "Accept-Language" header field (see Section 14.4 of 316 [RFC2616]) in order to indicate their language preference. 318 7. SPP Protocol SOAP Data Structures 320 SPP Protocol over SOAP uses a set of XML based data structures for 321 all the supported operations and any parameters that those operations 322 are applied to. As also mentioned earlier in this document, these 323 XML structures are envelope-independent and transport-independent. 324 Refer the "Protocol Operations" (Section 8) of this document for a 325 description of all the operations that MUST be supported. 327 The following sections describe the definition all the XML data 328 structures. 330 7.1. Concrete Object Key Types 332 Certain operations in SPPF require an object key that uniquely 333 identifies the object(s) on which a given operation needs to be 334 performed. SPPF defines the XML structure of the any such object key 335 in an abstract manner and delegates the concrete representation to 336 any conforming transport protocol. The following sub-sections define 337 the various types of concrete object key types used in various 338 operations in SPP Protocol over SOAP. 340 7.1.1. Generic Object Key 342 Most objects in SPP Protocol over SOAP are uniquely identified by the 343 attributes in the generic object key (Refer Section 5.2.1 "Generic 344 Object Key Type" of [I-D.draft-ietf-drinks-spp-framework] for 345 details). The concrete XML representation of ObjKeyType is as below: 347 348 349 350 351 352 353 354 355 356 357 359 The ObjKeyType has the data elements as described below: 361 o rant: The identifier of the registrant organization that owns the 362 object. 364 o name: The character string that contains the name of the object. 366 o type: The enumeration value that represents the type of SPPF 367 object. For example, both a Destination Group and a SED Group can 368 have the same name "TestObj" and be associated with same 369 Registrant Id. Hence, to uniquely identify the object that 370 represents a Destination Group with the name "TestObj", the type 371 "DestGrp" must be specified when using this concrete ObjKeyType 372 structure to identify the Destination Group "TestObj". 374 The object types in SPP Protocol over SOAP MUST adhere to the above 375 definition of generic object key, and are defined as an enumeration 376 in the XML data structure as follows: 378 379 380 381 382 383 384 385 387 7.1.2. Public Identity Object Key 389 Public Identity type objects can further be of various sub-types like 390 a Telephone Number (TN), Routing Number (RN), TN Prefix, URI, or a TN 391 Range and cannot be cleanly identified with the attributes in the 392 generic ObjKeyType. The definition of PubIdKeyType is as below: 394 395 396 397 398 399 400 402 404 406 407 408 409 410 412 The PubIdKeyType has data elements, as described below: 414 o rant: The identifier of the registrant organization that owns the 415 object. 417 o number: An element of type NumberType (refer Section 12 of 418 [I-D.draft-ietf-drinks-spp-framework]) that contains the value and 419 type of a number . 421 o range: An element of type NumberRangeType (refer Section 12 of 422 [I-D.draft-ietf-drinks-spp-framework]) that contains a range of 423 numbers. 425 o uri: A value that represents a Public Identifier. 427 Any instance of PubIdKeyType MUST contain exactly one element from 428 the following set of elements: "number", "range", "uri". 430 7.1.3. SED Group Offer Key 432 In addition to the attributes in the generic ObjKeyType, a SED Group 433 Offer object is uniquely identified by the organization ID of the 434 organization to whom an SED Group has been offered. The definition 435 of SedGrpOfferKeyType is as below: 437 438 439 440 441 442 443 444 445 446 448 The SedGrpOfferKeyType has the data elements as described below: 450 o sedGrpKey: Identifies the SED Group that was offered. 452 o offeredTo: The organization ID of the organization that was 453 offered the SED Group object identified by the sedGrpKey. 455 7.2. Operation Request and Response Structures 457 An SPPF client interacts with an SPPF server by sending one or more 458 requests to the server, and by receiving corresponding responses from 459 the server. The basic set of operations that an SPPF client can 460 submit to an SPPF server and the semantics of those operations are 461 defined in Section 7 ("Framework Operations") of 462 [I-D.draft-ietf-drinks-spp-framework]. The following sub-sections 463 describe the XML data structures that are used for each of those 464 types of operations for a SPP Protocol over SOAP implementation. 466 7.2.1. Add Operation Structure 468 In order to add (or modify) an object in the registry, an authorized 469 entity can send the spppAddRequest to the registry. 471 An SPP Protocol over SOAP Add request is wrapped within the 472 element while an SPP Protocol over SOAP Add response 473 is wrapped within an element. The following sub- 474 sections describe the spppAddRequest and spppAddResponse elements. 475 Refer to Section 10 for an example of Add operation on each type of 476 SPPF object. 478 7.2.1.1. Add Request 480 An SPP Protocol over SOAP Add request definition is contained within 481 the generic element. 483 484 485 486 488 490 492 493 494 496 The data elements within the element are described 497 as follows: 499 o clientTransId: Zero or one client-generated transaction ID that, 500 within the context of the SPPF client, identifies this request. 501 This value can be used at the discretion of the SPPF client to 502 track, log or correlate requests and their responses. SPPF server 503 MUST echo back this value to the client in the corresponding 504 response to the incoming request. SPPF server will not check this 505 value for uniqueness. 507 o minorVer: Zero or one minor version identifier, indicating the 508 minor version of the SPPF API that the client is attempting to 509 use. This is used in conjunction with the major version 510 identifier in the XML namespace to identify the version of SPPF 511 that the client is using. If the element is not present, the 512 server assumes that the client is using the latest minor version 513 supported by the SPPF server for the given major version. The 514 versions supported by a given SPPF server can be retrieved by the 515 client using the "Get Server Details" operation described in 516 Section 7.2.9. 518 o obj: One or more elements of abstract type BasicObjType (defined 519 in [I-D.draft-ietf-drinks-spp-framework]). Each element contains 520 all the attributes of an SPPF object that that the client is 521 requesting the SPPF server to add. Refer to section 3.1 of 522 [I-D.draft-ietf-drinks-spp-framework] for the XML structure of all 523 concrete types, for various SPPF objects, that extend from 524 abstract BasicObjType and hence are eligible to be passed into 525 this element. The elements are processed by the SPPF server in 526 the order in which they are included in the request. With respect 527 to handling of error conditions, conforming SPPP SOAP servers MUST 528 stop processing BasicObjType elements in the request at the first 529 error, and roll back any BasicObjType elements that had already 530 been processed for that add request ("stop and rollback"). 532 7.2.1.2. Add Response 534 An SPP Protocol over SOAP add response object is contained within the 535 generic element. This response structure is used 536 for all types of SPPF objects that are provisioned by the SPPF 537 client. 539 540 541 542 544 545 546 548 549 550 552 553 554 555 556 557 559 560 561 562 563 564 565 566 567 569 An contains the elements necessary for the SPPF 570 client to precisely determine the overall result of the request, and 571 if an error occurred, it provides information about the specific 572 object(s) that caused the error. 574 The data elements within the SPP Protocol over SOAP Add response are 575 described as follows: 577 o clientTransId: Zero or one client transaction ID. This value is 578 simply an echo of the client transaction ID that SPPF client 579 passed into the SPPF update request. When included in the 580 request, the SPPF server MUST return it in the corresponding 581 response message. 583 o serverTransId: Exactly one server transaction ID that identifies 584 this request for tracking purposes. This value MUST be unique for 585 a given SPPF server. 587 o overallResult: Exactly one response code and message pair that 588 explicitly identifies the result of the request. See Section 7.3 589 for further details. 591 o detailResult: An optional response code, response message, and 592 BasicObjType (as defined in [I-D.draft-ietf-drinks-spp-framework]) 593 triplet. This element will be present only if an object level 594 error has occurred. It indicates the error condition and the 595 exact request object that contributed to the error. The response 596 code will reflect the exact error. See Section 7.3 for further 597 details. 599 7.2.2. Delete Operation Structure 601 In order to remove an object from the registry, an authorized entity 602 can send the spppDelRequest into the registry. An SPP Protocol over 603 SOAP Delete request is wrapped within the element 604 while a SPP Protocol over SOAP Delete response is wrapped within the 605 generic element. The following sub-sections 606 describe the spppDelRequest and spppDelResponse elements. Refer to 607 Section 10 for an example of Delete operation on each type of SPPF 608 object. 610 7.2.2.1. Delete Request 612 An SPP Protocol over SOAP Delete request definition is contained 613 within the generic element. 615 616 617 618 620 622 624 625 626 628 The data elements within the element are described 629 as follows: 631 o clientTransId: Zero or one client-generated transaction ID that, 632 within the context of the SPPF client, identifies this request. 633 This value can be used at the discretion of the SPPF client to 634 track, log or correlate requests and their responses. SPPF server 635 MUST echo back this value to the client in the corresponding 636 response to the incoming request. SPPF server will not check this 637 value for uniqueness. 639 o minorVer: Zero or one minor version identifier, indicating the 640 minor version of the SPPF API that the client is attempting to 641 use. This is used in conjunction with the major version 642 identifier in the XML namespace to identify the version of SPPF 643 that the client is using. If the element is not present, the 644 server assumes that the client is using the latest minor version 645 supported by the SPPF server for the given major version. The 646 versions supported by a given SPPF server can be retrieved by the 647 client using the Get Server Details Operation described in 648 Section 7.2.9. 650 o objKey: One or more elements of abstract type ObjKeyType (as 651 defined in [I-D.draft-ietf-drinks-spp-framework]). Each element 652 contains attributes that uniquely identify the object that the 653 client is requesting the server to delete. Refer to Section 7.1 654 for a description of all concrete object key types, for various 655 SPPF objects, which are eligible to be passed into this element. 656 The elements are processed by the SPPF server in the order in 657 which they are included in the request. With respect to handling 658 of error conditions, conforming SPPP SOAP servers MUST stop 659 processing ObjKeyType elements in the request at the first error, 660 and roll back any ObjKeyType elements that had already been 661 processed for that delete request ("stop and rollback"). 663 7.2.2.2. Delete Response 665 An SPP Protocol over SOAP delete response object is contained within 666 the generic element. This response structure is 667 used for a delete request on all types of SPPF objects that are 668 provisioned by the SPPF client. 670 671 672 673 675 676 677 679 680 681 683 684 685 686 687 688 690 691 692 693 694 695 696 697 698 700 An contains the elements necessary for the SPPF 701 client to precisely determine the overall result of the request, and 702 if an error occurred, it provides information about the specific 703 object key(s) that caused the error. 705 The data elements within the SPP Protocol over SOAP Delete response 706 are described as follows: 708 o clientTransId: Zero or one client transaction ID. This value is 709 simply an echo of the client transaction ID that SPPF client 710 passed into the SPPF update request. When included in the 711 request, the SPPF server MUST return it in the corresponding 712 response message. 714 o serverTransId: Exactly one server transaction ID that identifies 715 this request for tracking purposes. This value MUST be unique for 716 a given SPPF server. 718 o overallResult: Exactly one response code and message pair that 719 explicitly identifies the result of the request. See Section 7.3 720 for further details. 722 o detailResult: An optional response code, response message, and 723 ObjKeyType (as defined in [I-D.draft-ietf-drinks-spp-framework]) 724 triplet. This element will be present only if an specific object 725 key level error has occurred. It indicates the error condition 726 and the exact request object key that contributed to the error. 727 The response code will reflect the exact error. See Section 7.3 728 for further details. 730 7.2.3. Accept Operation Structure 732 In SPPF, a SED Group Offer can be accepted or rejected by, or on 733 behalf of, the registrant to whom the SED Group has been offered 734 (refer Section 3.1 of [I-D.draft-ietf-drinks-spp-framework] for a 735 description of the SED Group Offer object). The Accept operation is 736 used to accept such SED Group Offers by, or on behalf of, the 737 Registrant. The request structure for an SPP Protocol over SOAP 738 Accept operation is wrapped within the element 739 while an SPP Protocol over SOAP Accept response is wrapped within the 740 generic element. The following sub-sections 741 describe the spppAcceptRequest and spppAcceptResponse elements. 742 Refer to Section 10 for an example of Accept operation on a SED Group 743 Offer. 745 7.2.3.1. Accept Request Structure 747 An SPP Protocol over SOAP Accept request definition is contained 748 within the generic element. 750 751 752 753 755 757 760 761 762 764 The data elements within the element are 765 described as follows: 767 o clientTransId: Zero or one client-generated transaction ID that, 768 within the context of the SPPF client, identifies this request. 769 This value can be used at the discretion of the SPPF client to 770 track, log or correlate requests and their responses. SPPF server 771 MUST echo back this value to the client in the corresponding 772 response to the incoming request. SPPF server will not check this 773 value for uniqueness. 775 o minorVer: Zero or one minor version identifier, indicating the 776 minor version of the SPPF API that the client is attempting to 777 use. This is used in conjunction with the major version 778 identifier in the XML namespace to identify the version of SPPF 779 that the client is using. If the element is not present, the 780 server assumes that the client is using the latest minor version 781 supported by the SPPF server for the given major version. The 782 versions supported by a given SPPF server can be retrieved by the 783 client using the Get Server Details Operation described in 784 Section 7.2.9. 786 o sedGrpOfferKey: One or more elements of type SedGrpOfferKeyType 787 (as defined in this document). Each element contains attributes 788 that uniquely identify a SED Group Offer that the client is 789 requesting the server to accept. The elements are processed by 790 the SPPF server in the order in which they are included in the 791 request. With respect to handling of error conditions, conforming 792 SPPP SOAP servers MUST stop processing SedGrpOfferKeyType elements 793 in the request at the first error, and roll back any 794 SedGrpOfferKeyType elements that had already been processed for 795 that accept request ("stop and rollback"). 797 7.2.3.2. Accept Response 799 An SPP Protocol over SOAP accept response structure is contained 800 within the generic element. This response 801 structure is used for an Accept request on a SED Group Offer. 803 804 805 806 808 809 810 813 814 815 817 818 819 820 821 822 824 825 826 827 828 829 830 831 832 834 An contains the elements necessary for the SPPF 835 client to precisely determine the overall result of the request, and 836 if an error occurred, it provides information about the specific SED 837 Group Offer key(s) that caused the error. 839 The data elements within the SPP Protocol over SOAP Accept response 840 are described as follows: 842 o clientTransId: Zero or one client transaction ID. This value is 843 simply an echo of the client transaction ID that SPPF client 844 passed into the SPPF update request. When included in the 845 request, the SPPF server MUST return it in the corresponding 846 response message. 848 o serverTransId: Exactly one server transaction ID that identifies 849 this request for tracking purposes. This value MUST be unique for 850 a given SPPF server. 852 o overallResult: Exactly one response code and message pair that 853 explicitly identifies the result of the request. See Section 7.3 854 for further details. 856 o detailResult: An optional response code, response message, and 857 SedGrpOfferKeyType (as defined in this document) triplet. This 858 element will be present only if any specific SED Group Offer key 859 level error has occurred. It indicates the error condition and 860 the exact request SED Group Offer key that contributed to the 861 error. The response code will reflect the exact error. See 862 Section 7.3 for further details. 864 7.2.4. Reject Operation Structure 866 In SPPF, SED Group Offer can be accepted or rejected by, or on behalf 867 of, the registrant to whom the SED Group has been offered (refer 868 "Framework Data Model Objects" section of 869 [I-D.draft-ietf-drinks-spp-framework] for a description of the SED 870 Group Offer object). The Reject operation is used to reject such SED 871 Group Offers by, or on behalf of, the Registrant. The request 872 structure for an SPP Protocol over SOAP Reject operation is wrapped 873 within the element while an SPP Protocol over 874 SOAP Reject response is wrapped within the generic 875 element. The following sub-sections describe the 876 spppRejectRequest and spppRejecResponse elements. Refer to 877 Section 10 for an example of Reject operation on a SED Group Offer. 879 7.2.4.1. Reject Request 881 An SPP Protocol over SOAP Reject request definition is contained 882 within the generic element. 884 885 886 887 889 891 894 895 897 The data elements within the element are 898 described as follows: 900 o clientTransId: Zero or one client-generated transaction ID that, 901 within the context of the SPPF client, identifies this request. 902 This value can be used at the discretion of the SPPF client to 903 track, log or correlate requests and their responses. SPPF server 904 MUST echo back this value to the client in the corresponding 905 response to the incoming request. SPPF server will not check this 906 value for uniqueness. 908 o minorVer: Zero or one minor version identifier, indicating the 909 minor version of the SPPF API that the client is attempting to 910 use. This is used in conjunction with the major version 911 identifier in the XML namespace to identify the version of SPPF 912 that the client is using. If the element is not present, the 913 server assumes that the client is using the latest minor version 914 supported by the SPPF server for the given major version. The 915 versions supported by a given SPPF server can be retrieved by the 916 client using the Get Server Details Operation described in 917 Section 7.2.9. 919 o sedGrpOfferKey: One or more elements of type SedGrpOfferKeyType 920 (as defined in this document). Each element contains attributes 921 that uniquely identify a SED Group Offer that the client is 922 requesting the server to reject. The elements are processed by 923 the SPPF server in the order in which they are included in the 924 request. With respect to handling of error conditions, conforming 925 SPPF servers MUST stop processing SedGrpOfferKeyType elements in 926 the request at the first error, and roll back any 927 SedGrpOfferKeyType elements that had already been processed for 928 that reject request ("stop and rollback"). 930 7.2.4.2. Reject Response 932 An SPP Protocol over SOAP reject response structure is contained 933 within the generic element. This response 934 structure is used for an Reject request on a SED Group Offer. 936 937 938 939 941 942 943 946 947 948 950 951 952 953 954 955 957 958 959 960 961 962 963 964 965 967 An contains the elements necessary for the SPPF 968 client to precisely determine the overall result of the request, and 969 if an error occurred, it provides information about the specific SED 970 Group Offer key(s) that caused the error. 972 The data elements within the SPP Protocol over SOAP Reject response 973 are described as follows: 975 o clientTransId: Zero or one client transaction ID. This value is 976 simply an echo of the client transaction ID that SPPF client 977 passed into the SPPF update request. When included in the 978 request, the SPPF server MUST return it in the corresponding 979 response message. 981 o serverTransId: Exactly one server transaction ID that identifies 982 this request for tracking purposes. This value MUST be unique for 983 a given SPPF server. 985 o overallResult: Exactly one response code and message pair that 986 explicitly identifies the result of the request. See Section 7.3 987 for further details. 989 o detailResult: An optional response code, response message, and 990 SedGrpOfferKeyType (as defined in this document) triplet. This 991 element will be present only if any specific SED Group Offer key 992 level error has occurred. It indicates the error condition and 993 the exact request SED Group Offer key that contributed to the 994 error. The response code will reflect the exact error. See 995 Section 7.3 for further details. 997 7.2.5. Batch Operation Structure 999 An SPP Protocol over SOAP Batch request XML structure allows the SPPF 1000 client to send any of of Add, Del, Accept or Reject operations 1001 together in one single request. This gives an SPPF Client the 1002 flexibility to use one single request structure to perform more than 1003 operations (verbs). The batch request structure is wrapped within 1004 the element while a SPPF Batch response is wrapped 1005 within the element. This following sub-sections 1006 describe the spppBatchRequest and spppBatchResponse elements. Refer 1007 to Section 10 for an example of a batch operation. 1009 7.2.5.1. Batch Request Structure 1011 An SPP Protocol over SOAP Batch request definition is contained 1012 within the generic element. 1014 1015 1016 1017 1019 1021 1022 1023 1024 1026 1028 1029 1030 1031 1033 The data elements within the element are described 1034 as follows: 1036 o clientTransId: Zero or one client-generated transaction ID that, 1037 within the context of the SPPF Client, identifies this request. 1038 This value can be used at the discretion of the SPPF client to 1039 track, log or correlate requests and their responses. SPPF Server 1040 MUST echo back this value to the Client in the corresponding 1041 response to the incoming request. SPPF Server will not check this 1042 value for uniqueness. 1044 o minorVer: Zero or one minor version identifier, indicating the 1045 minor version of the SPPF API that the client is attempting to 1046 use. This is used in conjunction with the major version 1047 identifier in the XML namespace to identify the version of SPPF 1048 that the client is using. If the element is not present, the 1049 server assumes that the client is using the latest minor version 1050 supported by the SPPF server for the given major version. The 1051 versions supported by a given SPPF server can be retrieved by the 1052 client using the Get Server Details Operation described in 1053 Section 7.2.9. 1055 o addObj: One or more elements of abstract type BasicObjType where 1056 each element identifies an object that needs to be added. 1058 o delObj: One or more elements of abstract type ObjKeyType where 1059 each element identifies a key for the object that needs to be 1060 deleted . 1062 o acceptSedGrpOffer: One or more elements of type SedGrpOfferKeyType 1063 where each element identifies a SED Group Offer that needs to be 1064 accepted. 1066 o rejectSedGrpOffer: One or more elements of type SedGrpOfferKeyType 1067 where each element identifies a SED Group Offer that needs to be 1068 rejected. 1070 With respect to handling of error conditions, conforming SPPP SOAP 1071 servers MUST stop processing elements in the request at the first 1072 error, and roll back any elements that had already been processed for 1073 that batch request ("stop and rollback"). 1075 7.2.5.2. Batch Response 1077 An SPP Protocol over SOAP batch response structure is contained 1078 within the generic element. This response 1079 structure is used for an Batch request that contains many different 1080 types of SPPF operations. 1082 1083 1084 1085 1087 1088 1089 1090 1092 1094 1096 1098 1099 1100 1101 1103 An contains the elements necessary for an SPPF 1104 client to precisely determine the overall result of various 1105 operations in the request, and if an error occurred, it provides 1106 information about the specific objects or keys in the request that 1107 caused the error. 1109 The data elements within the SPP Protocol over SOAP Batch response 1110 are described as follows: 1112 o clientTransId: Zero or one client transaction ID. This value is 1113 simply an echo of the client transaction ID that SPPF client 1114 passed into the SPPF update request. When included in the 1115 request, the SPPF server MUST return it in the corresponding 1116 response message. 1118 o serverTransId: Exactly one server transaction ID that identifies 1119 this request for tracking purposes. This value MUST be unique for 1120 a given SPPF server. 1122 o overallResult: Exactly one response code and message pair that 1123 explicitly identifies the result of the request. See Section 7.3 1124 for further details. 1126 o addResult: One or more elements of type ObjResultCodeType where 1127 each element identifies the result code, result message and the 1128 specific object that the result relates to. 1130 o delResult: One or more elements of type ObjKeyResultCodeType where 1131 each element identifies the result code, result message and the 1132 specific object key that the result relates to. 1134 o acceptResult: One or more elements of type 1135 SedGrpOfferKeyResultCodeType where each element identifies the 1136 result code, result message and the specific SED Group Offer key 1137 that the result relates to. 1139 o rejectResult: One or more elements of type 1140 SedGrpOfferKeyResultCodeType where each element identifies the 1141 result code, result message and the specific SED Group Offer key 1142 that the result relates to. 1144 7.2.6. Get Operation Structure 1146 In order to query the details of an object from the Registry, an 1147 authorized entity can send the spppGetRequest to the registry with a 1148 GetRqstType XML data structure containing one or more object keys 1149 that uniquely identify the object whose details are being queried. 1150 The request structure for an SPP Protocol over SOAP Get operation is 1151 contained within the generic element while an SPP 1152 Protocol over SOAP Get response is wrapped within the generic 1153 element. The following sub-sections describe the 1154 spppGetRequest and spppGetResponse element. Refer to Section 10 for 1155 an example of SPP Protocol over SOAP Get operation on each type of 1156 SPPF object 1158 7.2.6.1. Get Request 1160 1161 1162 1163 1165 1168 1169 1170 1172 The data elements within the element are described 1173 as follows: 1175 o minorVer: Zero or one minor version identifier, indicating the 1176 minor version of the SPPF API that the client is attempting to 1177 use. This is used in conjunction with the major version 1178 identifier in the XML namespace to identify the version of SPPF 1179 that the client is using. If the element is not present, the 1180 server assumes that the client is using the latest minor version 1181 supported by the SPPF server for the given major version. The 1182 versions supported by a given SPPF server can be retrieved by the 1183 client using the Get Server Details Operation described in 1184 Section 7.2.9. 1186 o objKey: One or more elements of abstract type ObjKeyType (as 1187 defined in [I-D.draft-ietf-drinks-spp-framework]). Each element 1188 contains attributes that uniquely identify the object that the 1189 client is requesting the server to query. Refer to Section 7.1 of 1190 this document for a description of all concrete object key types, 1191 for various SPPF objects, which are eligible to be passed into 1192 this element. 1194 7.2.6.2. Get Response 1196 The spppGetResponse element is described in Section 7.2.8. 1198 7.2.7. Get SED Group Offers Operation Structure 1200 In addition to the ability to query the details of one or more SED 1201 Group offers using an a SED Group Offer key in the spppGetRequest, 1202 this operation also provides an additional, more flexible, structure 1203 to query for SED Group Offer objects. This additional structure is 1204 contained within the element while the 1205 response is wrapped within the generic element. 1206 The following sub-sections describe the getSedGrpOffersRequest and 1207 spppGetResponse elements. 1209 7.2.7.1. Get SED Group Offers Request 1211 Using the details passed into this structure, the server will attempt 1212 to find SED Group Offer objects that satisfy all the criteria passed 1213 into the request. If no criteria is passed in then the SPPF Server 1214 will return the list of SED Group Offer objects that belongs to the 1215 registrant. If there are no matching SED Group Offers found then an 1216 empty result set will be returned. 1218 1219 1220 1221 1223 1225 1227 1229 1231 1232 1233 1235 The data elements within the element are 1236 described as follows: 1238 o minorVer: Zero or one minor version identifier, indicating the 1239 minor version of the SPPF API that the client is attempting to 1240 use. This is used in conjunction with the major version 1241 identifier in the XML namespace to identify the version of SPPF 1242 that the client is using. If the element is not present, the 1243 server assumes that the client is using the latest minor version 1244 supported by the SPPF server for the given major version. The 1245 versions supported by a given SPPF server can be retrieved by the 1246 client using the Get Server Details Operation described in 1247 Section 7.2.9. 1249 o offeredBy: Zero or more organization IDs. Only offers that are 1250 offered to the organization IDs in this list should be included in 1251 the result set. The result set is also subject to other query 1252 criteria in the request. 1254 o offeredTo: Zero or more organization IDs. Only offers that are 1255 offered by the organization IDs in this list should be included in 1256 the result set. The result set is also subject to other query 1257 criteria in the request. 1259 o status: The status of the offer, offered or accepted. Only offers 1260 in the specified status should be included in the result set. If 1261 this element is not present then the status of the offer should 1262 not be considered in the query. The result set is also subject to 1263 other query criteria in the request. 1265 o sedGrpOfferKey: Zero or more SED Group Offer Keys. Only offers 1266 having one of these keys should be included in the result set. 1267 The result set is also subject to other query criteria in the 1268 request. 1270 7.2.7.2. Get SED Group Offers Response 1272 The spppGetResponse element is described in Section 7.2.8. 1274 7.2.8. Generic Query Response 1276 An SPP Protocol over SOAP query response object is contained within 1277 the generic element. 1279 1280 1281 1282 1284 1287 1288 1289 1291 An contains the elements necessary for the SPPF 1292 client to precisely determine the overall result of the query, and 1293 details of any SPPF objects that matched the criteria in the request. 1295 The data elements within the SPP Protocol over SOAP query response 1296 are described as follows: 1298 o overallResult: Exactly one response code and message pair that 1299 explicitly identifies the result of the request. See Section 7.3 1300 for further details. 1302 o resultObj: The set of zero or more objects that matched the query 1303 criteria. If no objects matched the query criteria then the 1304 result object(s) MUST be empty and the overallResult value MUST 1305 indicate success (if no matches are found for the query criteria, 1306 the response is considered a success). 1308 7.2.9. Get Server Details Operation Structure 1310 In order to query certain details of the SPPF server, such as the 1311 SPPF server's status and the major/minor version supported by the 1312 server, the Server Details operation structure SHOULD be used. This 1313 structure is contained within the element 1314 whereas a SPPF server status response is wrapped within the 1315 element. The following sub-sections 1316 describe the spppServerStatusRequest and spppServerStatusResponse 1317 elements. 1319 7.2.9.1. Get Server Details Request 1321 1322 1323 1324 1326 1327 1328 1330 The data elements within the element are 1331 described as follows: 1333 o minorVer: Zero or one minor version identifier, indicating the 1334 minor version of the SPP Protocol over SOAP API that the client is 1335 attempting to use. This is used in conjunction with the major 1336 version identifier in the XML namespace to identify the version of 1337 SPP Protocol over SOAP that the client is using. If the element 1338 is not present, the server assumes that the client is using the 1339 latest minor version of SPP Protocol over SOAP supported by the 1340 SPPF server for the given major version. The versions of SPP 1341 Protocol over SOAP supported by a given SPPF server can be 1342 retrieved by the client using this same spppServerStatusRequest 1343 without passing in the minorVer element. 1345 7.2.9.2. Get Server Details Response 1347 An SPP Protocol over SOAP server details response structure is 1348 contained within the generic element. 1350 1351 1352 1353 1354 1355 1356 1357 1359 The data elements within the element are 1360 described as follows: 1362 o overallResult: Exactly one response code and message pair that 1363 explicitly identifies the result of the request. See Section 7.3 1364 for further details. 1366 o svcMenu: Exactly one element of type SvcMenuType which in turn 1367 contains the elements to return the server status, the major and 1368 minor versions of the SPP Protocol over SOAP supported by the SPPF 1369 server (refer Section 12 of [I-D.draft-ietf-drinks-spp-framework] 1370 for definition of SvcMenuType). 1372 7.3. Response Codes and Messages 1374 This section contains the listing of response codes and their 1375 corresponding human-readable text. These response codes are in 1376 conformance with the response types defined in Section 5.3 of 1377 [I-D.draft-ietf-drinks-spp-framework]. 1379 The response code numbering scheme generally adheres to the theory 1380 formalized in section 4.2.1 of [RFC5321]: 1382 o The first digit of the response code can only be 1 or 2: 1 = a 1383 positive result, 2 = a negative result. 1385 o The second digit of the response code indicates the category: 0 = 1386 Protocol Syntax, 1 = Implementation Specific Business Rule, 2 = 1387 Security, 3 = Server System. 1389 o The third and fourth digits of the response code indicate the 1390 individual message event within the category defines by the first 1391 two digits. 1393 The response codes are also categorized as to whether they are 1394 overall response codes that may only be returned in the 1395 "overallResult" data element in SPPF responses, or object level 1396 response codes that may only be returned in the "detailResult" 1397 element of the SPPF responses. 1399 +--------+--------------------------+-------------------------------+ 1400 | Result | Result Message | Overall or Object Level | 1401 | Code | | | 1402 +--------+--------------------------+-------------------------------+ 1403 | 1000 | Request Succeeded. | Overall Response Code | 1404 | | | | 1405 | 2000 | Request syntax invalid. | Overall Response Code | 1406 | | | | 1407 | 2001 | Request too large. | Overall Response Code | 1408 | | MaxSupported:[Maximum | | 1409 | | requests supported] | | 1410 | | | | 1411 | 2002 | Version not supported. | Overall Response Code | 1412 | | | | 1413 | 2100 | Command invalid. | Overall Response Code | 1414 | | | | 1415 | 2300 | System temporarily | Overall Response Code | 1416 | | unavailable. | | 1417 | | | | 1418 | 2301 | Unexpected internal | Overall Response Code | 1419 | | system or server error. | | 1420 | | | | 1421 | 2101 | Attribute value invalid. | Object Level Response Code | 1422 | | AttrName:[AttributeName] | | 1423 | | AttrVal:[AttributeValue] | | 1424 | | | | 1425 | 2102 | Object does not exist. | Object Level Response Code | 1426 | | AttrName:[AttributeName] | | 1427 | | AttrVal:[AttributeValue] | | 1428 | | | | 1429 | 2103 | Object status or | Object Level Response Code | 1430 | | ownership does not allow | | 1431 | | for operation. | | 1432 | | AttrName:[AttributeName] | | 1433 | | AttrVal:[AttributeValue] | | 1434 +--------+--------------------------+-------------------------------+ 1436 Table 1: Response Codes Numbering Scheme and Messages 1438 Response message for response code 2001 is "parameterized" with the 1439 following parameter: "[Maximum requests supported]". When the 1440 request is too large, this parameter MUST be used to indicate the 1441 maximum number of requests supported by the server in a single 1442 protocol operation. 1444 Each of the object level response messages are "parameterized" with 1445 the following parameters: "AttributeName" and "AttributeValue". 1447 For example, if an SPPF client sends a request to delete a 1448 Destination Group with a name "TestDG", and it does not already 1449 exist, then the error message returned should be: "Attribute value 1450 invalid. AttrName:dgName AttrVal:TestDG". 1452 The use of these parameters MUST adhere to the rules defined in 1453 Section 5.3 of [I-D.draft-ietf-drinks-spp-framework]. 1455 8. Protocol Operations 1457 Refer to Section 7 of [I-D.draft-ietf-drinks-spp-framework] for a 1458 description of all SPPF operations, and any necessary semantics that 1459 MUST be adhered to in order to conform with SPPF. 1461 9. SPP Protocol over SOAP WSDL Definition 1463 The SPP Protocol over SOAP WSDL and data types are defined below. 1464 The WSDL design approach is commonly referred to as "Generic WSDL". 1465 It is generic in the sense that there is not a specific WSDL 1466 operation defined for each object type that is supported by the SPPF 1467 protocol. There is a single WSDL structure for each type of SPPF 1468 operation. Each such WSDL structure contains exactly one input 1469 structure and one output structure that wraps any data elements that 1470 are part of the incoming request and the outgoing response 1471 respectively. The spppSOAPBinding in the WSDL defines the binding 1472 style as "document" and the encoding as "literal". It is this 1473 combination of "wrapped" input and output data structures, "document" 1474 binding style, and "literal" encoding that characterize the Document 1475 Literal Wrapped style of WSDL specifications. 1477 Notes: The following WSDL has been formatted (e.g. tabs, spaces) to 1478 meet IETF document requirements. Deployments MUST replace 1479 "REPLACE_WITH_ACTUAL_URL" in the WSDL below with the URI of the SPPF 1480 Server instance. 1482 1483 1490 1491 1494 1495 1496 ---- Import base schema ---- 1497 1498 1499 1501 1502 1503 ---- Key type(s) extended 1504 from base schema. ---- 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1527 1528 1529 1530 1531 1533 1535 1536 1537 1538 1540 1541 1542 1543 1544 1545 1546 1548 1550 1551 1552 1553 1554 1556 1557 1558 ---- Generic Request and 1559 Response Definitions ---- 1560 1561 1562 1563 1564 1565 1567 1569 1571 1572 1573 1574 1575 1576 1577 1579 1581 1583 1584 1585 1586 1587 1588 1589 1591 1593 1596 1597 1598 1599 1600 1601 1602 1604 1606 1609 1610 1611 1612 1613 1614 1615 1617 1620 1621 1622 1623 1624 1625 1626 1628 1630 1631 1632 1633 1635 1637 1638 1640 1641 1642 1643 1644 1645 1647 1648 1649 1650 1651 1652 1653 1655 1658 1660 1662 1665 1666 1667 1668 1669 1670 1671 1673 1675 1677 1680 1681 1682 1683 1684 1685 1686 1688 1690 1692 1695 1696 1697 1698 1699 1700 1701 1703 1705 1707 1710 1711 1712 1713 1714 1715 1716 1718 1720 1722 1725 1726 1727 1728 1729 1730 1731 1733 1735 1737 1738 1740 1742 1744 1746 1747 1748 1749 1750 1751 1752 1753 1755 1758 1759 1760 1761 1762 1763 1764 1766 1768 1769 1770 1771 1772 1773 ---- Operation Result Type 1774 Definitions ---- 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1798 1799 1800 1801 1802 1803 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1829 1830 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1976 1977 1978 1979 1980 1981 1982 1983 1984 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2001 Figure 2: WSDL 2003 10. SPP Protocol over SOAP Examples 2005 This section shows XML message exchange between two SIP Service 2006 Providers (SSP) and a registry. The messages in this section are 2007 valid XML instances that conform to the SPP Protocol over SOAP schema 2008 version within this document. This section also relies on the XML 2009 data structures defined in the SPPF specification 2010 [I-D.draft-ietf-drinks-spp-framework]. Which should also be 2011 referenced to understand XML object types embedded in these example 2012 messages. 2014 In this sample use case scenario, SSP1 and SSP2 provision resource 2015 data in the registry and use SPPF constructs to selectively share the 2016 SED groups. In the figure below, SSP2 has two ingress SBE instances 2017 that are associated with the public identities that SSP2 has the 2018 retail relationship with. Also, the two Session Border Element 2019 instances for SSP1 are used to show how to use SPPF to associate 2020 route preferences for the destination ingress routes and exercise 2021 greater control on outbound traffic to the peer's ingress SBEs. 2023 ---------------+ +------------------ 2024 | | 2025 +------+ +------+ 2026 | sbe1 | | sbe2 | 2027 +------+ +------+ 2028 SSP1 | | SSP2 2029 +------+ +------+ 2030 | sbe3 | | sbe4 | 2031 +------+ +------+ 2032 iana-en:111 | | iana-en:222 2033 ---------------+ +------------------ 2034 | | 2035 | | 2036 | SPPF +------------------+ SPPF | 2037 +------->| Registry |<--------+ 2038 +------------------+ 2040 10.1. Add Destination Group 2042 SSP2 adds a destination group to the registry for use later. The 2043 SSP2 SPPF client sets a unique transaction identifier 'txn_1479' for 2044 tracking purposes. The name of the destination group is set to 2045 DEST_GRP_SSP2_1 2047 2048 2053 2054 2055 2056 2057 txn_1479 2058 2059 2060 iana-en:222 2061 iana-en:223 2062 DEST_GRP_SSP2_1 2063 2064 2065 2066 2067 The registry processes the request and return a favorable response 2068 confirming successful creation of the named destination group. Also, 2069 besides returning a unique server transaction identifier, Registry 2070 also returns the matching client transaction identifier from the 2071 request message back to the SPPF client. 2073 2074 2076 2077 2080 txn_1479 2081 tx_12345 2082 2083 1000 2084 Request Succeeded. 2085 2086 2087 2088 2090 10.2. Add SED Records 2092 SSP2 adds SED records in the form of ingress routes to the registry. 2094 2095 2100 2101 2102 2103 2104 txn_1479 2105 2106 2107 iana-en:222 2108 iana-en:223 2109 SED_SSP2_SBE2 2110 true 2111 10 2112 u 2113 E2U+sip 2114 2115 ^(.*)$ 2116 sip:\1@sbe2.ssp2.example.com 2117 2118 2119 2120 2121 2123 The registry returns a success response. 2125 2126 2128 2129 2132 txn_1479 2133 tx_12345 2134 2135 1000 2136 Request Succeeded. 2137 2138 2139 2140 2142 10.3. Add SED Records -- URIType 2144 SSP2 adds another SED record to the registry and makes use of URIType 2146 2147 2152 2153 2154 2155 txn_1479 2156 2157 2158 iana-en:222 2159 iana-en:223 2160 SED_SSP2_SBE4 2161 true 2162 ^(.*)$ 2163 sip:\1;npdi@sbe4.ssp2.example.com 2164 2165 2166 2167 2169 The registry returns a success response. 2171 2172 2173 2174 2177 txn_1479 2178 tx_12345 2179 2180 1000 2181 Request Succeeded. 2182 2183 2184 2185 2187 10.4. Add SED Group 2189 SSP2 creates the grouping of SED records (e.g. ingress routes) and 2190 chooses higher precedence for SED_SSP2_SBE2 by setting a lower number 2191 for the "priority" attribute, a protocol agnostic precedence 2192 indicator. 2194 2195 2200 2201 2202 2203 txn_1479 2204 2205 2206 iana-en:222 2207 iana-en:223 2208 SED_GRP_SSP2_1 2209 2210 2211 iana-en:222 2212 SED_SSP2_SBE2 2213 SedRec 2214 2215 100 2216 2217 DEST_GRP_SSP2_1 2218 true 2219 10 2220 2221 2222 2223 2225 To confirm successful processing of this request, registry returns a 2226 well-known result code '1000' to the SSP2 client. 2228 2229 2230 2231 2234 txn_1479 2235 tx_12345 2236 2237 1000 2238 Request Succeeded. 2239 2240 2241 2242 2244 10.5. Add Public Identity -- Successful COR claim 2246 SSP2 activates a TN public identity by associating it with a valid 2247 destination group. Further, SSP2 puts forth a claim that it is the 2248 carrier-of-record for the TN. 2250 2255 2256 2257 2258 txn_1479 2259 2260 2261 iana-en:222 2262 iana-en:223 2263 DEST_GRP_SSP2_1 2264 +12025556666 2265 2266 true 2267 2268 2269 2270 2271 2272 Assuming that the registry has access to TN authority data and it 2273 performs the required checks to verify that SSP2 is in fact the 2274 service provider of record for the given TN, the request is processed 2275 successfully. In the response message, the registry sets the value 2276 of to "true" in order to confirm SSP2 claim as the carrier of 2277 record and the reflects the time when the carrier of record 2278 claim is processed. 2280 2281 2284 2285 2288 txn_1479 2289 tx_12345 2290 2291 1000 2292 Request Succeeded. 2293 2294 2295 1000 2296 Request Succeeded. 2297 2298 iana-en:222 2299 iana-en:223 2300 2010-05-30T09:30:10Z 2301 DEST_GRP_SSP2_1 2302 +12025556666 2303 2304 true 2305 true 2306 2010-05-30T09:30:11Z 2307 2308 2309 2310 2311 2312 2314 10.6. Add LRN 2316 If another entity that SSP2 shares session establishment information 2317 (e.g. routes) with has access to Number Portability data, it may 2318 choose to perform route lookups by routing number. Therefore, SSP2 2319 associates a routing number to a destination group in order to 2320 facilitate ingress route discovery. 2322 2323 2328 2329 2330 2331 txn_1479 2332 2333 2334 iana-en:222 2335 iana-en:223 2336 DEST_GRP_SSP2_1 2337 2025550000 2338 2339 2340 2341 2343 Registry completes the request successfully and returns a favorable 2344 response to the SPPF client. 2346 2347 2349 2350 2353 txn_1479 2354 tx_12345 2355 2356 1000 2357 Request Succeeded. 2358 2359 2360 2361 2363 10.7. Add TN Range 2365 Next, SSP2 activates a block of ten thousand TNs and associate it to 2366 a destination group. 2368 2369 2374 2375 2376 2377 txn_1479 2378 2379 2380 iana-en:222 2381 iana-en:223 2382 DEST_GRP_SSP2_1 2383 2384 +12026660000 2385 +12026669999 2386 2387 2388 2389 2390 2391 Registry completes the request successfully and returns a favorable 2392 response. 2394 2395 2397 2398 2401 txn_1479 2402 tx_12345 2403 2404 1000 2405 Request Succeeded. 2406 2407 2408 2409 2411 10.8. Add TN Prefix 2413 Next, SSP2 activates a block of ten thousand TNs using the TNPType 2414 structure and identifying a TN prefix. 2416 2417 2422 2423 2424 2425 txn_1479 2426 2427 2428 iana-en:222 2429 iana-en:223 2430 DEST_GRP_SSP2_1 2431 +1202777 2432 2433 2434 2435 2437 Registry completes the request successfully and returns a favorable 2438 response. 2440 2441 2443 2444 2447 txn_1479 2448 tx_12345 2449 2450 1000 2451 Request Succeeded. 2452 2453 2454 2455 2457 10.9. Enable Peering -- SED Group Offer 2459 In order for SSP1 to complete session establishment for a destination 2460 TN where the target subscriber has a retail relationship with SSP2, 2461 it first requires an asynchronous bi-directional handshake to show 2462 mutual consent. To start the process, SSP2 initiates the peering 2463 handshake by offering SSP1 access to its SED group. 2465 2466 2471 2472 2473 2474 txn_1479 2475 2476 2477 iana-en:222 2478 iana-en:223 2479 2480 2481 iana-en:222 2482 SED_GRP_SSP2_1 2483 SedGrp 2484 2485 iana-en:111 2486 2487 offered 2488 2489 2006-05-04T18:13:51.0Z 2490 2491 2492 2493 2494 2496 Registry completes the request successfully and confirms that the 2497 SSP1 will now have the opportunity to weigh in on the offer and 2498 either accept or reject it. The registry may employ out-of-band 2499 notification mechanisms for quicker updates to SSP1 so they can act 2500 faster, though this topic is beyond the scope of this document. 2502 2503 2505 2506 2509 txn_1479 2510 tx_12345 2511 2512 1000 2513 Request Succeeded. 2514 2515 2516 2517 2519 10.10. Enable Peering -- SED Group Offer Accept 2521 SSP1 responds to the offer from SSP2 and agrees to have visibility to 2522 SSP2 session establishment information (e.g. ingress routes). 2524 2525 2528 2529 2530 2531 2532 txn_1479 2533 2534 2535 2536 iana-en:222 2537 SED_GRP_SSP2_1 2538 SedGrp 2539 2540 iana-en:111 2541 2542 2543 2544 2545 Registry confirms that the request has been processed successfully. 2546 From this point forward, if SSP1 looks up a public identity through 2547 the query resolution server, where the public identity is part of the 2548 destination group by way of "SED_GRP_SSP2_1" session establishment 2549 data association, SSP2 ingress SBE information will be shared with 2550 SSP1. 2552 2553 2555 2556 2559 txn_1479 2560 tx_12350 2561 2562 1000 2563 Request Succeeded. 2564 2565 2566 2567 2569 10.11. Add Egress Route 2571 SSP1 wants to prioritize all outbound traffic to the ingress route 2572 associated with the "SED_GRP_SSP2_1" SED Group record, through 2573 "sbe1.ssp1.example.com". 2575 2576 2581 2582 2583 2584 txn_1479 2585 2586 2587 iana-en:222 2588 iana-en:223 2589 EGR_RTE_01 2590 50 2591 2592 ^(.*@)(.*)$ 2593 \1\2?route=sbe1.ssp1.example.com 2594 2595 2596 iana-en:222 2597 SED_GRP_SSP2_1 2598 SedGrp 2599 2600 2601 2602 2603 2605 Since peering has already been established, the request to add the 2606 egress route has been successfully completed. 2608 2609 2611 2612 2615 txn_1479 2616 tx_12345 2617 2618 1000 2619 Request Succeeded. 2620 2621 2622 2623 2625 10.12. Remove Peering -- SED Group Offer Reject 2627 SSP1 had earlier accepted to have visibility to SSP2 session 2628 establishment data. SSP1 now decides to no longer maintain this 2629 visibility and hence rejects the SED Group Offer. 2631 2632 2635 2636 2637 2638 2639 txn_1479 2640 2641 2642 2643 iana-en:222 2644 SED_GRP_SSP2_1 2645 SedGrp 2646 2647 iana-en:111 2648 2649 2650 2651 2652 Registry confirms that the request has been processed successfully. 2653 From this point forward, if SSP1 looks up a public identity through 2654 the query resolution server, where the public identity is part of the 2655 destination group by way of "SED_GRP_SSP2_1" session establishment 2656 data association, SSP2 ingress SBE information will not be shared 2657 with SSP1 and hence SSP2 ingress SBE will not be returned in the 2658 query response. 2660 2661 2663 2664 2667 txn_1479 2668 tx_12350 2669 2670 1000 2671 Request Succeeded. 2672 2673 2674 2675 2677 10.13. Get Destination Group 2679 SSP2 uses the 'spppGetRequest' operation to tally the last 2680 provisioned record for destination group DEST_GRP_SSP2_1. 2682 2683 2687 2688 2689 2690 2691 2692 iana-en:222 2693 DEST_GRP_SSP2_1 2694 DestGrp 2695 2696 2697 2698 2700 Registry completes the request successfully and returns a favorable 2701 response. 2703 2704 2707 2708 2711 2712 1000 2713 success 2714 2715 2716 iana-en:222 2717 iana-en:223 2718 2012-10-22T09:30:10Z 2719 DEST_GRP_SSP2_1 2720 2721 2722 2723 2725 10.14. Get Public Identity 2727 SSP2 obtains the last provisioned record associated with a given TN. 2729 2730 2735 2736 2737 2738 2739 2740 iana-en:222 2741 2742 +12025556666 2743 TN 2744 2745 2746 2747 2748 2750 Registry completes the request successfully and returns a favorable 2751 response. 2753 2756 2757 2760 2761 1000 2762 success 2763 2764 2765 iana-en:222 2766 iana-en:223 2767 2012-10-22T09:30:10Z 2768 DEST_GRP_SSP2_1 2769 +12025556666 2770 2771 true 2772 true 2773 2010-05-30T09:30:10Z 2774 2775 2776 2777 2778 2780 10.15. Get SED Group Request 2782 SSP2 obtains the last provisioned record for the SED group 2783 SED_GRP_SSP2_1. 2785 2786 2790 2791 2792 2793 2794 2795 iana-en:222 2796 SED_GRP_SSP2_1 2797 SedGrp 2798 2799 2800 2801 2803 Registry completes the request successfully and returns a favorable 2804 response. 2806 2807 2810 2811 2814 2815 1000 2816 success 2817 2818 2819 iana-en:222 2820 iana-en:223 2821 2012-10-22T09:30:10Z 2822 SED_GRP_SSP2_1 2823 2824 2825 iana-en:222 2826 SED_SSP2_SBE2 2827 SedRec 2828 2829 100 2830 2831 2832 2833 iana-en:222 2834 SED_SSP2_SBE4 2835 SedRec 2836 2837 101 2838 2839 DEST_GRP_SSP2_1 2840 true 2841 10 2842 2843 2844 2845 2847 10.16. Get SED Group Offers Request 2849 SSP2 fetches the last provisioned SED group offer to the 2850 SSP1. 2852 2853 2856 2857 2858 2859 iana-en:111 2860 2861 2862 2864 Registry processes the request successfully and returns a favorable 2865 response. 2867 2868 2871 2872 2875 2876 1000 2877 success 2878 2879 2880 iana-en:222 2881 iana-en:223 2882 2012-10-22T09:30:10Z 2883 2885 2886 iana-en:222 2887 SED_GRP_SSP2_1 2888 SedGrp 2889 2890 iana-en:111 2891 2892 offered 2893 2894 2006-05-04T18:13:51.0Z 2895 2896 2897 2898 2899 2901 10.17. Get Egress Route 2903 SSP1 wants to verify the last provisioned record for the egress route 2904 called EGR_RTE_01. 2906 2907 2911 2912 2913 2914 2915 2916 iana-en:111 2917 EGR_RTE_01 2918 EgrRte 2919 2920 2921 2922 2924 Registry completes the request successfully and returns a favorable 2925 response. 2927 2928 2931 2932 2935 2936 1000 2937 success 2938 2939 2940 iana-en:222 2941 iana-en:223 2942 2012-10-22T09:30:10Z 2943 EGR_RTE_01 2944 50 2945 2946 ^(.*)$ 2947 sip:\1@sbe1.ssp1.example.com 2948 2949 2950 iana-en:222 2951 SED_GRP_SSP2_1 2952 SedRec 2953 2954 2955 2956 2957 2959 10.18. Delete Destination Group 2961 SSP2 initiates a request to delete the destination group 2962 DEST_GRP_SSP2_1. 2964 2965 2969 2970 2971 2972 2973 2974 iana-en:222 2975 DEST_GRP_SSP2_1 2976 DestGrp 2977 2978 2979 2980 2982 Registry completes the request successfully and returns a favorable 2983 response. 2985 2986 2988 2989 2992 tx_12354 2993 2994 1000 2995 Request Succeeded. 2996 2997 2998 2999 3001 10.19. Delete Public Identity 3003 SSP2 chooses to de-activate the TN and remove it from the registry. 3005 3006 3011 3012 3013 3014 3015 3016 iana-en:222 3017 3018 +12025556666 3019 TN 3020 3021 3022 3023 3024 3026 Registry completes the request successfully and returns a favorable 3027 response. 3029 3030 3032 3033 3036 tx_12354 3037 3038 1000 3039 Request Succeeded. 3040 3041 3042 3043 3045 10.20. Delete SED Group Request 3047 SSP2 removes the SED group called SED_GRP_SSP2_1. 3049 3050 3054 3055 3056 3057 3058 3059 iana-en:222 3060 SED_GRP_SSP2_1 3061 SedGrp 3062 3063 3064 3065 3067 Registry completes the request successfully and returns a favorable 3068 response. 3070 3071 3073 3074 3077 tx_12354 3078 3079 1000 3080 Request Succeeded. 3081 3082 3083 3084 3086 10.21. Delete SED Group Offers Request 3088 SSP2 no longer wants to share SED group SED_GRP_SSP2_1 with SSP1. 3090 3091 3095 3096 3097 3098 3099 3100 3101 iana-en:222 3102 SED_GRP_SSP2_1 3103 SedGrp 3104 3105 iana-en:111 3106 3107 3108 3109 3111 Registry completes the request successfully and returns a favorable 3112 response. Restoring this resource sharing will require a new SED 3113 group offer from SSP2 to SSP1 followed by a successful SED group 3114 accept request from SSP1. 3116 3117 3119 3120 3123 tx_12354 3124 3125 1000 3126 Request Succeeded. 3127 3128 3129 3130 3132 10.22. Delete Egress Route 3134 SSP1 decides to remove the egress route with the label EGR_RTE_01. 3136 3137 3141 3142 3143 3144 3145 3146 iana-en:111 3147 EGR_RTE_01 3148 EgrRte 3149 3150 3151 3152 3154 Registry completes the request successfully and returns a favorable 3155 response. 3157 3158 3160 3161 3164 tx_12354 3165 3166 1000 3167 Request Succeeded. 3168 3169 3170 3171 3173 10.23. Batch Request 3175 Following is an example of how some of the operations mentioned in 3176 previous sections MAY be performed by an SPPF client as a batch in 3177 one single SPP Protocol over SOAP request. 3179 In the sample request below SSP1 wants to accept a SED Group Offer 3180 from SSP3, add a Destination Group, add a NAPTR SED Record, add a SED 3181 Group, add a SED Group Offer, delete a previously provisioned TN type 3182 Public Identifier, delete a previously provisioned SED Group, and 3183 reject a SED Group Offer from SSP4. 3185 3186 3191 3192 3193 3194 txn_1467 3195 1 3197 3198 3199 iana-en:225 3200 SED_SSP3_SBE1_Offered 3201 SedGrp 3202 3203 iana-en:222 3204 3206 3207 iana-en:222 3208 iana-en:223 3209 DEST_GRP_SSP2_1 3210 3212 3213 iana-en:222 3214 iana-en:223 3215 SED_SSP2_SBE2 3216 10 3217 u 3218 E2U+sip 3219 3220 ^(.*)$ 3221 sip:\1@sbe2.ssp2.example.com 3222 3223 3225 3226 iana-en:222 3227 iana-en:223 3228 SED_GRP_SSP2_1 3229 3230 3231 iana-en:222 3232 SED_SSP2_SBE2 3233 SedRec 3234 3235 100 3236 3237 DEST_GRP_SSP2_1 3238 true 3239 10 3240 3242 3243 iana-en:222 3244 iana-en:223 3245 3246 3247 iana-en:222 3248 SED_GRP_SSP2_1 3249 SedGrp 3250 3251 iana-en:111 3252 3253 offered 3254 3255 2006-05-04T18:13:51.0Z 3256 3257 3259 3260 iana-en:222 3261 3262 +12025556666 3263 TN 3264 3265 3267 3268 iana-en:222 3269 SED_GRP_SSP2_Previous 3270 SedGrp 3271 3273 3274 3275 iana-en:226 3276 SED_SSP4_SBE1_Offered 3277 SedGrp 3278 3279 iana-en:222 3280 3282 3283 3284 3286 Registry completes the request successfully and returns a favorable 3287 response. 3289 3290 3292 3293 3296 tx_12354 3297 3298 1000 3299 Request Succeeded. 3300 3301 3302 3303 3305 11. Security Considerations 3307 SPP Protocol over SOAP is used to query and update session peering 3308 data and addresses, so the ability to access this protocol should be 3309 limited to users and systems that are authorized to query and update 3310 this data. Because this data is sent in both directions, it may not 3311 be sufficient for just the client or user to be authenticated with 3312 the server. The identity of the server should also be authenticated 3313 by the client, which is often accomplished using the TLS certificate 3314 exchange and validation described in [RFC2818]. 3316 11.1. Vulnerabilities 3318 Section 5 describes the use of HTTP and TLS as the underlying 3319 transport protocols for SPP Protocol over SOAP. These underlying 3320 protocols may have various vulnerabilities, and these may be 3321 inherited by SPP Protocol over SOAP. SPP Protocol over SOAP itself 3322 may have vulnerabilities because an authorization model is not 3323 explicitly specified in this document. 3325 During a TLS handshake, TLS servers can optionally request a 3326 certificate from a TLS client; that option is not a requirement for 3327 this protocol. This presents a denial of service risk in which 3328 unauthenticated clients can consume server CPU resources by creating 3329 TLS sessions. The risk is increased if the server supports client- 3330 initiated renegotiation. This risk can be mitigated by disabling 3331 client-initiated renegotiation on the server and by ensuring that 3332 other means (such as firewall access control lists) are used to 3333 restrict unauthenticated client access to servers. 3335 In conjunction with the above, it is important that SPP Protocol over 3336 SOAP implementations implement an authorization model that considers 3337 the source of each query or update request and determines whether it 3338 is reasonable to authorize that source to perform that specific query 3339 or update. 3341 12. IANA Considerations 3343 This document uses URNs to describe XML Namespaces and XML Schemas. 3344 According to [RFC3688], IANA is requested to perform the following 3345 URN assignment: 3347 URN: urn:ietf:params:xml:ns:sppf:soap:1 3349 Registrant Contact: IESG 3351 XML: See Section 9 of [THISDOCUMENT] 3353 13. Acknowledgements 3355 This document is a result of various discussions held with the IETF 3356 DRINKS working group, specifically the protocol design team, with 3357 contributions from the following individuals, in alphabetical order: 3358 Alexander Mayrhofer, David Schwartz, Deborah A Guyton, Jean-Francois 3359 Mule Kenneth Cartwright, Lisa Dusseault, Manjul Maharishi, Mickael 3360 Marrache, Otmar Lendl, Peter Saint-Andre, Richard Shockey, Samuel 3361 Melloul, Scott Hollenbeck, Sumanth Channabasappa, Syed Ali, and Vikas 3362 Bhatia . 3364 14. References 3366 14.1. Normative References 3368 [I-D.draft-ietf-drinks-spp-framework] 3369 Cartwright, K., Bhatia, V., Ali, S., and D. Schwartz, 3370 "Session Peering Provisioning Framework", draft-ietf- 3371 drinks-spp-framework-06 (work in progress), October 2013. 3373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3374 Requirement Levels", BCP 14, RFC 2119, March 1997. 3376 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3377 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3378 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3380 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 3381 Leach, P., Luotonen, A., and L. Stewart, "HTTP 3382 Authentication: Basic and Digest Access Authentication", 3383 RFC 2617, June 1999. 3385 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3386 January 2004. 3388 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3389 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 3391 [SOAPREF] Gudgin, M., Hadley, M., Moreau, J., and H. Nielsen, "SOAP 3392 Version 1.2 Part 1: Messaging Framework", W3C 3393 Recommendation REC-SOAP12-part1-20030624, June 2002. 3395 14.2. Informative References 3397 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 3399 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 3400 October 2008. 3402 [W3C.REC-xml-20081126] 3403 Sperberg-McQueen, C., Yergeau, F., Bray, T., Maler, E., 3404 and J. Paoli, "Extensible Markup Language (XML) 1.0 (Fifth 3405 Edition)", World Wide Web Consortium Recommendation REC- 3406 xml-20081126, November 2008, 3407 . 3409 [WSDLREF] Christensen, E., Curbera, F., Meredith, G., and S. 3410 Weerawarana, "Web Services Description Language (WSDL) 3411 1.1", W3C Note NOTE-wsdl-20010315, March 2001. 3413 Authors' Addresses 3415 Kenneth Cartwright 3416 TNS 3417 1939 Roland Clarke Place 3418 Reston, VA 20191 3419 USA 3421 Email: kcartwright@tnsi.com 3423 Vikas Bhatia 3424 TNS 3425 1939 Roland Clarke Place 3426 Reston, VA 20191 3427 USA 3429 Email: vbhatia@tnsi.com 3431 Jean-Francois Mule 3432 CableLabs 3433 858 Coal Creek Circle 3434 Louisville, CO 80027 3435 USA 3437 Email: jfm@cablelabs.com 3439 Alexander Mayrhofer 3440 enum.at GmbH 3441 Karlsplatz 1/9 3442 Wien A-1010 3443 Austria 3445 Email: alexander.mayrhofer@enum.at