middle of 2002, when the IETF/IAB workshop took
place, the advantages and shortcomings of SNMP were
clear. SNMP had proved to work reasonably well for
monitoring devices, especially when small amounts of
information needed to be retrieved. For configuration
purposes, however, the protocol had pretty much failed
for a variety of reasons, including lack of writable MIBs,
security concerns, and scaling constraints. By comparing
SNMP with other network management options, such as
CLIs, HTTP, and XML, network operators came up with
a list of requirements for the network management
technology of the future. Some of these requirements are
summarized in the following list:
This new network management technology should be easy to use.
There should be a clear distinction between configuration data and
operational data.
It should be possible to configure extensive network services as a whole
(such as IPTV and Layer 3 VPNs) instead of just configuring a network
device by device.
Configuration transactions and easy rollback in the event of failure
should be supported.
There should be a standard and consistent representation of the
network configuration commands between different vendors.
A distinction between candidate and active configurations should exist,
meaning that devices should be able to hold multiple configurations
and activate them as needed.Based on these requirements, the IETF developed
Network Configuration Protocol (NETCONF). The
NETCONF protocol specifies the means of opening a
secure management session with a network device,
includes a set of operations to manipulate the
configuration data and retrieve the operational state, and
describes a mechanism to send out notifications.
NETCONF was initially defined in 2006 in RFC 4741 and
updated in 2011 with RFC 6241. While the NETCONF
protocol specifies the mechanism to establish a