摘要

  • 在 draft-tt-netmod-yang-config-templates-03 中，显式的非模板配置优先级最高；较近的祖先压过较远的祖先；同一节点上发生冲突时，客户端名单中排在前面的适用模板胜出。
  • 要复现预期配置，必须保留同一快照中的完整 running 与 system、模板定义、应用位置和顺序、I-Regexp 键匹配及显式覆盖；这仍不能证明客户端原始输入、无竞态传播、NACM 正确、实现一致、运行收敛或流量交付。

一次故障复盘拿到了设备的 intended 树，也拿到一行 ct:apply-templates。两份材料看起来足以还原现场，实则不然。结果树告诉我们某个观察点展示了什么；模板名单告诉我们若干名字及其排列。二者都没有自动保存这些名字挂在哪一级祖先、当时模板正文是什么、哪些字符串键被正则命中，以及普通配置在哪里完成了最后覆盖。

第 03 版的价值，正是把这类模糊处变成明确规则。模板不只是减少重复输入的编辑工具，而是把紧凑配置变换为预期配置的机制。只要名单先后能够决定冲突结果，顺序本身就是配置数据，不能当成展示格式。

冲突由三条轴线裁决

第一条是显式性。running 或 system 中非模板方式写入的普通配置拥有最高优先级。模板可以提供类似默认值的内容，但显式值胜出。客户端可以覆盖模板给出的节点，却不能靠删除展开后的节点来否定模板本身。

第二条是位置。模板既可贴在目标节点，也可从祖先继承。多个适用模板发生冲突时，离目标最近的祖先胜过外层祖先。因此，只保存模板名字而丢失元数据所在路径，相当于丢失了决定结果的证据。

第三条是同一位置上的名单顺序。草案明确把顺序交给客户端。示例把 ethernet-interface 放在 base-interface 之前；对匹配的以太网条目，前者的 MTU 1500 压过后者的 65536。这里不能只写“应用了两个模板”，而要保存有方向的完整序列：排在前面的适用模板优先。

名单更新也不是增量猜测。非空元数据会替换整份名单；空值或仅含空白会移除应用；请求中没有该元数据则保留现状。若审计日志只记“增加 A、删除 B”，却没有记录提交时的完整替换值，未必能够重放那次决定。

正则让证据边界继续扩大

模板可对内建类型为 string 或派生自 string 的列表键使用正则。草案引用 RFC 9485 的 I-Regexp——一个刻意收窄、用于互操作的 XML Schema 正则子集。规则收窄有助于一致性，却不意味着单独一段模式文本就足以复现结果。

例如 eth.* 只有与当时参与计算的具体列表键结合才有意义。接口改名、缺失一个系统生成条目，或快照时间落在另一笔修改之后，都会在模式文字不变的情况下改变命中集合。因此，应冻结模式、候选键、规则版本与实现解释，而不是只保存模式。

模板本身还可以是不完整片段。草案要求服务器在可行时验证模板，并要求合并后的结果满足相应 YANG 约束。Datatracker 页面目前对抽取出的 ietf-config-template (revision 2026-07-03) 显示 0 个错误、0 个警告。那是特定工具表面的文档校验回执，不是 NETMOD 采纳、IETF 背书，也不是任何服务器完成合并的证据。

intended 是变换后的观察面

按照 NMDA，running 保持紧凑：它保存定义、应用元数据和显式配置，而不会被一份展开副本替换。继承、优先级和覆盖的结果出现在 intended。已应用模板在 running 或 system 中发生变化，应反映到预期配置。

正在被引用的模板不能直接删除。第 03 版要求服务器用 data-missing 拒绝，操作者须先更新所有引用位置，再删除定义。这是一条操作顺序，却不是并发安全证明。清点引用和执行删除可能跨越多个请求；另一客户端可在中间新增或改写引用。只有具体服务器的事务边界、锁或经过验证的维护程序，才能关闭这个窗口。

一份 intended 读回也不是变换的唯一逆解。不同历史可以到达同一棵树：模板正文不同但被显式值覆盖；名单换序但当下没有冲突；system 改变后又被 running 压住。结果能证明观察到的结果，不能倒推出完整客户端请求和所有中间版本。

先冻结实验，再谈离线复现

离线展开器可以构成强有力的独立检查，但输入必须成套：精确的草案与规则版本、服务器和展开器实现身份、完整且同一时点的 running 与 system、全部模板定义、每个应用路径及祖先深度、每处有序名单、I-Regexp 语义与候选键、显式覆盖，以及能证明这些部分属于同一次观察的数据存储版本或时间关系。

应对整个输入包计算哈希，而不只对渲染出的树计算哈希。再把离线结果与服务器 intended 逐节点、逐值比较。差异是诊断证据；一致则说明两个变换在这组输入上达成一致，不代表所有厂商实现天然相同。

协议回执要另行归档。NETCONF 或 RESTCONF 能证明请求被接收，也能携带资源版本信号，却不能证明模板更新没有竞态、每个主体看到的 NACM 过滤视图都正确，或预期节点已经落地。RFC 8341 把访问控制设为独立控制面，授权矩阵必须逐角色实测。

最后，RFC 8342 刻意区分 intended 与 operational。资源不足或执行失败，可能使预期配置没有出现在运行状态。即便运行状态一致，也还不是 FIB 编程、报文到达、时延或服务结果的回执。每个主张都需要自己的观察者。

文档状态也必须原样保留

第 03 版日期为 2026 年 7 月 3 日。草案页眉写着“Intended status: Standards Track”；Datatracker 则把它列为活跃的个人 Internet-Draft，显示无 stream、无 intended RFC status，IESG 状态为 I-D Exists。这些字段分别记录并不冲突；把它们压缩成“已进入 IETF 标准轨道”才会失真。

准确结论应当更窄：这份草案提出了可检验的有序合并规则；Datatracker 的工具检查说明抽取模块在该表面得到 0/0。两者都没有证明工作组采纳、IETF 背书、RFC 地位或生产互操作。

来源

主要来源：YANG Configuration Templates 第 03 版；IETF Datatracker 记录；YANG 1.1，RFC 7950；YANG Metadata，RFC 7952；NMDA，RFC 8342；NACM，RFC 8341；NETCONF，RFC 6241；RESTCONF，RFC 8040；I-Regexp，RFC 9485。版本时间线：Datatracker 历史。 边界参考：System Configuration 第 20 版；Lu Heng 关于运行代码优先、最小初始规范与现实层级的文章。