On an NMDA RESTCONF server, why read /ds/ietf-datastores:operational instead of /data to check whether a configured interface setting is actually in use?

seniorshould knowfreq 7%

answer

configured is not applied
RFC 8527 extends RFC 8040
identityref in the path
origin of each value

basics

~10 s

RESTCONF's /data is RFC 8040's combined view, whose configuration nodes show what was configured; RFC 8527's /ds/ietf-datastores:operational returns only values the system is actually using, and with-origin can say where each came from.

solid answer

~40 s

The Network Management Datastore Architecture (NMDA, RFC 8342) separates running (what was configured), intended (after transformations such as inactive nodes or templates) and operational (configuration and state actually in use). RFC 8040's {+restconf}/data predates it and stays unchanged; RFC 8527 adds {+restconf}/ds/<datastore>, with the datastore named as a module-qualified identity: ietf-datastores:running, :intended, :operational. An NMDA server MUST implement the operational resource and ietf-yang-library revision 2019-01-04 or later, and a client detects NMDA with HEAD or GET on it. Configuration for an absent interface stays in running and intended but does not appear in operational while the interface is missing, so comparing them shows what failed to apply; the optional with-origin parameter tags values as intended, learned, system, default and so on. Writes to intended return 405 with operation-not-supported.

The Network Management Datastore Architecture (NMDA, RFC 8342) separates `running` (what was configured), `intended` (after transformations such as inactive nodes or templates) and `operational` (configuration and state actually in use). RFC 8040's `{+restconf}/data` predates it and stays unchanged; RFC 8527 adds `{+restconf}/ds/<datastore>`, with the datastore named as a module-qualified identity: `ietf-datastores:running`, `:intended`, `:operational`. An NMDA server MUST implement the operational resource and `ietf-yang-library` revision 2019-01-04 or later, and a client detects NMDA with HEAD or GET on it. Configuration for an absent interface stays in running and intended but does not appear in operational while the interface is missing, so comparing them shows what failed to apply; the optional `with-origin` parameter tags values as `intended`, `learned`, `system`, `default` and so on. Writes to intended return `405` with `operation-not-supported`.

code

http · 17 lines

http

GET /mgmt/restconf/ds/ietf-datastores:operational/ietf-interfaces:interfaces?with-origin HTTP/1.1
Host: router1.example.net
Accept: application/yang-data+xml

HTTP/1.1 200 OK
Content-Type: application/yang-data+xml

<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
    xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
    or:origin="or:intended">
  <interface>
    <name>eth1</name>
    <description>uplink to core</description>
    <enabled or:origin="or:default">true</enabled>
    <oper-status>up</oper-status>
  </interface>
</interfaces>

go deeper

for a junior

Recall that NMDA separates what is configured (running) from what is in use (operational) and that RESTCONF reaches each under /ds.

for a middle

Explain the module-qualified identity in the /ds path and which of running, intended and operational accept writes.

for a senior

Use running versus operational to diagnose configuration that was accepted but not applied, and read origin annotations to trace learned or system values.

for a principal

Decide whether automation should verify every change against operational, and what that costs on servers lacking with-origin or NMDA.

Why /data is not enough

RESTCONF (RFC 8040) exposes one datastore resource, {+restconf}/data, which combines configuration and state. That fits the original NETCONF model, where configuration lived in running and state was a separate set of config false nodes. The Network Management Datastore Architecture (NMDA, RFC 8342) split the picture into datastores with distinct meanings:

running — the current configuration, as written by clients.
intended — read-only: running after every configuration transformation, such as removing inactive nodes or expanding templates; for simple implementations identical to running.
operational — read-only: all config true and config false nodes actually in use, including configuration learned from protocols, supplied by the system and taken from defaults.

For configuration nodes, a GET on /data answers "what is configured?", not "what is in use?". Configuration can be accepted yet not applied: RFC 8342 section 5.3.2 gives the case of configuration for an interface that is not physically present, which stays in running and intended but does not appear in operational. Changes also take time to percolate, and operational may briefly hold remnants of a removed configuration.

The /ds resources (RFC 8527)

