摘要

  • draft-ietf-netmod-yang-anydata-validation-00 设想从数据节点在编码中的身份出发，到 RFC 8525 YANG Library 中寻找 anydata 子树对应的 schema。
  • anydata-complete 要执行对应 schema 的全部约束，anydata-candidate 则刻意不执行 constraint checks。两者都不能单独证明来源、授权、运行状态、转发或业务结果。

一条接口计数器进入分析系统，校验器返回“通过”，汇总程序于是继续。问题在几周后才暴露：校验器使用的模块修订版、feature 集合和设备当时公开的 YANG Library 并不一致。绿色结果没有造假，只是从来没有说明它验证的是哪一个命题。

这正是 Validating anydata in YANG Library context 修订版 00 留下的有用问题。YANG 1.1 的 anydata 用来承载可以由 YANG 建模、但在容器模块设计时尚不知道具体模型的内容。数据存储过滤器、编辑操作、实例数据、订阅通知和 YANG-Push 都可能借用这种开放容器。灵活性带来的代价是：消费者收到节点后，应该用哪一套 schema 判断它？

草案提出一条查找链。XML 用本地名称与模块命名空间标识节点；JSON 使用节点标识符，必要时加模块限定；CBOR 可以依靠 SID、SID 差值、带命名空间的名称或 instance-identifier。只要编码留下足够身份信息，校验器就可尝试在 YANG Library 中找到相应数据节点。

“找到”并不是一次简单的字符串匹配。RFC 8525 把 datastore 关联到 schema，把 schema 定义为若干 module-set 的并集；模块条目还包含 revision、submodule、启用的 feature 与 deviation。content-id 在 Library 信息变化时必须变化，但它是实现自定义标识，并非全球统一的内容哈希。节点如果位于 schema mount 之下，还要记录挂载路径和局部上下文。

complete 与 candidate 不是两个名字相近的开关

修订版 00 提出两种可选模式。anydata-complete 要检查子树，并要求它遵守相应 schema 中的全部校验规则；anydata-candidate 不执行约束检查。这个命名借用了 RFC 7950 第 8.3.3 节的时序差异：running 或 startup 的约束在编辑或复制操作结束时执行，而 candidate datastore 可把执行推迟到 commit 或 validate。

因此，complete 通过只能说明：在已指明的编码、Library 快照、模块集合与校验器版本下，该实现没有发现其所执行规则的违规。candidate 通过只说明候选路径接纳了结构，不能冒充完整约束结论。把两者都写成“YANG 校验通过”，会抹掉草案最重要的证据等级。

失败也有边界。它可以指出类型、范围、must、when、列表数量、未知节点或上下文解析的问题，却不能自动回答责任归属。错误可能来自发送端缺陷、转码器改写、消费者选错 Library，或校验器自身差异。恰当动作是隔离、保留证据并调查，而不是凭一次失败宣布攻击或设备故障。

草案举出的风险很直观：某节点的软件缺陷让 YANG-Push 通知带来一个负数接口字节计数，分析组件据此算错总流量，进而影响计费或容量规划。完整 schema 校验可以捕捉其中一类错误；但一个非负数依然可能过时、缺失、重复、来源错误，或根本不是业务流程所假设的接口。

可复核的产品是凭据，而不是对勾

一份可用凭据应保存 payload 哈希、采集时间与编码，保存解析出的节点身份、YANG Library content-id 和 Library 快照，并列出 datastore、schema、module-set、模块及子模块 revision、feature、deviation 和 mount 上下文。最后还要记录校验器名称、构建版本、参数、所选模式、诊断与处置。

这些字段决定旧结果能否重放。启用或关闭一个 feature，节点可能出现或消失；deviation 会改变约束；mount 会改变查找起点；校验器升级可能改变解析行为。同一 payload 在两个时间点结论不同，首先说明上下文发生变化，不必然说明原始字节被篡改。

草案把处置权留给消费者：非合规消息可以被忽略、记录或触发告警。这个克制很重要。校验器只产生一个有限判断，哪些错误必须阻止自动化、哪些允许重试、哪些交给人工，应该由承担后果的数据所有者事先决定。

当前状态不支持“即将成为标准”的叙述

Datatracker 把 2025 年 12 月 2 日列为最新 revision 日期；历史记录显示修订版 00 当天成为 WG 版本。正文于 2026 年 6 月 3 日到期。当前页面的状态是 Expired Internet-Draft、Expired & archived、Dead WG Document 与 IESG Expired，结构化 Intended RFC status 为 None。

草案页眉曾写 Intended status: Standards Track，但这是历史稿件标签，不是 IETF 批准，也不能覆盖当前状态。文档没有 IANA 请求，安全分析仍未完成，Datatracker 也没有列出 shepherd。

实现状态一节指向 libyang 的一个 anydata-candidate 分支，并要求正式出版前删除这一节。分支只能说明有人尝试过一条代码路径，不能证明合并、独立实现、互操作或生产部署。本文不把它提升为运行事实。

schema 合规不能替相邻证据说话

RFC 8342 区分 running、intended 与 operational；值符合 schema，不等于设备已经应用。RFC 8341 单独处理访问控制；数据结构合法，不等于 NACM 已授权。订阅与 YANG-Push 规范处理选择和投递；一个合法子树不能证明事件无丢失、无重放、顺序正确或未在上游被改写。

身份、传输完整性与保管链需要自己的记录。设备计数器、FIB、抓包、远端观测与财务对账也回答不同问题。机器可读的绿色对勾，不应因此获得跨越这些层次的发言权。

修订版 00 最值得留下的，不是一个叫“有效”的新徽章，而是把原本不透明的 anydata 子树放进明确上下文里测试，并诚实保留两种强度不同的结论。只要上下文可复核，校验能缩小问题；一旦上下文被丢弃，对勾就会变成无法追责的承诺。

来源

草案记录：修订版 00、Datatracker 当前状态与历史记录。

技术边界：RFC 7950、RFC 8525、RFC 8342、RFC 8341、RFC 8528、RFC 8639与RFC 8641。

分析框架：Minimum Initial Specification、On Reality Layers与Running Code Primary。