Describe

6.3 Describe the high-level principles and benefits of a data modeling language, such as YANG

6 min read ENCOR 350-401 v1.2

Aligned to Cisco's 350-401 ENCOR v1.2 exam topics.

On this page

YANG is not a protocol. YANG is a data modeling language.

That sentence is worth memorizing.

NETCONF and RESTCONF are ways to access data. YANG describes what the data looks like: the hierarchy, names, types, allowed values, and whether something is configuration or operational state. Without a model, automation tools guess. With a model, tools can validate and understand the data before sending it to a device.

The problem YANG solves

Traditional CLI automation often works like this:

send command
scrape text -> use regex -> hope output did not change

That can work, but it is fragile. CLI output is designed for humans. YANG-modeled data is designed for machines.

With YANG, a client can ask for data in a structured way:

client
NETCONF/RESTCONF -> YANG-modeled interface data -> XML or JSON response

Now the script can work with fields such as name, enabled, oper-status, and description instead of parsing columns of text.

YANG building blocks

YANG data models are hierarchical. You do not need to write full YANG modules for ENCOR, but you should recognize the basic terms.

module: ietf-interfaces
└── container: interfaces
└── list: interface (key = name)
├── leaf: name (config)
├── leaf: enabled (config)
├── container: ipv4
│ └── list: address (key = ip)
│ ├── leaf: ip
│ └── leaf: prefix-length
└── leaf: oper-status (state only)

config nodes can be changed. state nodes are read-only operational data. Lists can repeat; containers group related fields.

Module

A module is a complete YANG model file. It defines a namespace and a set of data nodes.

Example model names you may see:

ietf-interfaces
Cisco-IOS-XE-native
openconfig-interfaces

A module can be standards-based, vendor-specific, or OpenConfig-based.

Container

A container groups related data.

interfaces

Think of a container as a folder.

List

A list is a repeated set of entries. Interfaces are a natural example because a device can have many interfaces.

interface name

A list usually has a key. For interfaces, the key is commonly the interface name.

Leaf

A leaf is an individual value.

name
description
enabled
oper-status

A leaf has a type, such as string, boolean, enumeration, or integer.

Leaf-list

A leaf-list is a repeated list of simple values.

ntp-servers: "10.10.10.5", "10.10.10.6"

YANG tree example

A simplified interface model might look like this:

module: example-interfaces
  interfaces (rw)
    interface* [name] (rw)
      name (string, rw)
      description? (string, rw)
      enabled? (boolean, rw)
      oper-status? (enumeration, ro)

Read it like this:

interfaces is a container;
interface* is a list, meaning there can be multiple interfaces;
[name] is the list key;
name, description, enabled, and oper-status are leaves;
rw means read-write data;
ro means read-only operational state;
? means optional.

Add one more exam translation: rw enabled is intended configuration, while ro oper-status is observed state. A script can successfully configure enabled: true and still read oper-status: down. Those two facts do not contradict each other.

When a RESTCONF payload uses a key such as ietf-interfaces:interfaces, the text before the colon is the model namespace/module prefix. Do not strip it away mentally. The prefix is part of how the client and device agree on which model is being used.

Configuration vs. state

This distinction matters.

Configuration is what you intend:

interface description
 admin enabled
 IP address
 routing process settings

State is what is actually happening:

operational status
packet counters
neighbor status
learned routes

A good automation engineer knows not to confuse them. You can configure an interface to be enabled, but the operational status might still be down because the cable is unplugged or the far side is shut.

YANG and protocols

YANG is commonly used with model-driven programmability protocols.

NETCONF

NETCONF is XML-based and commonly runs over SSH. It uses YANG-modeled data for configuration and state.

RESTCONF

RESTCONF exposes YANG-modeled data through HTTP-style operations. It can use JSON or XML payloads.

gNMI and telemetry

YANG models can also describe operational data for streaming telemetry workflows. ENCOR focuses more on NETCONF and RESTCONF, but the idea is the same: structured data beats scraped text.

Why YANG is useful

YANG gives network automation five big benefits.

1. Predictable structure

The tool knows where data lives.

interfaces/interface name='GigabitEthernet1' /enabled

That is better than hoping a CLI column is still in the same place.

2. Validation

The model can define type, range, mandatory fields, and allowed values. Bad data can be rejected before it becomes a bad configuration.

3. Programmatic access

Scripts can use structured payloads instead of regex-heavy parsing.

4. Multi-vendor possibility

IETF and OpenConfig models can reduce vendor-specific differences. Vendor-native models still exist and are often necessary, but standards-based models help when the same operation must work across different platforms.

5. Better automation design

A data model forces you to think in objects and state instead of lines of CLI.

Sample JSON from a YANG-modeled interface

A RESTCONF response for interfaces might look like this:

{
  "ietf-interfaces:interfaces": {
    "interface": [
      {
        "name": "GigabitEthernet1",
        "description": "Uplink to core",
        "type": "iana-if-type:ethernetCsmacd",
        "enabled": true
      }
    ]
  }
}

Notice the module prefix:

ietf-interfaces:interfaces

The prefix tells you which model namespace the data comes from.

Sample YANG snippet

A small YANG-like example:

module example-site {
  namespace "urn:example:site";
  prefix site;

  container site {
    leaf name {
      type string;
    }

    list device {
      key "hostname";

      leaf hostname {
        type string;
      }

      leaf management-ip {
        type string;
      }
    }
  }
}

You should recognize the shape:

site
name
device hostname
hostname
management-ip

Lab: read a YANG tree and build a payload

Goal

Understand the difference between a model tree and a JSON payload.

Given model tree

+ -> rw ntp + -> rw server* address + -> rw address string + -> rw prefer? boolean

Task 1: identify terms

Answer:

What is the container?
What is the list?
What is the key?
What are the leaves?

Correct answer:

Container: ntp
List: server
Key: address
Leaves: address, prefer

Task 2: write a matching JSON payload

{
  "ntp": {
    "server": [
      {
        "address": "10.10.10.5",
        "prefer": true
      },
      {
        "address": "10.10.10.6",
        "prefer": false
      }
    ]
  }
}

Task 3: explain why this is better than CLI scraping

Your answer should sound like this:

> The payload has predictable fields and types. A program can validate it before sending it, and a response can be parsed as structured data. CLI scraping depends on human-readable text that may change between versions or platforms.

Exam traps

YANG is a modeling language, not an API protocol.
NETCONF and RESTCONF use YANG-modeled data.
Containers group data.
Lists repeat entries and usually have keys.
Leaves are individual values.
Configuration and operational state are different.
Vendor-native models are useful but less portable than standards-based models.
OpenConfig/IETF models help with interoperability but may not expose every vendor feature.

What to memorize

YANG = model
NETCONF = XML/RPC-style protocol, often over SSH
RESTCONF = HTTP-based access to YANG-modeled data
container = grouping
list = repeated entries
leaf = value
rw = config-capable
ro = read-only state

Exam-ready summary

YANG gives automation tools a shared map of network data. Instead of scraping CLI text, a script can read or write structured data through NETCONF or RESTCONF. For ENCOR, know the terms, know why modeling helps, and know how a simple model tree maps to JSON or XML payloads.

Sources used

Cisco ENCOR 350-401 v1.2 exam topics: https://learningcontent.cisco.com/documents/marketing/exam-topics/350-401-ENCORE-v1.2.pdf
Cisco IOS XE Programmability Configuration Guide, YANG/NETCONF: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/prog/configuration/1715/b_1715_programmability_cg/m_1715_prog_yang_netconf.html