RFC 8527 (Standards Track, updates RFC 8040) adds one resource per datastore under the template {+restconf}/ds/<datastore>. The <datastore> segment is an identityref, encoded with the namespace-qualified JSON identity form of RFC 7951 (module:identity) and derived from the datastore identity in the ietf-datastores module. RFC 8527 keeps the existing resources' semantics unchanged, so /data still works for clients that know nothing of NMDA.

Resource	Datastore	Writable?	Notes
`{+restconf}/ds/ietf-datastores:running`	running	yes	same operations as `/data`
`{+restconf}/ds/ietf-datastores:intended`	intended	no	an edit MUST get `405 Method Not Allowed`, error-tag `operation-not-supported`
`{+restconf}/ds/ietf-datastores:operational`	operational	no (read-only datastore)	MUST be implemented; YANG actions can only be invoked here

Other datastores MAY be implemented — a module defining a datastore identity gets a resource named after it — but dynamic configuration datastores are excluded from the default operation set, since each one must be reviewed for what it supports. Two further differences apply under /ds: the with-defaults query parameter has its own semantics on operational (optional there, and it reports in-use values), and RFC 8040's rule that a GET on an unset leaf returns its schema default does not apply.

Old and new clients on one server

RFC 8527 is backwards compatible: it only adds resources. A client written for RFC 8040 keeps using /data and reads the module list from the deprecated modules-state tree, which RFC 8525 says an NMDA server SHOULD still populate. An NMDA-aware client reads the new yang-library tree from operational instead. Both can run against the same device; only the second can tell configured from applied.

Detecting an NMDA server

Send HEAD or GET on {+restconf}/ds/ietf-datastores:operational; an NMDA server MUST implement it.
Read {+restconf}/yang-library-version: an NMDA server MUST implement at least revision 2019-01-04 of ietf-yang-library (RFC 8525, which obsoletes RFC 7895).
Read the YANG library from the operational datastore to learn which datastores the server supports and which modules each holds — schemas may differ per datastore under NMDA.

Reading where a value came from

The optional with-origin query parameter (capability urn:ietf:params:restconf:capability:with-origin:1.0) asks the server to annotate returned configuration with origin metadata from the ietf-origin module. Origin values include:

intended — applied from the intended configuration;
learned — learned through protocol interaction, such as a routing protocol or DHCP;
system — supplied by the device itself, such as an always-present loopback;
default — a schema default in use;
dynamic — from a dynamic configuration datastore;
unknown — the system cannot tell.

with-origin is valid only on operational or a datastore derived from it; on any other datastore the server MUST answer 400 Bad Request with error-tag invalid-value. Annotations are returned only when asked for.

Traps

Writing to /ds/ietf-datastores:intended or operational to "fix" what is in use — both are read-only; configuration is written to running.
Spelling the path /ds/running — the identity must be module-qualified.
Expecting /ds to bring a candidate workflow — RFC 8527 names running, intended and operational and defines no commit or lock resource.
Treating an empty answer from operational as an error — no value means the node is not in use.

