2.4.10 Network Configuration (netconf)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. 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-07-13


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: https://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
Done  Submit final version of the Netconf Protocol draft to the IESG
Done  Submit final version of the Netconf over SOAP draft to the IESG
Done  Submit final version of the Netconf over BEEP draft to the IESG
Done  Submit final version of the Netconf over SSH draft to the IESG


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

    No Request For Comments

    Current Meeting Report

    Minutes for NETCONF WG meeting at IETF 63

    NETCONF WG Minutes, IETF 63

    IETF 63, Paris
    Thursday, 4 August 2005, 0900-1000, room 341

    Chairs: Simon Leinen, Andy Bierman (participating remotely)
    Scribes: Eliot Lear (Jabber), Dan Romascanu (off-line)
    Minutes: Simon Leinen.

    This was the 8th meeting of the WG (including the interim).

    Document Status

    AD Feedback on Submitted Documents

    All 4 WG documents (prot, ssh, beep, soap) were submitted for publication. Bert Wijnen, the Area Director in charge of our WG, already provided some feedback. Besides a few minor bugs, Bert noticed that the prot document had a null IANA considerations section although it seems clear that the document does have IANA considerations. This issue may require discussion. "You may need/want a few registries".

    Grouping of Documents for Publication

    On the way through the approval process towards RFC publication, the prot and ssh documents should be treated together, while the beep and soap documents should advance separately.

    Interoperability Testing

    MOME had an interoperability testing event last week, featuring nsis/ipfix/netconf. There were four netconf implementations present, two from commercial vendors and two from academic institutions. As a participant in the tests, James Hong provided some feedback.

    Data Model

    Since there is no standard NETCONF data model, an ad-hoc one was defined for the tests. Some incompatibilities on the data model level were found between the implementations. In addition, the data model used for testing concerned interfaces. This made testing <edit-config> difficult, as successful configuration changes would typically break connectivity to the NETCONF agent.

    SSH Mapping

    Only the mandatory SSH mapping was tested. Participants reported there were small issues getting SSH to interoperate, in particular the message separator and the use of SSH subsystems posed problems. As these particular parts of the SSH mapping were modified during the WG process, the issues may be the result of implementations initially based on earlier versions of the specification, rather than issues with the current specification.

    Two agent implementations lacked SSH transport and weren't tested.

    there was one SOAP implementation. we felt it would have been easier to test. we did NOT really test edit-config.


    According to James Hong, there were issues on how to handle "pipelined" requests. In the absence of the principal prot authors, this stirred some discussion on whether request pipelining is in fact permitted by the protocol as currently specified. Although each message can only contain a single <rpc> element, and each <rpc> element only a single method call, pipelining is explicitly permitted in the sense that an additional request may be send before the response was read.

    The organizers will forward a summary to the NETCONF mailing list.


    Dan Romascanu: Are there any recommendations for what the data model should include regarding future work?
    Simon: Having guidelines would be helpful.

    Sharon asked how the ad-hoc data model was described.
    James Hong said that the common model was a very simple XSD.

    Bert has a generally positive impression from the results of the interoperability tests. There didn't seem to be any major problems with the protocol itself.

    Charter Discussion

    Status With Respect to Current Charter and Options for Going Forward

    Simon reminds that the charter is a contract between the Working Group and the IETF. We have completed our current action items, but we have unmet goals, specifically around (fine-grained) locking and notifications. Notifications once were in the protocol but were dropped. The current charter also talks about XML usage guidelines that the group should develop, but this is very open ended - we should consider scope. Access control is another area that (like locking) was deferred because of interactions with the data model.

    Simon listed several possible ways to go forward:

    • "declare victory and go home"
    • finish notifications (to fulfill charter to the letter)?
    • go dormant until we have enough implementation experience and operating experience and then review.

    Lastly, the big question is whether or not to take on data modeling, and if so what would the scope of that work be?

    Sharon's "NETCONF Phase 2 Musing"

    (see slides)

    Sharon presents her view of NETCONF development. Phase one has been completed now. Primary focus for protocol is on configuration, but we shouldn't preclude discussion on other forms of management, such as monitoring.

    Notifications are useful for informing operators when a configuration has changed, as well as for security auditing purposes.

    There is a draft available on an "SMI" for NETCONF. The intent is to foster interoperability without creating unnecessary rules. We should be careful as to what - if anything - gtes taken forward from the SNMP SMI.

    As a proof of concept, there is an initial set of definitions for reusable application-level data types. There is also a definition of a schema for NETCONF reporting - which could be turned into a configuration schema. Other areas to work on include asynchronous messaging/event notification, access control, a method for deliverying software loads for NETCONF, and a method for multi-channel support. Some of this will have to be moved to a phase 3/phase N.

    As next steps, Sharon proposes that the NETCONF event and data modeling work be added to the NETCONF charter as phase 2. Other work can be added as there is interest and resources available.


    Gauging Interest in Additional Work and Experience with Existing Protocol

    Simon: we must update the charter, and that charter will receive review by AD and IESG, and (provided IESG accepts it) the IETF. He asks Bert about his and the IESG's decision criteria. Bert responds that the normal criteria apply, such as the need for significant interest etc. But first he has a few questions to the room:

    Bert asks the attendees Concerning any of the proposed new work items - who is in favor of those? About 10-12 people. Among these people, who has an implementation of NETCONF (including the SSH mapping)? Hardly any positive response, although one proponent claimed an implementation-in-progress. Bert points out that the one person in the room who was at the interoperability event last week didn't raise his hand. Bert has an issue with the fact that the people who want to add work items haven't worked on or experimented with implementations of what we have defined right now.

    Dan Romascanu is in favor of additional work in the data model area in particular. The absence of a data model and the consequent lack of interoperability is a problem when talking about NETCONF both with customers and internally (about a proprietary system that could be migrated to a NETCONF base). He did not raise his hand on the second question because his company does not write protocols; they expect commercial or public domain products to become available, and are already experimenting with what's available.

    Bert has more questions for the proponents of additional work items: How many of you have downloaded and experimented with the publicly available implementations? Still only a subset of the 10-12. How many have actually been working with operators to see if they'll use this protocol? A relatively large number. However it's not clear how useful this kind of feedback is until operators actually had the opportunity of playing with implementations. Bert reminds the group that we got here because operators weren't using many of the features that were added to SNMP over the years, such as writable MIBs, and he wants to be very prudent that we not miss the operators again. Through the OPS directorate, we asked operators - who made us start this work because they weren't happy with SNMP - to review the work and play with this stuff and make sure we've done the right thing before put in additional person-years to continue to develop this work. Please get other operators to comment.

    Sharon: We have a preliminary implementation we've put in front of operators and they like the direction.

    Notifications/Asynchronous Messaging

    Sharon: Every single project group asks about asynchronous messaging. If we don't standardize asynchronous messaging, we'll have an interoperability mess in a few years as vendors will do their own thing. "Asynchronous messaging" describes a subscription-based information retrieval model as opposed to a poll/response one. A lot of applications - not just configuration-related - need this, but often it is used for supporting the bigger picture of configuration management. Sharon avoids the word "notifications" because people often think about the specific SNMP mechanism.

    Kathleen Moriarty shares some thoughts from the perspective of a NETCONF customer, a large enterprise network and operator of various IPS (Intrusion Prevention Systems) from different vendors. Central management based on open standards would be very useful. Regulations such as Sarbanes-Oxley or the Federal Information Security Management Act (FISMA) mandate auditability of what changes were made when and by whom. A requirement for implementing NETCONF would be an open standard to do rollbacks. Another trend is to automate changes and rollbacks. Andy points out that detailed audit logs are different from rollback; NETCONF provides some rollback, but no auditing.

    Simon hears this as another request for notifications. Existing configuration systems that we use already have very good notifications for configuration-related events, using SNMP traps/notifications and syslog. SNMP traps and syslog are perceived as too hard to integrate with configuration applications, so it seems attractive to integrate this into the NETCONF protocol. But we're not the only ones having this problem! He agrees with Andy that this group could work on notifications, but maybe we would duplicate existing work, or do work that should better be done elsewhere.

    David Martin points out that although we decided early on that Web Services would be too heavy for NETCONF, it may be worthwhile to look at WS work in the area of notifications.

    Andy reminds the group that the original NETCONF proposal was to use reliable syslog (RFC 3195), and explicitly not to invent anything new. Jürgen Schönwälder cautions that RFC 3195 has not seen widespread use in the almost four years since it was published. Sharon was involved in the syslog stuff, trawled through the Web Services stuff, and also looked at event subscription in SIP. The intent is not to invent unnecessarily.

    Dave Perkins: On the auditing issue, we have a management application has the identity when you do a transaction. the user who pressed the button is not captured. [proxied discussion]

    Darren Loher agrees with Andy's comment that an event system such as reliable syslog would be extremely valuable in general. Andy isn't sure whether RFC 3195 is the right choice, but he wants to avoid reinvention if possible

    Data Model (and more on Notifications...)

    Azita Kia: On the data model, and that there was a lot of work done in SNMP. NETCONF has been successful so far, but without a data model, it's just a protocol to exchange generic data. Creating a data model is a very big task. Can we do some incremental work, leveraging the wealth of SMI definitions and MIBs that have already been done, by XMLizing some of those?

    Simon concedes that this could be a way forward, but also notes that MIBS and SNMP haven't been very successful for configuration.

    Jim Golvinsky: Not having a reference data model makes the protocol useless. We end up with N-square integration points. I'm going to be flamed now. He finds notifications important, but is concerned that we would be ignoring all the work that has been done in Web Services and also in the DMTF.

    Glenn Waters opines that the only way to build an integrated solution is to include notifications. Without them the protocol has a big hole. As to data models, we currently don't have a language to talk about data modeling. It's not sufficient to say "XML Schema". We need an SMI for XML, and need those rules to be put down in a single document. And we have to develop the language and then push the data model.

    Closing Remarks of our Area Director

    Bert says that in the past we've often heard "I'm channeling my customer's requirements." While I understand that few customers can make it here, we need to hear from them. I am willing to keep those communications private, but I'd like to hear from them. This was done because operators had expressed discontent with what was there, so they should be expected to review and comment.


    Netconf Phase 2 Musing