Network Configuration Protocol (NETCONF) is a network management protocol defined by the IETF in RFC 6241. NETCONF provides rich functionality for managing configuration and state data. The protocol operations are defined as remote procedure calls (RPCs) for requests and replies in XML-based representation. NETCONF supports running, candidate, and startup configuration data stores. The NETCONF capabilities are exchanged during session initiation. Transaction support is also a key NETCONF feature.
Figure 12-6 lists some key points for three NETCONF data stores: running, startup, and candidate.

Figure 12-6 NETCONF Data Stores
Figure 12-7 shows the NETCONF model, which has four layers, and how NETCONF details map to it.

Figure 12-7 The NETCONF Model
NETCONF is a client/server protocol and is connection oriented over TCP. All NETCONF messages are encrypted with SSH and encoded with XML. A NETCONF manager is a client, and a NETCONF device is a server. The initial contents of the <hello> message define the NETCONF capabilities that each side supports. The YANG data model defines capabilities for the supported devices. In addition, other standards bodies and proprietary specifications define capabilities.
Figure 12-8 provides an example of the NETCONF <hello> operation. Notice that the capabilities are listed, and each one has either ietf or tail-f noted to indicate whether IETF or Tail-F proprietary specifications define the YANG data for that capability.

Figure 12-8 NETCONF <hello> Operation
Table 12-5 lists NETCONF protocol operations, which, as you can see, use XML-based encoding.
Table 12-5 NETCONF Protocol Operations
Operation | Description |
<get-config> | Retrieves all or part of a specified configuration |
<edit-config> | Loads all or part of a specified configuration (for example, create, merge, replace, delete) |
<get> | Retrieves all or part of a running configuration and device operational data |
<get-schema> | Retrieves the device schema |
<lock> | Locks the entire configuration data store (that is, candidate) |
<unlock> | Removes the lock on the entire configuration data store (that is, candidate) |
<close-session> | Requests graceful session termination |
RESTCONF Concepts
RESTCONF, which is defined in RFC 8040, is an HTTP-based protocol that provides a programmatic interface for accessing YANG modeled data. RESTCONF uses HTTP operations to provide create, retrieve, update, and delete (CRUD) operations on a NETCONF data store containing YANG data. RESTCONF is tightly coupled to the YANG data model definitions. It supports HTTP-based tools and programming libraries. RESTCONF can be encoded in either XML or JSON.
Here is an example of a RESTCONF uniform resource identifier (URI):
/restconf/
<resource-type>
/
<yang-module:resource>
RESTCONF uses data and operations (RPCs) for resource types within a RESTCONF URI.
Figure 12-9 shows JSON-formatted RESTCONF data and RPC operations and their associated URIs.

Figure 12-9 RESTCONF API: URIs for Data or Operations
Figure 12-10 shows JSON RESTCONF data illustrating containers and lists with URIs.

Figure 12-10 RESTCONF API: Containers and Lists
Table 12-6 shows the RESTCONF API CRUD operations GET, POST, PUT, and DELETE and associated URIs.
Table 12-6 RESTCONF CRUD Operations
Operation | Description | URI |
GET | Gets a resource | GET /restconf/data/my-interfaces:interfaces/interface/<some name> |
PATCH | Invokes a resource patching mechanism | PATCH /restconf/data/my-interfaces:interfaces/interface/<some name> |
POST | Creates a resource or invokes an operation | POST /restconf/data/my-interfaces:flap-interface + JSON/XML Form Data |
PUT | Replaces a resource | PUT /restconf/data/my-interfaces:interfaces/interface/<some name> + JSON/XML Form Data |
DELETE | Removes a resource | DELETE /restconf/data/my-interfaces:interface/<some name> |