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

["Romascanu, Dan (Dan)" <[e-mail]>]

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
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf