Chapter 1: YANG Data Models: OpenConfig, IETF, and Native Models

Why Data Models Matter for Network Automation

Without a shared vocabulary, automation engineers must write separate, brittle scripts for each vendor's CLI. Model-driven programmability solves this by establishing a precise, machine-readable contract: here is the structure of network configuration data, independent of how any particular vendor exposes it.

Automation code written against a well-defined data model can be vendor-agnostic, self-documenting, and verifiable before it ever touches a device.

YANG Language Overview and RFC 7950

YANG (Yet Another Next Generation) is a schema language purpose-built for networking — similar in spirit to XSD or JSON Schema. It was first standardized in RFC 6020 (YANG 1.0, 2010) and significantly revised in RFC 7950 (YANG 1.1, 2016), the version in use today.

YANG is transport-agnostic: the same YANG module describes data carried over NETCONF (as XML), RESTCONF (as JSON or XML), or gRPC/gNMI (as protocol buffers or JSON).

Key properties defined in RFC 7950:

• Hierarchical: Data is organized as a tree of nodes
• Typed: Every leaf has a type (string, uint32, boolean, enumeration, identityref, etc.)
• Constrained: must expressions, when conditions, and cardinality constraints enforce valid data
• Extensible: Modules can augment or deviate from other modules without modifying the originals
• Self-documenting: description statements are part of the language itself, not comments

YANG Module Structure: module, submodule, revision, namespace

Every YANG model is organized as a module — a single .yang file with a top-level module statement. Larger models split content into submodules included with the include statement.

module ietf-interfaces {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces";
  prefix if;

  import ietf-yang-types {
    prefix yang;
    reference "RFC 6991";
  }

  revision 2018-02-20 {
    description "Updated to RFC 8343.";
    reference "RFC 8343";
  }

  container interfaces {
    list interface {
      key "name";
      leaf name { type string; }
      leaf enabled { type boolean; default "true"; }
    }
  }
}

The namespace is critically important: when sending a NETCONF <edit-config> or RESTCONF PATCH, the namespace must appear in the XML prefix or JSON key to tell the device which model family the data belongs to.

Figure 1.1: YANG Module Anatomy — Key Components and Their Relationships

Key Takeaway: YANG is a hierarchical, transport-agnostic, typed, and self-documenting schema language for network devices (RFC 7950). Every YANG module is identified by a globally unique namespace that must appear in NETCONF and RESTCONF payloads.

OpenConfig Project Goals and Vendor-Neutral Design

OpenConfig is an industry consortium of large network operators (Google, AT&T, British Telecom, Microsoft, and others) who produced YANG models reflecting the operator's perspective rather than any single vendor's implementation. Models are developed publicly on GitHub at github.com/openconfig/public.

Key design principles of OpenConfig:

• Vendor-neutral by design: No model node mirrors any specific vendor's CLI keyword
• Operator-driven scope: Covers features operators need most — BGP, interfaces, routing policy, MPLS, QoS
• Telemetry-first: Every OpenConfig model is designed with streaming telemetry in mind, providing operational state paths suitable for gNMI subscriptions
• Consistent structure: All OpenConfig models follow the same style guide, making them predictable once you learn the pattern

OpenConfig Model Hierarchy: The config/state Container Pattern

OpenConfig places configuration data in a config sub-container (read-write — intended configuration) and operational state data in a state sub-container (read-only — what the device has actually applied or observed) at every level of the hierarchy.

This pattern enables a single model to serve both configuration management (write to config) and telemetry collection (subscribe to state) in a unified schema.

Figure 1.2: OpenConfig config/state Container Pattern Applied to an Interface

Augmentations and Deviations

Augmentation: A vendor adds new schema nodes to an existing OpenConfig model without modifying the original. Augmented nodes from a different namespace require that namespace's prefix in NETCONF/RESTCONF payloads.

Deviation: A vendor declares where their implementation does not fully conform to an OpenConfig model. If a leaf is not-supported, automation tools can understand the actual capability of a specific device rather than assuming full model compliance.

Key Takeaway: OpenConfig models are operator-driven, vendor-neutral YANG modules with a consistent config/state container pattern. They are the recommended first choice for multi-vendor automation, with gaps addressed through augmentation and deviation.

IETF Standardization Process

IETF YANG models are produced by the NETMOD (Network Modeling) working group and published as RFCs after a formal review involving technical experts, working group consensus, and IESG approval. This rigor ensures broad multi-vendor consensus but means updates are slow — changes to a widely-deployed model like ietf-interfaces can take years.

IETF's goal: standards-minimal interoperability — every vendor implementing the RFC must support the same baseline schema. IETF module namespaces follow: urn:ietf:params:xml:ns:yang:ietf-<module-name>.

Key IETF Models

• ietf-interfaces (RFC 7223 / RFC 8343): Baseline schema for interface management — name, type, enabled state, basic statistics. Intentionally minimal; interface-type-specific attributes are added via augmentation (e.g., ietf-ip augments it to add IP address configuration)
• ietf-routing (RFC 8022 / RFC 8349): Three modules forming a core routing data model with generic routing instance and RIB concepts; protocol modules (ietf-ospf, ietf-bgp) augment it further
• ietf-access-control-list (RFC 8519): Schema for ACL configuration — acl-sets, acl-entries, matches, and actions

IETF vs OpenConfig: Comparison

Figure 1.3: Decision Flowchart — Selecting the Right YANG Model Family

Key Takeaway: IETF YANG models are formally standardized through the RFC process and provide a conservative, broadly interoperable baseline — best for compliance enforcement across any RFC-conformant vendor. OpenConfig complements IETF with richer schemas and built-in telemetry support.

IOS XE Native Model Structure

When OpenConfig and IETF models don't provide access to a feature, Cisco native YANG models fill the gap. These proprietary models map closely to IOS XE's internal data structures and CLI command hierarchy. The namespace pattern is http://cisco.com/ns/yang/<module-name>.

The -oper suffix marks operational state modules that provide read-only data — similar to the state containers in OpenConfig, but as separate modules rather than co-located containers.

Model Selection Decision Rules

1. Prefer OpenConfig for multi-vendor environments or when strong telemetry support is required
2. Use IETF models for strict standards compliance and maximum multi-vendor baseline interoperability
3. Fall back to Cisco native when a required feature is not covered by OpenConfig or IETF models
4. Never mix OpenConfig and Cisco native to configure the same parameter — mixed configuration causes unpredictable state

Discovering Available Models on Cisco IOS XE

All Cisco native YANG models are published per release in the GitHub repository at github.com/YangModels/yang under vendor/cisco/xe/<version>/. On a live device, available models can be discovered via:

• NETCONF get-schema (RFC 6022): Retrieves the YANG source for a specific module directly from the device
• Query ietf-yang-library (RFC 7895) via RESTCONF: GET https://<device>/restconf/data/ietf-yang-library:modules-state — returns every module name, revision, namespace, and feature set the device has loaded

Key Takeaway: Cisco native YANG models provide the deepest access to IOS XE features, closely mirroring the CLI hierarchy. They are indispensable for Cisco-specific advanced configuration but sacrifice portability. Always prefer OpenConfig and IETF where possible, and never use both simultaneously for the same configuration parameter.

Tree Diagram Notation and Symbols

RFC 8340 (BCP 215) defines the authoritative text-based format for representing YANG module hierarchies. The general structure of a tree line is:

<indent>+--<flags> <status><name><opts> [<keys>]  <type>

Access Flags (appear immediately after +--):

Cardinality and Node-Type Symbols (follow the node name):

Figure 1.4: RFC 8340 YANG Tree Notation — Node Types and Symbol Reference

Reading Container, List, Leaf, and Choice Nodes

module: ietf-interfaces
  +--rw interfaces                        <-- container (rw, no ?, no *)
     +--rw interface* [name]              <-- list (rw, *, keyed by [name])
        +--rw name           string       <-- leaf, mandatory (no ?)
        +--rw description?   string       <-- leaf, optional (?)
        +--rw type           identityref  <-- leaf, mandatory
        +--rw enabled?       boolean      <-- leaf, optional
        +--ro oper-status    enumeration  <-- leaf, read-only (ro)
        +--ro statistics                  <-- container, read-only
           +--ro in-octets     yang:counter64
           +--ro out-octets    yang:counter64

• interfaces — no * or ? means it is a mandatory container, always present
• interface* [name] — * means this is a list; [name] is the key leaf needed to address a specific entry
• name and type have no ? — mandatory leaves in every interface entry
• description? and enabled? carry ? — optional leaves
• oper-status is ro — you cannot write to it; it reflects device observation

Using pyang to Generate Tree Output

pyang is the standard open-source CLI tool for working with YANG modules. Install with pip install pyang.

# Generate a complete tree for a module
pyang -f tree ietf-interfaces.yang

# Focus on a specific subtree path
pyang -f tree --tree-path /interfaces/interface ietf-interfaces.yang

# Limit tree depth
pyang -f tree --tree-depth 3 Cisco-IOS-XE-native.yang

# Apply a deviation module to show actual device support
pyang -f tree --deviation-module Cisco-IOS-XE-native-devs.yang \
      Cisco-IOS-XE-native.yang

# Generate interactive HTML tree
pyang -f jstree openconfig-interfaces.yang > oc-interfaces.html

# Generate XML payload skeleton (all mandatory nodes)
pyang -f sample-xml-skeleton ietf-interfaces.yang

YANG Suite for Visual Model Exploration

Cisco YANG Suite is a free graphical web application for exploring YANG models and interacting with live Cisco devices over NETCONF, RESTCONF, gRPC, and gNMI. Deploy via Docker:

git clone https://github.com/CiscoDevNet/yangsuite
cd yangsuite
./start_yang_suite.sh

YANG Suite organizes models into two tiers:

• YANG Repository: A collection of related YANG modules for a specific OS version (e.g., "IOS XE 17.9")
• YANG Set (module set): A curated subset containing only the modules relevant to a specific task and their transitive dependencies

Figure 1.5: YANG Suite Workflow — From Model Repository to Live Device RPC

Key Takeaway: RFC 8340 defines standardized text notation for YANG tree diagrams — rw/ro indicate access, * marks list nodes, ? marks optional leaves, and bracketed keys identify list keys. pyang generates trees and validates models from the CLI; YANG Suite provides a graphical interface for visual exploration, RPC construction, and live device interaction.