Summary

  • RFC 10016 adds a read-only <system> datastore for configuration supplied by the system. Clients cannot edit that datastore directly, but may reference its nodes, override permitted values in <running>, or add configurable descendants to system-defined entries.
  • “Origin: system” says where a value came from. It does not prove human approval, immutability or successful application. Removing an override may reveal the system value again, while hardware, licence or software changes may alter which system nodes exist.

The operator removed an override in order to return a device to “no explicit setting”. The result was not absence. The system-provided value underneath reappeared in <intended> and later became active. A deletion that looked like less configuration produced more behaviour.

That is not a protocol surprise. It is the precedence model that RFC 10016 makes visible. The Standards Track document updates the Network Management Datastore Architecture by adding <system>, a conventional datastore containing configuration supplied by the server itself. The datastore is read-only to NETCONF and RESTCONF clients. Its contents can nevertheless participate in effective configuration.

The governance mistake is to read “read-only” as “unchanging”, or “system” as “approved”. Read-only identifies an access boundary: a client cannot write directly into <system>. It does not freeze the data across a software upgrade, a licence change or a hardware event. It does not prevent a permitted value from being shadowed by <running>. It does not establish who accepted the risk of the underlying value. And it does not show whether the value reached <operational>.

A datastore for a previously blurred source

RFC 8342 already distinguishes configuration a device intends to apply from configuration and state actually in use. It recognises conventional, dynamic, learned, system and default sources. RFC 10016 gives system configuration a named datastore and refines its meaning: configuration present in <system> counts as system configuration whether or not it is currently referenced or applied.

System configuration under this contract cannot be deleted by clients. Server-provided data that clients can delete is outside the document’s definition. A conforming NMDA server implements the ietf-system-datastore identity, whose schema relationship builds on YANG as defined by RFC 7950. A client can discover support through YANG library information described by RFC 8525.

There are two important lifecycles. Always-present system configuration is generated when the device powers on regardless of a particular physical resource. A loopback interface is the RFC’s example. Conditionally present configuration appears when a condition holds: a card is inserted, a resource exists, a licence or feature is enabled. When that condition disappears, the system node can disappear too.

The <system> datastore itself does not persist across reboot. The server reconstructs what its current conditions require. “It was present before reboot” and “the same node was generated after reboot” therefore need separate observations. A backup of <running> is not a complete record of the inputs that will create the next <intended> tree.

Read-only source, writable precedence

Clients can interact with system nodes in three ways. They may reference a node from configuration they create in <running>. Where the server permits an override, a matching <running> leaf takes precedence over the value in <system>. A client may also be allowed to add configurable descendants beneath a system-defined list entry, even though the entry itself originates with the system.

The merge rule is simple but its operational consequence is easy to miss: <running> wins over the corresponding <system> node when the two form <intended>. If either input requires transformations—template expansion or removal of inactive configuration, for example—each datastore must be transformed independently before the merge. A screenshot of the untransformed sources cannot prove the final winner.

Now consider deletion. The system supplies value A. An operator writes value B to <running>, so B wins. Later the operator removes B. The operation did not delete A; clients cannot delete A from <system>. A reappears in <intended> and may enter use after successful application. A workflow that labels the removal “setting cleared” has hidden the fallback value that matters.

The reverse transition is equally important. A conditionally present system node can disappear because hardware was removed or a licence changed. Related configuration may remain in <running> and <intended>, yet fail to appear in <operational> because the referenced resource is absent. The intent has not vanished, but the running reality has.

Origin is provenance, not consent

RFC 7952 provides the metadata mechanism used for origin annotations. RFC 10016 clarifies that configuration flowing from <system> reports origin system unless it was explicitly configured or overridden in <running>. Configuration originating in <running> reports the intended origin under the NMDA rules.

That annotation answers “which source supplied this node?” It does not answer “who approved this effective value?” A manufacturer, platform image, device resource, licence subsystem or local system process can supply a node without a named human making a current risk decision. Conversely, a client override may be the result of an automated controller rather than a person.

Treating origin as approval creates two false claims. The first is that a system-sourced value is trustworthy because the system provided it. The second is that a client-sourced override is deliberate because it appears in <running>. Provenance is necessary for accountability, but it must be joined to change authority, policy review and business intent.

Intended still does not mean applied

Whenever <system> changes, RFC 10016 requires the server to update and validate <intended> immediately. It also says that <running> should remain a valid configuration tree after system changes, while leaving the mechanisms for accomplishing that outside scope. These are useful guarantees about data processing, not proof that a value reached hardware or forwarding behaviour.

RFC 10016 deliberately does not change <operational>. Under RFC 8342, missing resources, propagation delays and remnant configuration can keep intended and applied state apart. The relevant chain is therefore <system> plus <running>, independently transformed, merged into <intended>, and then conditionally applied into <operational>. Every arrow has a different failure mode.

Notifications can help without closing the chain. Changes to system configuration may be reported through YANG subscription and datastore-update mechanisms such as RFC 8639 and RFC 8641. A notification proves that a publisher emitted an event within a subscription’s coverage. It does not by itself prove that every consumer processed it, recomputed policy, or verified the resulting operational tree.

Nor should <system> be confused with <factory-default>. RFC 8808 defines a datastore for factory default settings and a factory-reset operation. RFC 10016’s <system> describes what the current system provides under current conditions. The two take different roles in the architecture, even when some values happen to resemble each other.

The origin-and-precedence receipt

An origin-and-precedence receipt can make effective configuration accountable. For every material node, it records the system path, value fingerprint, origin, and presence condition. The condition names the relevant hardware, licence, feature, boot, software or resource epoch so that “system value” is not treated as timeless.

The next section records mutability and precedence: whether the system node is immutable or overridable; which <running> node references or shadows it; which configurable descendants were added; which transformations ran on each source; and which value won the merge into <intended>. It records the consequence of removing an override before the change is approved.

The activation section compares <intended> with <operational>. It records application time, resource presence, delay, failure, remnant state and the exact evidence used to say that the value is in effect. A reference can be valid while its target is inactive; a valid intended tree can still describe a resource not currently present.

The authority section names the system supplier, configuration client, operator approver and risk owner. It links the source change—software upgrade, licence transition, hardware insertion or policy commit—to the decision that accepted the resulting effective value. Sensitive details can remain protected; the receipt can retain hashes and scoped references.

This receipt is Daniel Kade’s editorial governance proposal, not a new requirement imposed by RFC 10016. Its purpose is to preserve the difference between a visible source, a winning value, an approved decision and an applied outcome.

Security begins with read access

Read-only does not mean harmless. RFC 10016 warns that <system> can contain hardware identifiers, security policies and critical resources. Access to sensitive nodes and subtrees must be controlled, and implementations are strongly advised to log attempts to read them. RFC 8341 supplies the Network Configuration Access Control Model for constraining NETCONF and RESTCONF users.

The override path is a separate risk. An attacker or mistaken client may write a <running> leaf that shadows a sensitive system value, creating policy bypass or availability failure even though <system> itself never changed. Monitoring only writes to <system> would therefore watch the one path clients cannot use and ignore the path that actually changes precedence.

The narrow conclusion is the useful one. RFC 10016 makes system configuration inspectable and gives NMDA clients a standard way to reason about it. It does not certify the system’s choice as operator intent, fix that choice forever, or prove application. Visibility is the beginning of control. The receipt must follow the value through precedence and into operation.

Sources