An immutable YANG flag is only the first receipt

Summary

draft-ietf-netmod-immutable-flag-14 defines a server-provided immutable metadata annotation and an opt-in with-immutability retrieval parameter. The flag documents behavior the server already has; it does not create or command that behavior.
A returned immutable=true and a later invalid-value error can explain one failed edit. They do not alone prove consistent policy across users and protocols, permanent configuration, operational convergence, stable dependencies, recovery or a business result.
Assurance therefore has to preserve the request, capability and schema context, exact instance and inheritance path, edit and error, datastore views, server-side change trigger, runtime observation and recovery outcome as separate receipts.

Imagine an automation controller collecting two records. The first is a NETCONF <get-data> reply from a read-only datastore, requested with with-immutability; a target leaf carries immutable=true. The second is an <edit-config> reply returning invalid-value when the controller proposes another value. The records fit together. The server advertised a restriction and then rejected the prohibited edit.

That is useful evidence. It is not the same as proof that the configuration can never change.

The distinction is the centre of revision 14. The draft calls its flag descriptive rather than prescriptive. It formalises a way for YANG-driven servers to disclose existing treatment of system-provided configuration, so clients can avoid otherwise valid requests that the server would refuse. The metadata does not turn mutable data into immutable data, and the draft does not regulate the hidden implementation that decides what the server provides.

The IETF Datatracker lists the text as an active NETMOD Internet-Draft dated 2 July 2026 and intended for the Standards Track. Its later process and validation entries concern the document. They are not measurements of a product, deployment or operator. The draft can be technically coherent while every implementation question remains open.

The client must ask the right question

The annotation is deliberately absent from an ordinary response. A client asks for it with with-immutability, and the request is valid only against the read-only <system>, <intended> or <operational> datastores. On another datastore, revision 14 requires unknown-element. RESTCONF adds a capability URI and accepts the query parameter without a value; an unexpected value produces HTTP 400 and invalid-value. NETCONF clients can look for the ietf-immutable-annotation module in YANG Library.

These are different receipts. A capability URI or YANG Library row says that a server claims to support a vocabulary. A successful retrieval shows that one request was accepted. The returned data then shows which visible instances were annotated. Combining them is stronger than retaining any one, but it still does not test the later edit path.

Legacy behavior adds another ambiguity. The draft says a server that does not implement the mechanism may reject the parameter or ignore it. A response with no annotations is therefore interpretable only with the capability, request and selected datastore preserved. “No flag observed” is not automatically “all configuration is mutable.”

The property belongs to an instance

The annotation follows data node instances. Two entries under the same YANG list may have different states. A parent passes its state to descendants when their annotations are omitted; a top-level node defaults to false. A descendant may reset the inherited state, and the state can change repeatedly down the tree.

That makes compressed evidence hazardous. Recording only the leaf path and true can omit the parent from which the value was inherited. Recording only the parent can conceal a mutable exception below it. RFC 7952 also limits where metadata can attach: an individual list or leaf-list entry can carry an annotation, while the collection as a whole can become immutable only through inheritance.

The difference changes what an editor is allowed to do. An immutable list entry cannot be removed from intended configuration and its descendants inherit the restriction unless reset. If an entire list inherits immutability, entries cannot be added, removed or reordered when user ordering applies. An isolated immutable entry does not make every sibling immutable.

Revision 14 also requires servers to ignore immutable annotations sent by clients. The flag is a report from the server, not a control bit delegated to the requester. A signed client payload containing immutable=true proves what the client transmitted; it cannot prove the server adopted the claim.

The refusal says less than its message suggests

The draft's NETCONF and RESTCONF examples reject an attempted value change with invalid-value, a target path and an explanatory message. Retaining the complete exchange is much better than a dashboard label saying “policy enforced.” It identifies the authenticated session, operation, intended new value, target path, time and the server's classification.

But one error does not reveal every decision behind the response. When NACM applies, access control is evaluated before immutability. A user without write permission receives access-denied; the server may never reach the immutable check. Different users can therefore see different errors without the underlying immutable property being user-dependent. Conversely, the same invalid-value string on two interfaces is not sufficient to prove that both traversed identical code or policy.

Alternative write surfaces matter as well. A NETCONF rejection does not test RESTCONF, a local console, a vendor tool, a boot loader, an upgrade routine or a server-owned process. The draft's requirement is a conformance claim to test, not evidence that a named deployment already satisfies it.

Server-controlled is not time-frozen

An immutable node is protected from a client's different value; the server remains the party that creates, updates or removes immutable configuration. Hardware discovery, software revision, licence state, enabled features and available resources can change what the server provides. “Immutable” therefore describes an authority boundary, not a promise that tomorrow's data will equal today's bytes.

The flag can exist even if the server does not expose a <system> datastore. Not every system-provided value is immutable. A client may also copy the same immutable value into running and later remove that copy without changing the merged intended value. A running-datastore diff can thus record a visible edit while the effective value never moved.

RFC 8342 keeps intended and operational state distinct for this reason. A synchronized read showing the same value and flag in system, intended and operational is a useful snapshot. It does not establish that the device applied the same state after an upgrade, that a required resource remained present, or that packets and services behaved as expected.

A proof chain, not a green badge

The practical assurance record begins with the exact retrieval request and capability/schema set. It then preserves the returned subtree so explicit annotations, omissions, inherited states and resets can be reconstructed. Next comes the attempted edit and complete reply, followed by coordinated datastore reads for the relevant authenticated views.

If software, hardware, licensing or feature state changes, that trigger becomes a new evidence event. Operators then need device telemetry, configuration application status and a service-level canary. If recovery matters, a rollback or failover must be executed and observed rather than inferred from the presence of an error code.

The sources establish the proposed semantics and the boundaries of the management protocols. They do not establish a named vendor's conformance, prevalence, a production change, an incident, successful rollback or a customer outcome. Revision 14's implementation appendix names full and partial precedents, but the list is not an independent interoperability report.

The Server Said “Immutable.” That Was Only the First Receipt

Summary

The client must ask the right question

The property belongs to an instance

The refusal says less than its message suggests

Server-controlled is not time-frozen

A proof chain, not a green badge

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing