NETCONF WG meeting minutes for IETF #57

[Andy Bierman <abierman@cisco.com>]

Hi,

Here are the minutes for the NETCONF WG meeting held in Vienna.

Andy
OPS Area
NETCONF WG Meeting Minutes
IETF #57
July 14, 2003
Minutes by Chris Elliot and Andy Bierman

Chairs
------

Andy Bierman <abierman@cisco.com>
Simon Leinen <simon@switch.ch>

Review Material
---------------

XML Network Management Interface
<draft-weijing-netconf-interface-00.txt>

XMLCONF Configuration Protocol
<draft-enns-xmlconf-spec-01.txt>

A SOAP Binding for NETCONF
<draft-goddard-netconfsoap-00.txt>

Agenda
------

 - Working group status and charter review
 - Presentations : Document Overviews 
 - Protocol Operations Issues
 - NETCONF Transport Issues
 - Next Steps

Minutes
-------

1) The major issues facing the working group were listed 
without much discussion:

  Transport mappings
    BEEP, HTTPS, SSH?
  RPC Layer
    SOAP encoding, xmlconf RPC, or simple request/response
  Advanced XML features
    WSDL templates, XPath filtering, more?
  Protocol Operations
    Add, Modify, Delete Variants
    Advanced operations: mandatory or optional
    Multi-device operation support
    Error Handling
    Notifications
  Security
    Authorization model, user identity

2) XML Network Management Interface (presented by Weijing Chen)

The XML Network Management Interface document was presented to the 
group for comment.  The main points raised in the presentation are
summarized, but refer to the presentation slides for details.
They are available online at:
http://www.ops.ietf.org/netconf/57/weijing/

2.1) Documentation structure

There should be multiple data model documents, and each should
have its own associated capabilities schema.  There should be
one protocol operations document.  There should be an abstract
transport document containing WSDL definitions for the protocol
and a concrete transport document containing WSDL transport
bindings.

There were no comments related to the document structure.

2.2) Protocol operations

There should be flexible and generic protocol operations in the
protocol, and the real protocol operations should be defined as
part of the data model.  The 'get' operation should provide a
variant for get-all, and variants to get read-only or writable
data elements. XPath should be used to refine selections.

Comments from the group focused on the need for precise
protocol operations for better interoperability. Leaving
the operation semantics up to the vendors will not allow
application developers to reuse code across devices from
different vendors.

There was agreement that some sort of 'get-all' operation was
needed, but the other variants should be based on the
type of data elements, not whether the element is writable,
because some non-configuration data is writable.  This issue
also has an impact on the schema design, but that is part
of the data definition language effort, not part of the charter
for this working group.

There was agreement that XPath support would be a good idea,
but that it should be optional, and a special capability flag
for XPath support is needed.

2.3) Transport

WSDL over SOAP should be used as the transport binding.
New mappings for SOAP over SSH may be defined, and used
in addition to the SOAP over HTTP and SOAP over BEEP
bindings already defined.

There were some strong comments from the group on this issue.
There seems to be some significant support for using SOAP
for the transport. NETCONF over BEEP is wrong because this
will cause the WEB Services model to be reinvented.  There
were no objections to supporting SOAP, but some objections
to making SOAP the mandatory-to-implement transport mapping.
This choice is heavily biased by the tool environment used,
which is outside the scope of standardization and depends
on many factors.  There was agreement that the WSDL 
definition can be independent of the SOAP binding definition.

3) XMLCONF Configuration Protocol (presented by Rob Enns)

The XMLCONF Configuration Protocol document was presented to the 
group for comment.  The main points raised in the presentation are
summarized, but refer to the presentation slides for details.
They are available online at:
http://www.ops.ietf.org/netconf/57/enns/

The basic design of the XMLCONF protocol was presented at the
NETCONF BOF at IETF #56, and won't be resummarized here.
The most significant change in the updated draft is the
addition of the 'operation' attribute in the 'edit-config'
protocol operation.  This was added as a result of mailing
list discussions, and is applied to the data model content
to refine the scope of an edit operation (merge, replace,
or delete).

There were a few comments from the group on this presentation,
but most comments occurred in the last part of the meeting
on protocol operation and transport issues. See section 5
for comments on this draft.

4) A SOAP binding for NETCONF (presented by Margaret Wasserman)

The SOAP binding for NETCONF document was presented to the 
group for comment.  The main points raised in the presentation are
summarized, but refer to the presentation slides for details.
They are available online at:
http://www.ops.ietf.org/netconf/57/goddard/

This draft proposes a SOAP transport binding for the NETCONF
protocol.  The draft supports the protocol features and transport
requirements found in the XMLCONF draft, such as multiple channels.
The draft proposes that the notification mechanism be replaced by
a polling mechanism since SOAP over HTTP is not currently well-suited
to support server to client connection establishment.  The SOAP
Envelope encoding is used, which allows the content portion
(protocol operation and data models) to be encoded exactly the
same whether SOAP is used or not.

