Technical Summary
This document describes how the authors developed a SOAP (Simple
Object Access Protocol)-based NETCONF client and server. In the case
that 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.
Working Group Summary
This document is an individual submission. Presentations were made in
the NETCONF Working Group, the NETCONF WG chairs reviewed the
document but no formal review was undertaken by the WG.
Document Quality
The document is based upon the implementation experienced gathered by
the authors in implementing RFC 4741 and RFC 4743. The document was
reviewed by Dan Romascanu as Area Director, by Mehmet Ersue and Bert
Wijnen, co-chairs of the NETCONF WG, and by Stefan Santesson for the
security directorate.
Personnel
This document is an indivudual submission and Dan Romascanu is the
shepherding AD.
RFC Editor Note
RFC Editor, please make the following changes:
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.
IESG Note
This document discusses implementation experience of NETCONF over SOAP.
Note that RFC 4741 section 2.4 states, "A NETCONF implementation MUST
support the SSH transport protocol mapping". Therefore, a NETCONF
implementation that only supports the SOAP transport described in this
document and not (at least) also SSH is not in compliance with the NETCONF
standards.