摘要

  • RFC 9675 把远端意图与本地执行分层：Manager 编码策略，Agent 在设备一侧检查权限、数据新鲜度和运行条件，再执行 Control。
  • DTNMA 的 Control 没有同步 RPC 式返回码；报告可能排队、过期、被替换、乱序到达，也可能用一份结果概括多个动作。
  • 可审计的结论必须分别保存目标、编码、托管、接收、授权、前置条件、执行、恢复、报告生成、队列历史、对账与后续当前观测。

一个绿色图标掩盖了两次相反的动作

设想远端控制台向一台间歇联网设备发出宏：第一步切换配置，第二步启动服务。消息在存储转发网络中经过数小时后抵达，控制台随即把状态标为“已送达”。

设备一侧的实际历史更复杂。Agent 接受了宏，完成第一步；第二步发现所需观测已超过新鲜度窗口，于是判定前置条件不成立。预先声明的恢复规则回滚第一步，并把设备置于安全配置。Agent 生成了一份概括报告，但报告仍在等待下一个联络窗口。与此同时，控制台只有一个绿色的传输标志。

这是用于分析的假设场景，不指向任何真实设备或事故。它揭示的却是 RFC 9675 的核心：在延迟容忍管理中，消息存活下来并不等于目标状态存活下来。送达证明了一段传输历史，不能替代授权、执行、恢复和当前观测。

如果产品把这些层压缩成“成功”，它不是简化了网络，而是删掉了决定意义的证据。

这是一份逻辑架构，不是部署证明

RFC 9675 于 2024 年 11 月发布，题为《Delay-Tolerant Networking Management Architecture》。它属于 IETF 流，由 IESG 批准，代表 IETF 社区共识；文档状态为 Informational，而非 Standards Track 规范。

文档定义的是逻辑和信息架构：有哪些角色、这些角色允许哪些行为、哪些用例需要被支持。它没有给出完整功能设计，也没有规定所有组件接口。它不强制采用 BPv7；IPv4、IPv6、TCP、UDP 或其他承载同样不是该架构的必选项。命名、寻址、路由和通信安全由实际运行网络提供。

这些边界必须保留。引用 RFC 9675 不能证明某台设备部署了 DTNMA，不能证明某条消息被目标 Agent 接收，更不能证明某个 Control 已获授权或某个物理结果已经发生。架构文字给出共同语言；实现、配置和运行记录才构成采用证据。

文档处理的约束却非常现实：端到端连接可能数天不存在，链路可能单向或高度不对称，设备可能休眠，DNS 或证书服务可能长期不可用，一次联络甚至不足以完成一个往返。依赖持续会话的“查询—等待—返回码”模型在这里无法成为管理前提。

Manager 管的是本地操作者，而不是直接改写现实

DTNMA Manager 是远端操作者角色。它接收管理应用提出的目标，把目标编码成标准表达，聚合消息并为目标 Agent 寻址。DTNMA Agent 是设备一侧的本地操作者。它收集与融合数据、验证信息、执行授权、运行 Control，并在出错时采取本地措施。

因此存在两层管理：一层配置本地操作者，另一层由本地操作者运行设备。远端目标首先改变 Agent 可以依据什么政策行动；它不会越过 Agent，直接成为应用状态或物理状态。

即使连接恰好及时，Control 仍在本地被评估和运行。收到消息只是触发因素，承载消息的会话并不是执行所依赖的持续控制通道。远端拥有提出目标的权力，本地拥有根据眼前条件决定如何落地的责任。

这不是削弱远端权威，而是把权威的边界写清楚。远端记录“希望发生什么以及授权范围”，本地记录“在何种事实下允许并实施了什么”。审计需要同时看到两边。

Control 不是把超时设成几天的 RPC

Control 是 Agent 执行的参数化预定义过程，它可以来自 Manager，也可以由本地规则选中。宏则是有序的多个 Control。RFC 9675 特别指出，Control 没有返回码概念，因为返回码暗含调用者与被调用者之间的同步关系。

把 RPC 超时从数秒延长到数天并不能修复模型。目标可能在执行前已过期；本地输入可能已经陈旧；其他更新可能正在改变同一资源；宏可能在中间步骤失败。失败会成为 Agent 的本地状态，并可能触发另一条规则、回滚或安全化处理。

一枚“完成”标记无法表达这样的动作图。真正有用的收据包括精确策略版本、接收时间、授权规则、输入及其新鲜度、前置条件、每一个宏步骤、竞争更新、错误处理、回滚以及动作后的观测。

即使所有步骤按计划执行，也只能证明执行历史。目标是否实现，还需要结果观测；结果是否仍然存在，还需要一个更晚且有时间边界的观测。

一份报告可能属于三个 Control

管理应用可以闭环等待，也可以在没有响应时继续发出新策略。RFC 9675 允许开放环路，因为闭环可能需要毫秒、数小时、数天甚至数年。

