If you have ever configured a modern router, switch, or firewall through anything other than a CLI screen-scrape, there is a good chance YANG was underneath it. YANG ("Yet Another Next Generation") is the data modeling language that finally gave network devices a machine-readable, vendor-neutral way to describe their configuration and operational state. It is the schema layer that made NETCONF, RESTCONF, gNMI, and the whole modern "network as code" movement possible.

The problem it solved. By 2010, network automation was a swamp. SNMP could read counters well enough but was hopeless for writing configuration. Every vendor had a bespoke CLI, and every automation team was writing brittle expect scripts that broke whenever a prompt changed. NETCONF (RFC 4741, later 6241) gave us a transactional XML-based protocol for pushing configuration, but NETCONF alone had no way to say what a valid configuration looked like. You needed a schema language. XML Schema was tried and universally hated for this use case: too verbose, no concept of configuration versus state, no notion of "this leaf only applies when that other leaf is set."

The key design decisions. YANG borrowed its syntax from SMIng (an abandoned attempt to modernize SNMP's SMI) and its structure from network engineers' intuitions about hierarchies. A YANG module defines a tree of container, list, and leaf nodes, roughly matching how you would draw a config on a whiteboard. Some notable choices:

• Config vs. state separation. Every node is flagged as either configurable (config true) or read-only operational state. This distinction, absent from SNMP and XML Schema, is what makes declarative reconciliation possible.
• Constraints as first-class citizens. must, when, unique, and leafref statements express cross-tree invariants. A validator can reject bad config before it touches the device.
• Augmentation and deviation. Vendors can extend a standard module without forking it, and can declare where their implementation deviates. This is how OpenConfig and IETF models coexist with vendor-specific extras.
• Groupings and typedefs. Reusable fragments prevent the copy-paste sprawl that killed XML Schema modeling efforts.
• Explicit revision history. Every module carries a revision stack. Schema evolution is a solved problem, not an afterthought.

Why it matters today. YANG is the reason you can talk to a Cisco IOS XR, a Juniper Junos, and an Arista EOS box with the same Python library. OpenConfig, driven by Google and other hyperscalers, publishes YANG models that vendors implement, giving operators a genuine multi-vendor abstraction. gNMI, the streaming telemetry protocol that has largely displaced SNMP polling in large networks, uses YANG paths as its addressing scheme. Kubernetes-native network operators, service meshes doing L4 policy, and even some cloud provider APIs quietly generate their schemas from YANG. Tools like pyang, yanglint, and yangson validate models the same way you would lint code.

The quirky bits. YANG was designed at Tail-f Systems (later acquired by Cisco) largely by Martin Bjorklund, and the language shows a Scandinavian preference for terseness. The syntax deliberately mimics C-style braces rather than XML, because the authors knew network engineers would refuse to read anything else. YANG 1.1 (RFC 7950, 2016) added actions and notifications attached to data nodes, closing gaps that operators had been working around with ugly RPCs. And despite YANG's tight coupling to NETCONF in its name, the language itself is transport-agnostic; RESTCONF (RFC 8040) and gNMI both consume the same modules.