Summary
- The NMOP anomaly lifecycle moves labels through detection, validation and refinement, but a state such as “confirmed” describes process position rather than unlimited authority to reuse the judgment.
- Annotator identity, confidence scores, secure transport and access control are useful provenance; none alone proves evidence completeness, service scope, causal certainty or permission to train a detector.
- Every feedback decision needs immutable evidence, revision lineage, validator role, authority basis, dissent, downstream consumers, replay results and a rollback boundary.
Confirmation for one purpose
An automated detector marks a sudden traffic change as a potential problem. A network engineer inspects the affected service, sees the same symptom in an incident record and changes the label to confirmed. For incident triage, that can be a sound decision. The service team restores the desired state and closes the event.
Weeks later, a refinement job collects confirmed labels and adjusts a detection model. The original engineer never reviewed that use. The label does not say whether confirmation covered one circuit or a whole product, whether the engineer saw all counterevidence, whether the incident cause was established, or whether another team disagreed. A judgment that was valid for operational response has silently become training truth.
No field was necessarily falsified. The category error entered through reuse.
Revision 07 of the IETF NMOP draft An Experiment: Network Anomaly Detection Lifecycle is dated 6 September 2026 and expires on 10 March 2027. It is an active Working Group Internet-Draft with intended status Experimental, not an RFC. The document proposes an iterative lifecycle, a state machine and YANG data models for exchanging anomaly labels among humans and algorithms.
Its most important contribution may be the admission that understanding changes. Detection, validation and refinement form a loop, not a one-way verdict machine. The governance challenge is to keep each transition from acquiring more authority than its evidence supports.
A state name is not an authority grant
The draft distinguishes forecasted and potential problems from confirmed or discarded ones. After confirmation, a problem can move into analysis; a refinement can adjust detection and return the case for verification. Those states make work legible. They do not answer who may perform each transition for which service.
An operator can be authorised to acknowledge an alarm without being authorised to amend a global training set. A data scientist can tune a model without being authorised to suppress an incident class. An automated refiner can execute an approved experiment without being allowed to change production remediation thresholds. “Human in the loop” names a participant pattern, not a delegation model.
The draft’s annotator structure includes a mandatory name, with optional identifier and version and an annotator type. That is valuable provenance. A name is not a role, and a role is not an authority basis. Version identifies a tool build or actor representation only if the implementation makes it so. The evidence record still needs the organisation, duty, approval scope, applicable service, decision purpose and expiry of that authority.
Otherwise two equally authenticated annotators can create incompatible revisions while the latest revision merely wins by arrival order.
Confidence does not close the evidence set
The model carries confidence and concern scores. Confidence expresses how strongly a detector regards behaviour as anomalous. Concern expresses how much investigation or corrective action a state may deserve. Both can help prioritise work, but neither is a probability that every relevant fact has been collected.
A detector can be highly confident that a time series departed from its learned range while having no knowledge of a planned change. A validator can be certain that customers experienced loss while remaining uncertain about cause. A concern score can justify escalation without granting permission for automated remediation. One hundred on a scale is still a statement made under a particular method and evidence boundary.
The receipt therefore needs the scoring method and version, input features, calibration window, missing signals, service scope and the claim the number is meant to support. Reusing the number outside that boundary turns precision into theatre.
A reference is not an immutable observation
The proposed model can refer to operational data through message-broker topic and subject fields. That can connect an annotation to the stream from which it arose. Yet a resolvable topic is not necessarily a frozen snapshot of the values a validator saw.
Retention can expire. Compaction can replace records. Producers can change schema or units. Access policy can hide part of the stream from a later reviewer. A subject name may route to current data rather than historical bytes. If a disputed label is replayed against a different dataset, the same reference can produce a different evidentiary world.
For consequential transitions, preserve content hashes, query and filter, observation interval, producer identity, schema version, units, collection point and completeness status. When legal, operational or privacy constraints prevent retention, record that limitation rather than treating the reference as equivalent to custody.
New versions must preserve disagreement
The Label Store is intended to persist information from each lifecycle stage. Labels are retrieved, reviewed, modified and stored again as new versions; an annotation may also be marked irrelevant. Versioning creates the opportunity for accountability, but only if implementations retain the predecessor and transition reason.
Suppose one validator confirms a problem and another later discards it after learning that the traffic change was planned. The second judgment may be better. It should not rewrite history as though the first never existed. The earlier decision may already have paged staff, changed a rule or entered a dataset. Its downstream effects remain real.
An irrelevant tag likewise needs a subject. Irrelevant to which service, time period, detector and decision? Removal from the active view should not erase the evidence that a label once influenced action. A revision chain should preserve actor, time, prior revision, evidence delta, decision reason, dissent and consumers notified of the change.
Authenticated writes can still be wrong
The security model relies on secure transports, mutual authentication and the Network Configuration Access Control Model to limit NETCONF or RESTCONF operations and content. These are essential controls. They can show that an authenticated principal used an allowed operation on protected data.
They cannot show that the principal interpreted the symptom correctly. Access control does not establish that the evidence was complete, that the claimed service was affected, or that the principal was independent of the detector being reviewed. A perfectly authorised edit can encode a mistaken conclusion; a compromised but valid account can encode a malicious one.
The semantic receipt must therefore sit beside the protocol receipt. Preserve not only who could write, but why this transition was justified, what evidence changed, what policy authorised the purpose, and what review is required before the result crosses into training, alarm suppression or remediation.
Feedback can manufacture its own confirmation
The refinement stage can adjust symptom definitions, weights, scores, automation or models and then replay an anomaly to test improvement. This is where a useful learning loop can become self-confirming.
If a mistaken confirmed label is used to tune the detector, the next version may reproduce that label more consistently. A replay against the same curated incident can show improved agreement because the target encoded the original judgment. Higher agreement is not necessarily greater correspondence with service reality.
The test set must be separated from the labels used for adjustment. Negative cases, dissenting annotations and changed network conditions must survive. Evaluation should distinguish detection accuracy from operational utility, causal accuracy, calibration and harm from false suppression. A model version needs a rollback path, and every downstream rule or model trained from a revision needs a dependency record.
Running code does not close this boundary. The draft cites Antagonist as an open-source implementation supporting visual label validation and ground-truth generation. That is evidence that the model can be exercised. It is not evidence that a particular label is true, that a production organisation assigned authority correctly, or that feedback improved customer outcomes.
Experimental status should remain operationally visible
The draft defines success for its experiment in terms of an open-source implementation applied to real networks. The packet establishes a proposed process, a data model and reported implementation work. It does not establish adoption, interoperability, accuracy, safety or measured benefit in a named production network.
This distinction matters because an experimental lifecycle can still create durable institutional records. Labels may outlive the draft revision that defined them. Model adjustments may outlive the evidence-retention window. A “final” state may become a dependency for systems that never saw the uncertainty present at detection.
Store the governing draft or schema revision with each record. Migration must preserve old semantics rather than silently translating every historical state into the newest vocabulary.
Sources
- https://datatracker.ietf.org/doc/draft-ietf-nmop-network-anomaly-lifecycle/
- https://datatracker.ietf.org/doc/draft-ietf-nmop-network-anomaly-lifecycle/history/
- https://datatracker.ietf.org/doc/draft-ietf-nmop-network-anomaly-lifecycle/references/
- https://datatracker.ietf.org/doc/draft-ietf-nmop-network-anomaly-lifecycle/referencedby/
- https://www.ietf.org/archive/id/draft-ietf-nmop-network-anomaly-lifecycle-07.html
- https://www.ietf.org/archive/id/draft-ietf-nmop-network-anomaly-lifecycle-07.txt
- https://www.ietf.org/archive/id/draft-ietf-nmop-network-anomaly-lifecycle-07.xml
- https://datatracker.ietf.org/doc/draft-ietf-nmop-network-anomaly-architecture/
- https://datatracker.ietf.org/doc/draft-ietf-nmop-network-anomaly-semantics/
- https://datatracker.ietf.org/doc/draft-ietf-nmop-terminology/
- https://datatracker.ietf.org/doc/draft-ietf-nmop-yang-message-broker-integration/
- https://www.rfc-editor.org/rfc/rfc9232.html
- https://www.rfc-editor.org/rfc/rfc9417.html
- https://www.rfc-editor.org/rfc/rfc8341.html
- https://www.rfc-editor.org/rfc/rfc8040.html
- https://www.rfc-editor.org/rfc/rfc6241.html
- https://github.com/vriccobene/antagonist
- https://github.com/ietf-wg-nmop/draft-ietf-nmop-network-anomaly-lifecycle
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
