Session Peering Provisioning (SPP) Protocol over SOAP
draft-ietf-drinks-spp-protocol-over-soap-09

I have no objection to the publication of this document, but SOAP, really? I thought we had moved on.

-- Section 4 --

   Implementations compliant with this document MUST use HTTP 1.1
   [RFC2616] or higher.  Also, implementations SHOULD use persistent
   connections.

You could remove "compliant with this document".  But more importantly, the "SHOULD" is not an interoperability requirement.  I'd rather see "implementations should use persistent connections for the performance reasons specified above."  But this is non-blocking, and there's no need to discuss it.

Also, RFC 2616 is obsolete.  The current reference for HTTP 1.1 is RFC 7230, and this reference needs to be changed to that.

-- Section 5 --
I support Stephen's DISCUSS here.  Further on what he says in his comment, this MUST requirement locks you into Digest for all time, regardless of what other authentication mechanisms might be defined and deployed later.  That doesn't seem wise.

If the real point here is that there are two mechanisms (Basic and Digest), and you want to use Digest because you don't want Basic, then maybe that's how you should say it: ban Basic rather than requiring Digest.

Roni Even's Gen-ART review raised some questions that should be answered, I think.

Thanks for your work on this draft.  I have some comments and suggestions that I'd like to be considered:

Section 4:
Instead of HTTP(S), I'd prefer to see HTTP/TLS. Would that cause any heartburn?  It would make the text consistent with the next section.

Please change SSL to TLS in this section as well.

Section 5:
OK, I see you have TLS listed here, along with a minimum version by reference to the RFC for TLS 1.2.  All good, thanks.

A pointer to the BCP from UTA: https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/ following the last sentence, might be helpful.  It's in IETF last call now, so it shouldn't hold up this draft and could even be done as an informational reference so it won't matter that it's not published yet.  Alternatively, this reference could be in section 11.1.

Section 7.3
Is a response code needed when the XML does not validate to the schema or other requirements that may exist in addition to schema conformance?  Or does this happen somewhere else or perhaps this should be stated as part of one of the existing response codes?

All editorial. Note that I did not review sections 9 & 10.

1 or 2: Might be nice to define "SPPPoS" for "SPP Protocol over SOAP". Would save a lot of space and make things easier to read.

3:

OLD
   This document RECOMMENDS SOAP 1.2 [SOAPREF] or higher, and WSDL 1.1
   [WSDLREF] or higher.
NEW
   SOAP 1.2 [SOAPREF] or higher, and WSDL 1.1 [WSDLREF] or higher are
   RECOMMENDED by this document.
END

4: s/compliant with this document/of this protocol

5ff: I don't see how the word "conforming" adds anything to this document. Instead of "conforming SPPPoS clients/servers MUST do X", why not say "SPPPoS clients/servers MUST do X"?

7: Title: s/SPP Protocol SOAP Data Structures/SPP Protocol over SOAP Data Structures

(resending after changing the notification to @tools.ietf.org)

In this text:

   This document RECOMMENDS SOAP 1.2 [SOAPREF] or higher, and WSDL 1.1
   [WSDLREF] or higher.
   
I'm not sure why these are RECOMMENDS, but more to the point, am I reading this that there's no mandatory-to-implement version of SOAP or WSDL for SPP over SOAP? I note that you have HTTP/1.1 or higher as a "MUST use" in Section 4.

Thanks for the response to my discuss, since the WG did  think
it through, I've cleared. 

----- OLD COMMENTS below

- General: why would one want to ever run this protocol
without TLS? Did the WG consider saying that TLS MUST be used?
Again, if you tell me you thought about it, I'll just clear.

- 7.1.2: The framework uses "Identifier" but here you use
"Identity" - it'd be better to be consistent I think and
"Identifier" is a lot better.

- section 11 is weaker than the corresponding section in the
framework draft. Two things: 1) why not point back to the
framework here? 2) shouldn't you say which of the
vulns/mitigations called out in the framework are relevant or
mitigated here?