device, and it is always present. NETCONF protocol operations refer to
this data store with the <running> XML element.
candidate: This data store acts as a workplace for creating and
manipulating configuration data. A <commit> operation causes the
configuration data contained in it to be applied to the running data
store.
startup: This data store contains the configuration data that is loaded
when the device boots up and comes online. An explicit <copy-config>
operation from the <running> data store into the <startup> data store
is needed to update the startup configuration with the contents of the
running configuration.The existence of these data stores is advertised by the
NETCONF device through capabilities. When opening a
new session with a NETCONF server, the first message
that is sent by the server contains a list of all the
capabilities that the server supports.
The information that can be retrieved from a NETCONF
server is separated into two classes: configuration data
and state data or operational data. Configuration data is
the set of writable data that starts the system operations;
operational data, also known as the read-only status
data, is the non-configuration data of the system (for
example, interface traffic statistics, power supply status).
YANG
As mentioned in RFC 6020, YANG is “a data modeling
language used to model configuration and state data
manipulated by the Network Configuration Protocol
(NETCONF), NETCONF remote procedure calls, and
NETCONF notifications.” The main motivation behind
YANG was to provide a standard way to model
configuration and operational data so that network
devices can be configured and monitored in a standard
and common way. While CLI configuration and
monitoring of network devices is user friendly, it is not
necessarily network automation friendly. Different
network vendors have different CLIs with different
features and capabilities. Trying to find a standard way
to automate the configuration and monitoring of a