## Why /data is not enough **RESTCONF** (RFC 8040) exposes one datastore resource, `{+restconf}/data`, which combines configuration and state. That fits the original NETCONF model, where configuration lived in `running` and state was a separate set of `config false` nodes. The **Network Management Datastore Architecture** (**NMDA**, RFC 8342) split the picture into datastores with distinct meanings: - **`running`** — the current configuration, as written by clients. - **`intended`** — read-only: `running` after every configuration transformation, such as removing inactive nodes or expanding templates; for simple implementations identical to `running`. - **`operational`** — read-only: all `config true` and `config false` nodes **actually in use**, including configuration learned from protocols, supplied by the system and taken from defaults. For configuration nodes, a GET on `/data` answers "what is configured?", not "what is in use?". Configuration can be accepted yet not applied: RFC 8342 section 5.3.2 gives the case of configuration for an interface that is not physically present, which stays in `running` and `intended` but does not appear in `operational`. Changes also take time to percolate, and `operational` may briefly hold remnants of a removed configuration. ## The /ds resources (RFC 8527) RFC 8527 (Standards Track, updates RFC 8040) adds one resource per datastore under the template `{+restconf}/ds/<datastore>`. The `<datastore>` segment is an **identityref**, encoded with the namespace-qualified JSON identity form of RFC 7951 (`module:identity`) and derived from the `datastore` identity in the `ietf-datastores` module. RFC 8527 keeps the existing resources' semantics unchanged, so `/data` still works for clients that know nothing of NMDA. | Resource | Datastore | Writable? | Notes | |---|---|---|---| | `{+restconf}/ds/ietf-datastores:running` | running | yes | same operations as `/data` | | `{+restconf}/ds/ietf-datastores:intended` | intended | no | an edit MUST get `405 Method Not Allowed`, error-tag `operation-not-supported` | | `{+restconf}/ds/ietf-datastores:operational` | operational | no (read-only datastore) | MUST be implemented; YANG actions can only be invoked here | Other datastores MAY be implemented — a module defining a datastore identity gets a resource named after it — but dynamic configuration datastores are excluded from the default operation set, since each one must be reviewed for what it supports. Two further differences apply under `/ds`: the `with-defaults` query parameter has its own semantics on `operational` (optional there, and it reports in-use values), and RFC 8040's rule that a GET on an unset leaf returns its schema default does not apply. ## Old and new clients on one server RFC 8527 is backwards compatible: it only adds resources. A client written for RFC 8040 keeps using `/data` and reads the module list from the deprecated `modules-state` tree, which RFC 8525 says an NMDA server SHOULD still populate. An NMDA-aware client reads the new `yang-library` tree from `operational` instead. Both can run against the same device; only the second can tell configured from applied. ## Detecting an NMDA server 1. Send HEAD or GET on `{+restconf}/ds/ietf-datastores:operational`; an NMDA server MUST implement it. 2. Read `{+restconf}/yang-library-version`: an NMDA server MUST implement at least revision `2019-01-04` of `ietf-yang-library` (RFC 8525, which obsoletes RFC 7895). 3. Read the YANG library from the operational datastore to learn which datastores the server supports and which modules each holds — schemas may differ per datastore under NMDA. ## Reading where a value came from The optional **`with-origin`** query parameter (capability `urn:ietf:params:restconf:capability:with-origin:1.0`) asks the server to annotate returned configuration with **`origin`** metadata from the `ietf-origin` module. Origin values include: - `intended` — applied from the intended configuration; - `learned` — learned through protocol interaction, such as a routing protocol or DHCP; - `system` — supplied by the device itself, such as an always-present loopback; - `default` — a schema default in use; - `dynamic` — from a dynamic configuration datastore; - `unknown` — the system cannot tell. `with-origin` is valid only on `operational` or a datastore derived from it; on any other datastore the server MUST answer `400 Bad Request` with error-tag `invalid-value`. Annotations are returned only when asked for. ## Traps - Writing to `/ds/ietf-datastores:intended` or `operational` to "fix" what is in use — both are read-only; configuration is written to `running`. - Spelling the path `/ds/running` — the identity must be module-qualified. - Expecting `/ds` to bring a candidate workflow — RFC 8527 names running, intended and operational and defines no commit or lock resource. - Treating an empty answer from `operational` as an error — no value means the node is not in use.

What does an RFC 8527 server return for with-origin on /ds/ietf-datastores:running?
`400 Bad Request` with error-tag `invalid-value`. `with-origin` is only valid on the operational datastore or one whose identity derives from `operational`, because origin describes how configuration came to be in use; running holds what clients wrote, so there is nothing to annotate.
Where must a RESTCONF client invoke a YANG action on an NMDA server that uses /ds?
Under `{+restconf}/ds/ietf-datastores:operational`, on the data node the action is bound to. RFC 8527 section 3.1 says actions can only be invoked there; RFC 8342 likewise ties action invocation to the operational state datastore.

saying these in an interview costs you the question

GET on /data shows what the device is actually running.
The /ds path segment is just the bare name, such as /ds/running.
An NMDA server lets you write to intended to change what is applied.
with-origin works on any datastore resource under /ds.
RFC 8527 replaces /data, so legacy clients break on NMDA servers.

On an NMDA RESTCONF server, why read /ds/ietf-datastores:operational instead of /data to check whether a configured interface setting is actually in use?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Why /data is not enough

The /ds resources (RFC 8527)

Old and new clients on one server

Detecting an NMDA server

Reading where a value came from

Traps

▾common follow-ups2 questions

▾red flags5 flags

Why /data is not enough

The /ds resources (RFC 8527)

Old and new clients on one server

Detecting an NMDA server

Reading where a value came from

Traps

answer

go deeper