2.4.9 Network Configuration (netconf)

Last Modified: 2003-08-14

Simon Leinen <simon@switch.ch>
Andy Bierman <abierman@cisco.com>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Technical Advisor(s):
Wesley Hardaker <hardaker@tislabs.com>
Mailing Lists:
General Discussion: netconf@ops.ietf.org
To Subscribe: netconf-request@ops.ietf.org
In Body: in msg body: subscribe
Archive: http://ops.ietf.org/lists/netconf
Description of Working Group:
Wes Hardaker is Technical Advisor for Security Matters

Configuration of networks of devices has become a critical requirement
for operators in today's highly interoperable networks. Operators from
large to small have developed their own mechanims or used vendor
specific mechanisms to transfer configuration data to and from a
device, and for examining device state information which may impact the
configuration. Each of these mechanisms may be different in various
aspects, such as session establishment, user authentication,
configuration data exchange, and error responses.

The Netconf Working Group is chartered to produce a protocol suitable
for network configuration, with the following characteristics:

  - Provides retrieval mechanisms which can differentiate between
    configuration data and non-configuration data
  - Is extensible enough that vendors will provide access to all
    configuration data on the device using a single protocol
  - Has a programmatic interface (avoids screen scraping and
    formatting-related changes between releases)
  - Uses a textual data representation, that can be easily
    manipulated using non-specialized text manipulation tools.
  - Supports integration with existing user authentication methods
  - Supports integration with existing configuration database systems
  - Supports network wide configuration transactions (with features
    such as locking and rollback capability)
  - Is as transport-independent as possible
  - Provides support for asynchronous notifications

The Netconf protocol will use XML for data encoding purposes,
because XML is a widely deployed standard which is supported
by a large number of applications. XML also supports hierarchical data

The Netconf protocol should be independent of the data definition
language and data models used to describe configuration and state data.
However, the authorization model used in the protocol is dependent on
the data model. Although these issues must be fully addressed to
develop standard data models, only a small part of this work will be
initially addressed. This group will specify requirements for standard
data models in order to fully support the Netconf protocol, such as:

  - identification of principals, such as user names or distinguished
  - mechanism to distinguish configuration from non-configuration data
  - XML namespace conventions
  - XML usage guidelines

It should be possible to transport the Netconf protocol using several
different protocols. The group will select at least one suitable
transport mechanism, and define a mapping for the selected protocol(s).

The initial work will be restricted to the following items:

  - Netconf Protocol Specification, which defines the operational
    model, protocol operations, transaction model, data model
    requirements, security requirements, and transport layer

  - Netconf over <Transport-TBD> Specification, which defines how
    the Netconf protocol is used with the transport protocol
    selected by the group, and how it meets the security and
    transport layer requirements of the Netconf Protocol
    Specification.. There will be a document of this type for
    each selected transport protocol.

The working group will take the XMLCONF Configuration Protocol
<draft-enns-xmlconf-spec-00.txt> as a starting point.
Goals and Milestones:
Done  Working Group formed
Done  Submit initial Netconf Protocol draft
Aug 03  Submit initial Netconf over (transport-TBD) draft
Dec 03  Begin Working Group Last Call for the Netconf Protocol draft
Jan 04  Begin Working Group Last Call for the Netconf over (transport-TBD) draft
Mar 04  Submit final version of the Netconf Protocol draft to the IESG
Apr 04  Submit final version of the Netconf over (transport-TBD) draft to the IESG
  • - draft-ietf-netconf-prot-00.txt
  • No Request For Comments

    Current Meeting Report

    OPS Area
    NETCONF WG Meeting Minutes
    IETF #57
    July 14, 2003
    Minutes by Chris Elliot and Andy Bierman
    Andy Bierman <abierman@cisco.com>
    Simon Leinen <simon@switch.ch>
    Review Material
    XML Network Management Interface
    XMLCONF Configuration Protocol
    A SOAP Binding for NETCONF
     - Working group status and charter review
     - Presentations : Document Overviews 
     - Protocol Operations Issues
     - NETCONF Transport Issues
     - Next Steps
    1) The major issues facing the working group were listed without much 
      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
        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: 
    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 
    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: 
    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: 
    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 
    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 
      - 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 
    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 
    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 
    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: 
    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. 


    XML Network Management Interface
    A SOAP Binding for NETCONF