摘要

  • draft-ietf-green-power-and-energy-yang-04 于 2026 年 9 月 9 日发布，仍是 GREEN 工作组处于 I-D Exists 状态的 Internet-Draft，不是 RFC 或已经通过的标准。
  • 新增的硬件组件识别段落称，source-component-id 使用 RFC 8348 的 uuid，以便跨设备、管理系统和管理域关联 Energy Object。
  • 同一版本的 YANG 模块却把该 leaf 的路径写成 /hw:hardware/hw:component/hw:name。按照 YANG 1.1，leafref 的路径决定它引用的节点及值空间，所以模型选择的是本地名称，而非独立的 UUID leaf。
  • 首要修复是让说明与模型选择同一身份。Daniel Kade 另建议保留受保护的身份绑定回执，用于日后的更换与重新绑定；这不是草案要求。

新版新增的恰好是矛盾最明显的一段

最近文档列表把第 04 版列在 9 月 9 日。Datatracker 条目说明它属于 GREEN 工作组，历史记录则记下当天 05:30:49（页面显示的 -0700 时区）新版本可用并获准进入记录。它仍处于 I-D Exists；YANG 校验零错误只说明语法检查通过，不能替说明文字解决身份选择。

第 04 版新增“硬件组件识别”章节，先区分 RFC 8348 里的三个字段：name 只在特定设备语境内有意义；physical-index 取决于旧 MIB 功能是否可用；只有 uuid 具备全局唯一性。接着，文字断言 source-component-id 绑定组件 UUID，从而摆脱设备本地命名惯例。

可执行模块没有跟着改变。source-component-id 的类型仍是 leafref，路径仍到 /hw:hardware/hw:component/hw:name，描述也仍说它引用组件名称。第 03 版已经如此；官方差异页显示，新版强化了 UUID 论述，却没有把该路径改向 UUID。

这不是措辞轻重问题，而是两个命名空间的选择。

leafref 的路径会约束数据，不是给读者的提示

RFC 7950规定，leafref 的 path 用来标识被引用的 leaf 或 leaf-list，引用方采用目标节点的值空间。第 04 版把目标写成 name，执行 YANG 的工具就没有理由从那段说明文字推导出另一个 UUID 节点。

RFC 8348也把差别写得很清楚。硬件组件列表以 name 为 key，它是分配给组件的字符串；uuid 则是另一个可选、只读的 yang:uuid 字段。该 RFC 的模型范围是单台服务器。于是，一个名字完全可以在设备内合法且唯一，却不能凭此成为跨设备稳定身份。

这并不证明已有实现会出错。实现者可能读到矛盾后自行建立映射、采用私有扩展，或等待新版。UUID 也不等于所有权、当前安装状态或电源控制权限。能够确定的事实更窄：9 月 9 日的不可变文本对 source-component-id 的内容给出了两个不相容的指向。

只要数据留在一台设备里，冲突可能暂时不显眼。跨系统汇总时，两个设备都可能有 psu-1，替换件也可能继承旧名称。它们都是合法字符串，却不证明观测对象相同。

统计错对象与控制错对象共用一条边界

GREEN 框架草案用组件层级关系校验并汇总电力信息。用例草案覆盖生命周期报告、间接测量与能源控制。精度分类、认证标签和累计能耗只有在主体正确时才有意义。关于错误对象的精确数据，仍然是错误证据。

控制树让后果更直接。第 04 版把管理员请求的电源状态与实际运行状态分开；另一个采用 require-instance false 的引用允许配置在 Energy Object 尚未出现或已经消失时继续存在，目标不存在时配置不起作用。它的安全章节还警告，未经授权写入管理员电源状态，可能关闭关键网络设备、损坏硬件或通过反复切换干扰监控，并建议用 NACM限制通过 NETCONF与 RESTCONF进行的操作。

NACM 能回答“谁可以写”，却不能单独回答“保留下来的意图是否重新绑定到了正确替换件”。对象消失之后，同一字符串再次出现，运营者需要核实主体连续性，而不是只核对字段格式。

先统一规范，再保留绑定决定

草案层面的第一步很小：说明、树图和模块必须选择同一个节点。若目标真是跨系统身份，模型就应携带或明确引用 UUID；若本地名称才是有意选择，文字就应缩小跨域承诺，并在别处定义映射。

实际运维还需要一份受保护的身份绑定回执，至少记录：

  1. 采用的草案或模块版本及摘要；
  2. Energy Object ID、设备范围和管理域；
  3. 本地组件名称、观测到的 UUID，未提供时明确记空；
  4. 映射由谁声明、何时观测；
  5. 可用的序列号、资产或替换证据；
  6. 消失、更换、重分配或合并事件；
  7. 仍附着在对象上的管理员电源意图；
  8. 批准重新绑定的权限主体与时间；
  9. 恢复汇总或控制前的复核结果。

回执不必公开站点拓扑、客户活动或用电曲线。草案自身已经提醒，细粒度电力数据及对象关系可能暴露负载、容量和高价值基础设施。哈希、带范围的标识符与结果代码可以只留在获授权的管理域中。

Heng Lu 关于最低初始规范的文章提供了合适尺度：只标准化独立系统必须共同理解的边界。《政策之镜》则提醒，自动化执行之后，促成动作的规则与主体仍应可见。

身份绑定回执是我的编辑建议。第 04 版没有定义它，GREEN 工作组也没有采纳它。

证据边界

现有证据只证明第 04 版中存在说明与 leafref 的不一致。它不证明任何产品采用错误字段，不证明已有测量被归错，也不证明休眠的电源命令已经执行。RFC 8348 的 UUID 是可选项；即使正确上报，也不自动证明所有权与操作授权。下一版本完全可能修正这个问题。

可以稳妥陈述的是：新增段落承诺以 UUID 跨域关联，现有 YANG 路径却仍选择 component/name。治理的起点，是让这两个答案合为一个。

来源