RFC 9817: Execution Is Not Authority in the Network

Summary

RFC 9817 moves computation into programmable network devices but does not turn placement into permission. Program identity, admitted artifact, selected instance, effective read/write rights and invoked purpose remain separate facts.
The same instance can lower latency while creating new state, precision, isolation, accounting and failure problems. A result is credible only when it can be followed from the requesting principal through the loaded target to the packet, application or physical-process effect.
The durable governance unit is an execution receipt: who authorized what code, on which resource, under which constraints, with what state, output, override and rollback. A fast action without that chain is an unpriced transfer of authority into the data path.

Forty microseconds concealed the most important question

The local controller reacted in forty microseconds. The remote controller would have needed several milliseconds. A plant process stayed within its target band, and the network team showed the latency graph as evidence that moving the simplified control function into a programmable switch had worked.

Then the review began.

Which version of the control function ran? Which compiler produced the loaded artifact? Who selected that instance? Which sensor fields could it read? Was its arithmetic precision sufficient for this operating range? What state did it inherit from the previous instance? Did the global controller receive the action, override it or merely observe it later? Which packets and actuator changes resulted? What remained on the device after rollback?

A latency graph cannot answer those questions. It measures one interval inside a much larger act.

RFC 9817, published in August 2025, describes use cases for Computing in the Network, or COIN. Its programmable network devices include switches and network interface cards. Its examples range from mobile offload and immersive media to industrial control, data preprocessing, content delivery, compute fabrics, virtual-network programming and distributed AI training.

The document is careful about its own authority. The RFC Editor record classifies it as Informational in the IRTF stream. It represents consensus of the Computing in the Network Research Group, not the IETF; it is not an Internet Standard, and IRTF results may not be suitable for deployment. RFC 7841 explains that separation between research-group publication and the standards process. The official COINRG page now records the group as concluded. None of those status facts validates or invalidates a particular implementation. They define what publication can and cannot prove.

The article's thesis is narrower than “COIN is good” or “COIN is dangerous.” Moving computation changes the custody of decisions. The system must show where that custody moved.

A program name is not a running instance

RFC 9817 distinguishes a COIN program from a COIN program instance. The first is specified functionality; the second is one running occurrence. That distinction is the first audit boundary.

A catalogue can say that a filtering, aggregation or control program exists. An orchestrator can say which logical version it requested. A compiler can produce a target-specific artifact. A device can acknowledge loading bytes. A scheduler can direct requests to one instance. The instance can process traffic. These are six different statements.

They diverge in ordinary operations. A rolling upgrade leaves old and new instances alive at once. A fallback target accepts an earlier instruction set. One device rejects a feature and loads a reduced path. A warm restart restores state under a new process identity. A service name continues resolving while the execution location moves. If every record says only “program X ran,” the evidence needed to explain the outcome has already been discarded.

RFC 9817 asks how programs and instances should be identified, how a particular instance should be selected and pinned, and how longer-lived transactions should preserve affinity to ephemeral state. Its Datatracker record and publication history show the document lineage; they do not define a universal runtime identity scheme. The expired COIN terminology draft is useful as a dated vocabulary artifact, not as a standard.

A defensible runtime identity joins at least the program specification, source or package hash, compiler and options, target binary, device capability profile, load transaction, instance identity, state generation and invocation. If one field changes, the operator should be able to say whether the change created a new authority object or merely a new copy.

That is running-code primacy applied literally. The requested program is a representation. The loaded artifact is another. The executing instance and its measured effect are further layers. The fact that their labels match does not make their contents identical.

Placement carries a permission envelope

A switch that only forwards on destination information performs a bounded network role. A programmable device may also parse application fields, inspect payload, aggregate values, rewrite content, replicate traffic, filter records or issue local control signals. Placing a program therefore places an access decision.

RFC 9817's security section is direct about the difficulty. Early programmable network devices may lack cryptographic support and often operate on unencrypted data or modify payload. If an intermediary receives decryption capability, the security model changes again. The text says least privilege is the ideal: the intermediary should have exactly the permissions needed to read or alter payload for its purpose.

“Exactly” is where governance begins. Permission must be expressed in something the target can enforce and the auditor can compare. A policy might authorize selected header fields but not payload; one telemetry key but not a neighboring customer identifier; aggregation but not export of raw records; a bounded rewrite but not packet injection; one tenant's queue but not the shared scheduler.

Requested permission is not effective permission. A compiler may widen a parser. A target may lack field-level controls. Encapsulation can move a value. A fallback path may execute in a richer environment. A debug mode can expose data that the production path hides. The receipt needs both policy and observed enforcement.

