Summary

  • The proposed immutable annotation describes system-provided configuration that a client cannot alter through read-write datastores; it does not say that the server-side value can never change.
  • The effective flag may be explicit, inherited from an ancestor or supplied by the top-level default, so a boolean without its path and inheritance origin is incomplete evidence.
  • A temporal provenance receipt should sit beside the annotation, recording the observed snapshot, server authority, change event and client edit outcome without pretending those fields belong to the draft.

One word, two axes

“Immutable” usually sounds like a promise about time. A record is written once, a digest never changes, an archive remains fixed. The NETMOD proposal uses the word more narrowly. Its boolean metadata describes configuration that the server will not let a client change by placing a different value in a read-write datastore or by removing the system-provided node from the intended configuration.

That control boundary is useful. YANG's ordinary config true classification cannot express every mixed tree found in real devices. A server may need to supply a list entry that clients cannot remove while still letting them configure descendants or add their own entries. Until now, implementations could explain the rejection in prose. draft-ietf-netmod-immutable-flag-14 makes the existing behaviour machine-readable.

The draft is unusually clear that the flag is descriptive, not prescriptive. It documents what the server already does. It also says immutable system configuration can be created, updated and deleted by the server. Put those statements together and the apparent paradox disappears: immutable is an answer to “may this client control this node through the configuration interface?”, not “can this value ever differ at another time?”

A governance system that treats those questions as synonyms will overstate its evidence. A true flag at noon can be perfectly compatible with a different server-provided value after a hardware replacement at three. The noon response remains accurate, but it is not a history.

The annotation has to be requested

The flag does not arrive in every configuration response. A client asks for with-immutability while reading the system, intended or operational datastore. A request against another datastore is invalid under the proposal. A NETCONF client can look for the ietf-immutable-annotation module in YANG library information; a RESTCONF client can look for the defined capability identifier.

This produces a small but important evidence chain. Capability discovery says that the server understands the request. The query says which read-only datastore and subtree the client asked for. The response carries annotations visible to that client under its read permissions. None of those elements can be reconstructed safely from a later screenshot of one boolean.

Legacy behaviour makes the chain more important. An older client will not request the new metadata and therefore will not receive it. A new client asking an older server may see an error for the unsupported parameter or may have the parameter ignored, depending on the implementation. Absence in the response can therefore mean default mutability, inheritance, suppression, lack of support, a legacy interaction or lack of access to the node. The surrounding capability and request evidence prevents those cases from collapsing into one.

A missing value can still mean true

The proposal uses inheritance to avoid repeating metadata throughout a tree. A child without an explicit annotation inherits the parent's state. A top-level node with no annotation defaults to false. Descendants can reset an inherited value and thereby establish a different state for their own subtrees. The draft places no limit on how many such changes can occur across a data tree.

The result is compact on the wire but demanding in an audit. A client that records only the selected node and a resolved boolean loses whether the value was explicit, inherited or defaulted. It also loses the ancestor that controlled the answer and any intervening reset. Two nodes can both resolve to true for different reasons, with different consequences when their parents change.

Lists and leaf-lists add another boundary. Metadata attaches to instances, not to an abstract list as a whole. Individual entries can differ. The restrictions of YANG metadata mean that whole-list behaviour may be inherited from a parent, while an entry can carry its own state. For an ordered list, inherited immutability can cover addition, removal and reordering. A generic “field locked” label does not express which operation is excluded.

An observation receipt should therefore store the instance path, node kind, explicit annotation if present, resolved state, inheritance source and schema revision. Resolution is a computation. Keeping its inputs makes it reproducible.

The same value may appear in running without becoming client-owned

The system-defined configuration model separates what the server supplies from what a client writes. The immutable proposal allows a client to place the same value in a read-write datastore such as running, and later remove that entry, without changing the value in intended configuration. The operation changes visibility in the writable datastore, not authority over the underlying system value.

This distinction frustrates a simple change log. A record saying “client created node” may be technically correct for running but wrong if interpreted as the origin of the intended value. Conversely, an immutable system node may be absent from running unless explicitly configured. A running-only inventory can therefore miss the configuration that actually constrains the device.

Temporal provenance needs both layers: the client's edit event and the server's system-configuration event. The server event should identify the local source—hardware discovery, boot profile, vendor policy or another bounded mechanism—only when that information is actually available. The standard annotation does not provide this provenance, so an operator must not invent it. “Server-provided, source unknown” is a legitimate state.

Access denial comes before immutability

When the Network Configuration Access Control Model is in use, the server checks access before it checks immutability. A user who is not authorized to perform the requested operation receives an access-denied result; the server does not first reveal that the target would also have been immutable.

This ordering matters for both security and analytics. A failed edit is not automatically evidence of immutability. The error tag, authenticated principal, target path and access-control decision are needed before an operator attributes the failure to the new flag. Counting every rejection as “immutable policy working” would mix authorization failures with mutability rules.

The annotation itself can disclose useful structural hints. The draft notes that an attacker might use knowledge of fixed system configuration to shape an attack. Visibility is therefore limited to clients already allowed to read the annotated nodes, and the security properties of NETCONF or RESTCONF still apply. A broad observability export that strips away read-scope context can accidentally publish more than the source client was meant to reveal.

Build a time-bounded provenance receipt

The annotation should remain the narrow field it is. The operational supplement can be a separate receipt. It starts with server or logical-network-element identity, software version, datastore, YANG module revision and capability-discovery result. It records the selected subtree, node-instance path, value, resolved immutable state, explicit or inherited origin, and the response time. If the platform exposes a configuration revision, snapshot ID or digest, that belongs beside the observation.

The receipt then records whatever the operator can prove about the server side: the system-configuration source, decision authority, last change event and reason. Missing provenance stays marked as missing. For an attempted client edit, the receipt adds the authenticated role, requested operation, NACM result, immutability result and returned error tag.

Finally, it has a review time. That field prevents “observed immutable” from becoming “certified permanent.” A later server update does not falsify the earlier receipt; it creates a new one. The pair reveals change while preserving the original control boundary.

This is not a request to enlarge the YANG annotation. Loading history, identities and operational workflow into a boolean would damage its interoperability. It is a recommendation for local evidence architecture: keep the standard statement small, then join it to facts the local system can actually observe.

Adoption will be mixed by design

At the research cutoff, revision 14 had been approved by the IESG and was in the RFC Editor queue, while still remaining an active Internet-Draft. Its YANG validation report showed no errors or warnings. Those process facts do not establish implementation across products or fleets.

The compatibility design predicts a mixed environment. Some servers will advertise the module or RESTCONF capability. Some clients will request it. Others will continue without the metadata. New clients may encounter older servers that ignore or reject the request. An adoption report should show those combinations rather than mark every absent annotation as mutable.

The right monitoring unit is a completed observation path: capability found, valid request sent, response received, state resolved, and—where relevant—an edit result classified after access control. That path is more informative than a product compatibility list because it locates the exact boundary where evidence stopped.

Sources