The Full Wiki



Note: Many of our articles have direct quotes from sources you can cite, within the Wikipedia article! This article doesn't yet, but we're working on it! See more info or our list of citable articles.


From Wikipedia, the free encyclopedia

The Network Configuration Protocol, NETCONF, is an IETF network management protocol. It was developed in the NETCONF working group and published in December 2006 as RFC 4741.

NETCONF provides mechanisms to install, manipulate, and delete the configuration of network devices. Its operations are realized on top of a simple Remote Procedure Call (RPC) layer. The NETCONF protocol uses an Extensible Markup Language (XML) based data encoding for the configuration data as well as the protocol messages. This in turn is realized on top of the transport protocol.

The NETCONF protocol can be conceptually partitioned into four layers:

       Layer                            Example
   +-------------+      +-------------------------------------------+
   |   Content   |      |     Configuration data                    |
   +-------------+      +-------------------------------------------+
             |                           |
   +-------------+      +-------------------------------------------+
   | Operations  |      |<get-config>, <edit-config>, <notification>|
   +-------------+      +-------------------------------------------+
             |                           |                    |
   +-------------+      +-----------------------------+       |
   |     RPC     |      |    <rpc>, <rpc-reply>       |       |
   +-------------+      +-----------------------------+       |
             |                           |                    |
   +-------------+      +-------------------------------------------+
   |  Transport  |      |   BEEP, SSH, SSL, console                 |
   |  Protocol   |      |                                           |
   +-------------+      +-------------------------------------------+




Basic Operations

The base protocol includes the following protocol operations: <get>, <get-config>, <edit-config>, <copy-config>, <delete-config>, <lock>, <unlock>, <close-session>, <kill-session>.


Basic NETCONF functionality can be extended by the definition of NETCONF capabilities. The set of additional protocol features an implementation supports is communicated between the server and the client during the capability exchange portion of session setup. Mandatory protocol features are not included in the capability exchange since they are assumed. RFC 4741 defines a number of optional capabilities including :xpath and :validate.

A capability to support subscribing and receiving asynchronous event notifications is published in RFC 5277. It defines the <create-subscription> operation, which enables creating real-time and replay subscriptions. Notifications are then sent asynchronously using the <notification> construct. The RFC also defines the :interleave capability, which when supported with the basic :notification capability facilitates the processing of other NETCONF operations while the subscription is active.

The working group is currently working on a partial locking capability. It is also working on a new capability to retrieve the schema definitions (XML Schema, Relax NG, etc) that define NETCONF content.

Transport Protocols

NETCONF defines four transport mappings


The content of NETCONF operations is well-formed XML. Most content is related to network management.

The NETMOD working group is currently working to define a "human-friendly" modeling language defining the semantics of operational data, configuration data, notifications, and operations.


The IETF developed SNMP in the late 1980s and it proved to be a very popular network management protocol. In the early part of the 21st century it became apparent that in spite of what was originally intended, SNMP was not being used to configure network equipment, but was mainly being used for network monitoring. In 2002, the Internet Architecture Board and key members of the IETF's network management community got together with network operators to discuss the situation. The results of this meeting are documented in RFC 3535. It turned out that operators were primarily using proprietary Command Line Interfaces (CLI) to configure their boxes. This had a number of features that the operators liked, including the fact that it was text-based, as opposed to the BER-encoded SNMP. In addition, many equipment vendors did not provide the option to completely configure their devices via SNMP. As operators generally liked to write scripts to help manage their boxes, they did find the CLI lacking in a number of ways. Most notably was the unpredictable nature of the output. The content and formatting of output was prone to change in unpredictable ways.

Around this same time, Juniper Networks had been using an XML-based network management approach. This was brought to the IETF and shared with the broader community.

Collectively, these two events led the IETF to the creation of a protocol which it hopes will better align with the needs of network operators and equipment vendors.

Not to be Confused with

netconf is also the (working) name of a network configuration tool, which is currently in development. It remains to be decided whether the tool name ought to be changed to avoid confusion.

See also

External links


Got something to say? Make a comment.
Your name
Your email address