2.4.10 Network Configuration (netconf)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Addiotional NETCONF Web Page

Last Modified: 2005-01-21


Simon Leinen <simon@switch.ch>
Andy Bierman <ietf@andybierman.com>

Operations and Management Area Director(s):

Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.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
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
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
Done  Submit initial Netconf over (transport-TBD) draft
Done  Begin Working Group Last Call for the Netconf Protocol draft
Done  Begin Working Group Last Call for the Netconf over (transport-TBD) draft
Jan 05  Submit final version of the Netconf Protocol draft to the IESG
Jan 05  Submit final version of the Netconf over (transport-TBD) draft to the IESG


  • draft-ietf-netconf-prot-05.txt
  • draft-ietf-netconf-beep-03.txt
  • draft-ietf-netconf-soap-04.txt
  • draft-ietf-netconf-ssh-03.txt

    No Request For Comments

    Current Meeting Report

    NETCONF meeting

    IETF 62, Minneapolis
    Tuesday 09.00-11.30 (actually 09.00-10.00)

    Chairs: Andy Bierman, Simon Leinen
    Minutes: Simon Leinen
    Jabber scribe: Eliot Lear

    WG Last Call status

    All documents were in Working Group Last Call, lasting until Friday 18 March (the week after the meeting). As this was the second WG Last Call, participants didn't find too many problems with the drafts in this round. There have been comments from people trying to implement the protocol, which can be viewed as a good sign. The documents should be ripe for submission to the IESG soon. Discussion about individual drafts followed.


    Margaret Wasserman, the editor, couldn't be at the meeting because of other conflicting IETF duties. The latest revision mainly removed the option of starting NETCONF from a normal shell session - it must now be started as a separate netconf SSH subsystem.

    Wes Hardaker has thoroughly reviewed the draft and posted some issues to the mailing list. Margaret will address those issues in a forthcoming revision.

    Simon Leinen had found a small bug in the examples, where the C: (client) and S: (server) headers were inverted. This should remind participants of the importance of reviewing the documents for these kinds of problems also.


    Eliot Lear mentions that Jürgen Schönwälder provided detailed comments on his BEEP mapping draft, and promised a new BEEP draft based on these. Required changes include:

    • Adding some examples
    • Adding some text on <hello>, which was missed due to draft skew between the core (-protocol) and -beep drafts
    • Address an issue of Jürgen's on the SASL/TLS combination - after getting Jürgen to explain these in more detail
    • Reconsider the "application protocol" terminology, which Jürgen dislikes. Eliot is looking for suggestions for better terms.
    • Thorough review to make sure the BEEP mapping covers everything in the core protocol draft.

    Discussion of XML and Schema Definition Issues

    Schema Strictness Requirements

    Wes asks whether the intent is that an implementor should be able to use the XSD definitions to do most of the validity checking of NETCONF requests.

    Andy doubts that this is possible, in particular because XSDs cannot capture the variants related to capabilities.

    XML Directorate Review

    Bert Wijnen, our responsible Area Director, asked (over Jabber) whether the XML Directorate has been asked to reviewed the documents for correct XML usage.

    Andy states that this has not yet been done, and noted that one of our authors (Phil Shafer) is on that directorate.


    Rob Enns decided not to show slides about the protocol draft because they are boring. Changes from last to current revision:

    • The many requests for clarifications from the mailing list have been addressed.
    • All of the closed issues that had come up in the WG Last Call have been addressed.
    • The change log was simplified because it was getting too long.

    Work is required in the following areas:

    • Filtering (section 6) - Some people have asked to clarify the section that explains how filtering works. Rob would welcome contributions for improved text. Andy - who had written that section - suggests that examples would be particularily useful here, and offers Rob his help to make the text more understandable later this week.
    • Examples in general - Past experience shows that implementors often use examples as a main guidance for implementations. Therefore, the examples should be given much care, in particular their correctness. Rob notes that all the examples in the protocol draft have been verified against the RelaxNG version of the NETCONF schema.
    • Clarify error codes for lock operations - LOCK_FAILED should be used instead of IN_USE.

    Secure-Transport Requirement

    John Ng asked about the requirement for secure transports (section 2.2 in the protocol draft), in particular whether it would be possible to use something like unencrypted telnet in a "secure private network" environment, or in situations where cryptography cannot be used. Andy assumes that security experts would not let a NETCONF proposal pass without mandatory security. Bert notes that security is mandatory to implement, but not mandatory to use.

    Detecting Dead Sessions

    John Ng raises the issue of how an agent notices when a manager has gone away (so that locks can be released). Andy says this is currently indicated by loss of the underlying TCP connection. John points out that this fails to distinguish between a manager that has nothing to say and one that has silently gone away. Eliot expresses his hope that someone who is holding a lock wouldn't be idle [but does that really help here?]. Andy recalls that we had this discussion before and decided this was a non-problem - hung sessions can be broken using <kill-session>.


    Ted Goddard, the author, couldn't be at the meeting. He has prepared the current revision of the draft in the beginning of 2005 and explained the changes on the list.

    Andy notes that it would be interesting to know which lower-layer mappings are actually supported by NETCONF implementors. Unfortunately we don't have any data on this.

    "NETCONF 2.0"?

    Since there were no further questions on the current drafts, Andy suggests to adjourn this part of the meeting to discuss data modeling issues. There have been discussions about "NETCONF 2.0" style work, but it would preferable to have specific drafts as a basis for discussion, rather than doing this "by committee" in rooms like this. Andy's suggestion was not followed, however:

    Protocol Extensions such as Notifications

    Eliot asks about the process for defining NETCONF extensions. A typical NETCONF extension - for instance, "notifications" - would require at least two drafts, one that defines the feature and others defining specific lower-layer mappings. Andy emphasizes that we should get over the current deadlock (with respect to notifications) that different lower layers suggest quite different approaches to an asynchronous "channel", and at least the SOAP one doesn't seem to support this at all. This looks like a tough decision - at one time we thought about only supporting notifications for specific underlying protocols (e.g. BEEP), but the WG had decided not to go down that path because of worries about fragmenting the protocol. It would be useful for someone to address this issue in a new draft.

    Speaking for a group of NETCONF implementors, Jürgen Quittek relates that they feel the lack of notifications to be the most significant problem. They consider submitting a draft outlining possible methods to address notifications. The open question is whether to do them within or outside the NETCONF framework; that's probably the first decision to make.

    Sharon Chisholm thinks that we now have a better idea on how notifications should be done than back when we decided to punt them for "NETCONF 1.0". It is important for people to document their approaches in drafts - ideally before the Paris meeting - so that we have a basis for discussion, rather than brainstorming here. A little discussion ensued between Andy's and Sharon's recollection of why notifications were postponed. Andy's view is that the driving factor was that participants felt they weren't worth the effort, and Sharon found that the reason was mainly tactical - to get the less contentious parts out first, although everybody eventually wanted notifications in NETCONF. Sharon doesn't think that we have thought about notifications enough to be able to say that they don't work on certain transports - she has seen proposals that have very little transport dependency.

    Eliot tries to reformulate his question about the constraints for extensions and capabilities, again with notifications as the example. They could be implemented using another channel in both BEEP and SSH, but the current SSH mapping draft doesn't talk about the ability to use additional channels. Another approach would be to to notifications over a separate TCP connection - they could be encoded as a large RPC response that could be parsed in an intermediate ("streaming") fashion - this would work over all transports without modifications to the current mappings.

    Remembering previous discussions about notifications, Andy talks about implementation difficulties with multiple channels, related to assumptions about locking. Multiple channels could solve the issue of mixing normal responses and asynchronous notifications, provided that there are separate code paths for those at each end. But at that point one could ask what this buys us that we cannot already do with SNMP traps [or notifications]? We didn't start out to replace SNMP notifications here - let's continue to use those until we figure NETCONF notifications out.

    General NETCONF Scope Discussion

    Sharon claims that notifications are just a subset of more general "asynchronous messaging" functionality for applications, many of which are related to configuration. Andy is worried about adding to the standard without clear requirements. Sharon points to a mailing list thread about such messages; "configuration change" notifications; and people looking at asynchronous messages from the monitoring perspective, as a mechanism for (performance) logging. To Andy, this sounds like reinventing IPFIX. Sending out accounting records is not a network configuration protocol's job. Sharon claims there are applications related to configuration, which will be shown in an upcoming draft.

    Faye Li supports Sharon's point of view. For configuration, an audit trail must also be supported. Operators want to receive a record for every configuration change.

    Dan Romascanu feels like a few years ago, when we were discussing whether to do configuration or a generic network management protocol. He disagrees with Sharon's and Faye's point of view. On the other hand, he thinks at one point we need a common framework for NETCONF and SNMP. Should check whether NETCONF plays nice with any security solutions that the ISMS WG might come up with.

    Andy asks Sharon to issue a draft as a basis for discussion.


    Passes to Sharon for her presentation on data modeling.

    Discussion ended with the suggestion to produce drafts about data modeling before the Paris meeting, and discuss them there.

    Closing Remarks

    Document authors are expected to produce revised drafts, with the necessary modifications as discussed here, soon after the I-D queue opens up after the meeting.


    Updtaes on the NETCONF Protocol I-D
    NETCONF Data Modeling Issues (NETMOD)