here.
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:
ht
tp://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.
|