Summary

  • draft-ietf-netconf-yang-notifications-versioning-14 允许订阅者用模块修订版或兼容的语义版本约束 YANG-Push 订阅，并为订阅开始、订阅修改通知增加模块上下文。
  • 修订版、可选版本与 yang-library-content-id 描述的是发布者报告的模式环境；它们不证明途中记录的归属、接收端解码器、存储映射和下游模型在同一时点完成切换。
  • Daniel Kade 建议保存一份遥测模式交接记录，把通知、前后模块集指纹、旧版最后记录与新版首条记录、队列和重放处置、测试、下游暂停、责任人及关闭依据连在一起。这不是 IETF 要求。

六个都正确的时间

一次升级至少留下六个时间：设备完成软件切换的时间，YANG 库改变的时间，状态变更通知里的 eventTime，采集器收到通知的时间，新解码器生效的时间，以及自动化重新获准使用数据的时间。

这些时间可以全都准确，却彼此不同。

若运维报告只保留一个“切换完成”，它实际上是在替其中一个系统取得整条链的解释权。发布者的时钟不能说明接收队列是否清空；通知抵达不能说明工作进程是否加载了正确模式；数据库写入成功也不能说明告警阈值仍有相同含义。

治理问题不在于哪个时间是假的，而在于把局部事实压缩为全局结论时，没有说明由谁、依据什么完成了这次压缩。

第 14 版解决了什么

现有流程有一个实际缺口。按照 RFC 8641 的运行方式，YANG-Push 接收端在收到订阅状态变更通知后，可能需要查询发布者的 ietf-yang-library，才能判断订阅所引用模块的语义是否改变。通知与查询分离，既增加延迟，也可能使查询看到比通知事件更晚的库状态。

第 14 版定义 ietf-yang-push-revision。订阅者可以指定模块名称，并要求某一修订版或语义版本。如果服务器不支持请求，应返回 RPC 错误。配置型订阅的版本约束一旦与 YANG 库不再匹配，发布者不得继续发送通知。

草案还扩展 subscription-started 与 subscription-modified，让它们携带相关模块名称、修订版、存在时的语义版本，以及可选的 yang-library-content-id。接收端因此不必仅凭未变的订阅 ID 推断语义环境未变。能力模型也可表明服务器是否支持这项扩展。

这是一项重要改进。它让订阅政策可以拒绝不合要求的模式，让运行中的模式变化更容易被观察。草案并没有声称这条通知能同时刷新采集器、数据队列、数据库和决策系统。那是合理的范围边界。

内容标识符不是通用指纹

yang-library-content-id 表示某一服务器当前 YANG 库信息，并且由实现自行定义。它发生变化，说明服务器上有一个或多个模块改变了；发生变化的模块不一定落在这条订阅的选择路径内。

因此，不能把它改称“本次遥测模式的加密哈希”。运维方可以对实际取得的模块字节、导入依赖、feature 与 deviation 计算自己的模块集指纹，但这是一件不同来源、不同范围的证据。保留两者比把两者混成一个字段更可靠。

通知中的模块列表更贴近订阅内容，但它仍不证明接收端解析了完全相同的依赖组合。采集器可能装有同名修订版，却启用了不同 feature；也可能正确加载模式，却继续使用旧的列映射。一个语法有效的值，仍可能因单位、范围或存在条件变化而被下游错误解释。

发布者诚实报告身份，不等于消费者已经验证结果。

通知不会自动形成数据栅栏

假设 A、B 在旧模式下产生，C 是变更通知，D 在新模式下产生。逻辑图上顺序是 A-B-C-D。现实中，控制通知与遥测数据可能经过不同队列，接收端可能看到 A-C-B-D；重放可能在 D 之后送来 B；旧工作进程可能在新工作进程处理完 D 后才完成 B。

C 即使经过认证、时间也准确，仍不能自动决定 B 应使用哪个解码器。还需要运输顺序、队列状态、工作进程分配和解码结果的证据。

协议扩展不必成为跨所有系统的分布式事务。把标准保持在可实施的范围内是优点。责任应落在使用这条通知作出“已完成”判断的运营者，而不是通过扩大通知含义来逃避。

“兼容”也要注明主语

传统 YANG 修订模型期望保持兼容；YANG 语义版本机制也能明确标记非向后兼容的变化。这些信号有助于选择模块并制定订阅政策。

具体消费者还有自己的故障面。一个被认为兼容的新增节点可能触发解析器缺陷；feature 或 deviation 的组合可能与测试环境不同；数据类型虽然可解析，旧的容量计算却可能错误地截断；新字段也可能被静默忽略。

所以至少要区分三件事：模块作者怎样标记变化，订阅政策是否接受，特定消费者是否通过了用途相关的测试。把三者都写成“兼容”，就会抹去实际承担风险的人。

版本不匹配后的沉默

草案规定，配置型订阅要求的修订版或版本与发布者 YANG 库不匹配时，不得发送通知。这条规则保护订阅者，避免发布者在不满足明确约束时照常输送数据。

但从外部看，沉默还有其他原因：on-change 订阅期间没有变化、传输中断、采集器停机、访问权限改变，或过滤器已经没有匹配项。若监控界面把最后一个值继续显示为“稳定”，版本保护会被误读为空闲。若每次沉默都被认定为模式故障，又会制造假告警。

交接记录需要保存当时有效的到达预期、观察到的停止条件、排除其他原因的证据，以及谁批准恢复。原因不明时，应冻结高后果用途，而不是替空白编写故事。

一份不复制遥测的交接记录

这份记录不需要保存第二套完整数据，只需把不同主体控制的关键事实接合起来：

  • 发布者身份、订阅 ID、精确 XPath 或子树选择，以及请求的修订版/版本约束；
  • 服务器前后的 content ID，以及分开保存的本地模块集指纹、导入依赖、feature 和 deviation；
  • 认证后状态通知的哈希、发布事件时间、接收时间与处理时间；
  • 能证明由旧模式正确解码的最后一条，以及由新模式正确解码的第一条；
  • 序列、重放、重新同步证据，队列、丢弃、隔离与再处理区间；
  • 解码器和存储映射版本、测试样例、失败与变化节点的处理规则；
  • 暂停、重算或经例外放行的告警、自动控制、报告与模型；
  • 决策责任人、剩余不确定性、回滚目标和关闭证据。

“最后”和“第一”应限定为采集器能够证明的记录，不应冒充发布者真正产生的边界。如果传输证据无法填平两者之间的距离，记录就应保留这段距离。

安全通道不替代语义验证

第 14 版把可写的版本政策节点视为敏感资源，要求 NETCONF/RESTCONF 使用安全传输、双向认证，并通过 NACM 限制访问。未经授权地更改约束，确实可能中断数据流或迫使系统进入意外的模式环境。

身份认证与完整性保护能够说明谁参与、消息是否被改动。它们不能证明旧队列已经清空、新解码器已经正确加载，或业务规则仍然有效。把这些结论附加到认证证据上，是让安全层替它从未观察的系统背书。

成熟的做法是在收到变化后启动有边界的暂停：取得并指纹化精确模块集，跑解码测试，核对队列与重放，比较前后投影，然后按用途逐一放行。若变化只发生在与过滤器无关的模块，关闭可以很快；若遥测直接驱动自动控制，证据门槛应更高。

草案让模式变化可见。交接记录让恢复决定可追责。

信息源