Skip to content
Log in Sign up My account

5.1 and 5.2 YANG Model Sets, NETCONF and RESTCONF

Blueprint 5.1: Choose the correct YANG data model set based on requirements (IETF, OpenConfig, Cisco native)

Given a requirement such as multi-vendor consistency, full feature coverage or streaming telemetry, pick the model family that fits and explain the trade-off.

Blueprint 5.2: Differentiate between NETCONF and RESTCONF

Given a tooling and operational requirement, choose the protocol and justify it: transactions and locking versus simplicity and web-stack fit.

ENCOR already teaches how YANG is written, how to read a tree and how the two protocols behave on the wire. This page does not repeat that. Read YANG data modeling and NETCONF and RESTCONF first. Here the question is always which one should the design use, and why.

The design decision in one picture

A model-driven design has four independent choices. Candidates mix them up on the exam, so keep them separate.

graph LR
  M["1. Model set<br/>IETF, OpenConfig, Cisco native"] --> E["2. Encoding<br/>XML, JSON, protobuf"]
  E --> P["3. Protocol<br/>NETCONF, RESTCONF, gNMI"]
  P --> T["4. Transport<br/>SSH, HTTPS, HTTP/2"]

This page covers choices 1 and 3 for configuration. Telemetry transport (gNMI) is on the next page.

Choosing a model set (5.1)

The three families compared

IETF OpenConfig Cisco native
Owner IETF working groups (RFCs) Operator-led consortium, published on GitHub Cisco
Goal Standard interoperable core Vendor-neutral, operator-driven, designed for automation at scale Expose every feature of the platform
Coverage Narrow: interfaces, IP, basic routing Medium: interfaces, BGP, ACL, platform, telemetry paths Widest: mirrors the IOS XE CLI
Vendor neutral Yes in theory, but vendors add augmentations Yes in practice for the supported subset No
Release cadence Slow, RFC process Fast, versioned on GitHub Tied to the IOS XE release
Config and state Config models plus separate state, NMDA aligns them Config and state in one tree (config and state containers) Separate config (-native) and operational (-oper) models
Best at Baseline interop Multi-vendor automation and streaming telemetry Anything vendor specific

Requirement-driven selection

Requirement Choose Reason
One automation codebase must configure Cisco, Arista and Juniper devices OpenConfig first, IETF where OpenConfig has no model Same paths and semantics on every vendor
A feature such as a specific QoS, NAT or EEM construct must be automated Cisco native Standard models do not cover it
Read-only health data (CPU, memory, interface counters, BGP state) streamed to a collector OpenConfig or Cisco operational (-oper) The state tree is designed for subscription
Strict standards compliance is a procurement requirement IETF Published as RFCs
The estate is all Cisco IOS XE and a single team owns it Cisco native, with OpenConfig for telemetry if the collector already speaks it Full coverage, one vendor
Device must be fully provisioned (day-0 and day-1) from templates Cisco native You need every line of config, not 80% of it

Rule of thumb

Start with the most standard model that covers the requirement. Drop to Cisco native only for the gap. A hybrid is normal: OpenConfig for interfaces and BGP, native for everything else.

Why "standard" does not mean "portable"

Three factors make a multi-vendor design harder than the model name suggests.

  1. Partial support. A device advertises the models and the deviations it implements. Two platforms can both claim openconfig-bgp and still differ in which leaves they accept.
  2. Augmentations. Vendors extend IETF and OpenConfig models with their own leaves. Portable code must stay inside the base model.
  3. Semantics. The same leaf can behave differently, for example whether a missing value means "default" or "unset".

The design response is to test each model against each platform and release, keep a per-platform deviation list, and pin the model revisions your tooling uses. A device reports its supported models and revisions in the NETCONF <hello> capabilities, and the public YangModels repository on GitHub publishes the models per IOS XE release.

Config versus operational data

Configuration models describe intended state. Operational models describe actual state: counters, neighbour tables, sensor readings. On IOS XE the Cisco operational models carry an -oper suffix. A design that streams telemetry will almost always subscribe to operational paths, because that is where counters and state live.

