skip to content

A RESTCONF server shares a device with NETCONF offering :candidate but not :writable-running; what happens to the datastores when a RESTCONF PATCH to /data succeeds?

level: seniorimportance: must knowfreq 11%

answer

  1. no commit step in RESTCONF
  2. the edit still lands somewhere
  3. someone else's staged edits
  4. confirmed commits and locks
  5. startup follows running

basics

~20 s

The PATCH edits the candidate, and the RESTCONF server must commit the candidate to running immediately after the edit — taking any other client's uncommitted candidate edits live with it — and, if the device has :startup, also update startup.

solid answer

~40 s

RESTCONF has no commit: RFC 8040 says each edit is activated when it completes, like NETCONF's `:writable-running`. Section 1.4 says where it lands. With `:writable-running`, edits go straight into running. Otherwise, with `:candidate`, they go into the candidate, which MUST be committed to running immediately after each successful edit — and any edits from other sources already in the candidate are committed too. If a NETCONF confirmed commit is pending, the RESTCONF commit acts as the confirming commit; if that confirmed commit expects a `persist-id`, or a NETCONF client holds a lock on the target datastore, the edit fails with `409 Conflict` and error-tag `in-use`. With `:startup`, the server also updates startup. Several changes that must succeed together go in one YANG Patch request (RFC 8072), which is applied atomically.

code

http · 12 lines
http
PATCH /mgmt/restconf/data/ietf-interfaces:interfaces/interface=eth1 HTTP/1.1
Host: router1.example.net
Content-Type: application/yang-data+json

{ "ietf-interfaces:interface" : [ { "name" : "eth1", "enabled" : false } ] }

HTTP/1.1 409 Conflict
Content-Type: application/yang-data+json

{ "ietf-restconf:errors" : { "error" : [ {
    "error-type" : "protocol",
    "error-tag" : "in-use" } ] } }

go deeper

for a junior

Know that RESTCONF has no commit step: an edit that succeeds is live on the device straight away.

for a middle

Explain section 1.4's rule: writable-running edits go to running; candidate edits are committed to running right after each edit.

for a senior

Show the production risks: other users' staged candidate edits swept live, a pending confirmed commit confirmed, and 409 in-use during NETCONF locks or persist-id waits.

for a principal

Set a policy for devices shared by NETCONF operators and RESTCONF automation, including when YANG Patch is mandatory for multi-part changes.

