摘要

  • 发布进程 ID、消息 ID、分段号、末段标志和接收窗口，可以支持关于“接收器看见并重组了哪些传输单元”的有限结论；它们无法照亮接收器建立可见序列之前已经消失的全部事件。
  • 可信的遥测结论需要八张相互独立的收据：传输关联、分段完整性、序列连续性、来源身份、订阅语境、时间语义、路径安全和权威运行状态。

设想接收器先收到分段 0，随后是 2，最后才是 1。分段 2 的 L 位表明总数为三，接收器据此排序、拼接并恢复出一条通知。这是一次真实的协议成功，却还不是一次完整的事实证明。

当前草案 日期为 2026 年 7 月 29 日，为受控环境中的配置订阅定义单向 UDP 关联。每个未进行 IP 分片的数据报只承载一条完整 UDP-Notif 消息或一个分段，不期待发布端重传。Datatracker 页面 将它列为 NETCONF 工作组的活跃 Internet-Draft、目标状态为 Proposed Standard；历史记录 显示它历经多次修订。它尚不是 RFC。

重组只证明一个有限对象

同一消息的各分段共享 Message Publisher ID 与 Message ID。Segment Number 从零开始、不得回绕；L 位标出末段，也给出预期总数。接收器必须容纳乱序到达、丢弃重复分段、等待所需集合，再按分段号升序拼接。除分段选项外的全部选项只保证出现在首段，并不保证每段都有。

这套语法最多证明某个接收器在某组报头字段下拼出了某串字节。它不能单独证明被丢弃的同号重复分段字节完全一致，首段及其选项没有遭遇未观测替换，或分组键始终属于同一个真实发布时期。可审计收据应保留每个已接收分段及重复分段的摘要、完整的 0 到 L 集合、首段选项、重组结果摘要、超时与资源上限。“已经重组”是动作描述，不是最终判决。

草案要求双方至少支持 96 KB 通知，接收器至少支持 64 个分段；同时建议发布端少于 64 段、通常在十秒内完成重组，并绝不能超过二十秒。任一分段丢失都可能使整条消息失败，过多分段还会放大接收器资源消耗。RFC 8900 说明 IP 分片为何脆弱；应用层分段绕开了 IP 分片，却没有消除“丢一段、废整条”的放大效应。

连续序列只能从可见处开始

Message ID 从随机 32 位值起步，同一 Message Publisher ID 下逐条加一，到最大值后回绕。稳定观察时期中的缺口因此能够暴露丢失；但若一整条消息在第一个可见 ID 之前消失，序列上不会留下缺口。配置订阅生效时，接收器甚至可能尚未启动。发布进程重启、Publisher ID 重用、中继、接收器停机、回绕和接收窗口前移，都会改变“连续”的含义。

草案允许把接收器成功交付数与 RFC 8639 的发布端 sent-event-records 计数比较。发布数更大，可以支持“至少有通知未成功送达”的推断，前提是两边的订阅范围和时期一致。完整消息里的重复分段与窗口外丢弃并不计作交付失败，虽然可另设诊断计数。于是，安静的失败计数可以与重复、错配、攻击流量或被窗口提前淘汰的证据同时存在。

RFC 8639 把订阅控制与传输分开，并定义生命周期、重放和计数。这种分离是必要的：传输序列不能自动获得“订阅究竟要求观察什么”的解释权。

分组键不是身份凭证

Message Publisher ID 标识软件进程，并只保证在发布节点本地唯一。若这种唯一性无法贯穿采集域，草案要求把源 IP 也纳入来源识别；中继必须保存唯一性。这些字段适合关联，并非密码学身份。在下层网络没有认证与加密时，草案要求安全传输并给出 DTLS 配置；RFC 9147 在一个 DTLS 关联内提供认证、完整性与抗重放能力。

认证成功仍不能证明该进程有权发布这项订阅，也不能证明重启前后的身份连续，更不能证明数据来自声称的数据存储。RFC 8341 把管理授权保留为另一层控制。身份收据需要绑定 DTLS 对端与凭证时期、设备、进程、Publisher ID 唯一域、源地址与端口、中继路径、接收窗口判定以及订阅授权。

固定报头装不下完整语境

报头能够表示 JSON、XML、CBOR 或私有编码，但具体编码按订阅配置。固定报头没有承载完整的订阅目标、过滤器、更新触发、周期、抑制时间、接收器绑定和配置版本。RFC 8641 正是依靠这些差异定义 YANG-Push。若订阅在 Message ID 继续递增时发生变化，传输序列可以毫无破绽，数据意义却已经漂移。

时间也一样。事件时间、发布端发送时间、接收时间和重组完成时间属于不同的时钟边界。支持乱序分段意味着到达顺序不是内容顺序；Message ID 顺序只是某个已解释发布时期内的发出顺序，不证明设备时钟准确，也不证明受管系统中的因果关系。时间收据应写明时钟源、误差、事件时间、发送/接收/重组时间，以及生成时采用的订阅版本。

字节有效仍可能是错误证据

UDP 校验和覆盖有限的意外损坏，DTLS 可以保护并认证字节；两者都不验证 YANG 语义、单位、新鲜度或数据状态的权威性。RFC 8342 区分 running、intended 与 operational：转换、资源缺失和系统生成状态让三者无法简单合并。一条成功解码的通知可以忠实反映发布进程，却仍不是决策所需的权威现状。

最后一张收据必须来自独立观察。先把通知绑定到明确的数据存储、模型库和订阅时期，再用另一条路径核验相关设备、路由、队列、接口或业务结果。传输层回答“什么抵达了”，运行世界回答“它是否足以支持行动”。

路径负担也是完整性问题

RFC 8085 对大流量 UDP 使用作出限制，草案也只允许在受控环境部署。它要求预留容量和 QoS，建议采用 CS2、节奏控制和有限的默认速率，并监控交付失败与队列。一个完整抵达、却挤压管理流量、拖垮重组内存或掩盖队列丢包的遥测流，不能被称为完整性成功。

因此完整链条必须保留八张收据：关联、分段重组、消息连续性、认证来源、订阅与编码、时序、校验和/DTLS/速率/QoS 安全，以及权威数据存储与独立结果。后一张不能借用前一张的确定性。

来源与审查边界

规范背景包括 RFC 8639、RFC 8641、RFC 8342、RFC 8341、RFC 8085、RFC 8900 和 RFC 9147。历史审查分别是：TSVART 对 -23 的 Ready with nits、OPSDIR 对 -21 的 Has issues、YANG Doctors 对 -20 的 On the right track。它们都不是对 -26 的最新裁定。