Subject: IETF Last Call comments on draft-ietf-netconf-soap-06.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 25 Nov 2005 14:42:18 +0100

NetConf WG, and specifically author(s) of the SOAP document,

please review and comment.

Bert
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Mark Baker
Sent: Wednesday, November 23, 2005 21:37
To: [email-masked]
Subject: NETCONF over SOAP and BCP 56

I'd like to take issue with a claim made in the NETCONF over SOAP draft;

http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-06.txt

In section 2.4 regarding BCP 56, the draft says;

"Fundamentally, these concerns lie directly with SOAP over HTTP, rather than the application of SOAP over HTTP to NETCONF."

That is incorrect.  The advice of BCP 56 is relevant to any use of HTTP.  For example, BCP 56 provides guidance about the use of port numbers, security, and URI schemes, none of which SOAP (1.1 or 1.2) take any position on.  Moreover, the SOAP specifications don't require that HTTP be used as a tunnel; they fully support the use of SOAP as an extension to the HTTP processing model.

IMHO, either the draft needs to defend its disregard of many of the recommendations of BCP 56, or it needs to accomodate them as best it can.  I expect this will be particularly difficult given that NETCONF is itself an application protocol, but at the very least I think the draft should recommend or require that port 80 not be used, or that a new HTTP method be used (viz a viz BCP 56 section 6), so as to separate NETCONF traffic from Web traffic.

Thanks,

P.S. http://xml.coverpages.org/draft-presuhn-nmwebdav-01.txt describes (at a very high level) a network configuration protocol that doesn't tunnel over HTTP, but instead uses HTTP/WebDAV as an application protocol.  The use of SOAP is not described though, but you could imagine all of the configuration documents wrapped in a SOAP envelope.  Such a use of HTTP for network configuration would probably comply with BCP 56.

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Ted Goddard <[email-masked]>
Date: Fri, 25 Nov 2005 09:46:37 -0700

Please find my comments in line:

On 25-Nov-05, at 6:42 AM, Wijnen, Bert (Bert) wrote:

> "Fundamentally, these concerns lie directly with SOAP over HTTP,  
> rather than the application of SOAP over HTTP to NETCONF."
>
> That is incorrect.  The advice of BCP 56 is relevant to any use of  
> HTTP.

I agree that BCP 56 is relevant to any use of HTTP; however
BCP 56 makes recommendations that are at odds with the widespread
practice of using HTTP as a universal tunneling protocol (however
dangerous it may be, it is widespread, and it is even the
expectation of many users of SOAP).  Would the following wording be
preferred?

    Fundamentally, many of these concerns lie directly with
    common usage of SOAP over HTTP, rather than the application
    of SOAP over HTTP to NETCONF.

> For example, BCP 56 provides guidance about the use of port  
> numbers, security, and URI schemes, none of which SOAP (1.1 or 1.2)  
> take any position on.  Moreover, the SOAP specifications don't  
> require that HTTP be used as a tunnel; they fully support the use  
> of SOAP as an extension to the HTTP processing model.

> IMHO, either the draft needs to defend its disregard of many of the  
> recommendations of BCP 56, or it needs to accomodate them as best  
> it can.  I expect this will be particularly difficult given that  
> NETCONF is itself an application protocol, but at the very least I  
> think the draft should recommend or require that port 80 not be  
> used, or that a new HTTP method be used (viz a viz BCP 56 section  
> 6), so as to separate NETCONF traffic from Web traffic.

Requiring a new HTTP method would make NETCONF incompatible with
existing SOAP implementations, but there is no difficulty with
requiring a specific port.  The draft currently contains the
following text:

    It is also possible to respond to the concern on the
    re-use of port 80.  A NETCONF SOAP service SHOULD be offered
    over a new standard port for NETCONF over SOAP (over HTTP)
    to be defined as requested in the IANA considerations of
    this document.

and in the IANA Considerations section:

    The IANA is requested to assign TCP ports for NETCONF for
    SOAP over HTTP and SOAP over BEEP.

Would it be preferred to revise the first paragraph to contain
the following?

    The NETCONF SOAP service MUST be offered
    over the new standard port for NETCONF over SOAP

Thanks,
Ted.

> Thanks,
>
> P.S. http://xml.coverpages.org/draft-presuhn-nmwebdav-01.txt  
> describes (at a very high level) a network configuration protocol  
> that doesn't tunnel over HTTP, but instead uses HTTP/WebDAV as an  
> application protocol.  The use of SOAP is not described though, but  
> you could imagine all of the configuration documents wrapped in a  
> SOAP envelope.  Such a use of HTTP for network configuration would  
> probably comply with BCP 56.
>
> Mark.
> --