Choosing NETCONF or RESTCONF (5.2)

What really differs

Property NETCONF (RFC 6241) RESTCONF (RFC 8040)
Transport SSH, TCP 830 HTTPS, TCP 443
Encoding XML only XML or JSON
Operations RPCs: get, get-config, edit-config, copy-config, delete-config, lock, unlock, commit and others HTTP methods: GET, POST, PUT, PATCH, DELETE
Candidate datastore Yes, if the device advertises the capability No candidate datastore
Locking Yes, whole-datastore locks No
Multi-step transactions Yes: edit candidate, validate, commit, with confirmed-commit rollback No: each request applies immediately
Atomicity Across everything in one edit-config and across a commit Per request only
Session Stateful, long lived Stateless, request and response
Tooling fit Network automation libraries (ncclient, YANG Suite) Anything that speaks HTTP: curl, Postman, web apps, REST libraries
Notifications Native (RFC 5277 and dynamic subscriptions) Limited, SSE-based and rarely used
Typical user Orchestrator that owns device lifecycle Application developer or script that changes one thing

Decision flow

graph TB
  S["Need to change device config"] --> Q1{"Need an atomic change<br/>across several subtrees<br/>or a validate-then-commit step?"}
  Q1 -->|Yes| NC["NETCONF with candidate<br/>and confirmed commit"]
  Q1 -->|No| Q2{"Tool or team is web native<br/>and wants JSON?"}
  Q2 -->|Yes| RC["RESTCONF"]
  Q2 -->|No| Q3{"Must stop other<br/>writers during the change?"}
  Q3 -->|Yes| NC
  Q3 -->|No| RC

Design scenarios to reason through

Transactional multi-device change. An orchestrator pushes a VRF, an interface and a BGP neighbour as one change and must roll back automatically if it breaks reachability. NETCONF wins: it can stage the change in the candidate datastore, validate, commit with a timer (confirmed commit), and roll back if the confirmation never arrives. RESTCONF has no equivalent, so the orchestrator would have to implement its own undo logic.

Self-service portal. A web application lets a help desk enable or disable a port. RESTCONF wins: one HTTPS call with a small JSON body, using standard HTTP authentication and the load balancers and API gateways the company already runs. NETCONF's persistent SSH sessions add no value here.

Many writers. Two tools might edit the same box. NETCONF's lock stops the other writer for the duration of your change. RESTCONF has no lock, so concurrent writers can overwrite each other; the design must serialise at a higher layer.

Firewall and proxy path. Port 443 usually crosses corporate firewalls and web proxies easily. Port 830 often does not. If the automation host sits across such a boundary, that favours RESTCONF.

Large bulk operations. NETCONF can send one edit-config containing many subtrees in a single round trip. RESTCONF needs one request per resource, or one PATCH on a common parent. For hundreds of devices with many changes each, NETCONF is usually more efficient.

Security and operations considerations

Concern NETCONF RESTCONF
Authentication SSH users, AAA, public keys HTTP basic over TLS, or tokens where fronted by a gateway; AAA still applies
Authorisation NACM (RFC 8341) plus AAA; on IOS XE, privilege level Same
Encryption SSH TLS
Attack surface One SSH subsystem The device's HTTPS server, shared with other web features
Rate and scale Few long sessions per device Many short connections, higher connection churn

On IOS XE, RESTCONF depends on the device HTTPS server (ip http secure-server), which is shared with the web UI and other services. Restrict it with an access class, do not leave it exposed on production interfaces, and prefer a management VRF. Both protocols must be limited to the management plane, reachable only from the management network.

Exam trap

NETCONF does not have a JSON encoding. If a scenario requires JSON from the device, the answer is RESTCONF (or gNMI for telemetry). If a scenario requires a candidate datastore, locking or confirmed commit, the answer is NETCONF, never RESTCONF.

Exam trap

