skip to content

A nightly job changes VLANs, interfaces and routing on one device; what atomicity does NETCONF give it that separate RESTCONF requests do not?

level: seniorimportance: must knowfreq 14%

answer

  1. where does the unit of change end?
  2. a scratch copy, then one commit
  3. running unchanged if any part fails
  4. YANG Patch narrows the gap

basics

~20 s

NETCONF lets the job lock the device, build every edit in the candidate, validate, and commit it all at once; if any part fails, running stays unchanged. Separate RESTCONF requests each stand alone, so a failure midway leaves earlier edits applied.

solid answer

~40 s

In RESTCONF the unit of change is one HTTP request: RFC 8040 leaves transaction management to the server, with no client-visible staging, lock or commit. Nine `PATCH` requests that fail at the sixth leave five applied, and the client must undo them itself. A YANG Patch (RFC 8072) narrows the gap: one `PATCH` carrying an ordered list of edits that the server must apply completely or not at all. NETCONF goes further because its session persists: the job can `<lock>` the datastores, send many `<edit-config>` operations into the candidate, `<validate>`, and `<commit>`, which by RFC 6241 leaves running unchanged unless every change applies. A confirmed commit adds a timed revert if the change cuts the manager off. RESTCONF has no equivalent of the lock, the multi-request staging or the timed revert.

go deeper

for a junior

Know that a NETCONF change can be staged in a candidate and committed in one step, while each RESTCONF request takes effect on its own.

for a middle

Explain commit's all-or-nothing rule, what YANG Patch adds to RESTCONF, and why an entity-tag check is not a lock.

for a senior

Reason about the failure midway: which edits are live, what the job must undo, how a confirmed commit protects reachability, and what changes on a device without a candidate.

for a principal

Judge which changes need staging and a lock and which are safe as single requests, and design the compensation path for the requests that are not atomic.

## The question behind the question An interviewer asking this wants to know whether you can name the **unit of change** in each protocol, and what happens when a multi-part change fails halfway. The scenario: one device, one maintenance job, edits that span several modules — VLAN membership, interface settings, a routing change — that only make sense together. ## RESTCONF: each request is its own unit RESTCONF rides on HTTP, and each request stands alone. RFC 8040 §3.4: "Configuration edit transaction management and configuration persistence are handled by the server and not controlled by the client." Consequences: - There is **no client-visible staging area**. On a device with a writable running datastore the edit goes straight to running; on a device with only a candidate, the server commits the candidate automatically after each successful edit (RFC 8040 §1.4). - There is **no lock**. RFC 8040 §1.4: "RESTCONF cannot manipulate locks." Collisions are detected optimistically with an entity-tag (`If-Match`) or a timestamp (`If-Unmodified-Since`); a stale edit is rejected, but nothing stops another writer between two of your requests. - There is **no client-controlled commit or timed revert**. So if the job is written as nine independent requests and the sixth fails, the first five stay applied. The client must notice, decide whether the half-changed device is safe, and send compensating edits. ## YANG Patch: one request, many edits RFC 8072 defines **YANG Patch**, a `PATCH` body with media type `application/yang-patch+json` or `+xml` carrying an **ordered list of edits** — `create`, `delete`, `insert`, `merge`, `move`, `replace`, `remove` — against one target resource. Its rule is all-or-nothing: "if the entire patch document cannot be successfully applied, then the server MUST NOT apply any of the changes". Aimed at the `{+restconf}/data` root, one YANG Patch can carry the VLAN, interface and routing edits together. Limits worth stating: 1. Support is optional: a server must support plain patch and advertises YANG Patch as a capability. 2. The whole change must be known up front and sent in one request; nothing can be added after seeing an intermediate result. 3. It still takes no lock and offers no timed revert. ## NETCONF: build, validate, commit Because a NETCONF session persists (RFC 6241 §2.1), the job can run the classic sequence: 1. `<lock>` the datastores it will touch. While the lock is held, other NETCONF sessions cannot edit them, and RFC 6241 §7.5 requires that CLI and SNMP writers be refused too. 2. Send as many `<edit-config>` operations as it needs into the **candidate** datastore, a scratch copy that does not affect forwarding. 3. `<validate>` the candidate, if the device offers it. 4. `<commit>`. RFC 6241 §8.3.4.1: "If the device is unable to commit all of the changes in the candidate configuration datastore, then the running configuration MUST remain unchanged." 5. `<unlock>`. Outstanding candidate changes are discarded when the lock is released, including when the session dies. A **confirmed commit** adds a safety net for the case where the change itself cuts the manager off: the commit is reverted unless a confirming commit arrives within the timeout, 600 seconds unless the client sets another. On a device without a candidate, NETCONF is weaker: `<edit-config>` on running stops at the first error by default (`stop-on-error`), and restoring the starting state needs `rollback-on-error`, which only devices advertising `:rollback-on-error` offer. ## Side by side | Property on one device | Separate RESTCONF requests | One YANG Patch | NETCONF candidate and commit | |---|---|---|---| | All-or-nothing across the whole change | no | yes | yes | | Change built over several messages | yes, each applied at once | no | yes, staged | | Pessimistic lock against other writers | no | no | yes | | Validate before going live | no | server validates the patch | yes | | Timed revert if the manager loses the device | no | no | yes, confirmed commit | ## The honest answer - For a change you can express completely in advance, **YANG Patch** gives RESTCONF single-device all-or-nothing behaviour. - What only NETCONF gives is a change **held under a lock and assembled over several steps**, committed in one go, with an optional **automatic revert**. - Neither extends to several devices: each commit is local to one device.

  • Does an If-Match entity-tag give RESTCONF the protection of a NETCONF lock?
    No. An entity-tag check is optimistic: the server rejects an edit, with `412 Precondition Failed`, when the data changed since the client read it. It does not stop anyone writing between two of your requests, and it cannot hold a multi-request change together. A NETCONF lock is pessimistic: for its lifetime the server refuses other sessions' edits, and RFC 6241 says CLI and SNMP writes too.
  • Is there a RESTCONF equivalent of a NETCONF confirmed commit?
    No. RFC 8040 defines no trial commit. A NETCONF confirmed commit (RFC 6241 §8.4) reverts unless confirmed within the confirm timeout, 600 seconds by default, which protects against an edit that cuts the manager off. A RESTCONF client that loses the device after an edit has no automatic way back; it needs another path to the device to repair it.

Separate RESTCONF requests are like paying for each item at a different till: if the sixth till refuses your card, the first five purchases stand and you must return them yourself. NETCONF's candidate is a basket you fill, check and pay for once — the till takes all of it or none.

saying these in an interview costs you the question

  • Several RESTCONF requests form one transaction until the client disconnects.
  • A YANG Patch keeps the edits that succeeded and reports the ones that failed.
  • An If-Match entity-tag check is the same as holding a lock.
  • NETCONF edit-config on running rolls everything back on error by default.
  • A NETCONF commit applies whatever part of the candidate is valid.