Subject: [Netconf] NETCONF over SOAP issue with draft-iijima-netconf-soap-implementation-10

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 1 Sep 2008 16:37:12 +0200

During the IESG review of draft-iijima-netconf-soap-implementation-10
(AD-sponsored independent submission targeting Informational RFC) Pasi
Eronen raised the issue of the usage by the implementation described in
the document of the cookie field inside the HTTP header to map incoming
requests to NETCONF sessions.  This makes such an implementation
implementation to be an alternative SOAP binding for NETCONF which does
not interoperate with RFC4743 compliant implementations.

In the IESG discussions we chose to approve the document as
Informational but make clear in the text that such implementations are
not interoperable. We would like however to have the NETCONF WG look at
the proposed text and make sure that we got it right and especially that
RFC4743 is not in error.

If you believe that there are any problems with the proposed text please
let us know until 9/10 the latest. 

Proposed Notes to the RFC Editor:

1. In the Abstract Section:

OLD: 

  This document describes how the authors developed a SOAP (Simple
  Object Access Protocol)-based NETCONF client and server.  When SOAP
  is used as a transport protocol for NETCONF, various kinds of
  development tools are available.  By making full use of these tools,
  developers can significantly reduce their workload.  The authors
  developed an NMS (Network Management System) and network equipment
  that can deal with NETCONF messages sent over SOAP.  This document
  aims to provide NETCONF development guidelines gained from the
  experience of implementing a SOAP-based NETCONF client and server.

NEW: 

  This document describes how the authors developed a SOAP (Simple
  Object Access Protocol)-based NETCONF client and server. It 
  describes an alternative SOAP binding for NETCONF which does not  
  interoperate with an RFC4743 conformant implementation making 
  use of cookies on top of the persistent transport connections of HTTP.
  
  When SOAP is used as a transport protocol for NETCONF, various kinds
of
  development tools are available.  By making full use of these tools,
  developers can significantly reduce their workload.  The authors
  developed an NMS (Network Management System) and network equipment
  that can deal with NETCONF messages sent over SOAP.  This document
  aims to provide NETCONF development guidelines gained from the
  experience of implementing a SOAP-based NETCONF client and server.

2. Add to Section 1.2 the following paragraph:

  This  document describes an alternative SOAP binding for NETCONF which
  does not interoperate with an RFC4743 conformant implementation as it 
  relies on cookies used on top of the persistent transport connections 
  of HTTP. This is provided for information purposes only based on the 
  implementation experience of the authors. 

3. In Section 3.1.2

OLD: 

  In [RFC4743], HTTP is specified as an option of an underlying
  protocol for NETCONF over SOAP.  When HTTP is used for that purpose,
  it is also specified that a NETCONF session will be supported by an
  HTTP connection.  However HTTP is a stateless protocol; that is, HTTP
  cannot process a user's request according to the state resulting from
  the user's previous request.  Unless the state is kept at the HTTP-
  level, a different NETCONF service provider will be invoked every
  time the NETCONF application sends a NETCONF message to the NETCONF
  service provider.  To ensure that the same NETCONF service provider
  is used every time the NETCONF application sends a NETCONF message,
  the state of the HTTP connection must be maintained.  Accordingly, a
  cookie field inside an HTTP header was devised for maintaining the
  state of an HTTP connection.  We therefore used such a cookie field
  to maintain the state of the HTTP connection over which the NETCONF-
  session maintenance is ensured.

NEW: 

  In [RFC4743], HTTP is specified as an option of an underlying
  protocol for NETCONF over SOAP.  When HTTP is used for that
  purpose, it is also specified that a NETCONF session state is tied
  to the state of the underlying transport (TCP) connection (just
  like in NETCONF over SSH [RFC4742] and NETCONF over BEEP
  [RFC4744]). However, HTTP itself is a stateless protocol, and many
  server implementations process user requests independently of
  previous requests received over the same transport connection.  To
  simplify implementation of the NETCONF service provider, we used
  the cookie field inside the HTTP header to map incoming requests to
  NETCONF sessions. Note that this means our implementation actually
  uses an alternative SOAP binding for NETCONF which does not
  interoperate with RFC4743 compliant implementations.

Thanks and Regards,

Dan

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

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 2 Sep 2008 15:57:00 +0200

So it seems that neither the WG chairs, nor the Netconf-over-soap 
authors/editors.
nor any other WG member had noticed this. Strange. I will hacve to go and 
re-read.

Personally I am somewhat worried if we publish "implementation experience of
Netconf over SOAP" if it is not interoperable with the NETCONF over SOAP
standards track specification!!!! Even if that is spelled out clearly.

Does anyone else in teh WG have an opinion (or care)?

Bert

----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, September 01, 2008 4:37 PM
Subject: [Netconf] NETCONF over SOAP issue 
withdraft-iijima-netconf-soap-implementation-10

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 2 Sep 2008 15:57:00 +0200

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Sep 2008 16:28:08 +0200

On Tue, Sep 02, 2008 at 03:57:00PM +0200, Bert Wijnen (IETF) wrote:
 
> Personally I am somewhat worried if we publish "implementation
> experience of Netconf over SOAP" if it is not interoperable with the
> NETCONF over SOAP standards track specification!!!! Even if that is
> spelled out clearly.

I tend to agree. I personally don't care much about the SOAP interface
and as such I did not bother to read this document carefully.

Looking at it now, it strikes me a little bit when the document talks
about file names such as "netconf-soap_1.0.wsdl" in section 4 under
'Guidelines for Developing NETCONF Clients and Servers'.  It seems the
authors document in quite some detail their specific implementation
and I am not sure this belongs into an RFC - how stable is all this
going to be? The same goes to the discussion of build files etc.
which I personally find pretty out of scope for RFCs.

/js
 
-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Sep 2008 16:28:08 +0200

/js

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 2 Sep 2008 16:32:47 +0200

Inline

----- Original Message ----- 
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Bert Wijnen (IETF)" <[email-masked]>
Cc: "Romascanu, Dan (Dan)" <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, September 02, 2008 4:28 PM
Subject: Re: [Netconf] NETCONF over SOAP 
issuewithdraft-iijima-netconf-soap-implementation-10

> which I personally find pretty out of scope for RFCs.

It is not us (NETCONF WG) who have anything to say about such content
(as individuals, we can do so of course).

As a WG however, we have the duty and right to make sure that the
document does not conflict (or otherwise disagree) with the NETCONF
related standards track documents we produce (or have produced).
And as such, the fact that it describes an implementation that does
not interoperate with our standard protocol spec seems VERY ODD
to me. And that is a point that we as WG can (and probably should)
have an opinion on.

Bert

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 2 Sep 2008 16:32:47 +0200

Inline

----- Original Message ----- 
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Bert Wijnen (IETF)" <[email-masked]>
Cc: "Romascanu, Dan (Dan)" <[email-masked]>; <[email-masked]>; 

Bert