YANG is a data modeling language for network management. A YANG module describes the configuration and operational data a device or service exposes: which settings exist, what type each value must be, which values are required and how they nest. Protocols such as NETCONF and RESTCONF then read and change data that follows those models. YANG was developed in the IETF; version 1 was published in 2010 and version 1.1 in 2016.
At a glance
- YANG defines the shape of network data, not how it is transported.
- Models cover both configuration (what you set) and state (counters, status and other values the device reports).
- On the wire, NETCONF carries YANG-modeled data as XML, and RESTCONF as XML or JSON.
- Models come from the IETF, the OpenConfig operator group and individual vendors, and support varies by device and software version.
- YANG underpins much of what vendors call model-driven network automation.
What problem it solves
For decades, network devices were configured mostly through a command line meant for people. Each vendor, and often each operating system version, had its own syntax. Automation tools had to send commands and scrape text output, which broke whenever the output format changed. Monitoring through SNMP offered structured data for reading, but was rarely practical for configuration.
YANG gives devices a machine-readable contract. A model states, for example, that an interface has a name, a description, an enabled flag and a list of IP addresses, each with a defined type. Software can then send structured changes, have the device validate them against the model, and read back state in the same structure. When several vendors support the same model, one automation workflow can configure different hardware in a more consistent way.
How it works
Modules and trees. A YANG module defines a tree of data nodes. Containers group related nodes, lists hold repeated entries such as interfaces or VLANs, and leaves hold single values. Modules can import and extend each other.
Types and constraints. Each leaf has a type, such as a string, an integer range or an IP address. Constraints can make values mandatory, limit them to a set of options or require one setting to exist before another. The device checks changes against these rules.
Configuration and state. Models distinguish data an operator can set from data the device reports, such as operational status or packet counters. The same model can be used to push configuration and to collect state.
Operations and notifications. Modules can define remote procedure calls, such as a reboot or a ping test, and notifications a device sends when events occur.
Encodings and protocols. YANG itself is a text language for writing models. How the data that follows a model is encoded depends on the protocol: NETCONF uses XML, RESTCONF supports XML or JSON, and gNMI, a streaming telemetry and configuration interface, uses Protocol Buffers messages with several value encodings, including JSON and JSON-IETF. Which of these a device offers depends on the device.
Model sources. IETF standard models, OpenConfig models from network operators, and vendor-native models that expose features the common models do not cover. In practice, many deployments use some of each.
When it matters for buyers
- SD-WAN, managed network and NaaS proposals. Providers may describe their platforms as model-driven or API-first. Ask which models and interfaces they actually expose to you. See our managed network services page for help comparing providers.
- Multi-vendor networks. Common models can reduce per-vendor scripting, but only for the features each vendor implements in those models.
- Hardware selection. YANG, NETCONF and RESTCONF support differs by platform and software version. Check before you buy if automation is part of the plan.
- Ownership and exit. If a provider automates your network with YANG-based tooling, ask whether you get the templates and data when the contract ends.
Questions to ask vendors
- Which YANG models do your devices or platform support: IETF, OpenConfig, vendor-native, or a mix?
- Which interfaces expose those models: NETCONF, RESTCONF, gNMI or a proprietary API?
- How complete is model coverage? Which features can still only be configured through the command line or a GUI?
- How do model versions change across software releases, and how do you communicate those changes?
- Can we access the models and the configuration data directly, or only through your portal?
- If you manage our network, will we receive the automation templates and model data at exit?
How it differs from YAML
The names look alike, but they do different jobs. YAML is a general-purpose text format for writing data, used for configuration files across cloud, DevOps and automation tools. YANG is a modeling language that defines what network data must look like: the allowed settings, their types and their rules. YANG does not prescribe a file format for the data itself; the encoding depends on the protocol, such as XML over NETCONF or XML or JSON over RESTCONF. The two can meet in practice, for example when an automation tool stores device variables in YAML and converts them into YANG-modeled data before sending them to a device.