命令与报告并非天然一一对应。Agent 可以用一份报告描述多个 Control 之后的最终状态；一个 Control 也可能影响多份报告；报告甚至可以不标注触发它的 Control。生成过的报告还可能在发送前被队列策略移除。

因此，消息 ID 只能确认哪个对象进入了托管链，不能说明后来哪个状态由它造成。策略 ID 标识意图，不能证明意图到达时仍适用。Control ID 标识过程，不能说明实际使用了哪些输入、之后又发生了什么恢复。

证据系统应把远端目标、编码表达、托管历史、Agent 授权、执行轨迹、观测、报告实例和后续状态相互关联，却不能把它们合并成一个万能状态。如果一份报告概括三个 Control，就应明确保存多对一关系，而不是让界面把它误认成最后一条命令的回执。

抵达顺序不是事件顺序

DTNMA 报告依据本地状态生成，与 Manager 当时是否在线无关。它们可以留在存储中等待连接，经不同路径转发，并因重传而改变抵达次序。RFC 9675 明确提醒管理端不要从接收顺序推断意义。

每份报告都需要自己的生成时间、Agent 身份、模式版本和状态上下文。API 接收时间仍有传输运维价值，但它不是观测时间。时钟不确定时，应把不确定性保留在记录中，而不是为了画出整齐曲线制造一个虚假的全序。

有限存储还会制造证据缺口。报告可能过期、被较新的报告替换，或者在从未发送的情况下被删除。沉默可能意味着没有触发，也可能意味着触发后被策略抑制、仍在排队、已经过期、未获发送权限、目标映射改变、传输中断或 Agent 不可用。仅凭沉默不能选择其中任何一种解释。

融合结果是新对象，不是原始事实的无损压缩

Agent 可以把样本和计数器融合成最小值、最大值、平均值、异常分数或最终状态。这对于短暂联络和有限存储至关重要。但融合产物是由某一规则、某一版本生成的新对象，不自动保留全部输入。

融合规则变化后，看似同类的两份报告可能不可比较。一个正确的最终状态摘要也可能省略对事故复盘至关重要的中间失败。RFC 9675 没有禁止保留原始数据，并指出原始数据可帮助调试复杂交互。哪些观测必须留存，应在存储压力到来之前决定。

新鲜度同样不能永久继承。一个值在规则运行时可能足够新，在报告生成时已经成为历史，在报告抵达时则完全过时。签名可以保护来源和完整性，但不能把旧测量变成当前状态。

多个 Manager 让权限本身也有时间线

受限网络的不同分区可能让设备在不同时间接触不同 Manager。RFC 9675 支持多对多关联，并允许“接受谁的控制”和“向谁报告”分别配置。

这种灵活性避免假定一个永远在线的中心，同时要求实现明确权限范围、优先级、有效期和冲突处理。重连时需要知道当时的 Manager 映射、各策略版本、Agent 的授权结果以及最终胜出的本地规则。某个分区的报告先抵达，不能让该分区的 Manager 事后自动变成最高权威。

安全机制也必须按层解释。认证托管能证明受保护消息在特定信任政策下流转，不能证明 Control 对目标应用有权限。授权不能证明前置条件新鲜。执行不能证明目标实现。加密且签名的报告仍可能陈旧、不完整或乱序。

异步控制需要十三级收据

第一层记录目标：所求状态、范围、权威、决策时间和失效时间。第二层保存 Manager 的精确编码、Agent 目标集与聚合上下文。第三层是存储转发托管，第四层是 Agent 对精确字节的接收。

随后依次记录授权、带新鲜度的前置条件、每个 Control 和宏步骤、恢复或安全化、原始与融合观测、报告生成、队列中的插入替换过期删除与发送、Manager 侧按事件上下文进行的对账。最后一级才是为当前决策取得的独立、较新、受时间约束的结果观测。

这些层级不是为了把异步系统伪装成同步系统。它们让异步系统能够按自己的真实运行方式接受审计。不能从前四级直接跳到“现在就是如此”，也不能把报告生成或入队当作同步确认。

从共同规范到可观察采用

RFC 9675 的 Informational 和逻辑属性不是弱点，而是它的正确边界。它给出在受限环境中协调角色的最小公共框架，具体系统则必须用运行中的 Agent、Manager、规则、Control、报告模式、队列政策和执行历史证明采用。

这与 Heng Lu 对“最小初始规范”和现实层级的区分相呼应。文字政策是一层，本地可执行规则是一层，报告和仪表盘又是一层，设备或环境的实际结果仍是另一层。把这些层压扁，会让符号上的绿色取代现实中的未知。

领导者需要接受的不是更低的证据标准，而是更长的证据链。网络越难及时观察，时间、权限和因果记录就越重要。

来源