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.