## No commit, by design **RESTCONF** (RFC 8040) gives HTTP clients CRUD access to YANG-modelled data under `{+restconf}/data`. It was built as a subset of NETCONF that **eliminates datastores and explicit locking** (section 1.2): under RFC 8040 the client sees one datastore resource and never names `running` or `candidate`. Section 1.3 states the consequence: the editing model is "similar to the behavior of the :writable-running capability in NETCONF", and each edit is **activated upon successful completion**. Section 3.4 adds that configuration edit transaction management and persistence are handled by the server, not controlled by the client. There is no RESTCONF `commit`, no `lock`, no `discard-changes` — so on a device whose real configuration lives behind a NETCONF candidate, the server has to commit on the client's behalf. Three NETCONF datastores matter here. **running** is the configuration the device is currently using. **candidate** is a scratch copy a NETCONF client edits and then makes live with a `<commit>`; RFC 6241 says it can be shared among sessions and tells clients to assume it is. **startup** is the configuration loaded at boot. A NETCONF server advertises which of these it offers through capabilities such as `:writable-running`, `:candidate` and `:startup`. ## Where an edit lands Section 1.4 covers a RESTCONF server co-located with a NETCONF server: | NETCONF capability on the device | Where the RESTCONF edit is made | What happens next | |---|---|---| | `:writable-running` | the running datastore | active on success; nothing to commit | | `:candidate` (no `:writable-running`) | the candidate datastore | the server MUST commit candidate to running immediately after each successful edit | | `:startup`, in addition to either | — | the server MUST update startup after running changes | When the device has no NETCONF server at all, the same contract holds: the edit takes effect on success, and the server saves it to non-volatile storage if it supports that. ## The three surprises 1. **Someone else's staged change goes live.** The commit is of the whole candidate: "any edits from other sources that are in the candidate datastore will also be committed". A NETCONF operator half-way through a staged change sees it pushed to running by an unrelated RESTCONF PATCH. 2. **A RESTCONF edit can confirm a confirmed commit.** If a NETCONF client has a confirmed commit in progress, the RESTCONF server's commit acts as the **confirming** commit, so a change meant to roll back automatically if not confirmed is made permanent by a third party. 3. **Some states refuse the edit.** If the pending confirmed commit expects a `persist-id`, the RESTCONF edit MUST fail with `409 Conflict` and error-tag `in-use`. The same `409 Conflict` / `in-use` comes back when a NETCONF client holds a lock on the datastore the edit would modify — RESTCONF cannot take or see locks, but it must honour them. ## What RESTCONF offers instead of a transaction - **One request, one edit.** A PUT, POST, PATCH or DELETE is applied and activated on its own. - **Several changes, one request.** A **YANG Patch** (RFC 8072, media type `application/yang-patch+xml` or `+json`) carries an ordered list of edits in one PATCH; if the whole patch cannot be applied, the server MUST NOT apply any of it. - **Optimistic concurrency.** The datastore resource carries an entity-tag and last-modified time; on a co-located NETCONF server they MUST be those of running, so a conditional request can detect that running changed since the client last read it. How conditional requests work is the HTTP-methods subject. - **NMDA does not add a commit.** RFC 8527's `{+restconf}/ds/ietf-datastores:running` lets a client target running explicitly, but RFC 8040 and RFC 8527 define no commit or lock resource for RESTCONF. ## Operating a device that speaks both - Treat RESTCONF writes as **immediately live**; there is no stage-and-review step to rely on. - Agree that NETCONF users do not leave staged work in a shared candidate while RESTCONF automation runs, or hold a lock for the duration of a staged change so RESTCONF edits fail with `409` instead of committing it. - Expect `409 Conflict` with `in-use` as a normal result during NETCONF maintenance, and retry after the lock is released rather than treating it as a bug. - Use YANG Patch when a change is only safe as a whole. - Remember persistence: with `:startup`, every RESTCONF edit is also saved, so a bad edit survives a reboot. - Expect NETCONF users to notice: after a RESTCONF edit their candidate matches running again, so work they had staged is no longer pending — it is already live.

  • Why does a RESTCONF edit fail with 409 in-use even though RESTCONF has no lock operation?
    RFC 8040 section 1.4: RESTCONF cannot manipulate locks, but locks taken by NETCONF clients still exist on a co-located server. If the datastore the edit would modify is locked, or a confirmed commit awaits a `persist-id`, the edit MUST fail with `409 Conflict` and error-tag `in-use`, so the lock holder's work is protected.
  • How do you make three dependent changes either all apply or none over RESTCONF?
    Send them as one YANG Patch (RFC 8072): a PATCH whose body is an ordered list of edits in `application/yang-patch+json` or `+xml`. The server applies the edits in order and, if the whole patch cannot be applied, MUST NOT apply any of them. Three separate requests would each be committed on their own.
  • Does the NMDA /ds/ietf-datastores:running resource give RESTCONF a staged workflow?
    No. RFC 8527 lets a client name running, intended or operational explicitly, but defines no commit or lock resource, and RFC 8040 defines none either. Writes to running through `/ds` still take effect when they complete.

A RESTCONF edit on a candidate-based device is like a shared shopping basket that the till checks out every time anyone drops in one item: your item is paid for at once, and so is everything other shoppers had left in the basket.

saying these in an interview costs you the question

  • A RESTCONF client stages changes and then POSTs a commit to activate them.
  • RESTCONF edits on a candidate device wait for the next NETCONF commit.
  • Only the RESTCONF client's own edit is committed from a shared candidate.
  • RESTCONF ignores NETCONF locks because it cannot see them.
  • Sending three PATCH requests in a row is atomic as a group.