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 3651 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