An issue was raised regarding the streaming of multiple RPC
requests.  One approach is to make every RPC request a separate
XML instance document. Another approach is to use a single
instance document with a special root element that contains 
multiple RPC requests.  It was agreed that separate XML instance
documents would be better because some popular parser tools
wait to receive an entire XML instance document before 
dispatching the content to component specific document handlers.

Another issue raised was how multiple HTTP connections are
managed as if it was a multi-channel session.  This will be
investigated further.  The possibility of creating a variant
of the protocol which requires only a single channel will
also be investigated.


5) Open Discussion on Protocol Operations Issues and NETCONF 
   Transport Issues

An open mike Q&A discussion was held, covering protocol and
transport issues.  The highlights of this discussion are
listed here.

5.1) Named configurations

A request was made for the protocol to support named 
configurations.  This is an open issue.  There are some
technical issues to overcome, such as:
  - management of resources needed to support named 
    configurations
  - scope of protocol operation support on named 
    configurations.  Are these real databases (like 'running' 
    configuration) or just text files?

The working group plans to add named configuration support to 
the protocol.

5.2) Configuration templates

A request was made for configuration template support.
This is an open issue.  It is not clear if this would
be part of the protocol operations, part of the data models,
or both. Perhaps XPath can be used to supply some of this
functionality.  The feature needs to be investigated further.

5.3) Standardized error logging

A request was made to add support for a standard way to 
retrieve error output.  A suggestion was made that we
should not standardize how devices generate error output,
but just that they should generate error output.
Another suggestion was made to support error messagess both 
as response to config request and as a log entry. Multiple
error logs may be needed to handle roles.

Detailed support for error logging is an open issue.

5.4) 'Get' protocol operation

The XMLCONF draft includes two 'Get' operations, one for
configuration data and one for everything else.  A request
was made to change this scheme.  It should be possible to
retrieve all types of data with a single request.  It
was agreed that a 'get all' type of operation is needed.

5.5) Warning messages

A request was made to add support for warnings as part of
the error response in an RPC reply.  It was agreed that 
this feature would be useful.  The detailed format of the
error response and a list of protocol errors is still TBD.

5.6) Multiple operations per RPC request

A request was made to add support for transactional bindings, 
like binding edit/deletion together into one transaction.
It was agreed this feature is needed.  It is supported to
some extent in the XMLCONF 'edit-config' protocol operation.

There is an important distinction between atomic execution
of multiple operations and a rollback-on-error capability.
It is not easy to insure atomic execution because commands
are invoked sequentially.  A more realistic requirement
is to leave the device in the state it was at the start 
of the RPC request, if any error occurs during command
execution.

5.7) Locking

The issue of configuration locking was raised.  The locks
in the XMLCONF draft are global, and locking is an
optional feature.  There is lots of interest in making the
lock feature mandatory.  This is an open issue.  Locking
is important for multi-device transactions.  The group
is leaning towards making the lock operation mandatory.

Locking of a portion of a configuration database depends
on the particular data models supported by the device.
Multiple access mechanisms do not always use the same
data models for the same features (e.g. SNMP and CLI).
A partial lock feature may be difficult to define as
a NETCONF protocol operation.  Partial locking is an
open issue.

5.8) Need Issues list

A request was made to start maintaining an issues list for
the working group.  It was agreed that such a list is needed.
An initial list is in progress.  It will be posted on the
NETCONF WEB site at http://www.ops.ietf.org/netconf/.

5.9) Mandatory-to-implement transport mapping

This is probably the most controversial issue facing the
working group.  There is widespread agreement that the
standard would be much more interoperable if there is
a single mandatory-to-implement transport mapping.  There
is less agreement on which transport mapping should be the
mandatory one.  The main candidates are SOAP, BEEP, and SSH,
but some people want Telnet and even console port support.

The working group will address this issue in the following
manner:
  - specify detailed transport requirements, including
    usage scenarios for each feature
  - evaluate each candidate transport mapping against
    the requirements list
  - poll the operator community for preferences

Selection of the mandatory-to-implement transport is an 
open issue.

6) Next steps

The working group will take the following actions in the
near term.

6.1) Baseline protocol document

The XMLCONF draft will be updated and published as a NETCONF 
working group draft, and used as the starting point for the 
protocol document.  The BEEP mapping will be moved to a 
separate document.  

6.2) Interim meeting 

An interim meeting will be held September 8-10, 2003
in Sunnyvale, CA, USA.  The purpose of the meeting
is to make as much progress as possible on all open
issues.  A detailed agenda will be posted to the mailing 
list at least two weeks before the meeting.

Information on this meeting can be found at:
http://www.ops.ietf.org/netconf/interim-2003-09/

6.3) Transport mapping documents

Proposals are needed for mapping the NETCONF protocol
to SSH or BEEP.  It is hoped at least an initial version
of the SSH document will be proposed before the interim
meeting.