> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # YANG Data Models Explained for Network Engineers - URL: https://www.pinglabz.com/yang-data-models-explained/ - Published: 2026-07-12T02:58:38.000Z - Updated: 2026-08-24T05:22:39.000Z - Description: YANG is the schema language behind NETCONF, RESTCONF, and gNMI. This post explains data models for network engineers: what a model defines, the difference between native and OpenConfig models, and how to actually explore one. - Author: Jaime - Tags: Network Automation, #Import 2026-08-01 19:54 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](https://www.pinglabz.com/network-automation/). ## 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](https://www.pinglabz.com/netconf-cisco-ios-xe-hands-on/) or [RESTCONF](https://www.pinglabz.com/restconf-cisco-ios-xe/)). 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](https://www.pinglabz.com/netconf-cisco-ios-xe-hands-on/) and [RESTCONF](https://www.pinglabz.com/restconf-cisco-ios-xe/) 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. Next: [NETCONF hands-on](https://www.pinglabz.com/netconf-cisco-ios-xe-hands-on/) and [RESTCONF](https://www.pinglabz.com/restconf-cisco-ios-xe/), or the [Network Automation cluster guide](https://www.pinglabz.com/network-automation/).