Summary

  • RFC 10016 adds a read-only <system> datastore for device-supplied configuration. It can change with software, licences and physical resources even though management clients cannot edit it directly.
  • A permitted node in <running> takes precedence over the matching system value. Remove that client override and the system value can reappear in <intended>; remove a card and client configuration can remain intended while disappearing from <operational>.
  • The standard fixes transformation, merge and validation order. It does not prove successful application, universal notification coverage or a safe response when system changes threaten the validity of client configuration.

The empty slot did not empty the configuration

A line card is removed during maintenance. The chassis immediately stops reporting the card's system-supplied interface. The automation controller still holds the IP address and description that it pre-provisioned for that interface. Its last write succeeded months ago, and the controller's desired-state record remains green.

The device now presents three different truths. The node tied to the card has disappeared from <system>. The client's entries remain in <running>. Their merged form may remain in <intended>. Because the resource is absent, none of it is applied or visible in <operational>.

That is not a race accidentally left between two vendors. It is a result expressly described by RFC 10016, the July 2026 Standards Track update to the Network Management Datastore Architecture. The document gives system-defined configuration a conventional datastore of its own. In doing so, it makes a boundary visible that management systems have often hidden behind the single word “configuration”.

The empty slot matters because each datastore answers a different question. <system> records configuration supplied by the device. <running> contains explicit client configuration. <intended> is the transformed, merged and validated target that the system attempts to apply. <operational> records the configuration and state actually in use. A value's presence in one is not authority to claim its presence in another.

Read-only does not mean motionless

RFC 10016 defines <system> as read-only to management clients. A NETCONF or RESTCONF edit aimed directly at it must be denied. That restriction identifies who may write through those protocols; it does not freeze the datastore.

The system can generate nodes that are always present, such as a loopback, and nodes that exist only while a condition holds. Inserting a card can create system configuration. Removing it can remove that configuration. Enabling a licence or feature can add another set. A software upgrade can alter the system-supplied tree. The datastore itself does not persist across reboot: it is regenerated from the system rather than serving as a durable vendor snapshot.

That last property separates it from <factory-default>. Under RFC 8808, factory-default contents must persist across restarts and can initialize read-write datastores during a factory reset. <system> describes what the current system supplies; <factory-default> is a persistent reset source. Calling both “defaults” would erase the difference precisely when recovery depends on it.

The access boundary is also narrower than immutability. A client may not edit <system>, yet a server may allow that client to place a matching node in <running>. The client has not rewritten the system source. It has introduced a higher-precedence value into the merge.

Two reversals, two owners

The first reversal begins with an override. Suppose the device supplies an enabled value and an authorized controller writes a different value to the corresponding node in <running>. Where the server permits override, the client value takes precedence even if the system value changes later. The operator sees the client result in the merged target.

Deleting that client value is not a return to emptiness. RFC 10016 says the system-initialized value then appears in <intended> and may eventually come into use if application succeeds. An apparently subtractive operation activates a different principal's value. The change record therefore needs a before-and-after view of both sources, not merely proof that one path was deleted.

The second reversal begins with a condition. Remove a hardware resource and its system node can vanish. Related client configuration can remain in <running> and <intended>, but cannot be applied or appear in <operational> while the resource is missing. Reinsert the card and that retained intent may become relevant again. The client did not recreate the card; the card's return changed which retained configuration could execute.

These reversals are mirror images only at a distance. Override removal reveals a lower-precedence value. Resource removal withdraws an execution condition. One calls for checking the value that will re-emerge; the other calls for labelling retained intent as unapplied and testing its future activation.

Transform first, merge second, validate immediately

RFC 10016 does not permit an implementation to improvise the conceptual order. If <system> or <running> contains templates, inactive nodes or other configuration requiring transformation, the server must transform each datastore independently. It then merges them, with a matching <running> node taking precedence where override is permitted. The result becomes <intended>, subject to validation.

Whenever <system> changes, the server must immediately update and validate <intended>. That is a firm shared rule. The adjacent continuity rule is deliberately less complete: <running> should remain a valid configuration tree after a system change, but the mechanisms that achieve this are outside RFC 10016's scope.

That gap is an ownership signal. A licence removal could withdraw a target referenced by client configuration. A software upgrade could change system-supplied constraints. A hardware event could make a pre-provisioned subtree temporarily unapplied. The standard says when validation must occur; it does not choose the operator's stop condition, remediation workflow or rollback source.

RFC 8342 reinforces the final separation. <intended> is what the system attempts to apply. Missing resources, delays and other local factors can keep part of it out of <operational>. A successful commit to <running> and a valid <intended> tree are important evidence, but neither proves that packets, policies or interfaces are active.

Visibility creates a new evidence and security surface

Before RFC 10016, system configuration existed even when clients lacked a standard way to retrieve it. The new datastore improves comparison: a controller can discover the system source instead of inferring it from the merged or operational result. Legacy NMDA clients continue to work with the earlier datastores, but they need updates to use this visibility fully.

Visibility is not automatically benign. <system> may expose hardware identifiers, security policies and critical resources. RFC 10016 requires access control for sensitive nodes and strongly advises logging access attempts. RFC 8341 supplies the Network Configuration Access Control Model, but the deployed identities, groups and rules remain local choices.

The override path is a write risk as well as a convenience. A mistaken or hostile value in <running> can shadow a sensitive system node, with consequences that include security-policy bypass and availability loss. “The source is read-only” is not a sufficient control statement when another source can win the merge.

System changes may be reported through subscriptions and on-change notifications under RFC 8639 and RFC 8641. Yet on-change support can vary by implementation and object. A receiver must know which nodes its subscription actually covers, detect gaps and resynchronize when continuity is uncertain. A notification channel is evidence transport, not a guarantee that the evidence is complete.

The four-datastore change record

For every software, licence, feature, hardware or override-removal event, preserve four snapshots and one causal record. Capture <system> and <running> before the change, the transformed inputs and resulting <intended> after it, and the relevant <operational> subtree once application has settled. Record the system event, management client identity, access decision, validation outcome and notification sequence that connect the snapshots.

Test both directions. Remove an override in a canary and verify the exact system value that reappears. Remove or disable a resource and verify that retained client intent is clearly marked as unapplied. Restore the resource and prove which values become active. Reboot separately: <system> is regenerated, so a pre-reboot byte comparison is not a persistence contract.

Heng Lu's running-code primacy gives the ledger its governing test. A model, registry row or controller record describes a claim. The active device and its observed operational state determine which claim became executable reality.

His framework of minimum initial specification and localized future decision also clarifies the division of authority. The shared layer should define deterministic transformation, precedence and validation rules. Device owners, automation owners and risk principals still decide which overrides are allowed, how changes are staged, which failures stop a rollout and how state is restored. RFC 10016 makes the sources legible. Accountability begins when those sources disagree.