Experience of Implementing NETCONF over SOAP
RFC 5381

[Ballot discuss]
There's one place where it's not clear whether the text is just
explaining how things work, or actually specifies new behavior
that is not part of the current RFCs. Specifically, Sections 3.1.2 and
3.2.2 seem to specify a different approach to maintaining sessions
than what is used in RFC 4741/4743.

[Ballot discuss]
Discuss discuss: We don't usually publish documents whose title could
be "Beginner's Guide to Apache Axis". I didn't review those parts
(since I'm not even a beginner with this particular tool). For an
Apache Axis tutorial, it doesn't look particularly good; and it
doesn't seem to have much NETCONF specific content. Fine text for a
web page, perhaps, but I don't quite understand why it would be a good
fit for the RFC series.

However, there's one place where it's not clear whether the text is
just explaining how things work, or actually specifies new behavior
that is not part of the current RFCs. Specifically, Sections 3.1.2 and
3.2.2 seem to specify a different approach to maintaining sessions
than what is used in RFC 4741/4743.

Additional comments:

Section 2.1 suggests that using SOAP/HTTP for NETCONF means we
also get things like WS-Security, WS-Reliability, etc. -- this
is not really true; RFC 4743 doesn't use e.g. WS-Security.

Section 3.1.2 says HTTP creates TCP connection for every request;
this hasn't been true for at least 10 years.

[Ballot discuss]
3.1.2. Session Maintenance in NMS


  When exchanging NETCONF messages between an NMS and network
  equipment, implementation of a session-maintenance function is
  necessary on both sides.

  HTTP is a stateless protocol that is used as an underlying transport
  protocol for SOAP.  HTTP creates and terminates a TCP session at
  every request.  Therefore, when using HTTP as a transport protocol
  for SOAP messages, session maintenance at the TCP level as well as at
  the NETCONF level is necessary.  Unless a session is maintained at
  the TCP level, a different NETCONF service provider is invoked every
  time the NETCONF client sends a NETCONF message to the NETCONF
  server.  We used a cookie field inside a HTTP header as a session
  identifier for the session on TCP level.

  The session-maintenance function at the TCP level has to be
  incorporated as follows.  After the NETCONF application sends a
  NETCONF hello message to a NETCONF service provider, the application
  receives a newly allocated session identifier written in the cookie
  field of a replying hello message.  The NETCONF application preserves
  the cookie paired with the network equipment's MAC address and uses
  it as a session identifier for subsequent NETCONF message exchanges.
  When an NMS sets the cookie for subsequent NETCONF messages, the
  network equipment recognizes the session and maintains it.  The
  stored cookie is erased when the NMS sends a close-session message
  and a response message is received from the network equipment.
 
 
I am a bit uncertain if I understood this correctly but to me the
above text seems to have some issue.

1. "HTTP creates and terminates a TCP session at
  every request."
 
  This is not true if HTTP 1.1 support for persistent connections are used.
 
2. Secondly, the closing of the TCP connection seems to be breaking the
  RFC 4743 rules for session handling.
 
3. "The session-maintenance function at the TCP level has to be
  incorporated as follows."
 
  This text seems to imply that this document is redefining RFC 4742.
 
4. I don't understand why MAC address has to be maintained can you please
  clarify why that would be necessary?


General discuss discuss:

I think it is great that this type of document gets writtne. However, I think this document has somewhat the wrong tone for its intention. On
several places it has wordnings such as:

"must have", "must use", "needs" instead of "we used" "may use" as this is intended
to describe what the document authors did rather than

example:

The development of a Java-based NETCONF client
  needs JDK (Java Development Kit) [JDK] and Apache Axis.

[Ballot discuss]
3.1.2. Session Maintenance in NMS


  When exchanging NETCONF messages between an NMS and network
  equipment, implementation of a session-maintenance function is
  necessary on both sides.

  HTTP is a stateless protocol that is used as an underlying transport
  protocol for SOAP.  HTTP creates and terminates a TCP session at
  every request.  Therefore, when using HTTP as a transport protocol
  for SOAP messages, session maintenance at the TCP level as well as at
  the NETCONF level is necessary.  Unless a session is maintained at
  the TCP level, a different NETCONF service provider is invoked every
  time the NETCONF client sends a NETCONF message to the NETCONF
  server.  We used a cookie field inside a HTTP header as a session
  identifier for the session on TCP level.

  The session-maintenance function at the TCP level has to be
  incorporated as follows.  After the NETCONF application sends a
  NETCONF hello message to a NETCONF service provider, the application
  receives a newly allocated session identifier written in the cookie
  field of a replying hello message.  The NETCONF application preserves
  the cookie paired with the network equipment's MAC address and uses
  it as a session identifier for subsequent NETCONF message exchanges.
  When an NMS sets the cookie for subsequent NETCONF messages, the
  network equipment recognizes the session and maintains it.  The
  stored cookie is erased when the NMS sends a close-session message
  and a response message is received from the network equipment.
 
 
I am a bit uncertain if I understood this correctly but to me the
above text seems to have some issue.

1. "HTTP creates and terminates a TCP session at
  every request."
 
  This is not true if HTTP 1.1 support for persistent connections are used.
 
2. Secondly, the closing of the TCP connection seems to be breaking the
  RFC 4743 rules for session handling.
 
3. "The session-maintenance function at the TCP level has to be
  incorporated as follows."
 
  This text seems to imply that this document is redefining RFC 4742.
 
4. I don't understand why MAC address has to be maintained can you please
  clarify why that would be necessary?


General discuss discuss:

I think this document has somewhat the wrong tone for its intention. On
several places it has wordnings such as:

"must have", "must use", "needs" instead of "we used" "may use" as this is intended
to describe what the document authors did rather than

example:

The development of a Java-based NETCONF client
  needs JDK (Java Development Kit) [JDK] and Apache Axis.

[Ballot discuss]
Discuss-discuss.

I would have voted Yes on this document, if it were not for one
detail. I am looking at Section 3.2.1 that says one need not implement
the SOAP encodingStyle attribute, or the SOAP header inside a SOAP
envelope, if "memory is tight".

I wanted to check the SOAP spec for whether this was actually legal.
I was unable to find any statement regarding what SOAP actually
requires as mandatory to implement. The relevant section

http://www.w3.org/TR/soap12-part1/#soapencattr

only says that the attribute MAY appear. To me that sounds like it
does not have to be present on the wire, but the endpoints have to be
able to understand it if it is.

But I would like some SOAP expert to weigh in on this.

[Ballot discuss]
I wonder if a brief IESG note along the lines of the following would be a good idea:

---
IESG Note:

  RFC 4741 section 2.4 states, "A NETCONF implementation MUST support
  the SSH transport protocol mapping."
---

While I appreciate and value the input this document provides to the
IETF, we choose mandatory-to-implement facilities to promote
interoperability and I wouldn't want this document to accidentally
mislead a reader.  Note that I will change my position to no
objection after the IESG discusses this unless the IESG has rough
consensus in favor of this sort of a note.