NETCONF and RESTCONF are two ways to read and write YANG-modeled configuration. NETCONF came first, is XML over SSH, and has transactional semantics. RESTCONF is HTTP, JSON-friendly, and easier to call from anything.
Pick by capability, not by preference.
The comparison
| NETCONF | RESTCONF | |
|---|---|---|
| Transport | SSH, port 830 | HTTPS, port 443 |
| Encoding | XML | JSON or XML |
| Datastores | running, candidate, startup | running (candidate varies) |
| Transactions | Yes, with commit and rollback | Limited, per-request |
| Tooling | ncclient, vendor SDKs | curl, requests, anything HTTP |
If a device supports candidate datastores and confirmed commits, NETCONF gives you the safest change primitive: stage, validate, commit, and roll back if the session dies.
The operations that matter
| Operation | What it does |
|---|---|
<get> |
Retrieve state and config |
<get-config> |
Retrieve configuration only, from a datastore |
<edit-config> |
Modify configuration |
<validate> |
Check against the schema |
<commit> |
Apply a candidate |
<discard-changes> |
Throw the candidate away |
<lock> / <unlock> |
Prevent concurrent edits |
The lock matters in a district where two scripts might run at once: without it, two edits to the same tree interleave.
RESTCONF in practice
GET /restconf/data/ietf-interfaces:interfaces
PUT /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1
PATCH /restconf/data/.../interface=GigabitEthernet1
DELETE /restconf/data/.../interface=GigabitEthernet1
Headers matter: Content-Type: application/yang-data+json, Accept: application/yang-data+json.
PATCH merges; PUT replaces. Replacing an interface object with a partial body is how people accidentally erase a description or an MTU.
Candidate datastores are not universal
Many devices only support the running datastore. A failed edit can leave configuration half applied. If you cannot stage and commit, validate the payload before sending and keep a rollback plan.
Capabilities tell you what is possible
At session start, a NETCONF server advertises its capabilities: which YANG modules, which datastores, which features. Read them before assuming an operation exists.
<capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
A script that assumes <commit> without checking is a script that works on one vendor.
Worked example: a VLAN change
- Connect over NETCONF, read capabilities, confirm candidate support.
- Lock the running datastore.
edit-configinto candidate: add VLAN 110 with a name.validatethe candidate.commitwith a confirmed-commit timeout of 60 seconds.- Verify with
<get-config>and a client test. - Confirm the commit, or let it roll back automatically if verification fails.
Step 5's confirmed commit is the safety net: if nobody confirms, the device reverts. That is a real rollback, not a hope.
What breaks in production
- Editing running directly with no candidate, so a partial failure leaves a half-configured device.
- No lock, so concurrent scripts overwrite each other.
- PUT instead of PATCH, erasing fields that were not in the payload.
- Ignoring capabilities, then failing on a device that lacks the feature.
- No timeout, so a hung session holds a lock until it ages out.
Next
The protocol works. Continue with Ansible for Network Devices for the tool most teams reach for first.