摘要

  • 修订版 11 提议让模块定义、实现追加和用户配置共同形成节点标签，再把 masked-tag 中精确匹配的值从可见 operational 集合里减掉。
  • 余下的标签只能证明服务器在特定 datastore、模式和权限文境中展示了这项分类；它不证明节点存在、数值新鲜、实现符合标签含义，更不证明这份已经过期的草案得到部署。

设想一次安全巡检：工具查询所有被标记为敏感的 YANG 节点，得到三个路径，于是把它们加入重点监控。第四个预期路径没有出现。工程师面临的不是一个答案，而是一组可能性：它从未被标记；标签被用户遮蔽；NACM 没让当前身份看到；选择器在这套模块修订中无法解析；或者查询选错了 datastore。

这正是 node-tags 草案最有用的阅读方式。它不是给节点盖章，而是在一个中心关联表里组织分类。ietf-node-tags 模块为每条关联保存整数 id、类型为 nacm:node-instance-identifier 的 node-selector、tag 集合和 masked-tag 集合。选择器既可指模式节点，也可指数据节点实例。草案建议通过 <get-data> 查询 operational datastore；面对模式节点，还提到 <get-schema>。附录先找出带标签的路径，再把路径放进 establish-subscription 请求。

这是操作示例，不是部署报告。本次来源中没有任何厂商交付、独立实现、互操作测试或生产使用证据。

三个来源不等于三条清晰流水线

草案把来源分成三类。模块作者在设计时加入标签；实现可以根据自身能力添加标签；用户也能配置标签。随后，用户可遮蔽任何来源的标签。

但修订版 11 在枚举 operational 结果的合成步骤时，只明确写了三件事：加入模块定义时分配、带 system origin 的标签；加入用户配置、带 intended origin 的标签；删去与 masked-tag 相同的标签。这里没有单列“实现追加”步骤。

一种合理解释，是把实现自动加入的标签归入服务器侧、最终以 system 材料呈现的范围。不过这仍是对两段文字的衔接解释，不是草案明写的第四步。任何审计记录都应保留这点含混，而不是画出一张比原文更确定的来源图。

遮蔽也容易被误读。它删的是最终集合中的精确值，不是对历史的擦除，更不是证明那枚标签原先不成立。反过来，标签没有被遮掉，也不代表它正确。可见结果本身没有回答是谁添加、何时添加、基于哪个软件版本、又用什么证据判断节点应当这样分类。

ietf:、vendor:、user: 三种前缀提供命名空间纪律。草案同时指出，未登记的前缀依然构成有效标签，实现也应处理它。登记因此只能证明名称受怎样协调，不能替冒号后的判断背书。一个规范名称可以描述错误实现；一个未登记名称也可能偶然描述准确。

路径看似明确，文境仍然隐藏

node-selector 采用结构化类型，容易让人产生可移植错觉。RFC 7950 规定 YANG 模式和实例标识的语义；RFC 8525 则说明设备实际公布的模块、修订、feature 与 deviation。只要其中一项变化，同样的选择器就可能失效或落到不同目标。挂载的模式文境还会进一步改变路径解释。

RFC 8342 把 intended 与 operational 分开。草案沿用这一思路：用户配置属于 intended 来源，合成后的展示属于 operational。这里的 operational 是服务器提供的运行数据视图，不是绕过软件和权限之后的物理真相。

访问控制会继续塑造结果。RFC 8341 可限制关联表或目标节点的读取。RFC 6241 与 RFC 8040 分别提供 NETCONF 和 RESTCONF 的事务表面，但一次成功响应只证明该身份在那次事务中获得了什么。缺失结果不能直接翻译为“不存在”。

RFC 7952 的 metadata annotation 是一个有益对照：注解随数据实例出现，而 node-tags 把选择器与标签集中关联。两者都不会自动补齐作者、时间、保管链与新鲜度。机器可读的形式不会凭空制造这些证据。

把自动化停在正确的证据台阶

第一层事实是文件存在：修订版 11 确实被提交和讨论。第二层是文档状态：Datatracker 能证明它何时更新、何时过期。标签前缀登记只能证明命名空间分配。查询返回标签，则证明服务器在特定权限和 datastore 文境中展示了合成后的值。

只有把选择器放进冻结的 YANG Library 快照并成功解析，才能说明该路径在那套模式中指向一个节点。随后一次获授权的读取，只能说明服务器在那次事务里返回了什么。数值是否新鲜、实现是否正确、通知是否完整、转发表是否按预期工作、业务是否得到结果，仍需设备遥测、FIB 检查、报文观测和服务核对。

草案附录把查询结果接到订阅上。RFC 8639 和 RFC 8641 确实能建立订阅与 YANG-Push。RFC 9195 和 RFC 9196 能表达实例数据与能力。它们仍不会把分类标签变成“通知全部抵达”或“设备忠实实现”的证明。RFC 9371 对厂商标识的安排同样只改善命名空间，而不认证厂商行为。

风险在自动动作发生时放大。草案明确提醒：标签可能泄露节点用途并暴露攻击面；添加和删除应受权限约束；依据标签采取什么动作不在规范范围内。把 ietf:critical 直接连接到停服、放行或变更配置，是本地控制策略，不是草案授予的权限。

过期状态不能从邻近 RFC 借来

修订版 11 日期为 2023 年 10 月 21 日，原文写明 2024 年 4 月 23 日到期。Datatracker 当前把它列为 Expired Internet-Draft、Expired & archived、Dead WG Document，IESG 状态也是 Expired。它预期成为 Proposed Standard，但最终没有成为 RFC。

Datatracker 还显示其 YANG 模块验证为零错误、零警告。这能证明提交的模型通过了指定工具检查；不能证明采用、互操作、部署或 operational 合成正确。

RFC 8819 是最相近的正式标准，却不能把自己的身份借给这份草案。RFC 8819 规范的是 YANG 模块级标签，也包含模块定义、实现、用户与遮蔽的来源逻辑。node-tags 把相似思想下沉到节点。前者已发布为标准，不会让后者自动升级。

Heng Lu 关于“最小初始规范”“权威”“实现力量”“现实层”和 running code 的文章在这里只提供分析镜头：文档、登记与标签能够协调行动，真正采用和可观测运行仍是另一层。这不是 IETF 规范要求。它提醒决策者把标签当作查找线索，而不是让它借用规范、登记机构或服务器的权威去证明节点现实。

来源

主要记录：修订版 11、Datatracker 当前状态与状态历史。

模式与访问文境：RFC 6241、RFC 7950、RFC 7952、RFC 8040、RFC 8341、RFC 8342、RFC 8407、RFC 8525与RFC 8526。

标签、订阅与相邻证据模型：RFC 8639、RFC 8641、RFC 8819、RFC 9195、RFC 9196与RFC 9371。

分析镜头：最小初始规范、关于权威、实现力量、现实层与Running Code Primacy。