Subject: Re: [drinks] review of draft-ietf-drinks-sppp-over-soap-04

From: "Cartwright, Ken" <[email-masked]>
Date: Fri, 19 Aug 2011 17:21:16 -0400

I've incorporated the updates listed below, that address the points made by Peter.  The remaining task is to incorporate some SOAP message examples, as suggested by Ning.  I will do that on Tuesday (I'm out on Monday).

Ken

1.  Clarified that sentence and others.
2.  Changed the approach of other IETF RFCs that use WSDL (e.g. 4743) to refer to this reference as informative rather than normative.
3.  Updated the wording in the Transport Security section to make it clear the intent is to use HTTPS for integrity and privacy.  Also added a reference to 2818 later in the document.
4.  The WSDL name space definition and the target namespace specifications are correct as they stand.
5.  Added to the wording of the Security Considerations section to refer to the practice of using certificate exchange/verification to perform server authentication, and referred to 2818.
6.  Added some more verbiage to the "Environment Specific Considerations section and removed the use of the overloaded word "may".
7.  It is not clear to me that we really _need_ anything else in the IANA section.  So I left that as it stands.
8.  Added a sentence about SOAP faults that could, theoretically, be generated by the chosen SOAP library, but that do not relate to SPPP.  However, this is a subject that does not directly relate to SPPP.  So I did not get too verbose on this subject.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Wednesday, July 20, 2011 6:52 PM
To: [email-masked]
Subject: [drinks] review of draft-ietf-drinks-sppp-over-soap-04

I've been asked to take a look at draft-ietf-drinks-sppp-over-soap.
Overall I think it is in fine shape. Here are a few comments.

1. The document needs to be edited for clarity. For example, some of the
sentences don't parse (e.g., the third sentence of Section 1).

2. There's a normative reference to W3C Note NOTE-wsdl-20010315, which
says "This document is a NOTE made available by the W3C for discussion
only. Publication of this Note by W3C indicates no endorsement by W3C or
the W3C Team, or any W3C Members. W3C has had no editorial control over
the preparation of this Note. This document is a work in progress and
may be updated, replaced, or rendered obsolete by other documents at any
time." Thus the phrase "WSDL is a widely standardized and adopted
technology" in this I-D is not accurate, at least with regard to
standarization. Furthermore, no published RFCs contain a normative
reference to the WSDL document, which also is not in the downref
registry. This will need to be called out during IETF Last Call.

3. Section 3 states "SOAP faults are not used by the SPPP SOAP mapping."
It would be good to define how an application is supposed to handle SOAP
faults if they occur for other reasons, or reference the SOAP
specification on this point.

4. Transport security is a bit unclear to me. The spec says:

    All SOAP and HTTP SPPP Clients and Servers MUST support Transport
    Layer Security (TLS) as defined in [RFC5246] as the secure transport
    mechanism.

Does that mean supporting HTTP Over TLS (RFC 2818) except using the most
up-to-date version of TLS, or using TLS directly over TCP?

5. I am not a WSDL expert, but the definition looks fine to me (even if
hard to read). This seems a bit odd:

  xmlns:sppps="urn:ietf:params:xml:ns:sppp:soap:1"
  targetNamespace="urn:ietf:params:xml:ns:sppp:soap:1"

Why define the same namespace in two ways?

6. Section 7 says "The identity of the server should also be
authenticated by the client." However, no guidance is provided about how
to do that. A reference to RFC 2818 seems necessary.

7. Section 7.3 states:

    Some deployments of SPPP over SOAP may choose to use transports
    without encryption.  This presents vulnerabilities but may be
    selected for deployments involving closed networks or debugging
    scenarios.

Do you mean "MAY"? Is encryption truly optional? Please clarify that you
mean MUST-implement and SHOULD-deploy or somesuch (where your "may" here
really means "here's why a deployment might have a good reason to
violate the SHOULD-deploy").

8. The IANA considerations seem a bit thin. Please see RFC 3688 for the
template. I know there are a few examples in Section 14 of RFC 6120, so
feel free to borrow from there. :)

Peter

--
Peter Saint-Andre
https://stpeter.im/

_______________________________________________
drinks mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/drinks

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: "Cartwright, Ken" <[email-masked]>
Date: Tue, 23 Aug 2011 16:33:08 -0400

Here is the updated version of the document that includes examples to address the point made by Ning.  That was the last outstanding comment.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cartwright, Ken
Sent: Friday, August 19, 2011 5:21 PM
To: [email-masked]
Subject: Re: [drinks] review of draft-ietf-drinks-sppp-over-soap-04

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Wednesday, July 20, 2011 6:52 PM
To: [email-masked]
Subject: [drinks] review of draft-ietf-drinks-sppp-over-soap-04

7. Section 7.3 states:

Peter

--
Peter Saint-Andre
https://stpeter.im/