Summary

  • RFC 9675 makes a remote manager responsible for policy while a co-resident agent monitors state, authorizes actions and runs Controls locally, including during long disconnection.
  • A DTNMA Control has no RPC-style return code. Reports may be queued, replaced, expired, delivered out of order or combined into one end-state account for several Controls.
  • Defensible management keeps separate receipts for objective, encoding, custody, agent receipt, authorization, fresh preconditions, execution, recovery, report generation, queue history, reconciliation and a later time-bounded observation.

The green command was older than the state it described

A control room sends a policy update to a device that will not have a reliable return path until the next contact window. The message enters a store-and-forward network. Hours later the dashboard shows that the policy was delivered. Later still, a compact report arrives and the command turns green.

The display is tidy. The history behind it is not.

Before the message arrived, the device detected a local condition and entered a safe mode. The new policy was accepted, but one Control in its macro failed a precondition because a sensor value was stale. A local recovery rule restored an earlier configuration. The eventual report summarized the end state after several Controls; it did not map one-to-one to the remote instruction. By the time the report reached the control room, another autonomous rule had changed the device again.

Nothing in this hypothetical sequence contradicts delay-tolerant management. It exposes what synchronous management habits hide. “Sent”, “delivered”, “authorized”, “executed”, “reported” and “true now” are different events.

RFC 9675 provides the architecture for operating through that difference. It does not give a dashboard permission to erase it.

A logical architecture for the missing round trip

RFC 9675 is the November 2024 Informational RFC for the Delay-Tolerant Networking Management Architecture, or DTNMA. It is an IETF-stream document approved through the IESG and represents IETF community consensus. It is not an Internet Standards Track specification.

That status is only the first restraint. The RFC describes a logical, informational architecture: components, enabled behaviours and use cases. It deliberately does not specify a functional design or complete interfaces. It does not require Bundle Protocol, even though BPv7 is a natural transport where intermittent connectivity exists. It leaves transport choice, naming, addressing, routing and communications security outside its own scope.

The scope matters because the architecture is easy to mistake for a product promise. RFC 9675 does not prove that a named device implements DTNMA, that a command reached it, or that a secure bundle was authorized to alter an application. It describes how management roles must change when timely end-to-end exchange, stateful sessions and synchronous human participation cannot be assumed.

In a challenged network, devices can sleep, links can be one-way, bandwidth can be asymmetric and infrastructure such as DNS or a certificate authority can disappear for long periods. Delay can be measured in days. A contact can end before one round trip completes. The ordinary model—query, wait, receive a return code, then act—becomes an unreliable foundation.

DTNMA responds with self-operation. The device determines reporting schedules, evaluates local state, selects operational configuration and performs error discovery and mitigation without requiring a remote operator to remain in the loop.

The manager configures the operator that actually acts

RFC 9675 divides responsibility between a DTNMA Manager and a DTNMA Agent. The Manager is the remote-operator role. It accepts desired policy from managing applications, encodes that policy into a standard expression, aggregates messages and addresses them for delivery.

The Agent is the local-operator role associated with the managed device. It accepts policy directives, gathers and fuses data, reports performance, handles errors, validates data and runs local control. When connectivity to the Manager disappears, the Agent remains beside the applications and services it manages.

This produces two management tiers. One tier manages the Agent's configuration. The other operates the device through the Agent. A remote objective therefore does not jump directly into device state. It changes the policy surface on which local rules, current inputs, authorization and Controls operate.

Even when a connection is timely, control remains local. RFC 9675 says the Agent evaluates and runs a received Control as part of local autonomy. Receipt becomes a stimulus; the response is local execution. There is no continuing dependency on the session that carried the request.

This is not a loss of remote authority. It is a more precise allocation of authority. The Manager defines an objective or policy. The Agent applies that policy under conditions the remote side may not be able to observe in real time. An audit needs both records.

A Control is not an RPC with a very long timeout

DTNMA calls the parameterized procedures run by an Agent Controls. A Control can arrive from a Manager or be selected by a local rule. A macro is an ordered sequence of Controls.

The RFC makes an unusually useful distinction. Controls resemble remote procedure calls because they invoke parameterized functions. They do not have a return code. A return code implies a synchronous relationship between caller and procedure, and that relationship may not exist across a challenged network.

Stretching an RPC timeout does not repair the model. A procedure can start after the remote issuer has lost contact. The device can evaluate a different state from the state assumed when the objective was created. A macro can fail halfway. A local rule can handle the failure before the remote operator even knows execution began.

Control success or failure becomes part of Agent state. That state can trigger more rules. Certain failures can leave a device in an undesirable condition, so RFC 9675 calls for Control-specific recovery such as rollback or safing. The operational result is a graph of local actions, not one return value travelling slowly home.

The receipt should therefore record the exact policy version, Agent receipt time, authorization decision, inputs and their freshness, precondition results, every Control and macro step, competing updates, local error handling, rollback or safe-state transition, and the state observed after those actions. A generic “completed” flag is a lossy compression of the very history the architecture needs.

Open-loop policy breaks the command-response pairing

Managing applications can wait for a response before issuing another command, or they can operate open-loop and issue new policy without one. In RFC 9675's terms, a closed loop may close in milliseconds, hours, days or years.

There also need not be a one-to-one mapping between command and response. One report can represent the end state after multiple Controls. A Control can contribute to several reports. A report can omit an association with the Control that caused it. Queue policy can remove a report before it is ever sent.

This makes correlation a first-class engineering problem. A message identifier can establish which object moved through custody. It cannot by itself establish which later state resulted from that object. A policy identifier can name intent. It cannot show that the policy remained applicable when it arrived. A Control identifier can name a procedure. It cannot show which local inputs the procedure used or what subsequent recovery changed.

