摘要

  • immutable 注解描述客户端不能通过读写配置改变的系统提供节点，并不冻结服务器自身的更新能力。
  • 节点状态可能来自显式注解、父节点继承或顶层默认值，只有一个真假结果不足以复原判定过程。
  • 运维证据应另外保存观察快照、实例路径、继承来源、服务器权威和写入失败的真实判定阶段。

同一个词，两个问题

日常语境中的“不可变”很容易让人想到跨越时间的永久性：档案封存后不再改变，摘要值永远对应同一内容。draft-ietf-netmod-immutable-flag-14 的使用范围更窄。注解为真的系统配置，服务器不允许客户端在读写数据存储中配置成另一个值，也不允许客户端把系统提供的节点从 intended 配置中移除。

这项能力解决的是 YANG 树里的真实难题。有些节点必须保持 config true，因为它们下面还有允许用户配置的子节点，或者 when、must、leafref 需要引用它们；与此同时，设备又必须保证某些系统条目存在。过去只在 description 中写一段自然语言，自动化客户端很难提前判断。机器可读注解能让它在提交编辑前识别边界。

草案反复强调，该标记是描述性的，不是命令服务器采用某种行为。它同时说明，不可变的系统配置只能由服务器创建、更新和删除。这两句话并不冲突：注解回答“客户端能否从这个配置接口改变节点”，不回答“服务器明天是否仍给出同一数值”。

因此，中午观察到真值，并不排斥设备在下午更换硬件后由服务器生成另一值。中午的记录仍然正确，只是它从来不是历史保证。合规面板若把“客户端不可改”缩写成“永不改变”，就把控制轴误作时间轴。

看见注解本身也有前提

服务器不会在所有响应中自动附带注解。客户端要在读取 system、intended 或 operational 只读数据存储时显式请求 with-immutability。对其他数据存储使用该参数，按草案应返回错误。NETCONF 客户端可以从 YANG library 判断服务器是否实现 ietf-immutable-annotation 模块；RESTCONF 则有专门的 capability 标识。

于是，真正的观察链从布尔值之前就开始：能力是否被发现，请求使用了什么协议和数据存储，选择了哪个子树，哪个主体有读取权限，响应何时到达。事后只截取一个“true”，无法可靠补齐这些条件。

新旧版本并存又产生更多含义。旧客户端不会请求，自然收不到注解。新客户端面对旧服务器时，参数可能被明确拒绝，也可能被忽略。响应中没有注解，还可能是因为状态来自继承、顶层默认是假、服务器省略了冗余元数据，或者客户端无权读取该节点。没有能力与请求记录，“缺失”就会被错误地等同于“可修改”。

没写出来的真值

草案用继承减少树中重复的元数据。子节点没有显式注解时，沿用父节点状态；顶层节点没有标记时，默认是假。后代节点可以重置继承状态，让自己的子树获得另一种结果。在一棵数据树内，状态切换次数没有上限。

这样的线缆格式简洁，却要求审计保留计算过程。若只存实例路径和最终真假，就不知道它是显式给出的、继承来的，还是默认产生的；也找不到决定结果的祖先与中途重置。两个都解析为真的节点，可能因为完全不同的父级规则而在下一版本出现不同变化。

列表尤其能说明路径的重要性。元数据附着于节点实例，同一列表的不同条目可以取不同状态。受 RFC 7952 编码约束，不能简单给“整个列表实例”挂一个包办一切的注解；列表整体的限制可能从父节点继承，而具体条目又能重置。添加、删除、修改与用户排序所受限制也并非总是一回事。

观察凭证至少应保存实例路径、节点类型、YANG 模块与修订、显式注解、解析后状态、继承源以及相关重置。解析是一个运算，只有保留输入，第三方才能重算。

在 running 中重复同值，不代表获得所有权

客户端可以把与系统相同的值显式写入 running，之后也可以删掉这条写入，但 intended 中的系统值不会因此改变。变化的是读写数据存储里是否可见，不是底层数值的权威来源。

只盯着 running 的变更日志，可能会写下“客户端创建了这个节点”，继而把有效配置的来源错归给客户端。反过来，不可变系统节点在没有显式重复之前，可能根本不出现在 running。以 running 为唯一资产清单，会漏掉真正约束设备的配置。

时间来源记录需要同时容纳客户端事件与服务器事件。服务器侧数值可能来自硬件发现、启动模板、厂商规则或其他本地机制。标准注解不负责告诉客户端是哪一种。若平台没有证据，最诚实的字段是“服务器来源未知”，而不是根据产品经验补写一个故事。

先判权限，再判不可变

服务器启用 NACM 时，先执行访问控制，再检查不可变性。没有操作权限的用户会收到访问拒绝；服务器不会为了证明节点不可变而先泄露这一属性。这个顺序既是安全边界，也是运维分析必须遵守的因果顺序。

一次编辑失败不能自动计入“不可变策略拦截”。凭证要记录认证主体、请求操作、目标路径、NACM 结论、不可变检查是否实际发生，以及最终错误标签。否则，权限不足、数值校验失败和不可变限制都会混入同一指标。

注解本身还可能透露哪些配置较为固定。草案提醒，这类提示可能帮助攻击者寻找利用方式。因此，只有已经获准读取被注解节点的客户端才能看见它，NETCONF 或 RESTCONF 的安全传输与相互认证要求也没有改变。把注解汇入广域分析平台时若丢掉原始读取范围，就可能扩大信息受众。

给观察加一张有期限的来源凭证

标准布尔值无需承载整个历史。运维者可以在它旁边维护一张本地凭证：服务器或逻辑网络元素、软件版本、数据存储、YANG 模块修订、能力发现结果和读取协议；随后是所选子树、实例路径、配置值、解析后状态及其显式或继承来源。响应时间与平台能够提供的配置版本、快照编号或摘要也应保留。

接下来记录本地确实能够证明的服务器事实：系统配置来源、决策权威、上一次服务器侧变更与理由。不知道的就保持未知。若客户端尝试编辑，再附上角色、操作意图、NACM 结果、不可变结果和返回错误。

凭证最后还要有复查时间。这样，“当时观察为不可变”就不会被包装成“已认证永久不变”。服务器以后改变数值，不应覆盖旧凭证，而应生成一张新凭证。两者并列，才能显示时间变化又不否定原先的客户端边界。

这不是要求扩写 YANG 注解。把身份、历史和本地工作流塞进一个通用布尔值，会损害互操作性。更合适的结构是：标准字段保持窄小，本地证据系统再与自己真正观察到的事实进行连接。

采用情况是一张矩阵

研究截止时，第 14 版已获 IESG 批准并进入 RFC Editor 队列，但仍是活跃 Internet-Draft；YANG 验证报告为零错误、零警告。这些流程事实都不能证明产品与网络已经部署。

真实环境会同时存在支持或不支持的服务器、请求或不请求的客户端，以及新客户端遇到旧服务器时的拒绝或忽略。还会有大量通过继承解析、因而未显式出现的状态。一个兼容率无法说明证据到底在哪一步中断。

可用的监测单位是一条完整路径：发现能力、发出有效请求、收到响应、解析状态；若存在编辑，再在访问控制之后正确分类结果。每条路径停下的位置，才对应具体的升级、策略或可观测性决策。

来源