YANG Data Models Explained for Network Engineers

Every modern network API, NETCONF, RESTCONF, gNMI, is really a way of moving structured data in and out of a device. And structured data needs a schema: an agreed definition of what fields exist, what type each one is, and how they nest. That schema language is YANG, and it is the thing that makes model-driven automation possible. You cannot really understand NETCONF or RESTCONF without understanding what YANG is modelling.

This article explains YANG for network engineers: what a data model is, the difference between native and OpenConfig models, and how to actually explore one. It extends the Network Automation cluster guide.

The Core Idea: A Schema for Configuration

When you type show ip interface brief, IOS gives you text formatted for a human. That text has no schema; a script has to scrape it with fragile regex, and the format can change between releases. Model-driven management replaces that with structured data (XML or JSON) whose shape is defined by a YANG model. The model says, precisely: an interface has a name (string), an enabled flag (boolean), an IP address (a specific type), and so on.

The payoff is that automation stops guessing. A script does not parse text hoping the columns line up; it requests interfaces/interface/name and gets exactly that field, in a defined type, every time. YANG is the contract that makes this reliable.

YANGThe modelling language. Defines the structure and types (the schema).

XML / JSONThe encoding. The actual data on the wire, shaped by the YANG model.

NETCONF / RESTCONFThe transport. How the encoded data gets to and from the device.

Three layers: YANG (what the data looks like), the encoding (XML or JSON), and the protocol (NETCONF or RESTCONF). YANG is the foundation the other two stand on.

The Anatomy of a Model

A YANG model is a tree. The building blocks you will meet:

container

A grouping node with no value of its own, holding other nodes. Like a folder. interfaces is a container.

list

Multiple instances of the same structure, keyed by a field. interface is a list keyed by name.

leaf

A single value with a type. name, enabled, mtu are leaves.

leaf-list

Multiple values of the same leaf. A list of DNS servers, for example.

Put them together and the standard ietf-interfaces model reads as: a container interfaces, holding a list interface keyed by name, where each entry has leaves like name, enabled, and type. That tree is exactly what you address when you make a NETCONF or RESTCONF request; the path interfaces/interface=GigabitEthernet2/enabled walks straight down it.

Native vs OpenConfig: The Distinction That Matters

There are two families of YANG model on a Cisco device, and knowing which to use is a real design decision:

Native (Cisco-IOS-XE-*)

Cisco's own models, mirroring the full IOS XE feature set. Everything the CLI can do, but Cisco-specific: a script written against them only works on Cisco.

OpenConfig / IETF

Vendor-neutral models (openconfig-*, ietf-*). The same model works across Cisco, Juniper, Arista. Broad coverage, but not every vendor-specific feature.

The trade-off is the same one as everywhere in networking: vendor-specific power versus multi-vendor portability. Use OpenConfig or IETF models when you want your automation to work across a mixed estate and you only need common features (interfaces, BGP, basic config). Use native models when you need a Cisco-specific feature that the standard models do not cover, accepting that your script is now Cisco-only. Many real deployments use both: OpenConfig for the portable 80%, native for the Cisco-specific 20%.

Exploring a Model

You do not have to read raw YANG source to work with a model. Two practical approaches.

pyang renders a model as a readable tree. Point it at a downloaded YANG file and it prints the structure:

$ pyang -f tree ietf-interfaces.yang
module: ietf-interfaces
  +--rw interfaces
     +--rw interface* [name]
        +--rw name             string
        +--rw description?     string
        +--rw type             identityref
        +--rw enabled?         boolean
        +--rw ipv4
           +--rw address* [ip]
              +--rw ip               inet:ipv4-address
              +--rw netmask?         ...

That tree is the map. The rw flags mean read-write (configurable); ro would mean read-only (operational state you can read but not set). The * marks a list, and [name] is its key. The ? marks an optional leaf. Once you can read this tree, you can construct any NETCONF or RESTCONF path into the model.

The device itself advertises the models it supports. A NETCONF hello exchange lists every model in the device's capabilities, and you can pull the actual schema from the box. In practice you explore against the real device: request a subtree and see what comes back, which is exactly what the NETCONF and RESTCONF articles do.

Why a Network Engineer Should Care

It is tempting to treat YANG as a programmer's concern. It is not, and here is why it matters operationally:

It makes automation robust. Text scraping breaks when output formats change between releases. A YANG-modelled request returns the same structured field regardless of how the CLI happens to format it. Your automation stops being fragile.
It is how the exam frames automation. The ENCOR blueprint expects you to understand data models, not just run scripts. Knowing container/list/leaf and native-vs-OpenConfig is directly testable.
It is the future of the interface. gNMI and streaming telemetry, the direction the industry is heading, are entirely model-driven. The CLI is not going away, but the programmatic interface is YANG-shaped, and understanding the model is understanding the interface.

FAQ

Do I have to read raw YANG source?

No. Use pyang -f tree to render a readable tree, or explore against the live device by requesting subtrees. You almost never read the raw .yang files directly.

Native or OpenConfig models?

OpenConfig/IETF for multi-vendor portability and common features; native (Cisco-IOS-XE-*) for Cisco-specific features the standard models do not cover. Many shops use both.

What is the difference between rw and ro in the tree?

rw is read-write (configuration you can set), ro is read-only (operational state you can read but not change). NETCONF separates these into config and state datastores.

Is YANG the same as XML?

No. YANG is the schema (the model definition). XML (or JSON) is the encoding (the actual data). YANG defines the shape; XML/JSON carries the values.

How do I know which models a device supports?

The device advertises them in its NETCONF capabilities (the hello exchange) and via the netconf-state schema list. You can enumerate them programmatically.

Key Takeaways

YANG is the schema language for model-driven management: it defines the structure and types of configuration and state data.
Three layers: YANG (the model), XML/JSON (the encoding), NETCONF/RESTCONF (the transport). YANG is the foundation.
Models are trees of container, list, leaf, leaf-list. The path into that tree is exactly what NETCONF/RESTCONF requests address.
Native models (Cisco-IOS-XE-*) cover everything but are Cisco-only; OpenConfig/IETF models are vendor-neutral but cover common features. Choose by portability need.
Explore with pyang -f tree or against the live device. You rarely read raw YANG source.
It matters because model-driven automation is robust (no text scraping), exam-relevant, and the direction of streaming telemetry and gNMI.