The older middlebox taxonomy in RFC 3234 explains why this cannot be reduced to placement. An intermediary can be explicit or implicit, inline or call-out, functional or optimizing, routing or processing, soft-state or hard-state. It creates configuration, failure and diagnostic surfaces beyond the endpoints. The end-to-end principle permits useful in-network enhancement, but an incomplete function in the network does not replace end-to-end correctness.

RFC 7663 carries the architectural warning into IPv6 network functions: intermediaries affect transparency, extension and failure behavior. A programmable platform may make a function easier to change, but programmability does not remove the intermediary's power. It accelerates the rate at which that power can change.

“Who decides?” is not an implementation detail

In the industrial-control use case, RFC 9817 asks: who decides which control instance executes, and which information may be used for the decision? This is not a scheduler-tuning question. It names two different authorities.

The placement authority chooses where a function runs. The data-use authority defines what facts the chooser may consider. Geography, latency, device load, energy, tenant identity, data class, legal jurisdiction, safety mode and commercial price may all change the answer. A technically available target can be institutionally forbidden. A low-latency target can be too imprecise. A local target can lack a required override channel. A resource offered by an end user can belong to the wrong trust domain.

The chooser itself also has a principal. A user may request an experience, an application may express constraints, an operator may protect the fabric, a tenant may control its virtual network, a safety authority may restrict control logic, and a regulator may constrain location or interception. These interests are not naturally identical.

The receipt should therefore include the requesting principal, the decision authority, the constraint set, the evidence snapshot used, the candidates excluded, the selected target and the rule that resolved conflict. “The orchestrator chose the best instance” is not reviewable. Best for whom, under what authorized objective, using which current facts?

RFC 9817 does not answer the question. That is precisely why a deployment must not conceal it behind automation.

State turns movement into custody

Mobile offload and distributed applications require more than stateless packet handling. RFC 9817 asks how service requests retain affinity to a program instance holding ephemeral state, and how state remains consistent when execution moves. The word “ephemeral” does not make the custody problem temporary.

State can contain sequence position, partial aggregation, model parameters, flow classification, a safety window, a cryptographic context, rate-limit counters or a customer's intermediate data. Moving the program without its state can duplicate work, omit work or change a control result. Moving state without its authority can expose data. Copying it without generation and lineage creates two plausible presents.

The evidence unit is not “migration succeeded.” It is a state handoff with source instance, destination instance, state schema, generation, bounded contents, encryption and access context, quiescence or overlap rule, transfer hash, activation point, first accepted invocation, source retirement and residual-state disposition.

Exactly-once and at-least-once are different obligations. RFC 9817's virtual-network programming section notes that a distributed program may need to process a packet exactly once, or at least once when the operation is idempotent. A counter increment, actuator command or payload rewrite may not be idempotent. A duplicate is then an outcome, not a harmless implementation detail.

A rollback that reloads code but leaves later state behind is not a rollback to the earlier system. A failover that has the right binary but the wrong counter generation can be available and false at once.

Fast control can be less accurate control

The industrial-control example considers simplified functions running close to a process and more capable controllers farther away. It openly frames the trade: very low latency may come with lower accuracy, while a distant controller may be slower and more accurate. It says local actions should be overridable by a global controller and predicted accuracy should be exposed.

Predicted accuracy is a declaration. Measured error under a defined operating envelope is evidence. Physical process behavior is an outcome. The three should never share one green badge.

Programmable devices may have constrained arithmetic, memory, timing and instruction support. A simplified controller can behave well in the central range and fail near a saturation boundary. It may use stale state during a handoff. The global override may arrive after an irreversible action. An explicit hierarchy can still oscillate if local and remote controllers use different clocks or error models.

A useful control trace joins input timestamps, calibration and validity, program/artifact identity, numeric representation, state generation, local output, predicted error, remote observation, override decision, actuator receipt and measured process response. Without that chain, a claim of “microsecond control” describes speed while hiding correctness.

The presence of an override channel does not prove override authority or effectiveness. It must be tested under congestion, partition, restart and conflicting state.

Resource sharing creates a second contract

COIN is not only a code-placement system. It is a resource-allocation system. A program consumes parser stages, tables, memory, arithmetic units, queueing, bandwidth, compute time and energy. In a shared device, one tenant's program can change another tenant's headroom even when their data remains isolated.

RFC 9817's Compute-Fabric-as-a-Service questions ask how dynamic resources enter and leave a tenant-specific fabric, how availability and usage are accounted for, and how trust and isolation policies are enforced. The virtual-network section asks about fair division, overuse, misuse, traffic injection and unauthorized traffic access. Those questions are not answered by a monthly invoice.

