Summary

  • RFC 9315 defines intent as declarative operational goals and desired outcomes without prescribing how to achieve them. Acceptance, translation and configuration are therefore intermediate states, not proof that the outcome exists in the running network.
  • A credible intent-based system must preserve two records without merging them: validated intent and observed operational state. Assurance compares them over time, detects drift, exposes uncertainty and either corrects within bounded authority, rolls back or returns the decision to the user.

Analysis

The success receipt that arrived too early

Consider an illustrative failure, not a reported incident. An authorized operator states that every path supporting a critical service must retain protection. An intent-based system clarifies the request, accepts it and selects a course of action. Devices acknowledge the resulting changes. The interface displays success. Later, a topology change removes the alternate path. Nothing has altered the accepted sentence, but the network can no longer deliver its outcome.

The first receipt proves that a request entered the system. A second may prove that the system found the request well formed. Device acknowledgements can prove that particular operations were accepted. None of those records demonstrates continuing protection. The missing fact lives in another place: observed forwarding behavior under the topology, load and failure conditions that now exist.

That separation is the most useful discipline in RFC 9315. The document defines intent as operational goals and outcomes expressed declaratively, without specifying how they must be implemented. It then divides intent-based functionality into fulfilment and assurance. Fulfilment moves a goal towards realization. Assurance asks whether the network is actually adhering to it.

Jeff Tantsura is one of four authors, with Alexander Clemm, Laurent Ciavaglia and Lisandro Zambenedetti Granville. The document was published in October 2022 as an Informational product of the Internet Research Task Force’s Network Management Research Group. It is not an Internet Standards Track specification. Its value here is conceptual precision, not proof that a product, operator or deployment achieved the vision.

Tantsura’s IETF Datatracker profile establishes his documented participation and broader RFC record. It does not make him the inventor or controller of intent-based networking. The mechanism belongs to collaborative research work, and its operational claims must still stop where the publication stops.

Goal, rule, service and setting are different objects

RFC 9315 spends considerable effort separating intent from terms that are often treated as synonyms. A service model represents a service and its parameters. A policy supplies rules that govern behavior, often through events, conditions and actions. A device setting specifies a concrete state. Intent states a desired outcome while leaving the method open.

The distinction matters because each object carries different authority. An operator may be authorized to demand a protected service but not to prescribe every interface command. A policy engine may choose actions within a defined scope but not redefine the outcome. A device may accept a setting without knowing which customer promise or operational purpose the setting serves.

Collapsing these layers creates false certainty. If the system calls every northbound request “intent,” a convenient API can be sold as a life-cycle capability. If it calls an accepted configuration “fulfilled,” the control plane can grade its own work before the data plane has spoken. If a service instance is treated as the goal itself, the system may preserve the object while losing the result the object was meant to provide.

The RFC names this rhetorical risk “intent-washing.” The warning is more than a dispute over vocabulary. An abstraction earns its operational value only when it preserves the mapping from the authorized outcome through every consequential decision and back from observed behavior. Renaming an interface does not create that chain.

Two truths that must not be fused

One principle in RFC 9315 is a Single Source of Truth, or SSoT. In this context, the SSoT is the set of validated intent expressions. That is a source of truth about what the system has accepted as the desired state. It is not a source of truth about what packets, paths or services are doing now.

The document keeps operational-state records beside the SSoT so that intended and actual states can be compared. Drift exists precisely because the intended record can remain stable while behavior moves away from it. If the intent database automatically certifies reality, the comparison disappears and the most important failure becomes unobservable by design.

The source and version of each accepted statement therefore matter. Who supplied it? What authority did that actor hold? Which scope, constraints and trade-offs were accepted? What ambiguity was clarified? Which competing intent was moderated, and by whom? When did the statement become effective, and can it expire or be retracted? These facts make the desired state reviewable without pretending it is self-executing.

Operational evidence needs its own provenance. A latency sample covers a path, time and observation point. Reachability seen from one location may not describe another. A device state can be fresh while the service-level inference built from it is incomplete. An assurance verdict should show the predicate tested, the evidence window, the uncovered area and the confidence attached to the comparison.

Sofia Ren applies Heng Lu’s running-code discipline here as an analytical lens. Running-Code Betrayal and his public argument for reality rather than advocacy support a narrow test: a declaration may guide reality, but it cannot replace observation of reality. This comparison is Ren’s interpretation; it does not assert the RFC authors’ private intent.

