Summary

  • Revision 01 of draft-claise-green-capability-discovery, posted on 10 September 2026, adds maximum power plus typical and worst-case entry and exit times to a proposed YANG capability model.
  • The model can describe supported states before deployment or expose them as read-only operational data, at system or hardware-component level. Power values, transition times and component coverage may all be incomplete.
  • The draft expressly does not define permitted transitions, writable actions or the decision to enter a state now. Rated nominal power is a planning baseline, not a measurement of actual consumption or savings.
  • The document remains an individual Internet-Draft with no stream or Working Group adoption recorded. A useful operational record must join capability, local authority, device response, measured power and service effect.

The catalogue stops before the switch

Suppose a planning tool learns that a router line card supports an on state and a sleep state. The vendor data says the card normally draws 200 watts when on and 15 watts when asleep. It gives an 800-millisecond typical wake-up and a two-second maximum. The arithmetic promises 185 watts of potential reduction.

The tempting next sentence is that the card can now be put to sleep. That sentence is not in the evidence. The inventory has not said whether the transition is allowed from the card’s present state. It has not said whether traffic was drained, whether a redundant path exists, who is entitled to request the change, whether the device will accept it or what power and latency changed afterward.

This is the useful boundary exposed by the 10 September revision. A common capability description can remove guesswork from procurement and planning without becoming a remote control or a green-performance certificate.

What revision 01 added

The Datatracker record lists A YANG Data Model for Power State Capability Discovery as an active individual Internet-Draft. Its history shows revision 00 on 25 August and revision 01 on 10 September 2026. Datatracker records no stream and no Working Group state. The draft’s own masthead says Standards Track, but that intended destination is not adoption, consensus, IESG approval or RFC publication.

The change from revision 00 to revision 01 is material. The official diff adds a maximum-power figure beside expected nominal power. It adds typical and maximum times for entering and leaving a state. It spells out partial component coverage, planning-only treatment of rated values, two worked examples and an open-issues section.

The revision also exposes unresolved work. The authors ask whether a whole-system capability is needed in addition to per-component data, acknowledge uncertainty over whether vendors can report transition durations, and identify incompatible meanings of Nameplate Power across related GREEN documents. These are not defects to hide. They are decision points that keep early data from acquiring more authority than its definitions can support.

One component, three records

The proposed module extends the system-capability framework defined in RFC 9196. A system-wide default may describe the device, while a per-node entry can point to an item in the RFC 8348 hardware inventory: a chassis, line card, port, transceiver or another component. The companion GREEN Power and Energy draft supplies the live administrative and operational state and instantaneous power. The shared hardware-component name is the join.

That produces three distinct records.

The capability record says which states the platform declares it supports, the rated power associated with each and the expected transition times. Because this information is static, a manufacturer can distribute it before installation as an RFC 9195 instance-data file. A running device may instead expose the same schema from the operational datastore described by RFC 8342.

The authority record says whether a controller or operator may request a transition for this component now. The capability draft supplies no writable node, RPC, action or notification. It says explicitly that supported states do not reveal which transitions are permitted. A request belongs to the control side of the separate GREEN model; the device may accept or reject it.

The outcome record says what happened. It needs the state actually reached, measured power, traffic carried, restoration delay and service effect. A successful write is not evidence of the expected watt saving. A nominal value is not a meter reading. A state called sleep does not prove that a service objective survived.

Missing data is unknown, not zero

Revision 01 makes the accounting limit unusually clear. Power figures are optional. A component may report the states it supports but omit what they cost. A device may publish capability data for some components and not others during incremental deployment. If a line card has no entry, the correct value is unknown—not zero watts and not “incapable of sleeping.”

The same rule applies to totals. Per-component power excludes child components in the hardware hierarchy. A chassis total assembled from advertised entries is complete only if every component in the relevant subtree is covered and counted once. Otherwise the sum is a lower bound.

Rated values have another limit. Offered load, temperature and local conditions make actual draw time-varying. The draft therefore says nominal power must be treated as a planning baseline rather than measurement. The power-steering proposal may consume a slowly changing Power Savings Potential, while a central controller can collect live telemetry. Neither route turns a catalogue subtraction into observed energy saved.

Entry and exit durations are similarly optional and approximate. A state with attractive savings can still be unusable when a line card carries latency-sensitive traffic. The maximum wake-up time must be tested against the applicable service threshold, not admired as an isolated device property.

The inventory itself needs custody

Read-only does not mean harmless. The draft’s security section requires secure management transport, mutual authentication and access control, pointing to the NACM rules in RFC 8341. A capability file can reveal which components offer the greatest saving and which take longest to return. That is also a map of where forced wake-ups, prevented sleep or repeated transitions could cause the greatest disruption.

Pre-deployment files introduce a second custody question. A schema can be identical while its issuer, platform revision and age differ. Procurement should retain the manufacturer, product and hardware revision, file digest, generation time and applicable inventory boundary. A live device reading should retain the device identity, software and inventory revision, retrieval time and access path. Schema compatibility is not provenance.

Keep a runtime transition receipt

A consequential transition should leave one bounded record. It should identify the hardware component and inventory revision; the capability source and its age; whether the relevant subtree is complete; nominal and maximum power assumptions; typical and worst-case transition bounds; current measured draw; offered load and traffic role; the applicable service objective; the policy and person or controller authorized to act; the exact request; device acceptance or rejection; state actually reached; measured energy delta; service impact; and rollback trigger.

This receipt is Daniel Kade’s editorial proposal, not a requirement of the draft or the GREEN Working Group. It follows the narrower institutional logic in Heng Lu’s minimum-specification note: standardize the smallest shared evidence layer and leave the future operating decision local. The Policy Mirror sharpens the same question by asking which actor actually controls each surface, while Reality, Not Advocacy argues for reporting the observable record rather than upgrading a proposal into an outcome.

The GREEN charter can frame energy-efficient networking work. It does not convert this individual draft into adopted work. Nor do the draft’s requested namespace and module registrations create current IANA entries. The useful news is smaller and more concrete: revision 01 makes capability more legible while leaving authority and outcome visibly separate.

Sources