After a router upgrade, a RESTCONF backup job shows enabled=true vanishing from every interface; what changed, and how does with-defaults make the export deterministic?

## What the backup actually saw A nightly job exports each router's configuration with `GET /restconf/data/ietf-interfaces:interfaces?content=config` and diffs it against yesterday's copy. After a software upgrade, the diff shows `"enabled": true` removed from every interface. No one touched the interfaces, traffic is flowing — and a reconciliation script that reads "missing" as "disabled" is about to do damage. The configuration did not change. The way the server **reports default data** did. ## Default handling is a server choice, and it is advertised In YANG, a leaf can carry a `default` statement; in RFC 8343, `enabled` defaults to `true`. RFC 8040 §3.5.4 says that when such a leaf is missing from the configuration, the server **MUST use the YANG default as the configured value**. Whether the server also *reports* the leaf is governed by RFC 6243's **basic modes**, which RESTCONF reuses. Every server MUST list its mode in the `capability` leaf-list (§9.1.2), as a URI such as `urn:ietf:params:restconf:capability:defaults:1.0?basic-mode=trim`. | basic-mode | What counts as default data | Retrieval without `with-defaults` | |---|---|---| | `report-all` | nothing — every node is reported | all nodes, defaults included | | `trim` | any node equal to its schema default | nodes holding the schema default are omitted | | `explicit` | nodes the client never set | nodes the client set are reported, even when equal to the default | A server moving from `report-all` to `trim` across releases produces exactly the diff above: every `enabled` leaf still equal to `true` vanishes from the reply. (A move to `explicit` would do the same on every interface where no client ever wrote `enabled`.) ## The with-defaults parameter The **`with-defaults` query parameter** (RFC 8040 §4.8.9) lets the client override the basic mode for one GET, applying RFC 6243's retrieval modes: - **`report-all`** — every data node is reported, including those the server considers default. - **`trim`** — nodes containing the schema default are not reported, state nodes included. - **`explicit`** — nodes the client set are reported even at their default; nodes the server filled in are not; state nodes holding the default are reported. - **`report-all-tagged`** — like `report-all`, but each node the server considers default carries metadata saying so. In JSON the tag uses the RFC 7952 metadata encoding and the module name `ietf-netconf-with-defaults`: ```json { "name": "eth0", "enabled": true, "@enabled": { "ietf-netconf-with-defaults:default": true } } ``` In XML it is the `default` attribute from RFC 6243 §6. ## One configuration, four replies Suppose an operator explicitly wrote `enabled: true` on `eth0` and never touched `eth1`, on a server whose basic-mode is `explicit` (one that remembers who set what): | `with-defaults` | `eth0` (set by a client) | `eth1` (never set) | |---|---|---| | `report-all` | reported | reported | | `trim` | omitted | omitted | | `explicit` | reported | omitted | | `report-all-tagged` | reported | reported and tagged | On a `trim` server the distinction disappears earlier: RFC 6243 §2.2.3 says a value written equal to the schema default is not saved at all, so both interfaces are default data and both would be tagged. ## Support is optional, and narrower than NETCONF's 1. The parameter itself is optional: a server that supports it lists `urn:ietf:params:restconf:capability:with-defaults:1.0`. 2. NETCONF's `:with-defaults` capability can name extra modes in an `also-supported` parameter. RESTCONF does **not** report `also-supported`, so a client cannot see which values work. 3. A value the server does not support draws `400 Bad Request` with error-tag `invalid-value`. Probe the value you depend on once per platform and release, and record the result. ## Two edge cases worth knowing - **A GET on the leaf itself.** If the target of a GET is a leaf that has a default and has not been set, the server MUST return the default value in use and **ignore its basic-mode** (§3.5.4). So `GET .../interface=eth0/enabled` returns `true` even on a `trim` server. - **The operational datastore under NMDA.** RFC 8527 redefines `with-defaults` for `{+restconf}/ds/ietf-datastores:operational` — it returns in-use values, `trim` filters out values matching the schema default — and advertises that support with its own capability URI. ## Making the export deterministic - Request `with-defaults=report-all` on backups, so the exported text no longer depends on the server's basic-mode or on the next release. - Use `report-all-tagged` when the consumer needs to know which values were defaulted — for instance, to avoid writing defaults back as if an operator had set them. - Record the advertised `basic-mode` alongside each backup, so a changed mode explains a diff instead of looking like a change. - In code that consumes `trim` or `explicit` replies, treat an absent leaf as "the YANG default applies", never as false or deleted. The interview answer in one line: an omitted leaf under `trim` is still configured at its default; `with-defaults` makes reporting the client's choice instead of the server's.