Summary

  • Revision 04 of draft-ietf-green-power-and-energy-yang became available on 9 September 2026. It remains a GREEN working-group Internet-Draft in the I-D Exists state, not an RFC or approved standard.
  • New prose says source-component-id uses the uuid from RFC 8348 to correlate an Energy Object across devices, management systems and administrative domains.
  • The YANG module in the same revision still defines that leaf as a reference to /hw:hardware/hw:component/hw:name. Under YANG 1.1, the path selects the referred node and its value space; the executable contract therefore selects the local name, not the separate UUID leaf.
  • The first repair is to align prose and schema. Daniel Kade also proposes a protected identity-binding receipt for later replacement and rebinding decisions. That receipt is editorial guidance, not a requirement in the draft.

One revision contains two component identities

The IETF recent-documents page lists revision 04 on 9 September. The Datatracker record identifies it as an active document of the GREEN working group, and the history records the new version at 05:30:49 in the displayed -0700 timezone. Its status is still I-D Exists. A clean validation report does not turn a draft into a standard, and it does not decide whether explanatory prose points to the same leaf as the module.

The new Hardware Component Identification section makes a precise distinction. RFC 8348 offers name, physical-index and uuid. Revision 04 explains that a name is meaningful within its device, a physical index depends on support for the older MIB relationship, and only the UUID is globally unique. It then says source-component-id is bound to that UUID so observations can be correlated across devices, management systems and administrative domains.

The module says something else. Its source-component-id leaf has type leafref; the path is /hw:hardware/hw:component/hw:name; and its description calls it a reference to the component name. The revision 03 text already used that path. The official comparison shows revision 04 strengthening the UUID explanation without changing the target of this leaf.

That is not a debate about typography. It is a choice between two different namespaces.

A leafref is not a narrative hint

RFC 7950 defines the YANG 1.1 rules. A leafref path identifies the leaf or leaf-list being referred to, and the referring node takes the value space of that target. In revision 04, the selected target is name.

RFC 8348 makes the difference visible. Its hardware list is keyed by name, a string assigned to the component. The UUID is a separate optional, read-only yang:uuid leaf. RFC 8348 also describes its model as managing hardware on a single server. A name can therefore be valid and unique in the local list without being a globally stable component identity.

This does not prove that an implementation will misbehave. Implementers may notice the prose, add a private mapping or wait for another revision. Nor does a UUID prove ownership, current installation or authority to control the component. The narrower finding is documentary: the current immutable revision gives a data-model consumer two incompatible instructions about what value source-component-id contains.

The distinction matters most when data leaves the box. Two routers can both have a component called psu-1. A replacement can inherit an old local name. A collector can accept both values as perfectly valid strings. None of those outcomes establishes that the measurements describe the same physical component across systems.

Reporting and control share the identity boundary

The GREEN framework uses hierarchical relationships to validate and aggregate power information. The use-cases draft includes lifecycle reporting, indirect monitoring and power control. Those activities need a stable answer to a simple question: which component did this observation or instruction concern?

If the answer changes by reader, aggregation can join unrelated measurements, omit a replacement or preserve the appearance of continuity after the underlying component changed. A certification label or an accuracy class cannot repair a mistaken subject. High-quality data about the wrong object remains wrong evidence.

The control side raises the stakes. Revision 04 separates an administrative power-state request from the observed operational state. It also lets a configured Energy Object reference remain when the object is absent, using require-instance false; while the object is missing, the configuration has no effect. The draft's security section warns that an unauthorized administrative write could power down critical infrastructure, damage hardware or disturb monitoring, and points to NACM for restricting access over management systems such as NETCONF and RESTCONF.

Access control answers who may write. It does not answer whether a durable intent has been rebound to the intended replacement. When an object disappears and an identifier later resolves again, an operator needs evidence that the subject, not merely the string, is still right.

Align the contract, then preserve the binding

The immediate standards repair is small: make the prose, tree and module select the same node. If cross-system identity is the goal, the schema must carry or unambiguously reference the UUID rather than merely describing it. If a local name is intentional, the cross-domain claim should be narrowed and an explicit mapping supplied elsewhere.

Deployment governance then needs a separate identity-binding receipt. A compact protected record could contain:

  1. the exact draft or module revision and its digest;
  2. the Energy Object identifier and the device or administrative-domain scope;
  3. the component's local name and observed UUID, with an explicit null when no UUID is exposed;
  4. the source that asserted the mapping and the observation time;
  5. the hardware serial, asset or replacement evidence used locally, where available;
  6. any disappearance, replacement, reassignment or merge event;
  7. the administrative power intent that remains attached to the object;
  8. the authority that approved a rebind, plus the decision time; and
  9. the validation result before telemetry aggregation or control resumes.

The receipt need not disclose topology or customer activity. The draft itself warns that fine-grained power data and object relationships can reveal workload, capacity and high-value infrastructure. Hashes, scoped identifiers and controlled result classes can remain inside an authorised management domain.

This follows the restraint in Heng Lu's minimum-initial-specification essay: standardise the boundary independent systems must share, not every internal fact. The Policy Mirror adds the operational point: the rule and identity that caused a control action should remain visible after automation executes it.

The receipt is my proposal. Revision 04 does not define it, and the GREEN working group has not adopted it.

Evidence boundary

The source record proves a mismatch in revision 04 as published on 9 September. It does not prove a deployed product follows the wrong leaf, a measurement has been attributed incorrectly or a stale power command has run. The UUID in RFC 8348 is optional, and even a correctly reported UUID does not establish ownership or operating authority. Future revisions may align the text and module.

The safe claim is exact: a paragraph now promises UUID-based cross-domain correlation while the current YANG leafref still selects component/name. Governance begins by making those two statements agree.

Sources