"OpenConfig is a protocol" and "YANG is a protocol" are always wrong. OpenConfig is a set of YANG models, and RESTCONF, NETCONF and gNMI are the protocols that carry data modelled with them. Also do not confuse "vendor neutral model" with "every vendor implements all of it". A design must verify support per platform.

Exam trap

Choosing a model set is independent of choosing NETCONF or RESTCONF. You can carry an OpenConfig model over NETCONF, and a Cisco native model over RESTCONF. Answer options that tie a model family to one protocol are wrong.

CLI that clarifies the design point

Enabling the two protocols on IOS XE shows that they are separate services and that RESTCONF depends on the HTTPS server:

netconf-yang
!
restconf
ip http secure-server
ip http authentication local

R1# show netconf-yang sessions
R1# show platform software yang-management process

The second command lists the helper processes (nesd, ncsshd, dmiauthd, nginx and others). nginx serves RESTCONF, and ncsshd serves NETCONF over SSH. If a design review asks "what do we expose when we turn this on", this is the evidence.

Design exercise

Scenario. A retailer runs 600 branch routers (Cisco IOS XE) and 40 data-centre switches from a second vendor that supports OpenConfig. The network team uses a Python-based orchestration platform. Requirements:

  1. Interface and BGP configuration must be driven from one code base across both vendors.
  2. Branch WAN changes (VRF, tunnel, BGP, QoS policy) must apply as a unit and roll back automatically if the branch loses contact with the hub.
  3. A separate store-operations web portal must let staff bounce a LAN port at one branch.
  4. The security team forbids opening additional management ports on branch firewalls beyond TCP 443 and SSH.

Choose the model sets and protocols.

Model answer

Model sets. Use OpenConfig for interfaces and BGP so one code path serves both vendors. Use Cisco native for the branch QoS policy and for any VRF or tunnel details that OpenConfig on the router does not cover, and accept that this part is Cisco only. Do not use IETF as the primary set: its coverage of BGP is thin, and the second vendor's IETF support is less complete than its OpenConfig support. Before committing, verify the OpenConfig revision and deviations on both platforms.

Protocols. Use NETCONF for the orchestrator's branch changes. Requirement 2 needs a transaction across several subtrees and automatic rollback; the candidate datastore with confirmed commit provides both. Use RESTCONF for the portal: it is a single small change from a web application, and JSON over HTTPS is the natural fit. NETCONF over SSH uses TCP 830, but requirement 4 only allows 443 and SSH. The design must therefore either get a firewall exception for TCP 830 from the orchestrator only, or run the orchestrator inside the management network (for example over an existing VPN or SD-WAN management path) so that 830 never crosses a branch firewall that is limited to 443 and SSH. The portal's RESTCONF calls use 443 and need no firewall change.

Rejected alternatives.

  • RESTCONF only: simpler and firewall friendly, but it cannot provide candidate datastore, lock or confirmed commit, so the rollback requirement would need custom orchestration code.
  • NETCONF only: works, but forces the web portal to embed an SSH/XML client for a trivial task.
  • Cisco native everywhere: gives full coverage but breaks requirement 1, because the second vendor cannot consume it.
  • IETF everywhere: maximal standards compliance, but too narrow for BGP and QoS.

Quick check

A requirement says automation must roll back a multi-line change automatically if connectivity is lost after the change. Which protocol, and which feature?

NETCONF, using the candidate datastore with a confirmed commit. If the confirming commit does not arrive before the timeout, the device reverts. RESTCONF has no candidate datastore or confirmed commit.

Your tooling must configure routers from two vendors with the same paths and also configure a Cisco-only NAT feature. What model sets?

OpenConfig (or IETF where it has coverage) for the shared features, and Cisco native for the NAT feature that has no standard model. A hybrid is the normal answer.

Why can a web portal prefer RESTCONF even when NETCONF is available?

RESTCONF uses HTTPS and JSON, so any web stack can call it with standard libraries, load balancers and gateways. For simple single-resource changes it is less effort than managing an SSH session and XML.

References