Summary

  • draft-ietf-netconf-error-registries-00 proposes canonical IANA lists for YANG protocol error tags and identities, but the first revision is visibly incomplete and does not make a returned name a root-cause record.
  • Reliable automation must retain the protocol session, operation, principal, authorization boundary, target path, module-qualified identity, structured hints, transaction result, remediation and service readback around the registry value.

The automation receives invalid-value and immediately reaches for a remedy.

That reaction feels disciplined. The error has a standard spelling. It can be counted, graphed and matched in a rule. Yet under RESTCONF the same tag can accompany HTTP 400, 404 or 406. In access-controlled cases, a server may deliberately answer 404 with invalid-value instead of confirming that a protected resource exists. The label is not wrong. It is doing less work than the operator has asked it to do.

This is the useful tension inside draft-ietf-netconf-error-registries-00, posted on 30 September 2026. The active NETCONF working-group document proposes two IANA registries: a YANG Protocol Error List and a YANG Protocol Error Identities registry. Its purpose is sensible. Protocol authors and implementers should not have to compile canonical values from a dispersed set of RFCs every time YANG-driven management evolves.

Revision 00 is a Standards Track Internet-Draft in the IETF stream and expires on 3 April 2027. It is not an RFC. It does not establish an approved registry, prove implementation, or report interoperability. At five pages, it is best read as the opening specification of a governance surface.

The first proposed registry would record an error-tag, the valid error-type and error-severity, any structured error-info, a description and a registering reference. The second would record an identity name, its base identity where applicable, additional information and a reference. Both would be extended under IETF Review.

That centralization matters. A canonical list can prevent spelling drift, make additions discoverable, identify the document that owns a value and give clients a durable vocabulary. It can also force a standards process to decide when an entry is added, changed, deprecated or replaced. Those are genuine control-plane gains.

But revision 00 also demonstrates how much precision a registry needs before software can depend on it. The three leading field descriptions in the error-list proposal are still marked TBD. The text says its initial contents come from RFC 6241 Appendix A, then inlines only the first five tags: in-use, invalid-value, too-big, missing-attribute and bad-attribute. Appendix A continues with many more, including access-denied, resource-denied, rollback-failed, data-missing, operation-not-supported, operation-failed and malformed-message.

The identity list has the same first-revision character. It repeats filter-unsupported, insufficient-resources and no-such-subscription, while leaving out identities found in the RFCs it cites. RFC 8639 includes stream-unavailable, suspension-timeout and unsupportable-volume. RFC 8641 includes cant-exclude, no-such-subscription-resync, on-change-unsupported, on-change-sync-unsupported and sync-too-big. The draft also points to RFC 5226 for registry policy even though RFC 8126 is the current BCP 26 edition and obsoletes it.

None of this proves a defect in a future standard. It proves that revision 00 is revision 00. The honest editorial conclusion is not that the registry idea failed. It is that the proposed canonical source still needs uniqueness, completeness, current references and explicit field semantics before it can become the dependency that the introduction imagines.

The larger problem begins after that cleanup succeeds.

RFC 6241 does not describe a NETCONF failure as one code. Its <rpc-error> structure can contain the conceptual layer where the failure occurred, a protocol error tag, severity, a model-specific or implementation-specific application tag, an XPath to the affected node, a human-readable message and structured protocol- or model-specific information. One reply may contain multiple error elements when a request encounters multiple problems.

Those fields are not decorative. They are evidence dimensions. error-tag says what broad condition the protocol can safely expose. error-app-tag can narrow the condition within a particular model. error-path ties it to a target. error-info can carry exact bad attributes or parameter hints. The operation and session tell the client what was attempted and under which conversation. Remove those dimensions and a perfectly valid registry term becomes a weak incident record.

RFC 8640 makes the hierarchy concrete for subscribed notifications. filter-unsupported maps to the broad NETCONF tag invalid-value; insufficient-resources maps to resource-denied; on-change-unsupported maps to operation-not-supported; sync-too-big maps to too-big; and unchanging-selection maps to operation-failed. The specific error identity is carried as a module-qualified error-app-tag, such as ietf-subscribed-notifications:no-such-subscription.

Even that specific name needs its operating context. RFC 8640 says the viable base identity depends on whether the failed RPC was establishing, modifying, deleting, killing or resynchronizing a subscription. For establish and modify requests, optional structured error-info may suggest parameter settings that could make a later request succeed. The same word detached from the RPC, module and hints cannot authorize the same response.

Consider unchanging-selection. RFC 8641 allows a publisher to return it when a subscription selects data that does not exist or data the receiver is not allowed to read. It can also appear when access-control changes make a previously useful selection unable to yield visible updates. Those cases require different action: correct the path, obtain authority, or re-establish filtering after a policy change. The shared identity protects abstraction and reduces information leakage. An automation system that insists on extracting one hidden cause from the name defeats the protocol’s security boundary.

no-such-subscription is similarly careful. RFC 8639 can use it when the identifier does not exist, when it names a subscription belonging to another subscriber, or when the referenced item is a configured subscription to which that RPC does not apply. The caller receives a safe operational verdict: this request cannot act on that identifier. It does not receive a licence to conclude which database row exists.

insufficient-resources compresses a different uncertainty. It says the publisher cannot produce the requested subscription. It does not say whether the scarce object is memory, bandwidth, queue space, CPU, an implementation limit or a policy quota. It does not say who owns the constraint, how long it will last, which workload should yield, or when a retry becomes rational.

This is why a registry is an authority over names, not an oracle over events.

The minimum useful receipt begins before the error: protocol and transport session, operation, request identifier, authenticated principal and authorization decision. It then preserves the target datastore and path, broad tag, module-qualified identity, base identity, structured information, server and module revision, and transaction outcome. After an intervention it records what changed, who authorized it, the result of a readback and whether the service actually recovered.

Each link answers a different question. Did the server understand the request? Was the caller permitted to learn about the target? Which model defined the specific identity? Did the transaction change state? Did a retry alter any relevant parameter? Did the intended service become healthy? A label alone answers none of them completely.

Heng Lu’s minimum-initial-specification principle provides the right division of labour. The standards process should define the smallest stable vocabulary and extension rules that many implementations can share. It should not pretend to decide an incident’s local remediation without the later facts held by the server, operator and service owner. The registry localizes vocabulary governance; the runtime localizes causal judgment.

The reality-layer distinction is equally important. operation-failed is a symbol describing a protocol outcome. The depleted queue, revoked permission, nonexistent node or unsuitable parameter is the operating reality. The symbol may deliberately preserve several possible realities. Treating it as the reality itself creates false certainty.

Running-code primacy supplies the final test. An automated retry is not recovery because the API accepted another request. A configuration write is not recovery because a transaction returned success. Recovery needs a readback of changed state and observation of the intended service outcome. Otherwise the organization has merely moved from one named state to another.

Sources