YANG: the schema behind every modern network API

NETCONF, RESTCONF, and gNMI move structured data between a client and a network device. None of them define the shape of that data. YANG does. It describes what fields exist on an interface, what parameters a BGP neighbor takes, what values are legal for an admin-status. The protocols are the transport. YANG is the schema.

RFC 6020 introduced YANG in 2010. RFC 7950 updated it to version 1.1 in 2016. It is not a protocol. It defines the structure, types, and constraints of data — the data itself gets encoded as XML (NETCONF) or JSON (RFC 7951). YANG doesn’t care about the wire format.

The closest analogies: JSON Schema defines the shape of JSON documents. Protobuf .proto files define the shape of serialized messages. YANG defines the shape of network configuration and state data.

Core constructs

Reading pyang tree output

pyang -f tree is the standard way to visualize a YANG model. Here’s ietf-interfaces — the base interface data structure every vendor implements:

module: ietf-interfaces
  +--rw interfaces
     +--rw interface* [name]
        +--rw name                        string
        +--rw description?                string
        +--rw type                        identityref
        +--rw enabled?                    boolean
        +--rw link-up-down-trap-enable?   enumeration
        +--ro admin-status                enumeration
        +--ro oper-status                 enumeration
        +--ro last-change?                yang:date-and-time
        +--ro if-index                    int32
        +--ro phys-address?               yang:phys-address
        +--ro higher-layer-if*            interface-ref
        +--ro lower-layer-if*             interface-ref
        +--ro speed?                      yang:gauge64
        +--ro statistics
           +--ro discontinuity-time    yang:date-and-time
           +--ro in-octets?            yang:counter64
           +--ro in-unicast-pkts?      yang:counter64
           +--ro in-broadcast-pkts?    yang:counter64
           +--ro in-multicast-pkts?    yang:counter64
           +--ro in-discards?          yang:counter32
           +--ro in-errors?            yang:counter32
           +--ro out-octets?           yang:counter64
           +--ro out-unicast-pkts?     yang:counter64
           +--ro out-broadcast-pkts?   yang:counter64
           +--ro out-multicast-pkts?   yang:counter64
           +--ro out-discards?         yang:counter32
           +--ro out-errors?           yang:counter32

Tree notation

Python tools

Three model families

The same physical interface — GigabitEthernet1 on a Cisco IOS XE device — returns different JSON depending on which YANG model family you query. Three families coexist on the same device:

{
  "ietf-interfaces:interface": {
    "name": "GigabitEthernet1",
    "type": "iana-if-type:ethernetCsmacd",
    "enabled": true,
    "ietf-ip:ipv4": {
      "address": [
        {
          "ip": "10.10.20.48",
          "netmask": "255.255.255.0"
        }
      ]
    }
  }
}

{
  "openconfig-interfaces:interface": {
    "name": "GigabitEthernet1",
    "config": {
      "name": "GigabitEthernet1",
      "type": "iana-if-type:ethernetCsmacd",
      "enabled": true
    },
    "subinterfaces": {
      "subinterface": [
        {
          "index": 0,
          "openconfig-if-ip:ipv4": {
            "addresses": {
              "address": [
                {
                  "ip": "10.10.20.48",
                  "config": {
                    "ip": "10.10.20.48",
                    "prefix-length": 24
                  }
                }
              ]
            }
          }
        }
      ]
    },
    "openconfig-if-ethernet:ethernet": {
      "config": {
        "auto-negotiate": true
      }
    }
  }
}

{
  "Cisco-IOS-XE-native:GigabitEthernet": {
    "name": "1",
    "ip": {
      "address": {
        "primary": {
          "address": "10.10.20.48",
          "mask": "255.255.255.0"
        }
      }
    },
    "mop": {
      "enabled": false
    },
    "Cisco-IOS-XE-ethernet:negotiation": {
      "auto": true
    }
  }
}

Same device. Same physical interface. Three different JSON structures.

Selection order: OpenConfig first for multi-vendor consistency. IETF second where OpenConfig lacks coverage. Vendor native as fallback for platform-specific features.

NETCONF vs RESTCONF

Two protocols, same YANG models underneath.

NETCONF has proper transactional semantics — candidate datastore, commit, rollback — but requires SSH sessions and XML. RESTCONF is stateless HTTPS with JSON support, works with any HTTP client, but lacks native multi-operation transactions.

from ncclient import manager
import xmltodict

m = manager.connect(
    host='sandbox-iosxe-latest-1.cisco.com',
    port=830,
    username='developer',
    password='C1sco12345',
    hostkey_verify=False
)

# Fetch interface config using IETF model
intf_filter = """
<filter>
  <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
    <interface>
      <name>GigabitEthernet1</name>
    </interface>
  </interfaces>
</filter>
"""

# get_config() = configuration only (rw nodes)
config = m.get_config(source='running', filter=intf_filter)

# get() = configuration + operational state (rw + ro)
state = m.get(filter=intf_filter)

parsed = xmltodict.parse(state.xml)
print(parsed['rpc-reply']['data']['interfaces']['interface']['name'])

import requests
import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

BASE = "https://sandbox-iosxe-latest-1.cisco.com/restconf/data"
HEADERS = {
    "Accept": "application/yang-data+json",
    "Content-Type": "application/yang-data+json"
}
AUTH = ("developer", "C1sco12345")

# Fetch interface data using IETF model
r = requests.get(
    f"{BASE}/ietf-interfaces:interfaces/interface=GigabitEthernet1",
    headers=HEADERS,
    auth=AUTH,
    verify=False
)

interface = r.json()
print(interface["ietf-interfaces:interface"]["name"])

YANG to JSON Schema (and MCP)

YANG’s type system maps to JSON Schema:

This means YANG models can be compiled into MCP tool inputSchema definitions — giving an LLM agent a machine-readable description of what parameters a network operation accepts. The IETF draft on MCP applicability describes this: “private YANG is compiled to JSON-Schema in the controller (milliseconds); tool registers via /tools/register and is immediately callable.”

The concept is sound. The hard parts: leafref has no JSON Schema equivalent, augment requires flattening across modules, deviation means per-device schema variations, and when/must constraints use XPath expressions that JSON Schema can’t fully represent. At scale — hundreds of models across multiple vendors — this translation layer is where the real engineering work lives.

Quick reference

YANG is a schema language. The protocols change, the encodings change, the clients change. The data model doesn’t.