摘要

  • draft-ietf-netmod-immutable-flag-14 定义服务器提供的 immutable 元数据注解，以及由客户端主动携带的 with-immutability 检索参数；它记录服务器原有行为，不创造也不命令这一行为。
  • 一次返回的 immutable=true 和随后一次 invalid-value 拒绝，可以解释某次编辑失败，却不能单独证明不同用户与协议始终一致、配置永久不变、运行态收敛、依赖稳定、回滚有效或业务结果成立。
  • 可靠核验应分别保存请求、能力与 schema、具体节点实例及继承路径、编辑与完整错误、各 datastore 视图、服务器侧变更触发、运行态观察和恢复结果。

一个自动化控制器先从只读 datastore 发送带 with-immutability 的 <get-data>，收到某个叶节点的 immutable=true；随后它向 running 提交不同值，服务器返回 invalid-value，错误路径也指向同一节点。两张回执前后吻合，看起来已经足够说明“不可变”。

它们确实说明了一件事：在那个时间、那个会话、那条路径上，服务器先披露限制，后以不可变为由拒绝编辑。它们没有说明配置永远不会变化。

第 14 版草案 自己把边界写得很清楚：标记是描述性的，不是规定性的。它把 YANG 驱动服务器已经采用的系统配置处理方式转为机器可读元数据，让客户端在发送注定失败的请求前看到原因。注解不会把可变配置变成不可变配置，也不会替服务器验证其内部策略。

Datatracker 将该文本列为 NETMOD 的活跃 Internet-Draft，日期为 2026 年 7 月 2 日，目标状态为 Standards Track。后续流程更新和 YANG 校验记录属于文档处理证据，不是产品采用、互操作或生产执行证据。规范文本通过检查，与某台设备正确实现，是两个问题。

请求范围决定回执含义

普通读取不会自动返回该注解。客户端必须明确携带 with-immutability，并且只可针对只读的 <system>、<intended> 或 <operational> datastore。若用于其他 datastore，草案要求服务器返回 unknown-element。RESTCONF 另设 capability URI，查询参数不得带值；出现意外值时，应返回 HTTP 400 与 invalid-value。NETCONF 客户端则可通过 YANG Library 检查 ietf-immutable-annotation 模块。

这些并不是同一层证据。capability 或 YANG Library 记录说明服务器宣称支持某种词汇；成功读取说明这次请求被接受；返回子树才显示当前可见实例怎样被标注。三者联结后更强，但仍未触及编辑执行。

旧服务器还会制造歧义。草案允许未实现机制的服务器拒绝未知参数，也可能忽略它。因此，“响应中没有注解”只有在能力、请求和 datastore 均被保存时才可解释，不能直接推成“全部可变”。

不可变性属于实例，也会继承和重置

注解附着于数据节点实例。同一个 list 下，不同条目可以一条不可变、另一条可变。子节点省略注解时继承父节点状态；顶层省略时默认为 false。任意后代可以显式重置，整棵树中改变状态的次数也没有上限。

因此，只存一个叶路径与 true 可能丢掉真正的来源——它也许来自父节点。只存父节点又可能遮住下方的可变例外。RFC 7952 对元数据可附着的位置还有约束：单个 list 或 leaf-list 条目可以带注解，而集合整体只能从父节点继承不可变性。

操作后果也随层级变化。若整个 list 继承不可变性，客户端不能新增、删除或在 ordered-by user 时重排条目；但某个条目仍可显式重置状态。若只是一个 list 条目不可变，它不能从 intended 中消失，其后代默认继承，兄弟条目却不因此变成不可变。

草案还要求服务器忽略客户端发送的 immutable 注解。它是服务器报告，不是客户端可以设置的控制位。即使客户端请求经过签名，里面的 immutable=true 也只证明客户端发过这组字节，不证明服务器接受这项声明。

拒绝回执只约束一次决定

草案的 NETCONF 与 RESTCONF 示例都以 invalid-value 拒绝改值，并给出目标路径和说明文字。完整保存会话、操作、拟写值、路径、时间与响应，远胜一个“策略已执行”的绿色状态。

然而，同一个错误名不会自动解释所有决策。NACM 存在时，服务器先做访问控制，再检查不可变性。没有写权限的用户收到 access-denied，流程可能尚未到达 immutable 检查。不同用户看到不同错误，并不等于底层属性随用户改变；反过来，两种接口都出现 invalid-value，也不能仅凭字符串相同就证明执行了同一策略路径。

还要考虑其他写入口。一次 NETCONF 拒绝没有测试 RESTCONF、本地控制台、厂商工具、启动加载器、升级程序或服务器自己的进程。草案提出的协议/用户无关性是待实现并待核验的符合性要求，不是某个部署已经满足它的现场证据。

服务器控制不等于时间冻结

immutable 约束的是客户端以不同值覆盖节点，创建、更新或删除不可变配置的控制权仍在服务器。硬件探测、软件版本、许可证状态、启用功能和可用资源变化，都可能改变服务器提供什么，或把什么视为不可变。“不可变”说明谁不能改，不等于明天的字节必须与今天相同。

即使服务器不暴露 <system> datastore，也可能存在不可覆盖的硬件预定义配置；同时，并非所有 system configuration 都不可变。客户端还可以把与服务器相同的值显式复制进 running，之后再删掉这份副本，而合并后的 intended 值从未移动。running 的 diff 因而可能显示编辑，实际有效值却没有变化。

RFC 8342 把 intended 与 operational 分开。一次同步读取显示 system、intended、operational 中值和标记相同，是有用快照；它仍不能证明升级后继续相同、依赖资源仍存在、设备确实应用，或流量和服务达到预期。

从布尔值回到八层证据链

实用的核验记录先保存精确检索请求、身份和能力/schema 集，再保存完整返回子树，以重建显式注解、省略、继承与重置。之后保存编辑请求和完整响应，并为相关用户和协议做协调的 datastore 读取。

只要软件、硬件、许可证、功能或资源状态改变，就产生新的证据事件。此时还需要设备遥测、配置应用状态和服务级 canary。若恢复能力属于承诺，就应真正执行并观察回滚或故障切换，而不是从错误码推断它可用。

本分析的封闭一手来源集包括第 14 版草案及 Datatracker 页面/历史、RFC 7952、7950、8342、8525、8526、8527、6241、8040、8341、9907，以及 system configuration 第 20 版：https://datatracker.ietf.org/doc/html/draft-ietf-netmod-immutable-flag-14; https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/; https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/history/; https://www.rfc-editor.org/rfc/rfc7952.html; https://www.rfc-editor.org/rfc/rfc7950.html; https://www.rfc-editor.org/rfc/rfc8342.html; https://www.rfc-editor.org/rfc/rfc8525.html; https://www.rfc-editor.org/rfc/rfc8526.html; https://www.rfc-editor.org/rfc/rfc8527.html; https://www.rfc-editor.org/rfc/rfc6241.html; https://www.rfc-editor.org/rfc/rfc8040.html; https://www.rfc-editor.org/rfc/rfc8341.html; https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-20; https://www.rfc-editor.org/rfc/rfc9907.html。

这些来源证明草案语义和协议边界，不证明任何具名厂商已经符合、实现已普及、生产变更发生、故障被避免、回滚成功或客户结果成立。草案附录列出若干完整或部分先例，也只能表述为草案作者的清单，不能冒充独立互操作报告。