Summary

  • RFC 9968 records the NEMOPS workshop's call for usable tooling, service-level modeling, verification, observability and more deployable network-management work. It is an Informational IAB workshop report, not a standards-track command or a transfer of authority to a model, controller or dashboard.
  • A configuration model can describe intended state. Telemetry can report observed state. An adapter can translate representations. None can independently prove complete coverage, customer permission, a proportionate trade-off, or the identity of the party entitled to accept a failed change.
  • A defensible automation chain keeps four records separate: the service intent, the observed evidence and its freshness, a bounded proposal, and a local authorization with scope, owner, rollback and review. Joining the records improves operation; silently treating one as another creates unaccountable control.

A workshop report is evidence of a discussion, not an operating warrant

The Internet Architecture Board convened the Next Era of Network Management Operations workshop in December 2024, twenty-two years after the 2002 network-management workshop recorded in RFC 3535. Its May 2026 report, RFC 9968, takes stock of a difficult reality: management models, protocols and tools have improved, yet operators still face fragmented ecosystems, incomplete model coverage, uneven implementations, sparse open tooling and transitions that are hard to execute.

That diagnosis is worth reading carefully because it resists the usual easy story. Network management has not failed because operators refused to learn a single correct interface. The workshop heard that SNMP remains important for monitoring, that CLI remains heavily used for configuration, that NETCONF and YANG do not expose every required feature on many devices, and that a multi-vendor estate has to live with several models at once. The practical problem is not simply lack of syntax. It is how an operator can relate an intended service to imperfectly exposed devices, changing software and actual customer outcomes.

But the report also describes its own limit. It is an IAB-stream Informational document, not an Internet Standards Track specification. It says it reports presentations and discussion notes without interpretation or validation and does not necessarily represent consensus unless it says so; positions expressed at the workshop need not be IAB positions. That is not a weakness. It is an honest account of what a workshop report is: a durable record of questions, evidence and recommendations.

The distinction matters as management systems become more persuasive. A visual model can look complete. A knowledge graph can connect every object it has been given. A controller can turn a desired state into a queue of API calls. An automated recommendation can carry a confidence score. None of these changes the source of decision rights. A useful artifact can be mistaken for a warrant precisely when it is neat, machine-readable and fast.

The old workshop had already named the principle. RFC 3535 asked operators to distinguish configuration data, operational state and statistics; to minimize the effects of a move from configuration A to configuration B; to use least-privilege access; and, crucially, to distinguish distributing a configuration from activating it. A network may possess a valid file, a capable API client and a correctly parsed model while still lacking permission to activate that state on a live service.

Four records that should not be collapsed

The smallest accountable design separates four things that modern automation is eager to merge.

First comes service intent: the outcome the operator owes, such as reachability, latency envelope, protected traffic class, customer handoff, maintenance limit or restoration objective. It must identify the owner of that commitment. A device configuration is often only one implementation path toward it.

Second comes observed evidence: telemetry, logs, counters, alarms, route views, probe results and operator observation. Evidence needs provenance, collection time, scope, loss behavior, model revision and an explicit statement of what it does not cover. A sensor can faithfully report a partial world. A silent subscription can mean health, loss, filtering, a broken collector or simply that no modeled event occurred.

Third comes the proposed change: a declared delta from the current state, bounded by devices, services, customers, time, dependencies, expected effect and reversible path. A proposal must not be hidden inside an imperative call. If an adapter maps a service model into vendor-specific configuration, preserve both sides and the adapter version. Otherwise, the organisation can later prove neither what it requested nor what the device received.

Fourth comes the authorization record: the party who may approve this scope, the evidence that informed the choice, conditions of execution, a named rollback authority and a time limit. This is not an argument for a ceremonial human click on every command. It is an argument that an automation policy itself must have a traceable local owner, bounded applicability and revocation path.

RFC 8342, the Network Management Datastore Architecture, helps clarify why this separation is valuable. It distinguishes intended, applied and operational state rather than treating a device as one undifferentiated fact. The distinction is technical, not constitutional. It does not decide whether an applied state breached a customer promise or whether a controller may change it. Yet it offers a useful habit: ask what kind of record is being shown before asking what conclusion it supports.

The same restraint applies to configuration protocols. RFC 6241 defines NETCONF mechanisms, including surfaces around candidate and running configuration and confirmed commit. RFC 8040 supplies a RESTCONF interface. They can make a change structured, authenticated and recoverable within their specified scope. They cannot determine whether a transit customer, a hospital tenant or a regional operations team should carry the failure mode. Protocol access is an implementation capability, not a general licence to decide consequences.

Better telemetry does not settle the decision

The NEMOPS report is right to emphasize verification and observability. A configuration that cannot be tested for device acceptance is not a serious automation input. Service-level models are more useful than a pile of isolated device objects when the risk belongs to a service. Off-box adapters may be the practical route through heterogeneous vendor models. These are gains in evidence and execution discipline.

They are not claims of omniscience. RFC 8639 and RFC 8641 define a framework and datastore-update subscriptions for YANG notifications; RFC 9196 describes capabilities and datastore-update-notification modules. Such facilities can tell a receiver what a publisher reports under an agreed schema. They do not independently demonstrate that every relevant device is modeled, that a translation was lossless, that a stream remained continuous, or that no external condition changes the decision.

The error to avoid is not automation. It is a false syllogism: the model says a change is possible; the model is authoritative; therefore the change is authorized. The first statement may be technically well supported. The second has to be demonstrated separately. Authority comes from the operator's commitments, delegated roles, contracts, law where applicable, and the party who will carry the operational and economic loss. No data-tree path can conjure it.

Heng Lu's notes on running-code primacy, minimum initial specification and localized future decision, and reality layers provide a useful editorial test. A common model should make interoperability easier without pretending to govern every later choice. Running effects deserve more weight than a symbolic declaration of control. A record is valuable when its limits stay visible.

Test the seam where evidence becomes action

An operator should rehearse not only a successful configuration transaction but the seam between seeing and changing. Begin with a service-level intent that can be measured independently. Capture the controller's inventory and model revisions, device capability advertisement, source timestamps, notification gaps, translation output and proposed configuration delta. Then test whether every target accepts the proposal, whether every affected service remains inside its declared envelope, and whether a bounded rollback restores the prior condition.

The test must include negative cases. Remove one telemetry feed while the service remains healthy. Delay a subscription. Make one device reject a modelled leaf. Let an adapter encounter an unsupported vendor feature. Introduce an out-of-band CLI adjustment. Simulate a controller restart between distribution and activation. Change the scope after approval but before execution. Each case reveals a different failure: incomplete observation, model overstatement, translation loss, state drift, stale authority or a rollback that exists only on a slide.

The proof is a replayable record, not a dashboard screenshot: inputs and hashes, versions, target set, proposal, approvals, device responses, external probes, client or service result, rollback result and any exceptions. This is how a leadership team can distinguish a controller that issued requests from an operation that maintained the service it was meant to protect.

Sources