GREEN Working Group B. Claise Internet-Draft Everything OPS & Arrcus Intended status: Standards Track 25 August 2026 Expires: 26 February 2027 Discovering the Power State Capabilities of Components draft-claise-green-capability-discovery-00 Abstract This document defines a YANG module that augments the system capabilities model of RFC 9196 to allow a network element to advertise, per hardware Component, the set of Power States that the Component supports together with a static characterization of each such state: the nominal Power the Component draws in that state. This capability model complements the operational Power and Energy data model defined in the GREEN Power and Energy YANG module, which reports the current Power State and the measured Power of a Component, but not which Power States are available or how much Power each draws. It is anchored to the hardware inventory of RFC 8348, reuses the Power State identities of the GREEN Power and Energy model, and, because it is static, may be provided at implementation time as YANG instance data per RFC 9195 so that an Energy Management System can learn a platform's Power State capabilities before the equipment is deployed or even powered on. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 26 February 2027. Claise Expires 26 February 2027 [Page 1] Internet-Draft Power State Capability Discovery August 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Capability is Kept Separate from Operational State . . . 4 2.2. Capability is Anchored to the Hardware Component . . . . 4 2.3. Power State Names are Reused, Not Reinvented . . . . . . 5 2.4. The Characterization is a Reusable Grouping . . . . . . . 5 2.5. Capability MAY be Provided as Instance Data (RFC 9195) . 5 3. Relationship to Other Work . . . . . . . . . . . . . . . . . 5 4. The Power State Capabilities Model . . . . . . . . . . . . . 6 4.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 6 4.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7 5. Operational Considerations . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. Normative References . . . . . . . . . . . . . . . . . . . . 13 10. Informative References . . . . . . . . . . . . . . . . . . . 14 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction Networks are provisioned for peak demand and might be over- provisioned some of the time. Reducing the energy consumed by the idle capacity requires the ability to place selected Components into a low-power (sleep) Power State when they are not needed, and to return them to full operation when demand returns. To determine which Components can be placed in a low-power state, and estimating the resulting Energy Saving, the Energy Management System, the controller, or the distributed path computation (depending on Claise Expires 26 February 2027 [Page 2] Internet-Draft Power State Capability Discovery August 2026 operational design) draws on two things about each Component: 1. which Power States the Component actually supports 2. where it is known, how much Power the Component draws in each supported state. The GREEN Power and Energy YANG module [I-D.ietf-green-power-and-energy-yang] models the operational side of this problem: for each Energy Object it reports the current administrative and operational Power State (power-state-admin / power-state-oper) and the measured instantaneous Power. It does not, however, describe which Power States a Component is capable of entering. GREEN reports a single Nameplate Power for the Component, but not the Power the Component draws in each supported Power State -- which is precisely what a Power Savings Potential calculation needs. That information is a Capability: it is essentially static, it is a property of the platform rather than of the running datastore, and it is useful before the device is even powered on. No common capability model exists today, so each consumer defines the pieces it needs. The Power Conserving Path Placement Strategy [I-D.many-teas-power-steering] and its IS-IS encoding [I-D.many-lsr-power-group] introduce their own "sleep-capable" indication and Power Savings Potential value, defined independently of the GREEN data model. This document defines a single capability model, discoverable through the standard system capabilities mechanism of [RFC9196], from which those quantities can be derived -- for example, Power Savings Potential as the difference between the nominal Power of power-state-on and that of a low-power state -- rather than defined separately by each consumer. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology This document makes use of the terms defined in [I-D.ietf-green-terminology]. Terms reused from that document are capitalized in this specification, including in particular Component, Device, Power, Power State, Power State Set, Nameplate Power, Energy Object, Energy Saving, and Energy Efficiency Capabilities. Claise Expires 26 February 2027 [Page 3] Internet-Draft Power State Capability Discovery August 2026 The term "Power Savings Potential (PSP)" is used as defined in [I-D.many-teas-power-steering]. 2. Design Overview The design follows four principles. 2.1. Capability is Kept Separate from Operational State The set of supported Power States and their characterization is a Capability, not operational state. It is therefore carried in the system capabilities subtree of [RFC9196] rather than being mixed into the operational power data of [I-D.ietf-green-power-and-energy-yang]. Keeping the capability model separate from live status lets a management system learn a Component's Power States without querying a running device -- and, as Section 2.5 describes, even from a vendor- supplied file before the Component is deployed. 2.2. Capability is Anchored to the Hardware Component A Power State is a property of a physical Component (a line card, a fabric, an optical module), which is exactly the entity that is placed into a low-power state. This document therefore anchors the capability to a Component in the hardware inventory [RFC8348], using the per-node capability mechanism of [RFC9196]: the node-selector selects the /hardware/component entry to which the capability applies. The node-selector is the generic instance-identifier type defined in [RFC8341] and reused by [RFC9196]; although that type originates in the NACM module, it carries no access-control semantics and can address any data node. Because /hardware/component is operational state, the capability is advertised under the operational datastore [RFC8342], as illustrated below: system-capabilities datastore-capabilities [datastore = ietf-datastores:operational] // hardware components live in the operational datastore per-node-capabilities [node-selector = "/ietf-hardware:hardware/component[name='linecard-3']"] // node-selector: a generic RFC 8341 instance-identifier, // resolving here to an RFC 8348 hardware component power-state-capabilities { ... } // added by this document No new correlation identifier is required. The GREEN Power and Energy model already binds each of its energy-entry instances to a hardware Component through the source-component-id leafref to /hw:hardware/hw:component/hw:name. As a result the hardware Claise Expires 26 February 2027 [Page 4] Internet-Draft Power State Capability Discovery August 2026 inventory (RFC 8348), the capability model (this document), and the live operational state ([I-D.ietf-green-power-and-energy-yang]) all refer to one and the same Component name, and no change to the GREEN module is needed. 2.3. Power State Names are Reused, Not Reinvented The supported Power States are identified by identities derived from the power-state base identity already defined in [I-D.ietf-green-power-and-energy-yang] (namely power-state-on, power- state-off, and power-state-sleep). Where a Component supports more than one low-power depth, additional identities are derived from power-state-sleep; such a collection of related states forms a Power State Set, and its member names SHOULD align with the Power State Sets described in [I-D.ietf-green-framework] rather than being independently invented, so that consumers can compare states across vendors. 2.4. The Characterization is a Reusable Grouping The per-state characterization is defined once, as the YANG grouping power-state-capability (Section 4.2). The grouping is used both at the system-wide level and at the per-Component level of [RFC9196], following the same two-level pattern as the companion ietf- notification-capabilities module of [RFC9196]. 2.5. Capability MAY be Provided as Instance Data (RFC 9195) Because the capability is static and platform-specific, it does not have to be read from a running Device. It MAY be published by a vendor, or generated from a product data sheet, as a YANG instance data file per [RFC9195]. An Energy Management System or a planning tool can thereby learn the Power State capabilities of a platform -- which Components can sleep and how much Power they save -- at design or procurement time, before any equipment is deployed. When the Device is running, the same data MAY instead be read from the operational state datastore. The two sources use the identical schema defined here. 3. Relationship to Other Work This document is deliberately narrow: it supplies the missing capability layer that three existing efforts each assume but none provides in a common form. [I-D.ietf-green-power-and-energy-yang] reports, for a Component, the Power State it is in now and its measured Power. This document adds the static complement: the set of Power States that Component can Claise Expires 26 February 2027 [Page 5] Internet-Draft Power State Capability Discovery August 2026 enter and the nominal Power of each, keyed to the same hardware Component. A consumer needs both -- what the Component can do, from this document, and its live status, from the GREEN YANG module. [I-D.many-teas-power-steering] and [I-D.many-lsr-power-group] define a Power Conserving Path Placement Strategy and its IS-IS encoding, which need to know which resources are sleep-capable and their Power Savings Potential. With this capability model both become derived facts rather than separately defined values: a Component is "sleep- capable" when it advertises a Power State derived from power-state- sleep, and its PSP for a given low-power state is simply the difference between the nominal-power of power-state-on and the nominal-power of that state. Those documents can then reference a single capability definition instead of carrying their own. This capability model does not replace those mechanisms, and it does not reduce what they must distribute. The dynamic, load-dependent quantities they carry -- for example, the Power Savings Potential actually available under the current traffic, or the sleeping bandwidth of a link -- change with network conditions and remain theirs to distribute, whether in the IGP or via telemetry. What this document changes is narrower: the static foundation those quantities build on -- which Power States a Component supports, and the rated Power of each -- is defined once here, rather than re-specified, with its own units and semantics, inside each consumer. 4. The Power State Capabilities Model This module advertises the set of supported Power States, not the permitted transitions between them; transition constraints are out of scope. 4.1. Tree Structure The following tree diagram uses the notation defined in [RFC8340]. Claise Expires 26 February 2027 [Page 6] Internet-Draft Power State Capability Discovery August 2026 module: ietf-power-state-capabilities augment /sysc:system-capabilities: +--ro power-state-capabilities +--ro unit-multiplier? identityref +--ro supported-power-state* [power-state] +--ro power-state identityref +--ro nominal-power? uint32 +--ro max-power? uint32 augment /sysc:system-capabilities /sysc:datastore-capabilities /sysc:per-node-capabilities: +--ro power-state-capabilities +--ro unit-multiplier? identityref +--ro supported-power-state* [power-state] +--ro power-state identityref +--ro nominal-power? uint32 +--ro max-power? uint32 4.2. YANG Module This module imports the system capabilities module of [RFC9196] and reuses the power-state and unit-multiplier identities of [I-D.ietf-green-power-and-energy-yang]. module ietf-power-state-capabilities { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-power-state-capabilities"; prefix pscap; import ietf-system-capabilities { prefix sysc; reference "RFC 9196: YANG Modules Describing Capabilities for Systems and Datastore Update Notifications"; } import ietf-power-and-energy { prefix eo; reference "I-D.ietf-green-power-and-energy-yang: A YANG Data Model for Power and Energy Monitoring and Control"; } organization "IETF GREEN (Getting Ready for Energy-Efficient Networking) Working Group"; contact Claise Expires 26 February 2027 [Page 7] Internet-Draft Power State Capability Discovery August 2026 "WG Web: WG List: Author: Benoit Claise "; description "This module augments the system capabilities model defined in RFC 9196 to allow a server to advertise, per hardware Component, the set of Power States that the Component supports together with a static characterization of each such state (the nominal Power the Component draws in that state). The capability is anchored, via the RFC 9196 per-node capability mechanism, to a Component of the hardware inventory defined in RFC 8348. It reuses the 'power-state' and 'unit-multiplier' identities defined in ietf-power-and-energy. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; revision 2026-08-25 { description "Initial revision."; reference "RFC XXXX: Discovering the Power State Capabilities of Components"; } grouping power-state-capability { description "Static characterization of the Power States that a Component supports. This grouping is reusable: it is used both at the system-wide level and at the per-Component level of the RFC 9196 capabilities model."; leaf unit-multiplier { type identityref { base eo:unit-multiplier; } Claise Expires 26 February 2027 [Page 8] Internet-Draft Power State Capability Discovery August 2026 default "eo:multiplier-units"; description "Scale factor applied to every Power value ('nominal-power' and 'max-power') reported in this grouping. This reuses the 'unit-multiplier' identity of ietf-power-and-energy. When not explicitly specified, the default of 'eo:multiplier-units' (10^0 = 1) applies, meaning Power values are expressed in Watts."; } list supported-power-state { key "power-state"; description "The set of Power States supported by the Component, with one entry per supported state."; leaf power-state { type identityref { base eo:power-state; } description "A Power State that the Component supports, identified by an identity derived from the 'power-state' base identity of ietf-power-and-energy (for example 'power-state-on', 'power-state-off', or 'power-state-sleep'). Additional low-power depths are represented by further identities derived from 'power-state-sleep'. The abstract identities 'power-state-admin' and 'power-state-oper' MUST NOT be used here."; } leaf nominal-power { type uint32; units "Watts"; description "The nominal Power drawn by the Component while it is in this Power State, scaled by 'unit-multiplier'. The Power Savings Potential of a low-power state is the difference between the 'nominal-power' of 'power-state-on' and the 'nominal-power' of that low-power state."; } leaf max-power { type uint32; units "Watts"; description Claise Expires 26 February 2027 [Page 9] Internet-Draft Power State Capability Discovery August 2026 "The maximum Power that the Component may draw while in this Power State, scaled by 'unit-multiplier'. This is the per-Power-State counterpart of the Component's Nameplate Power: a rated ceiling for this particular state."; } } } augment "/sysc:system-capabilities" { description "System-wide (Device-level) Power State capabilities that apply unless overridden by a per-Component entry."; container power-state-capabilities { description "Default Power State capabilities for the whole system."; uses power-state-capability; } } augment "/sysc:system-capabilities" + "/sysc:datastore-capabilities" + "/sysc:per-node-capabilities" { description "Per-Component Power State capabilities. The 'node-selector' of the enclosing RFC 9196 'per-node-capabilities' entry selects the Component to which these capabilities apply, typically a '/hw:hardware/hw:component' entry of RFC 8348."; container power-state-capabilities { description "Power State capabilities of the selected Component(s)."; uses power-state-capability; } } } 5. Operational Considerations The capability data defined by this module is essentially static for a given hardware configuration. A server that already implements the GREEN Power and Energy model [I-D.ietf-green-power-and-energy-yang] -- and hence the hardware inventory of [RFC8348] on which it depends -- can expose these capabilities as operational state, or a management system can obtain them out of band as instance data (Section 2.5). Claise Expires 26 February 2027 [Page 10] Internet-Draft Power State Capability Discovery August 2026 The nominal-power and max-power values are optional. A Component MAY advertise the Power States it supports with no Power value; a consumer then learns what the Component can do, but not what each state costs. Where present, these are static, rated figures -- the Power a Component is expected to draw in a Power State, in the spirit of Nameplate Power. They are an approximation: the Power actually drawn, especially in power-state-on, depends on the offered load, the operating temperature, and other environmental conditions, and is therefore network-specific and time-varying. An operator MUST treat nominal-power as a planning baseline, not as a measurement. These values are operational state (config false), not configuration: a Component reports them. Where a rated figure is unavailable, or too coarse for a given purpose, a more precise value can be obtained by measurement -- an Energy Management System can observe the measured instantaneous-power of [I-D.ietf-green-power-and-energy-yang] while the Component is in the corresponding Power State, and use it to supply or refine the advertised value. The dynamic, load-dependent Power Savings Potential that a real-time path placement acts upon is out of scope for this static capability model. In a distributed path-computation architecture it is derived from live conditions and flooded by the IGP (e.g., [I-D.many-teas-power-steering] / [I-D.many-lsr-power-group]); in a centralized architecture a controller can instead collect it via telemetry. This document supplies the stable capability baseline on which those mechanisms build. A consumer MUST NOT assume that a supported low-power Power State may be entered at any given moment; that is a runtime decision, taken by the consumer's policy and configured through the control side of the GREEN model (e.g., a write to power-state-admin, which the Device may accept or reject). It is out of scope here. 6. Security Considerations This section is modeled after the template described in Section 3.7.1 of [RFC9907]. Claise Expires 26 February 2027 [Page 11] Internet-Draft Power State Capability Discovery August 2026 The "ietf-power-state-capabilities" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as the Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040]. These YANG-based management protocols (1) have to use a secure transport layer (e.g., Secure Shell (SSH) [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use mutual authentication. The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. All data nodes defined in this YANG module are read-only ("config false") operational state, which may equivalently be provided as instance data (Section 2.5). The module defines no writable data nodes, no RPC or action operations, and no notifications. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Specifically, the "power-state- capabilities" subtree -- the set of Power States a Component supports and the nominal Power of each -- reveals which Components of a Device can be placed into a low-power state and how much Power that would save. An attacker with read access to this information can identify the resources whose repeated forced wake-up would cause the greatest energy or thrashing amplification, or whose sleeping would most usefully be prevented to degrade capacity. This is the same exposure noted for the corresponding routing advertisements in [I-D.many-lsr-power-group]. Read access to this subtree SHOULD be restricted, and, when the capability is distributed as a YANG instance data file [RFC9195], the file SHOULD be handled with the same care as other platform capability inventories. 7. IANA Considerations This document requests IANA to register the following URI in the "ns" subregistry of the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-power-state-capabilities Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document requests IANA to register the following YANG module in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry: Claise Expires 26 February 2027 [Page 12] Internet-Draft Power State Capability Discovery August 2026 Name: ietf-power-state-capabilities Namespace: urn:ietf:params:xml:ns:yang:ietf-power-state-capabilities Prefix: pscap Reference: RFC XXXX 8. Acknowledgments This work builds directly on the GREEN Power and Energy YANG model and terminology, and on the system capabilities framework of RFC 9196. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9196] Lengyel, B., Clemm, A., and B. Claise, "YANG Modules Describing Capabilities for Systems and Datastore Update Notifications", RFC 9196, DOI 10.17487/RFC9196, February 2022, . [RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A YANG Data Model for Hardware Management", RFC 8348, DOI 10.17487/RFC8348, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . Claise Expires 26 February 2027 [Page 13] Internet-Draft Power State Capability Discovery August 2026 [I-D.ietf-green-power-and-energy-yang] Claise, B., Chen, G., Palmero, M. P., and J. Lindblad, "Power and Energy YANG Module", Work in Progress, Internet-Draft, draft-ietf-green-power-and-energy-yang-03, 4 July 2026, . 10. Informative References [RFC9195] Lengyel, B. and B. Claise, "A File Format for YANG Instance Data", RFC 9195, DOI 10.17487/RFC9195, February 2022, . [RFC9907] Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 9907, DOI 10.17487/RFC9907, March 2026, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . Claise Expires 26 February 2027 [Page 14] Internet-Draft Power State Capability Discovery August 2026 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, . [I-D.ietf-green-terminology] Chen, G., Boucadair, M., Wu, Q., Contreras, L. M., and M. P. Palmero, "Terminology for Energy Efficiency Network Management", Work in Progress, Internet-Draft, draft-ietf- green-terminology-02, 30 June 2026, . [I-D.ietf-green-framework] Claise, B., Contreras, L. M., Lindblad, J., Palmero, M. P., Stephan, E., and Q. Wu, "Framework for Energy Efficiency Management", Work in Progress, Internet-Draft, draft-ietf-green-framework-02, 5 July 2026, . [I-D.many-teas-power-steering] Barth, C., Li, T., Beeram, V. P., and R. P. Bonica, "A Power Conserving Path Placement Strategy (PCPPS)", Work in Progress, Internet-Draft, draft-many-teas-power-steering- 01, 22 June 2026, . [I-D.many-lsr-power-group] Barth, C., Li, T., Beeram, V. P., and R. P. Bonica, "Using IS-IS To Advertise Power Group Membership", Work in Progress, Internet-Draft, draft-many-lsr-power-group-03, 22 June 2026, . Appendix A. Example The following JSON [RFC7951] instance data shows the Power State capabilities of a single line card, "linecard-3", reported as a per- Component capability against the operational state datastore. The line card supports two Power States: fully on, drawing 200 Watts, and asleep, drawing 15 Watts. The same encoding, wrapped in an instance- data-set per [RFC9195], could be shipped by the vendor before deployment. Claise Expires 26 February 2027 [Page 15] Internet-Draft Power State Capability Discovery August 2026 { "ietf-system-capabilities:system-capabilities": { "datastore-capabilities": [{ "datastore": "ietf-datastores:operational", "per-node-capabilities": [{ "node-selector": "/ietf-hardware:hardware/component[name='linecard-3']", "ietf-power-state-capabilities:power-state-capabilities": { "supported-power-state": [{ "power-state": "ietf-power-and-energy:power-state-on", "nominal-power": 200 },{ "power-state": "ietf-power-and-energy:power-state-sleep", "nominal-power": 15 }] } }] }] } } From these values, the Power Savings Potential of the sleep state (power-state-sleep) is derived by subtraction: 200 - 15 = 185 Watts, consistent with the Power Savings Potential convention of [I-D.many-teas-power-steering]. The current Power State and measured Power of the same line card are reported separately by [I-D.ietf-green-power-and-energy-yang], against the same Component name. Author's Address Benoit Claise Everything OPS & Arrcus Email: benoit@everything-ops.net Claise Expires 26 February 2027 [Page 16]