摘要

  • draft-ietf-netmod-yang-xml-00 集中描述 YANG 数据的 XML 表示：元素名与命名空间、列表顺序、类型值、元数据接口，以及 identityref 和 instance-identifier。
  • XML 可解析、schema 验证成功或 canonical bytes 相同，只能回答表示层问题；默认值是否生效、用户顺序是否保留、服务器是否接受操作、datastore 是否改变和业务结果是否成立，都需要另一份回执。

设想变更窗口前，自动化平台把两份 XML 备份判为相同。第一份使用默认命名空间，第二份使用前缀；空白和属性顺序也不同。规范化工具输出同一摘要，于是差异检查变绿。真正下发时，一台设备按 trim 隐去默认节点，另一台保留显式默认值；一条用户排序的规则又被工具按字母重排。XML 工具没有出错，错误的是组织把它的结论提升成了运行状态结论。

2026 年 6 月 8 日发布的 XML Encoding of Data Modeled with YANG 第 00 版，拟走 Standards Track，目标是把原来置于 RFC 7950 的规范性 XML 编码说明移出并集中定义。它覆盖配置数据、状态数据、RPC/action 参数与通知。不过它仍是工作中的 Internet-Draft，将于 2026 年 12 月 10 日到期，IANA 和安全考虑章节仍写着 FIXME。这是一条正在形成的表示契约，不是实现或安全成熟度证明。

前缀不是身份，命名空间才参与身份

草案规定，YANG 数据节点实例编码为 XML 元素；本地元素名等于节点标识符，命名空间来自定义该节点的模块。顶层元素必须建立命名空间，augment 来自另一模块的子节点必须切换到对应命名空间。

因此 <foo xmlns="urn:example:foo"/> 与使用任意前缀的同一展开名可以等价。文本比较会产生假差异，但随意改写前缀也可能制造假一致：必须同时保留 prefix 到 namespace URI 的绑定。

值内部也可能带名字。identityref 指向带命名空间的 identity，同一 identity 可以用不同局部前缀表示。instance-identifier 中每个节点名都必须显式带前缀，而这些前缀仍只在当前实例有效。要判断它指向什么，需要相应 schema 和数据树；字符串长得规范，并不证明目标节点存在。

XML 顺序不是单一规则

普通 container 的子元素通常可任意排列；RPC/action 的输入输出参数则按 schema 定义顺序编码。list 的 key 必须先出现。对于 list 与 leaf-list，ordered-by user 要保留用户顺序，system ordered 的顺序由实现决定，条目还可能与兄弟元素交错。

这让“一律排序再比较”变得危险。它确实能消除无意义的序列噪声，也可能把访问控制、优先级或 first-match 规则中真正有意义的顺序抹掉。审计必须保存原顺序，并由具体 YANG 节点的 ordered-by 规则决定哪些差异可以忽略。

缺席的节点也可能正在发挥作用

第 00 版草案没有定义 NETCONF 默认值基本模式。默认值何时生效由 RFC 7950 的 YANG 规则决定，服务器怎样报告默认数据由 RFC 6243 决定。RFC 7950 要求：默认值在 use 时，服务器必须在操作上像节点存在那样行事；when 或 if-feature 为 false 时，默认值又可能不生效。RFC 6243 允许 report-all、trim、explicit，也允许请求 report-all-tagged。

所以 XML 回复里没有一个 leaf，不能直接推出有效数据树里没有这个值；一个 leaf 显式等于 schema default，也不能说明是谁设置、是否存储或如何生效。比较之前必须说明目标是线上的 XML、存储配置、带生效默认值的 accessible tree，还是以某种 with-defaults 模式取回的完整展开视图。

XML 规范化没有承诺 YANG 语义

W3C Canonical XML 1.1 处理字符编码、属性顺序、命名空间声明等物理表示差异，便于摘要和签名。该规范同时明确：通用 XML 算法无法覆盖应用特定的等价规则。不同 canonical forms 仍可能被应用视为等价；相同 canonical form 也没有自动取得外部应用语义。

YANG 的规则正位于外部：模块 revision、feature、deviation、类型 lexical/canonical form、默认值、顺序、must/when 约束和引用解析。XML C14N 不会选择 schema，不会补全 YANG 默认节点，也不会验证 leafref 或 instance-identifier 的目标。

RFC 8525 的 YANG Library 可以公布服务器声称支持的 schema 集，但声称与进程实际加载仍需对照。RFC 8528 又允许同一个 mount point 的不同实例使用不同 mounted schema；把一个子树脱离 mount 实例保存，元素名相同也可能失去解释语境。

元数据和不透明子树不能被悄悄丢弃

草案允许 XML attributes 承载特殊用途信息，并把 YANG metadata 的定义交给 RFC 7952。一个只保留普通元素、删去“不认识属性”的中间层，可能留下可验证的 XML，却丢掉 origin、时间或其他 annotation。此时正文数据没有变，证据含义已经变了。

anydata 的内容模型在运行时可能未知，未知时无法保证转换到其他编码；anyxml 更不能被当作普通 YANG 节点树。任何 XML—JSON—XML 的“无损”承诺，都要逐个子树说明 schema 是否已知、哪些内容保持不透明。

格式通过后，协议证据才开始

磁盘上的 XML 不是 NETCONF 请求；发送请求不是服务器收到；收到不是授权；授权也不是应用。RFC 6241 用 <rpc-reply>、<rpc-error> 与 <ok> 描述协议结果。<ok> 能证明处理时没有错误或警告且没有数据返回，但不能替后来设备状态作证。

一项变更应保存请求字节与 message-id、认证会话、服务器能力与 YANG Library、响应、datastore 前后读回。随后还要按 RFC 8342 区分 running、intended 与 operational：有效配置、经系统转换的意图、实际使用的状态并非同义词。最后才是独立测得的外部效果，例如路由可达、策略命中或服务表现。

规范定义各方可以期待的含义，运行证据说明某次系统实际发生了什么。XML 规范化、schema 验证、协议回执和运行观测都不可少；每一项也只能关闭自己的问题。

来源