Mental model
Cisco objective 3.8 (and objective 5.11 for YANG model interpretation) treats model-driven programmability as a three-layer stack:
[ YANG model ] — defines what data looks like (types, hierarchy, constraints)
│
├── carried by NETCONF (XML over SSH, port 830)
└── carried by RESTCONF (JSON or XML over HTTPS, port 443)
YANG is the schema. NETCONF and RESTCONF are two transports that both carry data shaped by YANG. Same data, two wire formats, two protocols.
YANG, in one page
YANG (Yet Another Next Generation) is a language for describing data models. Think of it as the IDL (interface definition language) for network configuration and state.
A tiny excerpt from ietf-interfaces looks like:
container interfaces {
list interface {
key "name";
leaf name { type string; }
leaf description { type string; }
leaf type { type identityref { base interface-type; } }
leaf enabled { type boolean; default "true"; }
leaf-list ipv4-address { type inet:ipv4-address; }
}
}
What it tells you:
- There is an
interfacescontainer. - Inside it, a
listofinterfaceentries, keyed byname. - Each entry has
name,description,type,enabled, and 0+ipv4-addressleaves.
That schema is identical whether you read it over RESTCONF or NETCONF.
Standard vs vendor modules
- IETF modules (
ietf-interfaces,ietf-ip,ietf-routing) are vendor-neutral. Learn these first. - OpenConfig modules (
openconfig-interfaces,openconfig-system) are an industry-group alternative with broader scope. - Vendor-specific modules (
Cisco-IOS-XE-native,Cisco-NX-OS-device) expose features that are not standardised.
A device usually implements many modules at once. show platform software yang-management process on IOS XE lists what is active.
RESTCONF: how the YANG tree maps to URLs
Each level of the YANG tree becomes a URL segment. The module name prefixes the top container with a colon.
| YANG path | RESTCONF URL |
|---|---|
/interfaces (from ietf-interfaces) | /restconf/data/ietf-interfaces:interfaces |
/interfaces/interface[name="GigabitEthernet0/0"] | /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F0 |
/interfaces/interface[name="Gi0/0"]/enabled | /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F0/enabled |
Rules:
- Path segments URL-encoded (
/→%2F). - List keys shown with
=keyvalue. - JSON responses labelled with the fully-qualified name:
"ietf-interfaces:interface"not just"interface".
RESTCONF: read
curl -k -u admin:cisco123 \
-H "Accept: application/yang-data+json" \
https://10.0.0.1/restconf/data/ietf-interfaces:interfaces
Response (abbreviated):
{
"ietf-interfaces:interfaces": {
"interface": [
{ "name": "GigabitEthernet0/0", "description": "WAN uplink", "enabled": true },
{ "name": "GigabitEthernet0/1", "enabled": false }
]
}
}
RESTCONF: write
Three methods:
POST— create a new entry in a list.PUT— replace an entry entirely.PATCH— partial update (change only the fields you include). Most common.
curl -k -u admin:cisco123 -X PATCH \
-H "Content-Type: application/yang-data+json" \
-d '{"ietf-interfaces:interface":{"name":"GigabitEthernet0/1","enabled":true}}' \
https://10.0.0.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F1
Returns 204 No Content on success.
NETCONF: same thing in XML
<get-config>
<source><running/></source>
<filter type="subtree">
<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"/>
</filter>
</get-config>
Response is the same tree in XML. Operations: get, get-config, edit-config, commit, discard-changes, close-session.
Interpreting a YANG tree (exam skill)
Given a snippet like:
container system {
leaf hostname { type string; mandatory true; }
leaf location { type string; }
container ntp {
list server { key "address";
leaf address { type inet:ipv4-address; }
leaf prefer { type boolean; default "false"; }
}
}
}
Answer: “What is the path to the address of the NTP server?” → /system/ntp/server[address=...]/address.
Read the tree top-down; identify leaf (single value) vs list (keyed collection) vs container (grouping only).
Comparison
| NETCONF | RESTCONF | |
|---|---|---|
| Transport | SSH (port 830) | HTTPS (port 443) |
| Payload | XML | JSON (preferred) or XML |
| Operations | RPCs: get-config, edit-config, commit | HTTP methods: GET, POST, PUT, PATCH, DELETE |
| Capabilities | Full (locks, candidates, confirmed commit) | Simpler subset |
| Easiest from curl | No | Yes |
| Easiest from Ansible / NSO | Yes | Yes |
For a first script, choose RESTCONF. For tooling that needs confirmed-commit or candidate datastores, NETCONF.
FAQ
What is the difference between a candidate datastore and running datastore? Running is live config. Candidate is a scratch area you can edit, review, then commit. RESTCONF only exposes running by default.
Do I need to memorise YANG syntax for the exam? No. You need to read a YANG snippet and identify leaves, lists, containers, and construct the path to a value.
What is pyATS? Cisco’s test automation framework. Uses the same YANG models under the hood. See the CML and pyATS topic when it ships in Phase 5.
Which is faster: NETCONF, RESTCONF, or gNMI? gNMI streaming is fastest for metrics (push, binary payloads). RESTCONF is faster than NETCONF for one-off calls (no SSH session setup). For a bulk config push, NETCONF with a locked candidate datastore is cleanest.
