Summary

  • draft-ietf-nmop-network-incident-yang-14 separates the network incident lifecycle—raised, updated, cleared—from the operator lifecycle—acknowledged, diagnosed, resolved—and lets one resolve RPC target multiple incidents.
  • Successful resolution is reported later through a separate asynchronous notification. An official YANG Doctors review found no way to correlate a result notification to the RPC that produced it.
  • A command-to-clear receipt should join the authorized request, exact incident set, action, RPC outcome, correlated notification, ticket mapping and service validation. This is an editorial control proposal, not an IETF requirement.

The green state arrives without its parent

Network automation often makes a result visible after the initiating conversation has ended. A client asks a server to diagnose or resolve an incident; the server accepts the RPC; later, a notification reports the latest state. This is sensible for work that may take time. It also creates an evidence seam.

Revision 14 of A YANG Data Model for Network Incident Management makes that seam unusually clear. The incident-resolve RPC accepts a list of incident-no values. If an incident is successfully resolved, the draft says a separate notification is triggered and the incident state changes to cleared. How the server resolves the incident is outside the document's scope.

The notification identifies an incident number. That is enough to say which incident record changed. It is not the same as a request identifier that says which invocation caused the change. The difference matters when several clients act, when one request targets several incidents, when a server performs self-healing, or when the underlying condition disappears for another reason.

The 31 August YANG Doctors review states the problem directly: RPC results are sent through notifications, but the model provides no way to correlate a notification with the RPC that produced it. The review was marked “Almost Ready,” and it also noted that a next unpublished iteration should be reviewed. That is a live review finding, not a verdict that the draft is broken or that later work cannot answer it.

Two lifecycles prevent one category error

The draft does something important before this gap appears: it separates machine state from operator action. A network incident instance can be raised, updated or cleared. An operator can acknowledge, diagnose and resolve it. Those vocabularies overlap in ordinary conversation, but they are not interchangeable.

An observed fault may clear before an operator closes a ticket. An operator may mark work resolved while a monitoring condition remains active. A workaround may restore traffic without removing the probable root cause. A self-healing function may clear the incident without the human action that an auditor later assumes. The draft's two lifecycles keep these possibilities conceptually available.

Its operational considerations extend the distinction to another system. Operators should implement a deterministic translation between the YANG incident states and external ticket states such as Open, Assigned, In-Progress and Resolved. Otherwise the network layer can say closed while the ticket remains active, or the ticket can say resolved while the network still reports an incident.

Deterministic mapping is necessary, but it is not causal evidence. A rule can reliably translate cleared into Resolved and still be unable to say which request, actor or remediation caused the source state. It can propagate confidence without adding proof.

Authentication answers who connected, not what caused the outcome

The draft places the model behind secure YANG management protocols. NETCONF or RESTCONF is expected to use a secure transport and mutual authentication. NACM can restrict particular users to subsets of operations and content. The security section also warns that incident records may expose the broken state of a network and that a malicious or buggy client can consume resources by issuing many diagnose or resolve operations.

These are real controls. They should not be dismissed merely because a correlation field is absent. Mutual authentication can establish the management peer. NACM can decide whether that principal may call incident-resolve. Error identities can distinguish permission denial, timeout, unavailable resources or an unresolved probable cause.

None of those facts says that a later cleared notification was the outcome of one particular authorized call. Identity, permission, request acceptance, execution and observed state are separate claims. Collapsing them into “the system cleared the incident” gives a status field more institutional authority than it contains.

Bulk resolution raises the cost of ambiguity

One RPC can carry several incident numbers. That makes operational sense when a shared cause affects many records or a controller applies one coordinated response. It also means a partial result needs more than one timestamp.

Suppose a request names incidents 41, 42 and 43. The server accepts the RPC. Incident 41 later becomes cleared; 42 remains updated; 43 disappears after topology discovery refreshes its inputs. A flat success label cannot explain whether the same action affected all three, whether one incident was already clearing, whether the third record was reidentified, or whether a retry created a second causal path.

Revision 14 defines error reasons for failures, but errors describe what did not complete at the RPC boundary. The successful path still needs a join to its later notification. The draft also says resolution may affect running services and lets the client decline action when impact is not trivial. That makes the authorization decision and the chosen alternative part of the evidence, not administrative decoration.

Validation proves syntax, not an operational chain

The Datatracker record identifies revision 14, published on 18 August 2026, as an active NMOP Working Group draft intended for the Standards Track. Its Working Group Last Call ended on 3 September; at the 9 September evidence cutoff, the frozen record still said In WG Last Call, listed no responsible AD or telechat date, and did not show IESG approval. Datatracker recorded zero YANG validation errors and zero warnings on 7 September.

That is useful process evidence. A schema that does not compile cannot support interoperable operations. But successful validation proves neither deployment nor correct correlation across a command, an asynchronous notification and an external ticket. The IETF 126 NMOP minutes also record discussion about the relationship among the incident-list key, incident number and incident ID. The identifiers were being examined; the minutes do not supply an operational verdict.

Running code would sharpen the question. A persuasive test would issue two concurrent, differently authorized resolve requests with overlapping incident sets, induce a self-clearing condition, delay one notification and then show that every resulting state can be attributed without guessing. A failed attribution would be as informative as a clean pass if the implementation preserves the evidence.

Build the join outside the protocol

The missing governance object can be small. A command-to-clear receipt need not modify the YANG module or expose sensitive topology. It can sit in the operator's control and evidence plane.

At request time, the receipt records a unique invocation identity, the exact incident numbers and their current revisions, the authenticated principal and role, the applicable authorization and change-policy versions, the intended action class, anticipated service impact, decision time, approver where required, and the alternative chosen when direct remediation is too risky.

At execution time, it records whether the RPC was accepted or failed, the per-incident error reason, the server and model revision, and any retry or split request. When notifications arrive, it binds each one to the invocation, preserves the incident revision and event time, and distinguishes causal result, independent state change and unknown correlation.

At closure time, it adds the deterministic mapping into the external ticket, the ticket's own actor and time, a service-level validation result, residual cause or workaround, rollback state and correction history. Public reporting can disclose only classes, timestamps and outcome states; the detailed topology, customer identifiers and remediation commands can remain protected.

This record refuses an easy fiction. It does not require every clear state to have been caused by a command. “Cleared independently” and “cause unknown” are legitimate outcomes. The purpose is not to manufacture certainty but to stop an asynchronous interface from manufacturing it accidentally.

The Policy Mirror asks where the operative decision is written. Here, permission may be in NACM, requested intent in an RPC, observed condition in the incident datastore, operational closure in a ticket and customer reality in a service test. Running-Code Primacy requires those records to meet in execution. Reality, Not Advocacy keeps the claim bounded: the draft gives incident automation a useful vocabulary. Operators still need to prove which authorized act produced the green state they rely on.

Sources