One touch is not one shot

RFC 9315 describes an ideal in which a user expresses intent once and the system handles subsequent operations. It immediately limits the slogan: one touch should not be confused with one shot. A useful request may begin with missing parameters, implicit assumptions or competing goals. Refinement can require dialogue, explanation of trade-offs and an explicit user choice.

Suppose the operator requests both maximum utilization and protected paths. Under a capacity shortage, both may not be achievable. The system can calculate alternatives and expose consequences. It cannot discover which loss the organization is authorized to accept merely by optimizing harder. Conflict resolution is not a hidden engineering detail when the alternatives distribute operational or economic harm differently.

The clarification record becomes part of accountability. A later reviewer should be able to distinguish a constraint supplied by the user from one inferred by the system. The reviewer should also see whether an inferred value was confirmed, whether an alternative was rejected and whether the actor had authority to make that trade. Natural language can make interaction easier; it does not make authorization implicit.

Fulfilment is a chain, not a result word

The RFC divides fulfilment into ingestion, translation and orchestration. Ingestion recognizes and refines the desired outcome. Translation selects meaningful courses of action for management and configuration systems. Orchestration coordinates the lower-level operations needed to carry them out.

Each transition can preserve or lose meaning. Translation may choose one path calculation among several. Its inputs can contain stale topology, unavailable resources or an incomplete dependency view. Orchestration can partially succeed, leaving one domain changed and another untouched. A device acknowledgement can confirm receipt while saying little about the service effect.

A robust record therefore binds the accepted intent version to the selected interpretation, assumptions, target objects, ordered actions and partial failures. That record does not need to expose every low-level knob to the person who stated the goal. It does need to let an authorized reviewer reconstruct why the system believed its actions could produce the requested outcome.

Automation changes the time scale of error. A human may misconfigure one device slowly. A high-level system can render an ambiguous or compromised statement across many domains quickly. RFC 9315’s security discussion accordingly calls for checkpoints, safeguards and ways to prevent or contain error amplification. Abstraction reduces manual effort while increasing the radius of an unexamined inference.

Assurance is where the claim meets the network

Assurance begins with monitoring and observation. It collects events, measurements, performance evidence and telemetry. Compliance assessment then compares that observed behavior with the behavior expected from the accepted intent. The comparison can test whether fulfilment actions produced the desired effect and how large that effect was.

The word “continuously” should not be romanticized. No observation covers every packet or future condition. Evidence arrives with delay, sampling choices and blind spots. An assurance system should express these limits instead of converting a partial view into unconditional compliance. A green status without the time, scope and predicate of its evidence is an aesthetic, not a proof.

Intent drift can arise after initial success. A lower-level management action, control-plane change, resource failure or new competing goal can move behavior away from the accepted outcome. The drift record should show when divergence was first observed, how severe it is, which services and users are exposed, and whether confidence is strong enough to justify an automatic response.

Corrective action has its own boundary. The system may be permitted to restore a missing path inside an approved resource envelope. It may not be authorized to buy capacity, violate a geographic constraint, weaken encryption or displace another customer’s protection. When correction requires a new trade-off, assurance should escalate rather than silently rewrite the intent.

Two loops, two kinds of authority

RFC 9315 depicts an inner and an outer loop. The inner loop can monitor, assess and adjust network state without a human participating in every operation. It is the automation loop. The outer loop returns evidence and consequences to the user, who may refine, modify or retract the desired outcome.

These loops should not be collapsed into one sovereign controller. The inner loop needs enough authority to act within stated bounds and enough evidence to know whether the action worked. The outer loop preserves the decision that engineering cannot settle: whether the desired outcome, constraints or accepted trade-offs should change.

An intent also has a life cycle. It comes into being, changes and can end. Retraction is not administrative cleanup. A system that can accept a powerful goal but cannot reliably stop enforcing it has converted a temporary instruction into a durable source of control. Versioning, effective time, ownership and revocation are therefore operational properties.

The IETF mission in RFC 3935 gives a useful adjacent boundary: engineering work is tested through voluntary adoption and running code. RFC 9315 comes from the IRTF rather than the IETF standards stream, but the same epistemic restraint applies. A published concept can organize a test. It does not announce the test result.