Reservation, admission, installation, availability, consumption and outcome need separate receipts. A scheduler can reserve capacity that the target cannot expose. A program can fit at load time and exhaust a shared table during a new flow burst. A queue guarantee can exist in policy and lose to an undisclosed higher-priority function. A usage counter can measure instructions while ignoring memory pressure or extra packet copies.

A tenant needs the versioned resource envelope promised, the target capability measured, the resources admitted, the peak and distribution consumed, contention and eviction events, and the billing transformation. The operator needs a global view that prevents local admission from making the forwarding plane fragile.

“Fair” is a policy word until the unit and loss rule are stated. Equal table cells, equal bandwidth, equal spend and equal service impact produce different allocations.

Metadata can name a path without proving execution

Service-function systems already show the value and limit of explicit context. RFC 8300 defines the Network Service Header for carrying service-path and metadata context through a service chain. Such identifiers can help state which path and context were intended.

But a path identifier is not the loaded code hash. A service index is not proof that the function processed the packet exactly once. Metadata is not proof that the target enforced the claimed permission, used current state or produced the intended effect. It is one join key in a larger chain.

The same rule applies to orchestration records. A desired-state declaration, admission event, device acknowledgement, telemetry sample and end-to-end observation should be comparable without being collapsed. If the packet outcome disagrees with the orchestrator, the orchestrator is not entitled to win by institutional status.

That is the reality-layer discipline: maps are useful precisely when they remain maps.

The minimum viable experiment

A credible trial does not begin by showing that a P4-like program can be loaded. It begins by designing divergences among request, permission, artifact, instance, state, resource and outcome.

Use at least two programmable targets with different capability profiles, one shared resource and one stateful function. Define a program that may read two fields, alter one bounded field and emit one aggregate. Produce a signed or otherwise strongly identified source/package artifact, deterministic build record and target binary. Record the admitted permission envelope and the target's effective enforcement.

Establish a baseline with known packet inputs and an independent end-to-end observer. Then test:

a valid placement and clean execution;
an old artifact under a current service name;
a target that cannot enforce the narrow permission;
state migration with an overlap window;
a duplicate invocation of a non-idempotent operation;
resource exhaustion after successful admission;
tenant contention and eviction;
local output that the global controller overrides;
lost or delayed override under partition;
rollback with residual state;
metadata claiming a function path when execution is skipped;
lawful-location or data-class constraint excluding the fastest target.

Each case must produce a joined evidence set: principal, decision, constraints, program and artifact hashes, compiler, target capabilities, device and physical location, effective permissions, state generation, reserved and consumed resources, input fingerprint, output or mutation, override, packet/application/physical observation, alarm, operator decision, rollback and residual-state result.

The trial fails if its only success metric is latency. It also fails if the evidence can be reconstructed only from one controller whose decision is under review.

The expired COIN use-case-analysis draft groups many of these research surfaces—composition, placement, dynamic operation, integration, security and system properties. It is useful evidence of the problem decomposition, not proof that the problems have been solved.

What RFC 9817 does not establish

The document does not report a named operator deployment, an implementation matrix, a common identity scheme, a verified compiler, a permission language, a state-migration protocol, a universal resource-accounting unit, a rollback method or measured isolation.

It does not prove that in-network compute reduces latency, energy or cost in a particular production system. It does not prove that distributed AI training becomes faster, that industrial control becomes safer, that privacy improves, or that a tenant receives fair resource treatment. Its examples identify opportunities and research questions.

The official reference record shows the research and standards context; the referenced-by record shows later document relationships. Neither is an adoption metric. The errata search is an editorial status surface, not implementation telemetry.

In-network computing is also not one architecture. A device inside one industrial authority domain and a multi-provider compute fabric have different principals, privacy surfaces and failure consequences. RFC 8799 is useful here: limited-domain membership, roles and boundaries need explicit, verifiable meaning. “Inside the network” is not a security property.

The strongest reading of RFC 9817 is not that a future has been standardized. It is that the old word “forwarding” no longer describes all the powers a network device may exercise.

The Switch Executed the Program. It Did Not Inherit the Right to Read, Rewrite or Decide: RFC 9817

Summary

Forty microseconds concealed the most important question

A program name is not a running instance

Placement carries a permission envelope

“Who decides?” is not an implementation detail

State turns movement into custody

Fast control can be less accurate control

Resource sharing creates a second contract

Metadata can name a path without proving execution

The minimum viable experiment

What RFC 9817 does not establish

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing