Discovering the Power State Capabilities of Components
draft-claise-green-capability-discovery-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Benoît Claise | ||
| Last updated | 2026-08-25 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-claise-green-capability-discovery-00
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: <https://datatracker.ietf.org/wg/green/>
WG List: <mailto:green@ietf.org>
Author: Benoit Claise <mailto:benoit@everything-ops.net>";
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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, <https://www.rfc-editor.org/info/rfc9196>.
[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,
<https://www.rfc-editor.org/info/rfc8348>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
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, <https://datatracker.ietf.org/doc/html/draft-
ietf-green-power-and-energy-yang-03>.
10. Informative References
[RFC9195] Lengyel, B. and B. Claise, "A File Format for YANG
Instance Data", RFC 9195, DOI 10.17487/RFC9195, February
2022, <https://www.rfc-editor.org/info/rfc9195>.
[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, <https://www.rfc-editor.org/info/rfc9907>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[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,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[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,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
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,
<https://www.rfc-editor.org/info/rfc7951>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-green-
terminology-02>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-green-
framework-02>.
[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, <https://datatracker.ietf.org/doc/html/
draft-many-teas-power-steering-01>.
[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, <https://datatracker.ietf.org/doc/html/
draft-many-lsr-power-group-03>.
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]