draft-ietf-drinks-spp-protocol-over-soap-08.txt   draft-ietf-drinks-spp-protocol-over-soap-09.txt 
DRINKS K. Cartwright DRINKS K. Cartwright
Internet-Draft V. Bhatia Internet-Draft V. Bhatia
Intended status: Standards Track TNS Intended status: Standards Track TNS
Expires: January 23, 2016 J-F. Mule Expires: October 5, 2016 J-F. Mule
CableLabs CableLabs
A. Mayrhofer A. Mayrhofer
enum.at GmbH nic.at GmbH
July 22, 2015 April 3, 2016
Session Peering Provisioning (SPP) Protocol over SOAP Session Peering Provisioning (SPP) Protocol over SOAP
draft-ietf-drinks-spp-protocol-over-soap-08 draft-ietf-drinks-spp-protocol-over-soap-09
Abstract Abstract
The Session Peering Provisioning Framework (SPPF) specifies the data The Session Peering Provisioning Framework (SPPF) specifies the data
model and the overall structure to provision session establishment model and the overall structure to provision session establishment
data into Session Data Registries and SIP Service Provider data data into Session Data Registries and SIP Service Provider data
stores. To utilize this framework one needs a substrate protocol. stores. To utilize this framework one needs a substrate protocol.
Given that Simple Object Access Protocol (SOAP) is currently widely Given that Simple Object Access Protocol (SOAP) is currently widely
used for messaging between elements of such provisioning systems, used for messaging between elements of such provisioning systems,
this document specifies the usage of SOAP (via HTTPS) as the this document specifies the usage of SOAP (via HTTPS) as the
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 23, 2016. This Internet-Draft will expire on October 5, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SOAP Features and Protocol Layering . . . . . . . . . . . . . 4 3. SOAP Features and Protocol Layering . . . . . . . . . . . . . 4
4. HTTP(s) Features and SPP Protocol over SOAP . . . . . . . . . 7 4. HTTP(s) Features and SPP Protocol over SOAP . . . . . . . . . 7
5. Authentication, Integrity and Confidentiality . . . . . . . . 7 5. Authentication, Integrity and Confidentiality . . . . . . . . 7
6. Language Identification . . . . . . . . . . . . . . . . . . . 7 6. Language Identification . . . . . . . . . . . . . . . . . . . 7
7. SPP Protocol SOAP Data Structures . . . . . . . . . . . . . . 7 7. SPP Protocol SOAP Data Structures . . . . . . . . . . . . . . 7
7.1. Concrete Object Key Types . . . . . . . . . . . . . . . . 8 7.1. Concrete Object Key Types . . . . . . . . . . . . . . . . 8
7.1.1. Generic Object Key . . . . . . . . . . . . . . . . . 8 7.1.1. Generic Object Key . . . . . . . . . . . . . . . . . 8
7.1.2. Public Identity Object Key . . . . . . . . . . . . . 9 7.1.2. Public Identifier Object Key . . . . . . . . . . . . 9
7.1.3. SED Group Offer Key . . . . . . . . . . . . . . . . . 10 7.1.3. SED Group Offer Key . . . . . . . . . . . . . . . . . 10
7.2. Operation Request and Response Structures . . . . . . . . 10 7.2. Operation Request and Response Structures . . . . . . . . 11
7.2.1. Add Operation Structure . . . . . . . . . . . . . . . 11 7.2.1. Add Operation Structure . . . . . . . . . . . . . . . 11
7.2.2. Delete Operation Structure . . . . . . . . . . . . . 14 7.2.2. Delete Operation Structure . . . . . . . . . . . . . 14
7.2.3. Accept Operation Structure . . . . . . . . . . . . . 17 7.2.3. Accept Operation Structure . . . . . . . . . . . . . 17
7.2.4. Reject Operation Structure . . . . . . . . . . . . . 20 7.2.4. Reject Operation Structure . . . . . . . . . . . . . 20
7.2.5. Batch Operation Structure . . . . . . . . . . . . . . 23 7.2.5. Batch Operation Structure . . . . . . . . . . . . . . 23
7.2.6. Get Operation Structure . . . . . . . . . . . . . . . 26 7.2.6. Get Operation Structure . . . . . . . . . . . . . . . 26
7.2.7. Get SED Group Offers Operation Structure . . . . . . 27 7.2.7. Get SED Group Offers Operation Structure . . . . . . 27
7.2.8. Generic Query Response . . . . . . . . . . . . . . . 29 7.2.8. Generic Query Response . . . . . . . . . . . . . . . 29
7.2.9. Get Server Details Operation Structure . . . . . . . 29 7.2.9. Get Server Details Operation Structure . . . . . . . 29
7.3. Response Codes and Messages . . . . . . . . . . . . . . . 31 7.3. Response Codes and Messages . . . . . . . . . . . . . . . 31
7.4. Minor Version Identifier . . . . . . . . . . . . . . . . 33 7.4. Minor Version Identifier . . . . . . . . . . . . . . . . 33
8. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 33 8. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 33
9. SPP Protocol over SOAP WSDL Definition . . . . . . . . . . . 33 9. SPP Protocol over SOAP WSDL Definition . . . . . . . . . . . 33
10. SPP Protocol over SOAP Examples . . . . . . . . . . . . . . . 44 10. SPP Protocol over SOAP Examples . . . . . . . . . . . . . . . 45
10.1. Add Destination Group . . . . . . . . . . . . . . . . . 45 10.1. Add Destination Group . . . . . . . . . . . . . . . . . 45
10.2. Add SED Records . . . . . . . . . . . . . . . . . . . . 47 10.2. Add SED Records . . . . . . . . . . . . . . . . . . . . 47
10.3. Add SED Records -- URIType . . . . . . . . . . . . . . . 48 10.3. Add SED Records -- URIType . . . . . . . . . . . . . . . 48
10.4. Add SED Group . . . . . . . . . . . . . . . . . . . . . 49 10.4. Add SED Group . . . . . . . . . . . . . . . . . . . . . 49
10.5. Add Public Identity -- Successful COR claim . . . . . . 51 10.5. Add Public Identifier -- Successful COR claim . . . . . 51
10.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . 53 10.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . 53
10.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . 54 10.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . 54
10.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . 55 10.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . 55
10.9. Enable Peering -- SED Group Offer . . . . . . . . . . . 57 10.9. Enable Peering -- SED Group Offer . . . . . . . . . . . 57
10.10. Enable Peering -- SED Group Offer Accept . . . . . . . . 58 10.10. Enable Peering -- SED Group Offer Accept . . . . . . . . 58
10.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . 59 10.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . 59
10.12. Remove Peering -- SED Group Offer Reject . . . . . . . . 61 10.12. Remove Peering -- SED Group Offer Reject . . . . . . . . 61
10.13. Get Destination Group . . . . . . . . . . . . . . . . . 62 10.13. Get Destination Group . . . . . . . . . . . . . . . . . 62
10.14. Get Public Identity . . . . . . . . . . . . . . . . . . 64 10.14. Get Public Identifier . . . . . . . . . . . . . . . . . 64
10.15. Get SED Group Request . . . . . . . . . . . . . . . . . 65 10.15. Get SED Group Request . . . . . . . . . . . . . . . . . 65
10.16. Get SED Group Offers Request . . . . . . . . . . . . . . 67 10.16. Get SED Group Offers Request . . . . . . . . . . . . . . 67
10.17. Get Egress Route . . . . . . . . . . . . . . . . . . . . 69 10.17. Get Egress Route . . . . . . . . . . . . . . . . . . . . 69
10.18. Delete Destination Group . . . . . . . . . . . . . . . . 71 10.18. Delete Destination Group . . . . . . . . . . . . . . . . 71
10.19. Delete Public Identity . . . . . . . . . . . . . . . . . 72 10.19. Delete Public Identifier . . . . . . . . . . . . . . . . 72
10.20. Delete SED Group Request . . . . . . . . . . . . . . . . 73 10.20. Delete SED Group Request . . . . . . . . . . . . . . . . 73
10.21. Delete SED Group Offers Request . . . . . . . . . . . . 74 10.21. Delete SED Group Offers Request . . . . . . . . . . . . 74
10.22. Delete Egress Route . . . . . . . . . . . . . . . . . . 76 10.22. Delete Egress Route . . . . . . . . . . . . . . . . . . 76
10.23. Batch Request . . . . . . . . . . . . . . . . . . . . . 77 10.23. Batch Request . . . . . . . . . . . . . . . . . . . . . 77
11. Security Considerations . . . . . . . . . . . . . . . . . . . 79 11. Security Considerations . . . . . . . . . . . . . . . . . . . 79
11.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . . 80 11.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . . 80
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 80 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 81
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 81 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 81
14.1. Normative References . . . . . . . . . . . . . . . . . . 81 14.1. Normative References . . . . . . . . . . . . . . . . . . 81
14.2. Informative References . . . . . . . . . . . . . . . . . 81 14.2. Informative References . . . . . . . . . . . . . . . . . 82
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82
1. Introduction 1. Introduction
SPPF, defined in [I-D.draft-ietf-drinks-spp-framework], is best SPPF, defined in [I-D.draft-ietf-drinks-spp-framework], is best
supported by a transport and messaging infrastructure that is supported by a transport and messaging infrastructure that is
connection oriented, request-response oriented, easily secured, connection oriented, request-response oriented, easily secured,
supports propagation through firewalls in a standard fashion, and supports propagation through firewalls in a standard fashion, and
that is easily integrated into back-office systems. This is due to that is easily integrated into back-office systems. This is due to
the fact that the client side of SPPF is likely to be integrated with the fact that the client side of SPPF is likely to be integrated with
skipping to change at page 6, line 20 skipping to change at page 6, line 20
respectively, of the SOAP operation. respectively, of the SOAP operation.
SOAP faults are not used by the SPP Protocol over SOAP. All success SOAP faults are not used by the SPP Protocol over SOAP. All success
and error responses are specified in Section 7.3 of this document. and error responses are specified in Section 7.3 of this document.
However, if a SOAP fault were to occur, perhaps due to failures in However, if a SOAP fault were to occur, perhaps due to failures in
the SOAP message handling layer of a SOAP library, the client the SOAP message handling layer of a SOAP library, the client
application should capture and handle the fault. Specifics on how to application should capture and handle the fault. Specifics on how to
handle such SOAP faults, if they should occur, will be specific to handle such SOAP faults, if they should occur, will be specific to
the chosen SOAP implementation. the chosen SOAP implementation.
This document RECOMMENDS SOAP 1.2 [SOAPREF] or higher, and WSDL 1.1 Implementations MUST use SOAP 1.2 [SOAPREF] or higher, and MUST
[WSDLREF] or higher. support SOAP 1.2. Implementations SHOULD use WSDL 1.1 [WSDLREF], and
MUST NOT use earlier versions. Use of WSDL versions greater than 1.1
may introduce interopability problems with implementations that use
1.1.
SPPF is a request/reply framework that allows a client application to SPPF is a request/reply framework that allows a client application to
submit provisioning data and query requests to a server. The SPPF submit provisioning data and query requests to a server. The SPPF
data structures are designed to be protocol agnostic. Concerns data structures are designed to be protocol agnostic. Concerns
regarding encryption, non-repudiation, and authentication are beyond regarding encryption, non-repudiation, and authentication are beyond
the scope of this document. For more details, please refer to the scope of this document. For more details, please refer to
Section 4 ("Substrate Protocol Requirements") of Section 4 ("Substrate Protocol Requirements") of
[I-D.draft-ietf-drinks-spp-framework]. [I-D.draft-ietf-drinks-spp-framework].
As illustrated in the previous diagram, SPPF can be viewed as a set As illustrated in the previous diagram, SPPF can be viewed as a set
skipping to change at page 7, line 14 skipping to change at page 7, line 16
4. HTTP(s) Features and SPP Protocol over SOAP 4. HTTP(s) Features and SPP Protocol over SOAP
While SOAP is not tied to HTTP(S), for reasons described in the While SOAP is not tied to HTTP(S), for reasons described in the
introduction, HTTP(S) is a good choice as the substrate protocol for introduction, HTTP(S) is a good choice as the substrate protocol for
the SPP Protocol SOAP messages. HTTP 1.1 includes the "persistent the SPP Protocol SOAP messages. HTTP 1.1 includes the "persistent
connection" feature, which allows multiple HTTP request/response connection" feature, which allows multiple HTTP request/response
pairs to be transported across a single HTTP connection. This is an pairs to be transported across a single HTTP connection. This is an
important performance optimization feature, particularly when the important performance optimization feature, particularly when the
connections is an HTTPS connection where the relatively time connections is an HTTPS connection where the relatively time
consuming SSL handshake has occurred. consuming TLS handshake has occurred.
Implementations compliant with this document MUST use HTTP 1.1 Implementations compliant with this document MUST use HTTP 1.1
[RFC2616] or higher. Also, implementations SHOULD use persistent [RFC7230] or higher. Also, implementations SHOULD use persistent
connections. connections.
5. Authentication, Integrity and Confidentiality 5. Authentication, Integrity and Confidentiality
To accomplish authentication, conforming SPP Protocol over SOAP To accomplish authentication, conforming SPP Protocol over SOAP
Clients and Servers MUST use HTTP Digest Authentication as defined in Clients and Servers MUST use HTTP Digest Authentication as defined in
[RFC2617]. [RFC2617].
To achieve integrity and privacy, conforming SPP Protocol over SOAP To achieve integrity and privacy, conforming SPP Protocol over SOAP
Clients and Servers MUST support Transport Layer Security (TLS) as Clients and Servers MUST support Transport Layer Security (TLS) as
defined in [RFC5246] as the secure transport mechanism. defined in [RFC5246] as the secure transport mechanism. Use of TLS
MUST follow the recommendations contained in [RFC7525]
6. Language Identification 6. Language Identification
Section 9 of [I-D.draft-ietf-drinks-spp-framework] requires protocols Section 9 of [I-D.draft-ietf-drinks-spp-framework] requires protocols
to provide a mechanism to transmit language tags together with human- to provide a mechanism to transmit language tags together with human-
readable messages. When conforming SPP Protocol SOAP servers use readable messages. When conforming SPP Protocol SOAP servers use
such tagging, the XML "lang" attribute ([W3C.REC-xml-20081126], such tagging, the XML "lang" attribute ([W3C.REC-xml-20081126],
Section 2.12) MUST be used. Clients MAY use the HTTP "Accept- Section 2.12) MUST be used. Clients MAY use the HTTP "Accept-
Language" header field (see Section 14.4 of [RFC2616]) in order to Language" header field (see Section 5.3.5 of [RFC7231]) in order to
indicate their language preference. indicate their language preference.
7. SPP Protocol SOAP Data Structures 7. SPP Protocol SOAP Data Structures
SPP Protocol over SOAP uses a set of XML based data structures for SPP Protocol over SOAP uses a set of XML based data structures for
all the supported operations and any parameters that those operations all the supported operations and any parameters that those operations
are applied to. As also mentioned earlier in this document, these are applied to. As also mentioned earlier in this document, these
XML structures are envelope-independent and substrate-independent. XML structures are envelope-independent and substrate-independent.
Refer the "Protocol Operations" (Section 8) of this document for a Refer the "Protocol Operations" (Section 8) of this document for a
description of all the operations that MUST be supported. description of all the operations that MUST be supported.
skipping to change at page 9, line 18 skipping to change at page 9, line 20
<simpleType name="ObjKeyTypeEnum"> <simpleType name="ObjKeyTypeEnum">
<restriction base="token"> <restriction base="token">
<enumeration value="SedGrp"/> <enumeration value="SedGrp"/>
<enumeration value="DestGrp"/> <enumeration value="DestGrp"/>
<enumeration value="SedRec"/> <enumeration value="SedRec"/>
<enumeration value="EgrRte"/> <enumeration value="EgrRte"/>
</restriction> </restriction>
</simpleType> </simpleType>
7.1.2. Public Identity Object Key 7.1.2. Public Identifier Object Key
Public Identity type objects can further be of various sub-types like Public Identifier type objects can further be of various sub-types
a Telephone Number (TN), Routing Number (RN), TN Prefix, URI, or a TN like a Telephone Number (TN), Routing Number (RN), TN Prefix, URI, or
Range and cannot be cleanly identified with the attributes in the a TN Range and cannot be cleanly identified with the attributes in
generic ObjKeyType. The definition of PubIdKeyType is as below: the generic ObjKeyType. The definition of PubIdKeyType is as below:
<complexType name="PubIdKeyType"> <complexType name="PubIdKeyType">
<complexContent> <complexContent>
<extension base="sppfb:PubIdKeyType"> <extension base="sppfb:PubIdKeyType">
<sequence> <sequence>
<element name="rant" type="sppfb:OrgIdType"/> <element name="rant" type="sppfb:OrgIdType"/>
<choice> <choice>
<element name="number" <element name="number"
type="sppfb:NumberType"/> type="sppfb:NumberType"/>
<element name="range" <element name="range"
skipping to change at page 32, line 50 skipping to change at page 32, line 50
+--------+--------------------------+-------------------------------+ +--------+--------------------------+-------------------------------+
Table 1: Response Codes Numbering Scheme and Messages Table 1: Response Codes Numbering Scheme and Messages
Response message for response code 2001 is "parameterized" with the Response message for response code 2001 is "parameterized" with the
following parameter: "[Maximum requests supported]". When the following parameter: "[Maximum requests supported]". When the
request is too large, this parameter MUST be used to indicate the request is too large, this parameter MUST be used to indicate the
maximum number of requests supported by the server in a single maximum number of requests supported by the server in a single
protocol operation. protocol operation.
Response code 2000 SHOULD be used when the XML Schema validation of
requests fails.
Each of the object level response messages are "parameterized" with Each of the object level response messages are "parameterized" with
the following parameters: "AttributeName" and "AttributeValue". the following parameters: "AttributeName" and "AttributeValue".
For example, if an SPPF client sends a request to delete a For example, if an SPPF client sends a request to delete a
Destination Group with a name "TestDG", and it does not already Destination Group with a name "TestDG", and it does not already
exist, then the error message returned should be: "Attribute value exist, then the error message returned should be: "Attribute value
invalid. AttrName:dgName AttrVal:TestDG". invalid. AttrName:dgName AttrVal:TestDG".
The use of these parameters MUST adhere to the rules defined in The use of these parameters MUST adhere to the rules defined in
Section 5.3 of [I-D.draft-ietf-drinks-spp-framework]. Section 5.3 of [I-D.draft-ietf-drinks-spp-framework].
skipping to change at page 51, line 21 skipping to change at page 51, line 21
<clientTransId>txn_1479</clientTransId> <clientTransId>txn_1479</clientTransId>
<serverTransId>tx_12345</serverTransId> <serverTransId>tx_12345</serverTransId>
<overallResult> <overallResult>
<code>1000</code> <code>1000</code>
<msg>Request Succeeded.</msg> <msg>Request Succeeded.</msg>
</overallResult> </overallResult>
</ns3:spppAddResponse> </ns3:spppAddResponse>
</S:Body> </S:Body>
</S:Envelope> </S:Envelope>
10.5. Add Public Identity -- Successful COR claim 10.5. Add Public Identifier -- Successful COR claim
SSP2 activates a TN public identity by associating it with a valid SSP2 activates a TN public identifier by associating it with a valid
destination group. Further, SSP2 puts forth a claim that it is the destination group. Further, SSP2 puts forth a claim that it is the
carrier-of-record for the TN. carrier-of-record for the TN.
<soapenv:Envelope <soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1" xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/> <soapenv:Header/>
<soapenv:Body> <soapenv:Body>
skipping to change at page 59, line 5 skipping to change at page 59, line 5
<rant>iana-en:222</rant> <rant>iana-en:222</rant>
<name>SED_GRP_SSP2_1</name> <name>SED_GRP_SSP2_1</name>
<type>SedGrp</type> <type>SedGrp</type>
</sedGrpKey> </sedGrpKey>
<offeredTo>iana-en:111</offeredTo> <offeredTo>iana-en:111</offeredTo>
</sedGrpOfferKey> </sedGrpOfferKey>
</urn:spppAcceptRequest> </urn:spppAcceptRequest>
</soapenv:Body> </soapenv:Body>
</soapenv:Envelope> </soapenv:Envelope>
Registry confirms that the request has been processed successfully. Registry confirms that the request has been processed successfully.
From this point forward, if SSP1 looks up a public identity through From this point forward, if SSP1 looks up a public identifier through
the query resolution server, where the public identity is part of the the query resolution server, where the public identifier is part of
destination group by way of "SED_GRP_SSP2_1" session establishment the destination group by way of "SED_GRP_SSP2_1" session
data association, SSP2 ingress SBE information will be shared with establishment data association, SSP2 ingress SBE information will be
SSP1. shared with SSP1.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<S:Envelope <S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body> <S:Body>
<ns3:spppAcceptResponse <ns3:spppAcceptResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
<clientTransId>txn_1479</clientTransId> <clientTransId>txn_1479</clientTransId>
<serverTransId>tx_12350</serverTransId> <serverTransId>tx_12350</serverTransId>
skipping to change at page 62, line 5 skipping to change at page 62, line 5
<rant>iana-en:222</rant> <rant>iana-en:222</rant>
<name>SED_GRP_SSP2_1</name> <name>SED_GRP_SSP2_1</name>
<type>SedGrp</type> <type>SedGrp</type>
</sedGrpKey> </sedGrpKey>
<offeredTo>iana-en:111</offeredTo> <offeredTo>iana-en:111</offeredTo>
</sedGrpOfferKey> </sedGrpOfferKey>
</urn:spppRejectRequest> </urn:spppRejectRequest>
</soapenv:Body> </soapenv:Body>
</soapenv:Envelope> </soapenv:Envelope>
Registry confirms that the request has been processed successfully. Registry confirms that the request has been processed successfully.
From this point forward, if SSP1 looks up a public identity through From this point forward, if SSP1 looks up a public identifier through
the query resolution server, where the public identity is part of the the query resolution server, where the public identifier is part of
destination group by way of "SED_GRP_SSP2_1" session establishment the destination group by way of "SED_GRP_SSP2_1" session
data association, SSP2 ingress SBE information will not be shared establishment data association, SSP2 ingress SBE information will not
with SSP1 and hence SSP2 ingress SBE will not be returned in the be shared with SSP1 and hence SSP2 ingress SBE will not be returned
query response. in the query response.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<S:Envelope <S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body> <S:Body>
<ns3:spppRejectResponse <ns3:spppRejectResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
<clientTransId>txn_1479</clientTransId> <clientTransId>txn_1479</clientTransId>
<serverTransId>tx_12350</serverTransId> <serverTransId>tx_12350</serverTransId>
skipping to change at page 64, line 5 skipping to change at page 64, line 5
<resultObj xsi:type="ns2:DestGrpType"> <resultObj xsi:type="ns2:DestGrpType">
<ns2:rant>iana-en:222</ns2:rant> <ns2:rant>iana-en:222</ns2:rant>
<ns2:rar>iana-en:223</ns2:rar> <ns2:rar>iana-en:223</ns2:rar>
<ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate> <ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate>
<ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName> <ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>
</resultObj> </resultObj>
</ns3:spppGetResponse> </ns3:spppGetResponse>
</S:Body> </S:Body>
</S:Envelope> </S:Envelope>
10.14. Get Public Identity 10.14. Get Public Identifier
SSP2 obtains the last provisioned record associated with a given TN. SSP2 obtains the last provisioned record associated with a given TN.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope <soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1" xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/> <soapenv:Header/>
skipping to change at page 72, line 42 skipping to change at page 72, line 42
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
<serverTransId>tx_12354</serverTransId> <serverTransId>tx_12354</serverTransId>
<overallResult> <overallResult>
<code>1000</code> <code>1000</code>
<msg>Request Succeeded.</msg> <msg>Request Succeeded.</msg>
</overallResult> </overallResult>
</ns3:spppDelResponse> </ns3:spppDelResponse>
</S:Body> </S:Body>
</S:Envelope> </S:Envelope>
10.19. Delete Public Identity 10.19. Delete Public Identifier
SSP2 chooses to de-activate the TN and remove it from the registry. SSP2 chooses to de-activate the TN and remove it from the registry.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope <soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1" xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/> <soapenv:Header/>
skipping to change at page 79, line 43 skipping to change at page 79, line 43
<overallResult> <overallResult>
<code>1000</code> <code>1000</code>
<msg>Request Succeeded.</msg> <msg>Request Succeeded.</msg>
</overallResult> </overallResult>
</ns3:spppBatchResponse> </ns3:spppBatchResponse>
</S:Body> </S:Body>
</S:Envelope> </S:Envelope>
11. Security Considerations 11. Security Considerations
The base security considerations of SPPP outlined in Section 9 of
[I-D.draft-ietf-drinks-spp-framework] also apply to SPP Protocol over
SOAP implementations. Additionally, the following must be
considered:
SPP Protocol over SOAP is used to query and update session peering SPP Protocol over SOAP is used to query and update session peering
data and addresses, so the ability to access this protocol should be data and addresses, so the ability to access this protocol should be
limited to users and systems that are authorized to query and update limited to users and systems that are authorized to query and update
this data. Because this data is sent in both directions, it may not this data. Because this data is sent in both directions, it may not
be sufficient for just the client or user to be authenticated with be sufficient for just the client or user to be authenticated with
the server. The identity of the server should also be authenticated the server. The identity of the server should also be authenticated
by the client, which is often accomplished using the TLS certificate by the client, which is often accomplished using the TLS certificate
exchange and validation described in [RFC2818]. exchange and validation described in [RFC2818].
11.1. Vulnerabilities 11.1. Vulnerabilities
skipping to change at page 81, line 17 skipping to change at page 81, line 26
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.draft-ietf-drinks-spp-framework] [I-D.draft-ietf-drinks-spp-framework]
Cartwright, K., Bhatia, V., Ali, S., and D. Schwartz, Cartwright, K., Bhatia, V., Ali, S., and D. Schwartz,
"Session Peering Provisioning Framework", draft-ietf- "Session Peering Provisioning Framework", draft-ietf-
drinks-spp-framework-08 (work in progress), July 2015. drinks-spp-framework-08 (work in progress), July 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., <http://www.rfc-editor.org/info/rfc2119>.
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, DOI 10.17487/RFC2617, June 1999, RFC 2617, DOI 10.17487/RFC2617, June 1999,
<http://www.rfc-editor.org/info/rfc2617>. <http://www.rfc-editor.org/info/rfc2617>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
[SOAPREF] Gudgin, M., Hadley, M., Moreau, J., and H. Nielsen, "SOAP [SOAPREF] Gudgin, M., Hadley, M., Moreau, J., and H. Nielsen, "SOAP
Version 1.2 Part 1: Messaging Framework", W3C Version 1.2 Part 1: Messaging Framework", W3C
Recommendation REC-SOAP12-part1-20030624, June 2002. Recommendation REC-SOAP12-part1-20030624, June 2002.
14.2. Informative References 14.2. Informative References
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>. <http://www.rfc-editor.org/info/rfc2818>.
skipping to change at page 82, line 43 skipping to change at page 83, line 21
Jean-Francois Mule Jean-Francois Mule
CableLabs CableLabs
858 Coal Creek Circle 858 Coal Creek Circle
Louisville, CO 80027 Louisville, CO 80027
USA USA
Email: jfm@cablelabs.com Email: jfm@cablelabs.com
Alexander Mayrhofer Alexander Mayrhofer
enum.at GmbH nic.at GmbH
Karlsplatz 1/9 Karlsplatz 1/2/9
Wien A-1010 Wien A-1010
Austria Austria
Email: alexander.mayrhofer@enum.at Email: alexander.mayrhofer@nic.at
 End of changes. 32 change blocks. 
47 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/