Data formats, YANG models and device programmability: NETCONF, RESTCONF and gNMI

Why the CLI is not enough

The command line was designed for people. When a script logs in over SSH, types a command and tries to pick values out of the text that comes back, this is called screen scraping. It works, and libraries such as Netmiko make it easier, but it is fragile: column widths change between software versions, error messages are just more text, and there is no built-in way to check that a change was applied as a whole. SNMP is structured, but its Set operation was never widely trusted for configuration and its data models are limited. Automation at scale needs devices that speak in structured data.

Data formats: writing data down

A data format is a way of writing structured data as text. You will meet three, and they can all describe the same thing. Here is one interface in each:

XML:   <interface><name>Gi1/0/5</name><enabled>true</enabled></interface>
JSON:  {"interface": {"name": "Gi1/0/5", "enabled": true}}
YAML:  interface:
         name: Gi1/0/5
         enabled: true

• XML uses opening and closing tags. It is verbose but strict, and it is the encoding NETCONF uses.
• JSON uses braces for objects and square brackets for lists. It is compact and is the usual format for REST APIs.
• YAML uses indentation and is the easiest for humans to read and write. Ansible playbooks and many inventory files are YAML. Indentation errors are the most common mistake.

Data models: YANG

A format says how to write data; a data model says what the data is allowed to be. YANG (RFC 7950) is the modelling language used across networking. A YANG module defines a tree of containers, lists and leaves, with types and rules: an interface has a name that is a string, an MTU that is a number in a set range, an enabled flag that is true or false. Because the device and the tool share the same model, a request can be checked before anything changes.

• Standard models from the IETF cover common features such as interfaces and routing.
• OpenConfig models are written by network operators to be vendor-neutral.
• Native models from each vendor cover every platform-specific feature.

The three programmable interfaces

NETCONF works with datastores (running, startup and, on some platforms, candidate). You can lock a datastore, send a batch of changes to the candidate, validate it and commit it in one step, so either everything applies or nothing does. RESTCONF exposes the same YANG data as web resources: a GET on a URL returns JSON, and PUT, PATCH, POST and DELETE change it. gNMI (gRPC Network Management Interface) can also get and set configuration, but its main use is model-driven telemetry: the device streams counters every few seconds, or as soon as something changes, instead of waiting to be polled like SNMP.

netconf-yang
restconf
ip http secure-server
username autobot privilege 15 secret Use-A-Strong-Secret

On Cisco IOS XE these lines enable NETCONF and RESTCONF; check your platform's guide for gNMI. Protect the interfaces as you would SSH: dedicated accounts, an ACL limiting who can connect, and logging. For working code see NETCONF and YANG with Python and RESTCONF.

Real-world example: an interface audit that stopped breaking

A fictional regional bank had a nightly script that logged in to 300 switches, ran show interfaces status and parsed the columns to find unused ports. After a software upgrade on half the switches, a column grew wider and the script quietly reported wrong results for weeks. The automation team rewrote it to use RESTCONF with the standard IETF interfaces model. The script now asks for the interface list as JSON and reads the "enabled" and "oper-status" values by name, so layout changes no longer matter. They later moved the counters to gNMI streaming, which also gave the operations team near-real-time graphs.