A robust ledger connects, without merging, the remote objective, encoded policy, custody chain, Agent authorization, execution trace, observations, report instance and current outcome. When one report summarizes several Controls, the ledger must preserve that many-to-one relationship. When several managers sent policy during different partitions, it must preserve the conflict and the local rule that resolved it.

Arrival order is not event order

Reports in DTNMA are generated as a function of local state, independently of the connection to a Manager. They can wait in storage until connectivity returns. They can travel along different paths. Retransmission can delay one report behind another. RFC 9675 directly warns a managing device not to infer meaning from receive order.

That warning should reach the interface. Sorting reports by the time an API received them can invent a false trajectory. A warning may appear after a recovery report even though it happened first. A bulk upload can place yesterday's state beside a current summary. A slow path can make an older reading look like a regression.

Every report needs a generation time and enough context to interpret that time. Receive time remains useful for transport operations, but it is not a substitute. Reconciliation should use event time, schema, Agent identity, policy and rule versions, and known dependencies. When clocks are uncertain, the uncertainty belongs in the record rather than being hidden by a total ordering the evidence cannot support.

Storage policy creates a second gap. Queued reports consume finite resources. An implementation may treat a report as expired, replace it with a newer one or remove it without transmission. Silence therefore has several meanings: nothing triggered, policy suppressed reporting, a report is still queued, a report expired, authorization prevented delivery, connectivity failed, or the Agent itself is unavailable.

No one of those meanings can safely be chosen from silence alone.

A summary is evidence about a rule, not all of its inputs

Local data fusion is central to the architecture. An Agent can turn samples and counters into compact products that drive rules and reduce storage and transmission. That is necessary when a contact window cannot carry the raw history.

The compression is also an epistemic boundary. A minimum, maximum, average, anomaly score or end-state report is a new object created by a particular fusion rule. It does not retain every input unless the implementation separately preserves them. A changed fusion definition can make two similar reports non-comparable. A correct summary can omit the intermediate failure that matters to a later investigation.

RFC 9675 does not prohibit raw retention. It notes that raw data can help debug complex interactions and improve outcomes. Operators should decide which raw observations are indispensable before storage pressure makes that decision for them.

The same discipline applies to freshness. An autonomy model assumes its inputs represent actionable device state. If a value has not refreshed within the relevant period, the Agent can infer the wrong condition. RFC 9675 therefore expects an indicator that a value is fresh enough to represent current state.

Freshness is not permanent. A value can be fresh when a rule runs, historical when its report is generated, and obsolete when the report reaches the Manager. A signed report preserves origin and integrity under its security design; it does not make the measurement current.

Many managers create an authority history

Challenged topology can expose a device to different Managers in different partitions. RFC 9675 supports many-to-many associations and allows “control from” and “reporting to” relationships to vary independently.

That flexibility avoids treating one permanently reachable control centre as a fact. It also means authority must be explicit. Which Manager may alter which application? Which receives which reports? What happens when two authorized policies conflict? Which objective survives reconnection?

The RFC expects authorization services and notes the need for conflict-resolution mechanisms. It does not impose one universal constitutional order. Allowlists, blocklists and key-based infrastructures are possible tools. The local implementation still needs precedence, scope, expiry and safe-state rules.

A later report from one partition should not silently erase an authorized action from another. Reconciliation needs the Manager mapping in force, the local authorization result, the policy versions compared and the rule that won. Otherwise a vendor's preferred Manager can become the de facto authority merely because its reports arrive at the dashboard first.

Security protects messages without collapsing the layers

RFC 9675 places security in at least two areas: validity and access for data-model elements, and protection for exchanged management information. Agents and Managers need verification and authorization. Messaging is expected to use secured transport.

Because exact security mechanisms are outside the logical architecture, the evidence claim must remain bounded. Authenticated custody can show that a protected message passed between identified parties under a particular trust policy. It does not prove that the Control was authorized for the target application. Authorization does not prove its preconditions were fresh. Execution does not prove the objective was achieved. A confidential report can still be stale, incomplete or delivered out of order.

The architecture is stronger when these limits remain visible. Security then protects each receipt instead of turning one receipt into a universal verdict.

The receipt ladder for asynchronous control

Begin with the objective: requested state, scope, authority, decision time and expiry. Preserve the Manager's exact encoding, target Agent set and aggregation context. Record store-and-forward custody without equating custody with delivery.

At the Agent, record exact receipt time and bytes, authorization, fresh input state, resource limits and competing-update checks. Then retain every Control or macro step, recovery and safing action. Preserve raw observations needed to interpret fused values.

For reporting, record schema and rule versions, generation time, associated Controls where known, queue insertion, replacement, expiry, removal and transmission. At the Manager, reconcile by event context rather than arrival order. Finally obtain a new time-bounded observation for any decision that genuinely depends on current state.

This ladder does not try to recreate synchronous management. It makes asynchronous management auditable on its own terms.

Informational architecture, observable adoption

RFC 9675 is an IETF consensus document, but it remains Informational and logical. Publication does not prove adoption, and architecture diagrams do not make a device autonomous. Adoption becomes observable through deployed Agents and Managers, rule and Control definitions, report schemas, queue policies, authorization records, execution histories and actual device behaviour.

That is where Heng Lu's minimum-specification and running-code lenses are useful. A shared architecture can name the roles and boundaries while implementations make localized choices about transport, safety and authority. The written policy remains a coordination layer. The local Controls that actually run form another layer. Reports, dashboards and physical outcomes are further layers again.

The leadership mistake is to collapse them because the network is hard to observe. The challenged link does not lower the evidence standard. It makes the chain of custody, execution and time more important.

Sources