The IETF Network Configuration Working Group chartered to "produce a protocol suitable for network configuration" has issued an initial NETCONF Configuration Protocol Working Group Draft. The IETF netconf WG held its first meeting in July 2003 at the 57th IETF meeting in Vienna, Austria and will continue design work at an interim meeting on September 8-10, 2003. The draft NETCONF protocol "defines a simple mechanism through which a network device can be managed. Configuration data, state information, and system notifications can be retrieved. New configuration data can be uploaded and manipulated. The protocol allows the device to expose a full, formal, application programming interface (API). Applications can use this straight-forward API to send and receive full and partial configuration data sets. NETCONF uses a remote procedure call (RPC) paradigm to define a formal API for the network device. A client encodes an RPC in XML and sends it to a server using secure, connection-oriented session. The server responds with a reply encoded in XML. The contents of both the request and the response are fully described in XML DTDs or XML schemas, or both, allowing both parties to recognize the syntax constraints imposed on the exchange. A key aspect of NETCONF is an attempt to allow the functionality of the API to closely mirror the native functionality of the device. This reduces implementation costs and allows timely access to new features. In addition, applications can access both the syntactic and semantic content of the device's native user interface."

Bibliographic Information

Working Group Draft. NETCONF Configuration Protocol. Edited by Rob Enns (Juniper Networks). IETF Network Working Group, Internet-Draft. Reference: 'draft-ietf-netconf-prot-00'. August 11, 2003, expires February 9, 2004. 73 pages.

Individual IETF Submission. A SOAP Binding for NETCONF. By Ted Goddard (Wind River Systems). IETF Network Working Group, Internet Draft. Reference: 'draft-goddard-netconfsoap-00.txt'. June 19, 2003, expires December 18, 2003. 18 pages. Wigh 17 references. "While the device management protocol NETCONF is generally well served by BEEP, there are environments where additional transports are desirable. The binding to SOAP described here may find application where SOAP-based tools and implementations are prevalent or where the network configuration favors HTTP. When used with multiple HTTP connections, SOAP over HTTP is sufficient for all NETCONF features except those involving asynchronous notification..."

Individual IETF Submission. XML Network Management Interface. By Weijing Chen and Keith Allen (SBC Labs). IETF Netconf Working Group, Internet Draft. Reference: 'draft-weijing-netconf-interface-00'. June 2003, expires December 2003. 23 pages. "This document describes XML network management interface between network managed system and network managing system. The XML network management interface is intended for use in diverse network environment where transport and data model requirements vary greatly. It is unlikely that a single transport and data model specification will meet the needs of all anticipated service operators. Therefore, the XML network management interface is partitioned into the layered components..."

From the NETCONF Configuration Protocol WD

According to the initial WG draft, "There is a need for standardized mechanisms to manipulate, install, edit, and delete the configuration of a network device. In addition, there is a need to retrieve device state information and receive asynchronous device state messages in a manner consistent with the configuration mechanisms. There is great interest in using an XML-based data encoding because a significant set of tools for manipulating ASCII text and XML encoded data already exists."

NETCONF allows a client to discover the set of protocol extensions supported by the server. These "capabilities" permit the client to adjust its behavior to take advantage of the features exposed by the device. The capability definitions can be easily extended in a noncentralized manner. Standard and vendor-specific capabilities can be defined with semantic and syntactic rigor."

"The NETCONF protocol is a building block in a system of automated configuration. XML is the lingua franca of interchange, providing a flexible but fully specified encoding mechanism for hierarchical content. NETCONF can be used in concert with XML-based transformation technologies such as XSLT to provide a system for automated generation of full and partial configurations. The system can query one or more databases for data about networking topologies, links, policies, customers, and services. This data can be transformed using one or more XSLT scripts from a vendor-independent data schema into a form that is specific to the vendor, product, operating system, and software release. The resulting data can be passed to the device using the NETCONF protocol.

From the IETF Netconf Working Group Charter

"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 structures.

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 names
• 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 requirements.
• 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.

XMLCONF Overview

The IETF NETCONF WG agreed to base its work and initial Working Draft specification on the existing XMLCONF I-D. An XMLCONF Overview is provided in the presentation slides from NETCONF WG meeting. IETF 57 -- Vienna. By Rob Enns (Juniper Networks). 22 pages. The XMLCONF authors include Andy Bierman, Eliot Lear, David Perkins, Ted Goddard, Phil Shafer, Rob Enns, Ken Crozier, Steve Waldbusser, and Margaret Wasserman, XMLCONF Strategy is to: (1) Create a standard operational framework for configuration [Allow for monitoring and notifications, but focus on configuration]; (2) Separate the protocol from the data model [Allow for standard and proprietary content; standardize the protocol first, and then start on content]; (3) Create a transport independent, RPC-based configuration mechanism [XMLCONF over BEEP, SOAP, console]; (4) Develop high level protocol operations common to most devices [Focus on transactions]. The strategy should allow the implementation to mirror native capabilities of device (a text-based technology such as XML permits tight integration with CLI; no feature lag between XMLCONF and CLI)... Session Management include a management channel (Session control; creation of other channels; Abort command kills current command on the operations channel; Kill-session used to terminate the session of another user), an operations channel (used for RPC requests and replies) and a notification channel (an optional channel for asynchronous messages)..." See the posting for the source .PPT [cache].