Power and Energy YANG Module
draft-ietf-green-power-and-energy-yang-03
| Document | Type | Active Internet-Draft (green WG) | |
|---|---|---|---|
| Authors | Benoît Claise , Gen Chen , Marisol Palmero , Jan Lindblad | ||
| Last updated | 2026-07-08 (Latest revision 2026-07-04) | ||
| Replaces | draft-bcmj-green-power-and-energy-yang | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Yang Validation | 0 errors, 0 warnings | ||
| Additional resources |
GitHub Repository
Mailing list discussion |
||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-green-power-and-energy-yang-03
GREEN C. Benoit
Internet-Draft Everything OPS
Intended status: Standards Track C. Gen
Expires: 5 January 2027 Huawei
M. Palmero
Individual
J. Lindblad
All For Eco
4 July 2026
Power and Energy YANG Module
draft-ietf-green-power-and-energy-yang-03
Abstract
This document defines the YANG data model for Power and Energy
monitoring of devices within or connected to communication networks.
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 5 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Benoit, et al. Expires 5 January 2027 [Page 1]
Internet-Draft GREEN-PEM-YANG July 2026
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. The GREEN Framework . . . . . . . . . . . . . . . . . . . . . 4
3. Power and Energy Data Model . . . . . . . . . . . . . . . . . 4
4. Relationship to the Hardware YANG Data Model . . . . . . . . 6
5. Relationship to the EMAN Work . . . . . . . . . . . . . . . . 7
6. Power and Energy YANG Module . . . . . . . . . . . . . . . . 7
7. Operational Considerations . . . . . . . . . . . . . . . . . 28
7.1. Measurement Accuracy and Data Source Classification . . . 29
7.2. Industry-Standard Certifications . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
9.1. GREEN Certification Type Registry . . . . . . . . . . . . 34
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
11.1. Normative References . . . . . . . . . . . . . . . . . . 35
11.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction
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.
This document defines a YANG data model for Power and Energy
Monitoring and control of devices within or connected to
communication networks, for the use cases document in
[I-D.ietf-green-use-cases-01].
The data model includes both the monitoring and control of Energy
Objects for networked devices.
Benoit, et al. Expires 5 January 2027 [Page 2]
Internet-Draft GREEN-PEM-YANG July 2026
This YANG data model is based on the "GREEN framework"
[I-D.ietf-green-framework-01], following the "GREEN terminology"
[I-D.ietf-green-terminology-02].
Power and Energy Monitoring and Control can be applied to devices in
communication networks. All identifiable devices with measurable or
representable Power and Energy characteristics fall within the scope
of this specification. Target devices include (but are not limited
to) routers, switches, Power over Ethernet (PoE) endpoints, smart
PDU, storage and compute servers, etc.
Where applicable, device monitoring extends to the components of the
device as well as software and service running on the device. As a
result, the metrics to be monitored include Device Level Energy
Efficiency (DLEE), Component Level Energy Efficiency (CLEE) and
potential Service Level Energy Efficiency (SLEE) at the orchestrator-
level, etc. For example, a router can contain components such as
Line Processing Unit (LPU), Switch Fabric Unit (SFU), Main Processing
Unit (MPU).
1.1. Terminology
This document makes use of the terms defined in
[I-D.ietf-green-terminology-02]:
- Power
- Energy
- Energy Management
- Energy Monitoring
- Energy Control
- Energy Efficiency/Energy Efficiency Ratio
- Device Level Energy Efficiency (DLEE)
- Component Level Energy Efficiency (CLEE)
- Service Level Energy Efficiency (SLEE)
This document makes use of the terms defined in
[I-D.ietf-green-framework-01]
- Energy Object
The terms reused from [I-D.ietf-green-terminology-02] and
[I-D.ietf-green-framework-01] are capitalized in this specification.
This document uses the terms Power and Energy in accordance with
[I-D.ietf-green-terminology-02]. Power refers to the instantaneous
rate at which a device consumes or produces electrical energy
(typically expressed in Watts). Energy, by contrast, represents the
cumulative amount of work performed over time (typically expressed in
Benoit, et al. Expires 5 January 2027 [Page 3]
Internet-Draft GREEN-PEM-YANG July 2026
Joules or Watt-hours). Both concepts are required within this YANG
module. Power enables real-time monitoring, control, and
optimization of device operation, while Energy provides a time-
integrated view necessary for accounting, reporting, and even for
sustainability analysis. This specification includes both Power and
Energy attributes.
The terminology for describing YANG modules is defined in [RFC7950].
The meanings of the symbols in the YANG tree diagrams are defined in
[RFC8340].
2. The GREEN Framework
The "GREEN framework" described in [I-D.ietf-green-framework-01]
covers monitoring and controlling devices and components where
monitoring includes measuring Power, Energy, demand and attributes of
Power.
For the whole picture of the monitoring interfaces and the relevant
requirements, please refer to "GREEN reference model" in section 4 in
[I-D.ietf-green-framework-01].
3. Power and Energy Data Model
The Power and Energy Data Model reports the Power and Energy
consumption of each Energy Object as well as the units, sign,
measurement accuracy, etc.
A containment tree view of the Power and Energy Monitoring is
presented. The model differentiates the power-state-admin and power-
state-oper YANG leaves, representing the intended and operational
power states respectively. The two leaves together form the complete
power state management interface. The operational tree ('container
energy-objects') will typically contain a significantly larger number
of instances than the configuration tree ('container energy-
control'). The configuration tree, which is limited to explicitly
provisioned entries, provides a compact self-contained view of the
intent. For this reason, although an NMDA (Network Management
Datastore Architecture) design with a single "state" leaf (per
[RFC8342]) was considered, it is not adopted in this document.
Finally, note that the instance is in the configuration tree, having
a required-instance false leafref to operational tree instance.
Benoit, et al. Expires 5 January 2027 [Page 4]
Internet-Draft GREEN-PEM-YANG July 2026
The relationship list models the relationship between an Energy
Object and its peer Energy Objects, using the energy-relationship-
type identities: powered-by and powering (Power Source Relationship),
metered-by and metering (Metering Relationship), aggregated-by and
aggregating (Aggregation Relationship), and enabled-by and enabling
(Functional Enablement Relationship).
Each pair of identities expresses the same relationship from the
perspective of each participant (e.g., if Energy Object A is powered-
by Energy Object B, then Energy Object B is powering Energy Object
A). These relationship categories, including their use for power/
metering topology discovery and for preventing double-counting of
Energy values, are defined in [I-D.ietf-green-framework]. For each
relationship type, one or more peer Energy Objects can be identified
via the id leaf within the peer list, a string value that is
typically the peer's UUID when known, or another locally unique
identifier, together with human-readable details captured in the
details leaf, otherwise.
Regarding relationships among Energy Objects, this document does not
provide a mechanism to configure relationships on the device (i.e.,
there is no relationship list under /energy-control); the
relationship list under /energy-objects/energy-entry is read-only
operational data (config false).
For relationships between components within the same device (e.g.,
between a Line Processing Unit (LPU) and a Switch Fabric Unit (SFU)),
the device can typically determine and populate this data directly,
without requiring external configuration.
Relationships between Energy Objects located on different devices are
generally established and maintained at the controller or Energy
Management System (EnMS) level, which has visibility into the broader
network topology, as discussed in [I-D.ietf-green-framework-01]. A
device may still report a known inter-device relationship (e.g.,
using the peer's network-level UUID) when it has been made aware of
it, but this module does not provide a mechanism to configure such
relationships on the device itself.
Benoit, et al. Expires 5 January 2027 [Page 5]
Internet-Draft GREEN-PEM-YANG July 2026
module: ietf-power-and-energy
+--ro energy-objects
| +--ro energy-entry* [object-id]
| +--ro object-id string
| +--ro source-component-id? -> /hw:hardware/component/name
| +--ro power
| | +--ro instantaneous-power int32
| | +--ro nameplate-power? uint32
| | +--ro unit-multiplier identityref
| | +--ro data-source-accuracy? identityref
| | +--ro power-factor? power-factor
| | +--ro measurement-local? boolean
| +--ro energy
| | +--ro total-energy-consumed? uint64
| | +--ro total-energy-delivered? uint64
| | +--ro unit-multiplier? identityref
| | +--ro data-source-accuracy? identityref
| | +--ro measurement-local? boolean
| | +--ro certifications* identityref
| +--ro power-state
| | +--ro power-state-oper? identityref
| +--ro relationship* [type]
| +--ro type identityref
| +--ro peer* [id]
| +--ro id string
| +--ro details? string
+--rw energy-control
+--rw energy-entry* [object-id]
+--rw object-id string
+--rw power-state
+--rw power-state-oper? -> /energy-objects/energy-entry/power-state/power-state-oper
+--rw power-state-admin? identityref
4. Relationship to the Hardware YANG Data Model
The ietf-hardware YANG module [RFC8348] is required by the Power and
Energy YANG module. In the ietf-hardware YANG model, there are three
identifiers for hardware components, which are "name", "physical-
index" and "uuid". Among them, "name" is the key to "List of
components", "physical-index" matches entPhysicalIndex in the legacy
Entity MIB [RFC6933] if it exists, and UUID is the Universally
Unified IDentifier [RFC9562] of the component.
In the Power and Energy YANG Module defined in this specification,
there is a leaf named "source-component-id" which refers to the
component name in the ietf-hardware model. The "source-component-id"
can in turn reuse the UUID in the ietf-hardware YANG module.
Benoit, et al. Expires 5 January 2027 [Page 6]
Internet-Draft GREEN-PEM-YANG July 2026
The mapping between energy-object entries in this YANG Module and the
hardware-components in ietf-hardware YANG module [RFC8348] is
designed to be 1:1, architecturally aligning each energy-entry with
exactly one physical hardware component via source-component-id.
There are also cases where the controllers also generate their own
set of UUIDs for the hardware (components). In such a case, it might
be necessary to document the mappings between the UUIDs generated on
the hardware side and the UUIDs on the controller side. Basically,
the devices (such as routers) generate the UUID and the controller
can query it.
The ietf-hardware YANG module [RFC8348] allows discovering all the
device components, including the containment tree, and the parent/
child relationship, which is important for energy/power aggregation
(see the contains-child relationship in RFC 8348).
5. Relationship to the EMAN Work
The EMAN IETF Working Group (https://datatracker.ietf.org/wg/eman/
about/) is a concluded Working Group that produced a couple of RFCs
in the domain of Power and Energy. The Working Group produced MIB
modules for monitoring and control for power and energy, for the
context information, for battery monitoring, and an extension to the
ENTITY-MIB to add the UUID definition [RFC6933].
For various reasons, those MIB modules were not implemented by
vendors.
The Power and Energy data model defined in this specification uses
the Monitoring and Control MIB for Power and Energy [RFC7460] as a
starting point to discuss the solution to the different use cases in
[I-D.ietf-green-use-cases-01].
However, it has not been the goal to simply map the MIB module to a
YANG module. The changes compared to the EMAN MIB modules are mainly
due to the alignment with the up-to-date requirements of the network
carriers on Energy Efficiency. Compared to the MIB modules, some
definitions and types are optimized, some new Energy Objects are
added and some legacy Energy Objects are removed accordingly.
6. Power and Energy YANG Module
This YANG Module is used to monitor and control Power and Energy
usage of network devices and the components on these devices.
Benoit, et al. Expires 5 January 2027 [Page 7]
Internet-Draft GREEN-PEM-YANG July 2026
<CODE BEGINS> file "ietf-power-and-energy@2026-07-02.yang"
module ietf-power-and-energy {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-power-and-energy";
prefix eo;
import ietf-hardware {
prefix hw;
reference
"RFC 8348: A YANG Data Model for Hardware Management";
}
import iana-power-and-energy {
prefix ianaeo;
reference
"IANA-defined identities for power and energy class";
}
organization
"IETF GREEN Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/green/>
WG List: <mailto:green@ietf.org>";
description
"This YANG module specifies for Power and Energy monitoring and
control of devices within or connected to communication networks.
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 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
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).
Benoit, et al. Expires 5 January 2027 [Page 8]
Internet-Draft GREEN-PEM-YANG July 2026
This version of this YANG module is part of RFC XXX
(https://www.rfc-editor.org/info/rfcXXX); see the RFC itself
for full legal notices.";
revision 2026-07-02 {
description
"Initial revision";
reference
"RFC XXX: Energy Object YANG Data Model";
}
identity data-source-accuracy {
description
"Base identity for all possible data accuracy types.
This identity serves as the root for a hierarchy of accuracy
types, allowing for extensibility while maintaining alignment
with current and future industry standards.
The hierarchy, as defined in this YANG module, is as follows.
Other modules may extend this hierarchy with additional
accuracy base- and sub-types as needed.
data-source-accuracy
├── accuracy-like-parent
├── accuracy-unknown
│ └── accuracy-unavailable
├── accuracy-estimated
│ ├── accuracy-static
│ ├── accuracy-historic
│ └── accuracy-learned
└── accuracy-measured
├── accuracy-measured-bronze
│ ├── accuracy-measured-bronze-1
│ ├── accuracy-measured-bronze-10
│ ├── accuracy-measured-bronze-100
│ └── accuracy-measured-bronze-1000
├── accuracy-measured-silver
│ └── accuracy-measured-silver-...
├── accuracy-measured-gold
│ └── accuracy-measured-gold-...
├── accuracy-measured-red
│ └── accuracy-measured-red-...
└── accuracy-measured-ones
The accuracy levels under accuracy-measured are based on
percent-wise accuracy classes:
bronze: +/- 30%
silver: +/- 10%
Benoit, et al. Expires 5 January 2027 [Page 9]
Internet-Draft GREEN-PEM-YANG July 2026
gold: +/- 5%
red: +/- 2%
In addition, the accuracy-measured-ones identity indicates
a power data measurement with all digits valid, except trailing
zeros.
Since percent-wise accuracy works poorly for very small
values, standards such as IEC 62053, IEC 61850-7-4 and
IEEE 1451 define accuracy classes based on a combination of
percent-wise accuracy and absolute accuracy thresholds.
E.g. +/-1 % of reading + +/-0.05 absolute units.
Similarly, for each percent-wise accuracy class, this module
defines a few absolute tolerance classes, indicated by
suffixes to the accuracy identity names. The suffixes indicate
absolute accuracy thresholds:
no suffix: +/-0.5 absolute units
-1: +/-1 absolute unit
-10: +/-10 absolute units
-100: +/-100 absolute units
-1000: +/-1000 absolute units
Thus, for example, accuracy-measured-gold-10 indicates
a power data measurement with an accuracy of either
+/-5% or +/-10 absolute units, whichever is larger.
For example, a power sensor reading might report a value
of 16250, with unit multiplier of milli (10^-3), under
accuracy-measured-gold-10. This indicates that the actual
power value is between 16.2375 and 16.2625 Watts, since
5% of 16.250 Watts is 0.8125 Watts, which is greater than
the absolute threshold of 10 milliwatts (0.010 W).
At another time, the same sensor might report a value
of 150, with unit multiplier of milli (10^-3), under
accuracy-measured-gold-10. This indicates that the actual
power value is between 0.140 and 0.160 Watts, since 5% of
0.150 Watts is only 0.0075 Watts, which is less than the
absolute threshold of 10 milliwatts (0.010 W).";
}
identity accuracy-unknown {
base data-source-accuracy;
description
"The accuracy of the power data is unknown.";
}
identity accuracy-unavailable {
base accuracy-unknown;
description
Benoit, et al. Expires 5 January 2027 [Page 10]
Internet-Draft GREEN-PEM-YANG July 2026
"A power data is not available for some reason, such
as a sensor failure or a component being powered off.";
}
identity accuracy-like-parent {
base data-source-accuracy;
description
"The accuracy of the power/energy data is the same as this energy
object's parent object. This identity is useful for hierarchical
energy objects where child objects inherit the accuracy
characteristics.";
}
identity accuracy-estimated {
base data-source-accuracy;
description
"The power data is estimated, perhaps based on a model,
history or calculation rather than a direct measurement.";
}
identity accuracy-static {
base accuracy-estimated;
description
"The power data is based on static data, such as
manufacturer specifications, datasheet of typical power values
or nameplate ratings, rather than real-time measurements.";
}
identity accuracy-historic {
base accuracy-estimated;
description
"The power data is based on an historic measurement data
for this specific system and usage pattern.";
}
identity accuracy-learned {
base accuracy-estimated;
description
"The power data is based on an machine learning
model prediction.";
}
identity accuracy-measured {
base data-source-accuracy;
description
"The power data is a direct, real-time measurement
from a sensor.";
}
identity accuracy-measured-bronze {
base accuracy-measured;
description
"The power data is a direct, real-time measurement
from a sensor with precision and accuracy such that
|actual-sensor| <= sensor * 30% OR |actual-sensor| <= 0.5";
Benoit, et al. Expires 5 January 2027 [Page 11]
Internet-Draft GREEN-PEM-YANG July 2026
}
identity accuracy-measured-bronze-1 {
base accuracy-measured-bronze;
description
"The power data is a direct, real-time measurement
from a sensor with precision and accuracy such that
|actual-sensor| <= sensor * 30% OR |actual-sensor| <= 1";
}
identity accuracy-measured-bronze-10 {
base accuracy-measured-bronze;
description
"The power data is a direct, real-time measurement
from a sensor with precision and accuracy such that
|actual-sensor| <= sensor * 30% OR |actual-sensor| <= 10";
}
identity accuracy-measured-bronze-100 {
base accuracy-measured-bronze;
description
"The power data is a direct, real-time measurement
from a sensor with precision and accuracy such that
|actual-sensor| <= sensor * 30% OR |actual-sensor| <= 100";
}
identity accuracy-measured-bronze-1000 {
base accuracy-measured-bronze;
description
"The power data is a direct, real-time measurement
from a sensor with precision and accuracy such that
|actual-sensor| <= sensor * 30% OR |actual-sensor| <= 1000";
}
identity accuracy-measured-silver {
base accuracy-measured;
description
"The power data is a direct, real-time measurement
from a sensor with precision and accuracy such that
|actual-sensor| <= sensor * 10% OR |actual-sensor| <= 0.5";
}
identity accuracy-measured-silver-1 {
base accuracy-measured-silver;
description
"The power data is a direct, real-time measurement
from a sensor with precision and accuracy such that
|actual-sensor| <= sensor * 10% OR |actual-sensor| <= 1";
}
identity accuracy-measured-silver-10 {
base accuracy-measured-silver;
description
"The power data is a direct, real-time measurement
from a sensor with precision and accuracy such that
Benoit, et al. Expires 5 January 2027 [Page 12]
Internet-Draft GREEN-PEM-YANG July 2026
|actual-sensor| <= sensor * 10% OR |actual-sensor| <= 10";
}
identity accuracy-measured-silver-100 {
base accuracy-measured-silver;
description
"The power data is a direct, real-time measurement
from a sensor with precision and accuracy such that
|actual-sensor| <= sensor * 10% OR |actual-sensor| <= 100 ";
}
identity accuracy-measured-silver-1000 {
base accuracy-measured-silver;
description
"The power data is a direct, real-time measurement
from a sensor with precision and accuracy such that
|actual-sensor| <= sensor * 10% OR |actual-sensor| <= 1000";
}
identity accuracy-measured-gold {
base accuracy-measured;
description
"The power data is a direct, real-time measurement
from a sensor with precision and accuracy such that
|actual-sensor| <= sensor * 5% OR |actual-sensor| <= 0.5";
}
identity accuracy-measured-gold-1 {
base accuracy-measured-gold;
description
"The power data is a direct, real-time measurement
from a sensor with precision and accuracy such that
|actual-sensor| <= sensor * 5% OR |actual-sensor| <= 1";
}
identity accuracy-measured-gold-10 {
base accuracy-measured-gold;
description
"The power data is a direct, real-time measurement
from a sensor with precision and accuracy such that
|actual-sensor| <= sensor * 5% OR |actual-sensor| <= 10";
}
identity accuracy-measured-gold-100 {
base accuracy-measured-gold;
description
"The power data is a direct, real-time measurement
from a sensor with precision and accuracy such that
|actual-sensor| <= sensor * 5% OR |actual-sensor| <= 100";
}
identity accuracy-measured-gold-1000 {
base accuracy-measured-gold;
description
"The power data is a direct, real-time measurement
Benoit, et al. Expires 5 January 2027 [Page 13]
Internet-Draft GREEN-PEM-YANG July 2026
from a sensor with precision and accuracy such that
|actual-sensor| <= sensor * 5% OR |actual-sensor| <= 1000";
}
identity accuracy-measured-red {
base accuracy-measured;
description
"The power data is a direct, real-time measurement
from a sensor with precision and accuracy such that
|actual-sensor| <= sensor * 2% OR |actual-sensor| <= 0.5";
}
identity accuracy-measured-red-1 {
base accuracy-measured-red;
description
"The power data is a direct, real-time measurement
from a sensor with precision and accuracy such that
|actual-sensor| <= sensor * 2% OR |actual-sensor| <= 1";
}
identity accuracy-measured-red-10 {
base accuracy-measured-red;
description
"The power data is a direct, real-time measurement
from a sensor with precision and accuracy such that
|actual-sensor| <= sensor * 2% OR |actual-sensor| <= 10";
}
identity accuracy-measured-red-100 {
base accuracy-measured-red;
description
"The power data is a direct, real-time measurement
from a sensor with precision and accuracy such that
|actual-sensor| <= sensor * 2% OR |actual-sensor| <= 100";
}
identity accuracy-measured-red-1000 {
base accuracy-measured-red;
description
"The power data is a direct, real-time measurement
from a sensor with precision and accuracy such that
|actual-sensor| <= sensor * 2% OR |actual-sensor| <= 1000";
}
identity accuracy-measured-ones {
base accuracy-measured;
description
"The power data is a direct, real-time measurement
from a sensor with all digits valid, except trailing zeros.
For example, a sensor reading of 12300 represents
a sensor value between 12250 and 12350.";
}
typedef power-factor {
Benoit, et al. Expires 5 January 2027 [Page 14]
Internet-Draft GREEN-PEM-YANG July 2026
type uint8 {
range "0 .. 100";
}
default 100;
description
"The percent value of the power factor measurement.
Leaf often omitted, implying 100%.";
}
identity power-state {
description
"Base identity for all possible power states. This identity
serves as the root for a hierarchy of power states, allowing
for extensibility while maintaining alignment with the IANA
Power State Set Registry.";
reference
"IANA: Power State Set Registry:
https://www.iana.org/assignments/power-state-sets/";
}
identity power-state-admin {
base power-state;
description
"Base identity for administratively requested power states. The
administrative power state indicates the desired power state
requested for the Energy Object by a management system.";
}
identity power-state-oper {
base power-state;
description
"Base identity for operational power states. The operational
power state indicates the actual current power state of the
Energy Object. A difference between the administrative state
and the operational state indicates that the Energy Object is
transitioning between power states.";
}
identity power-state-on {
base power-state;
description "full power on.";
reference
"IANA: Power State Set Registry (ieee1621-power-state-set):
https://www.iana.org/assignments/power-state-sets/power-state-sets.xhtml#ieee1621";
}
identity power-state-off {
base power-state;
description "power off.";
reference
"IANA: Power State Set Registry (ieee1621-power-state-set):
https://www.iana.org/assignments/power-state-sets/power-state-sets.xhtml#ieee1621";
Benoit, et al. Expires 5 January 2027 [Page 15]
Internet-Draft GREEN-PEM-YANG July 2026
}
identity power-state-sleep {
base power-state;
description "low-power state.";
reference
"IANA: Power State Set Registry (ieee1621-power-state-set):
https://www.iana.org/assignments/power-state-sets/power-state-sets.xhtml#ieee1621";
}
identity unit-multiplier {
description
"Base identity for unit multipliers as defined in IEC 61850-7-3
Annex A. These represent exponents of 10 for scaling units
associated with the integer units used to measure the power or
energy.
yocto(-24), -- 10^-24
zepto(-21), -- 10^-21
atto(-18), -- 10^-18
femto(-15), -- 10^-15
pico(-12), -- 10^-12
nano(-9), -- 10^-9
micro(-6), -- 10^-6
milli(-3), -- 10^-3
units(0), -- 10^0
kilo(3), -- 10^3
mega(6), -- 10^6
giga(9), -- 10^9
tera(12), -- 10^12
peta(15), -- 10^15
exa(18), -- 10^18
zetta(21), -- 10^21
yotta(24) -- 10^24
";
}
identity multiplier-yocto {
base unit-multiplier;
description
"Represents a multiplier of 10^-24 associated with the
integer units used to measure the power or energy.";
}
identity multiplier-zepto {
base unit-multiplier;
description
"Represents a multiplier of 10^-21 associated with the
integer units used to measure the power or energy.";
}
identity multiplier-atto {
base unit-multiplier;
description
Benoit, et al. Expires 5 January 2027 [Page 16]
Internet-Draft GREEN-PEM-YANG July 2026
"Represents a multiplier of 10^-18 associated with the
integer units used to measure the power or energy.";
}
identity multiplier-femto {
base unit-multiplier;
description
"Represents a multiplier of 10^-15 associated with the
integer units used to measure the power or energy.";
}
identity multiplier-pico {
base unit-multiplier;
description
"Represents a multiplier of 10^-12 associated with the
integer units used to measure the power or energy.";
}
identity multiplier-nano {
base unit-multiplier;
description
"Represents a multiplier of 10^-9 associated with the
integer units used to measure the power or energy.";
}
identity multiplier-micro {
base unit-multiplier;
description
"Represents a multiplier of 10^-6 (0.000001) associated with the
integer units used to measure the power or energy.";
}
identity multiplier-milli {
base unit-multiplier;
description
"Represents a multiplier of 10^-3 (0.001) associated with the
integer units used to measure the power or energy.";
}
identity multiplier-units {
base unit-multiplier;
description
"Represents a multiplier of 10^0 (1) associated with
the integer units used to measure the power or energy.";
}
identity multiplier-kilo {
base unit-multiplier;
description
"Represents a multiplier of 10^3 (1,000) associated with the
integer units used to measure the power or energy.";
}
identity multiplier-mega {
base unit-multiplier;
description
Benoit, et al. Expires 5 January 2027 [Page 17]
Internet-Draft GREEN-PEM-YANG July 2026
"Represents a multiplier of 10^6 (1,000,000) associated with
the integer units used to measure the power or energy.";
}
identity multiplier-giga {
base unit-multiplier;
description
"Represents a multiplier of 10^9 (1,000,000,000) associated
with the integer units used to measure the power or energy.";
}
identity multiplier-tera {
base unit-multiplier;
description
"Represents a multiplier of 10^12 associated
with the integer units used to measure the power or energy.";
}
identity multiplier-peta {
base unit-multiplier;
description
"Represents a multiplier of 10^15 associated
with the integer units used to measure the power or energy.";
}
identity multiplier-exa {
base unit-multiplier;
description
"Represents a multiplier of 10^18 associated
with the integer units used to measure the power or energy.";
}
identity multiplier-zetta {
base unit-multiplier;
description
"Represents a multiplier of 10^21 associated
with the integer units used to measure the power or energy.";
}
identity multiplier-yotta {
base unit-multiplier;
description
"Represents a multiplier of 10^24 associated
with the integer units used to measure the power or energy.";
}
identity energy-relationship-type {
description "Base identity for energy object relationships";
}
identity powered-by {
base energy-relationship-type;
description "Energy Object A is powered by Energy Object B";
}
identity powering {
base energy-relationship-type;
Benoit, et al. Expires 5 January 2027 [Page 18]
Internet-Draft GREEN-PEM-YANG July 2026
description "Energy Object A is powering Energy Object B";
}
identity metered-by {
base energy-relationship-type;
description "Energy Object A is metered by Energy Object B";
}
identity metering {
base energy-relationship-type;
description "Energy Object A is metering Energy Object B";
}
identity aggregated-by {
base energy-relationship-type;
description "Energy Object A is aggregated by Energy Object B";
}
identity aggregating {
base energy-relationship-type;
description "Energy Object A is aggregating Energy Object B";
}
identity enabled-by {
base energy-relationship-type;
description
"Energy Object A is enabled by Energy Object B. B must be
operational for A to function correctly";
}
identity enabling {
base energy-relationship-type;
description
"Energy Object A is enabling Energy Object B. A must be
operational for B to function correctly.
The inverse relationship is 'enabled-by'.";
}
container energy-objects {
config false;
description
"Energy objects container for power and energy attributes.";
list energy-entry {
key "object-id";
description
"Power and energy entry for an energy object, indexed by object id.
Each entry contains the complete set of power and energy attributes
for a specific physical component.";
leaf object-id {
type string;
description
"An identifier that uniquely identifies the energy object";
}
Benoit, et al. Expires 5 January 2027 [Page 19]
Internet-Draft GREEN-PEM-YANG July 2026
leaf source-component-id {
type leafref {
path "/hw:hardware/hw:component/hw:name";
}
description
"Reference to the component name in the ietf-hardware
model. This leaf creates a direct semantic link between the
power/energy attributes and the physical component they
describe.";
reference
"RFC 8348: A YANG Data Model for Hardware Management";
}
container power {
description
"Container for power measurement attributes.";
leaf instantaneous-power {
type int32;
units "Watts";
mandatory true;
description
"The power usage measurement for the energy object right now.
This value represents the instantaneous power consumption
of the component. This value is specified in SI units of watts
with the magnitude of watts (milliwatts, kilowatts, etc.) indicated
separately as unit-multiplier in this container. Positive values
indicate power consumption, while negative values can indicate power
generation (e.g., for devices with battery backup or
renewable energy sources).";
}
leaf nameplate-power {
type uint32;
units "Watts";
description
"The nameplate power rating of an energy object. This is
the maximum power that the energy object is designed to consume or
produce, as specified by the manufacturer. Essential for
power budget calculations and capacity planning.";
}
leaf unit-multiplier {
type identityref {
base unit-multiplier;
}
mandatory true;
description
Benoit, et al. Expires 5 January 2027 [Page 20]
Internet-Draft GREEN-PEM-YANG July 2026
"The unit multiplier used to measure the power.
This multiplier applies to both instantaneous-power and nameplate-power
values, allowing representation of power values from milliwatts
to gigawatts using integer arithmetic.";
}
leaf data-source-accuracy {
type identityref {
base data-source-accuracy;
}
default accuracy-like-parent;
description
"The accuracy of the power data source. Indicates whether
the data source is a direct measurement, an estimate, or
unavailable and also the accuracy level of the data source.
By default, the accuracy is inherited from the parent energy
object, facilitating hierarchical accuracy definitions
without the need to specify accuracy at every level.
This metadata is crucial for network management
applications to assess the reliability and accuracy of the
power data.";
}
leaf power-factor {
type power-factor;
description
"The percent value of the power factor measurement for the
energy object. This information is important for
understanding the electrical characteristics of the energy object
and for correctly interpreting the power data.";
}
leaf measurement-local {
type boolean;
description
"Indicates whether the power measurement is local (true) or
remote (false). A local measurement is taken directly at
the energy object, while a remote measurement is collected from
an external source. This information can be useful for
troubleshooting and understanding the data source.";
}
}
container energy {
description
"Container for energy measurement attributes.";
leaf total-energy-consumed {
Benoit, et al. Expires 5 January 2027 [Page 21]
Internet-Draft GREEN-PEM-YANG July 2026
type uint64;
units "Watt-hours";
description
"The total cumulative energy consumed by the energy object
since the last reset. This value is specified as
watt-hours with the magnitude of watt-hours (milliwatt-hours,
kilowatt-hours, etc.) indicated separately as unit-multiplier
in this container. This value is useful for tracking
overall energy usage over time for billing, reporting,
or optimization purposes.";
}
leaf total-energy-delivered {
type uint64;
units "Watt-hours";
description
"The total cumulative energy delivered by the energy object
since the last reset. This value is specified as
watt-hours with the magnitude of watt-hours (milliwatt-hours,
kilowatt-hours, etc.) indicated separately as unit-multiplier
in this container. This value is relevant for energy objects
capable of generating power, such as those with renewable
energy sources or battery backup systems, or capable of providing
energy to other energy objects (e.g., PoE switches).";
}
leaf unit-multiplier {
type identityref {
base unit-multiplier;
}
default "multiplier-units";
description
"This multiplier applies to both total-energy-consumed and
total-energy-delivered values. It determines the scale of
the energy measurements, allowing representation of energy
values from milliwatt-hours to gigawatt-hours using
integer arithmetic. When not explicitly specified, the
default value of multiplier-units (10^0 = 1) applies,
meaning values are expressed in Watt-hours.";
}
leaf data-source-accuracy {
type identityref {
base data-source-accuracy;
}
default accuracy-like-parent;
description
"The accuracy of the energy data source. Indicates whether
the data source is a direct measurement, an estimate, or
Benoit, et al. Expires 5 January 2027 [Page 22]
Internet-Draft GREEN-PEM-YANG July 2026
unavailable and also the accuracy level of the data source.
By default, the accuracy is inherited from the parent energy
object, facilitating hierarchical accuracy definitions
without the need to specify accuracy at every level.
This metadata is crucial for network management
applications to assess the reliability and accuracy of the
energy data.";
}
leaf measurement-local {
type boolean;
description
"Indicates whether the energy measurement is local (true) or
remote (false). A local measurement is taken directly at
the energy object, while a remote measurement is collected from
an external source. This information can be useful for
troubleshooting and understanding the data source.";
}
leaf-list certifications {
type identityref {
base ianaeo:certification-type;
}
description
"List of certifications applicable to this energy object. If
this list is empty, the energy object has no certifications.";
}
}
container power-state {
description
"Container for Power state monitoring.";
leaf power-state-oper {
type identityref {
base power-state-oper;
}
description
"The actual operational power state of the Energy Object.
This reflects the current state, which may differ from the
admin-state during transitions. This leaf is the
operational counterpart of the administratively set
'power-state-admin' in /energy-control/energy-entry. The
two leaves together form the complete power state
management interface.";
}
}
list relationship {
key "type";
config false;
description
Benoit, et al. Expires 5 January 2027 [Page 23]
Internet-Draft GREEN-PEM-YANG July 2026
"Relationships for this energy entry.";
leaf type {
type identityref {
base energy-relationship-type;
// powered-by, powering, metered-by, metering, etc.
}
description
"The type of relationship this energy object has with peer
objects.";
}
list peer {
key "id";
description "Multiple peers for this relationship type.";
leaf id {
type string;
description
"This id specifies the Universally Unique Identifier
(UUID) of the peer (other) Energy Object that this
energy object is powering/powered-by/metering/metered-by,
etc. If the network level UUID is not known,some other
locally unique identifier MAY be used, in conjunction
with human readable details.";
reference
"RFC 9562: Universally Unique IDentifiers (UUIDs)";
}
leaf details {
type string;
description
"Additional details about the relationship.";
}
}
}
}
}
container energy-control {
description
"Energy control configuration, mirroring monitored objects. The
operational tree ('container energy-objects') will typically
contain a significantly larger number of instances than the
configuration tree here. The configuration tree represents the
administrator's intent and is limited to explicitly provisioned
entries.";
list energy-entry {
Benoit, et al. Expires 5 January 2027 [Page 24]
Internet-Draft GREEN-PEM-YANG July 2026
key "object-id";
description
"Control entry for a specific energy object.";
leaf object-id {
type string;
description
"An identifier that uniquely identifies the energy object.";
}
container power-state {
description
"Container for Power state management.";
leaf power-state-oper {
type leafref {
path "/energy-objects/energy-entry/power-state/power-state-oper";
require-instance false;
}
description
"References the corresponding operational energy object
instance in the monitoring tree.";
}
leaf power-state-admin {
type identityref {
base power-state-admin;
}
description
"The administratively requested power state for the
Energy Object. This is the state that the management
system desires the energy object to be in. This leaf is
the administrative counterpart of the operational set
'power-state-oper' in /energy-objects/energy-entry. The
two leaves together form the complete power state
management interface.";
}
}
}
}
}
<CODE ENDS>
The IANA-requested identities for power and energy class are
separately described below.
Benoit, et al. Expires 5 January 2027 [Page 25]
Internet-Draft GREEN-PEM-YANG July 2026
<CODE BEGINS> file "iana-power-and-energy@2026-07-02.yang"
module iana-power-and-energy {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-power-and-energy";
prefix ianaeo;
organization "IANA";
contact
" Internet Assigned Numbers Authority
Postal: ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
United States of America
Tel: +1 310 301 5800
E-Mail: iana@iana.org>";
description
"IANA-defined identities for power and energy class.
The latest revision of this YANG module can be obtained from
the IANA website.
Requests for new values should be made to IANA via
email (iana@iana.org).
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 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
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).";
reference
"https://www.iana.org/assignments/yang-parameters";
revision 2026-07-02 {
description
Benoit, et al. Expires 5 January 2027 [Page 26]
Internet-Draft GREEN-PEM-YANG July 2026
"Initial revision.";
reference
"RFC XXX: A YANG Data Model for Power and Energy monitoring and
control of devices within or connected to communication
networks";
}
identity certification-type {
description
"Base identity for certification types applicable to energy
objects. This identity serves as the root for a hierarchy of
certification types, allowing for extensibility.";
reference
"Industry sustainability and energy efficiency certifications";
}
identity energy-star {
base certification-type;
description
"ENERGY STAR certification for energy efficiency.";
reference
"https://www.energystar.gov/";
}
identity c80-plus{
base certification-type;
description
"80 PLUS Power Supply Certification";
reference
"https://www.clearesult.com/80plus/";
}
identity epeat {
base certification-type;
description
"Electronic Product Environmental Assessment Tool ratings (Bronze/Silver/Gold).";
reference
"https://www.epeat.net/";
}
identity eu-energy-level{
base certification-type;
description
"EU Energy Label: European efficiency ratings";
reference
"https://eprel.ec.europa.eu/screen/home";
}
Benoit, et al. Expires 5 January 2027 [Page 27]
Internet-Draft GREEN-PEM-YANG July 2026
identity cn-energy-level{
base certification-type;
description
"CN Energy Label: China efficiency ratings";
reference
"https://www.energylabel.com.cn";
}
identity cqc{
base certification-type;
description
"China Quality Certification for energy efficiency";
reference
"https://www.cqc.com.cn/";
}
}
<CODE ENDS>
7. Operational Considerations
In the YANG data model, the unit-multiplier leaf is defined with
different constraints in the power and energy containers. In the
power container, the leaf is mandatory true. This ensures that every
power measurement (instantaneous or nameplate) is always accompanied
by an explicit scale, eliminating any ambiguity about the unit. In
the energy container, the leaf is optional and has a default value of
"multiplier-units" (which corresponds to 10^0 = 1, i.e., Watt-hours).
If a device does not provide this leaf, the client MUST assume that
all energy values (total-energy-consumed and total-energy-delivered)
are expressed in Watt-hours. This default eliminates the ambiguity
that would otherwise exist when the leaf is absent.
Heterogeneous sensor capabilities across components complicate power
and energy aggregation. Operators must use the data-source-accuracy
identities (e.g., accuracy-measured-bronze vs. accuracy-estimated) to
weight data reliability carefully before aggregating Power
(instantaneous-power) and Energy (total-energy-consumed and/or total-
energy-delivered) values to avoid skewing Device Level Energy
Efficiency (DLEE) metrics.
Operators might not always be interested in getting the individual
component accuracy. What counts is the device level or domain level,
identity accuracy-like-parent is introduced to meet their demands.
From an implementation point of view, to facilitate data collection
and aggregation on runtime and avoid post-aggregation data confidence
interval issues, operators and implementers should use as much as
possible this accuracy-like-parent identity.
Benoit, et al. Expires 5 January 2027 [Page 28]
Internet-Draft GREEN-PEM-YANG July 2026
YANG Push support eliminates device-side bucket storage by streaming
energy telemetry directly to controller-side via subscriptions.
Operators must verify the 'yang-push' bundle is enabled and validate
push-max-operational limits accommodate all component subscriptions,
preventing notification flooding while avoiding memory overhead on
the device.
7.1. Measurement Accuracy and Data Source Classification
Power and energy metrics may originate from a wide range of sources
and estimation methods, each with different levels of reliability.
These include direct sensor measurements, manufacturer-provided
specifications, historical observations, and predictive models.
Without explicit characterization of data quality, comparisons and
aggregations may be misleading. The GREEN YANG data model therefore
requires all power and energy values to be associated with an
accuracy classification.
The model defines the following primary accuracy categories using
YANG identities:
* Unknown Accuracy: Data accuracy cannot be determined, or
measurements are unavailable due to sensor failures, powered-off
components, or other operational constraints.
* Estimated Data: Values derived through indirect methods:
- Static estimates: From manufacturer datasheets, nameplate
ratings (critical for UC 1: Incremental Deployment with legacy
devices)
o Identity: accuracy-static
- Historic estimates: Based on prior measurements of this
specific system under similar conditions
o Identity: accuracy-historic
- Learned estimates: Generated by machine learning models
predicting consumption from workload patterns (UC 15: AI
Training)
o Identity: accuracy-learned
* Measured Data: Direct, real-time sensor measurements with
quantified precision:
* Bronze: +/-30% accuracy for typical values.
Benoit, et al. Expires 5 January 2027 [Page 29]
Internet-Draft GREEN-PEM-YANG July 2026
* Silver: +/-10% accuracy for typical values.
* Gold: +/-5% accuracy for typical values.
* Red: +/-2% accuracy for typical values.
* Ones: All non-zero digits are significant/valid.
Percentage-based accuracy fails for small values. For example, +/-5%
of 0.1W is only 0.005W, which may be smaller than sensor noise.
Industry standards (IEC 62053, IEC 61850-7-4) address this by
specifying: Accuracy = MAX(percentage_error, absolute_threshold)
The absolute threshold suffixes (-1, -10, -100, -1000) refer to the
unit-multiplier scale. For unit-multiplier: milli, -10 means +/-10
milliwatts.
Example - A sensor with accuracy-measured-gold-10 reports:
* 16.25W -> actual value between 16.2375W and 16.2625W (5% = 0.8125W
> 0.010W threshold)
* 0.15W -> actual value between 0.140W and 0.160W (5% = 0.0075W <
0.010W threshold, so +/-10mW applies)
Explicit accuracy reporting enables:
* Weighted aggregation: High-precision measurements carry
appropriate weight when calculating network-wide energy
consumption
* Upgrade prioritization: Identify devices with low-accuracy
reporting for sensor upgrades or replacement
* Compliance validation: Automated verification against regulatory
thresholds requiring specific measurement precision
* Double-accounting prevention: Understand when PDU-level
measurements (+/-2%) should override device estimates (+/-30%) to
avoid counting the same energy twice (UC 13)
* Cross-domain correlation: Map accuracy expectations when
integrating with external systems like 3GPP energy KPIs (UC 6)
The accuracy hierarchy uses YANG identities for extensibility,
allowing vendors to define manufacturer-specific accuracy classes
while maintaining interoperability through standardized base types.
Benoit, et al. Expires 5 January 2027 [Page 30]
Internet-Draft GREEN-PEM-YANG July 2026
7.2. Industry-Standard Certifications
Energy efficiency certifications issued by recognized testing
organizations provide standardized benchmarks for the expected
performance of equipment and components. These certifications are
typically based on controlled laboratory measurements and formal
evaluation procedures. The GREEN YANG data model supports reporting
of such certifications in order to complement operational measurement
data.
Common Certifications:
* 80 PLUS (Power Supply Units): Bronze/Silver/Gold/Platinum/Titanium
tiers based on efficiency at 20%/50%/100% load
* Energy Star: Government-backed program certifying energy-efficient
products
* EPEAT: Electronic Product Environmental Assessment Tool ratings
(Bronze/Silver/Gold)
* EU Energy Label: European efficiency ratings
* CN Energy Label: China efficiency ratings
* CQC: China Quality Certification for energy efficiency
Additional certification schemes may be supported through extensible
identities.
Certification data and measurement accuracy serve complementary
functions within the model.
Certification information describes the verified design-time
efficiency characteristics of a device or component, as established
through independent testing. Measurement accuracy describes the
precision and reliability of reported operational data obtained from
sensors or estimation mechanisms.
Key differences include:
* Certification is typically applied at manufacturing time and
remains stable throughout the product lifecycle.
* Measurement accuracy may vary over time due to calibration,
environmental conditions, or sensor degradation.
Benoit, et al. Expires 5 January 2027 [Page 31]
Internet-Draft GREEN-PEM-YANG July 2026
* Certification is generally associated with discrete components,
such as power supply units.
* Measurement accuracy applies to individual metrics at component,
subsystem, or system level.
Both types of information may be reported simultaneously for the same
energy object.
Example: A power supply might have:
* Certification: c80-PLUS-Platinum (>=92% efficient at 50% load,
independently verified)
* Measurement Accuracy: accuracy-measured-silver (+/-10% sensor
precision on real-time power readings)
The certification tells operators the energy object, for example, a
PSU, is designed to be efficient; the measurement accuracy tells them
how precisely they can monitor its actual performance.
8. Security Considerations
This section is modeled after the template described in Section 3.7.1
of [rfc8407bis].
The Power and Energy YANG module defines a data model that is
designed to be accessed via YANG-based management protocols, such as
NETCONF [RFC6241] and RESTCONF [RFC8040]. These YANG-based
management protocols (1) have to use a secure transport layer (e.g.,
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.
There is one writable data node defined in this YANG module that may
be considered sensitive or vulnerable in some network environments.
Write operations (e.g., edit-config) to this data node without proper
protection can have a negative effect on network operations:
* /energy-control/energy-entry/power-state/power-state-admin:
Unauthorized write access to this leaf allows an attacker to
change the administratively requested power state of an Energy
Object. Depending on the target device or component, this could
be used to power down critical network infrastructure (resulting
Benoit, et al. Expires 5 January 2027 [Page 32]
Internet-Draft GREEN-PEM-YANG July 2026
in denial of service), force a component into a state that damages
hardware, or mask an ongoing attack by cycling power states to
disrupt monitoring. Access to this data node SHOULD be limited to
authorized administrators via NACM.
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 following
subtrees and data nodes have particular sensitivities:
* /energy-objects/energy-entry/power and /energy-objects/energy-
entry/energy: These subtrees expose real-time and cumulative power
and energy consumption for individual hardware components. Fine-
grained, time-correlated power/energy telemetry can reveal
operational patterns, such as workload levels, traffic volume, or
usage schedules, of a device or of the network behind it. In some
environments, this information could be leveraged as a side
channel to infer sensitive operational or business information
(e.g., data center utilization, capacity, or customer activity
patterns).
* /energy-objects/energy-entry/relationship: This list exposes
relationships (e.g., powered-by, powering, metered-by) and UUIDs
between Energy Objects, which can reveal the physical and logical
power topology of a site. Disclosure of this information could
assist an attacker in identifying high-value targets (e.g., shared
power infrastructure whose disruption has a broad impact) or in
correlating Energy Objects across administrative domains.
This document does not define any RPC operations or YANG
notifications.
9. IANA Considerations
This document requests IANA to create and maintain a new registry
group called "Power and Energy", with the following module
registration:
Benoit, et al. Expires 5 January 2027 [Page 33]
Internet-Draft GREEN-PEM-YANG July 2026
+===========+===================================================+
| Field | Value |
+===========+===================================================+
| Name | iana-power-and-energy |
+-----------+---------------------------------------------------+
| Namespace | urn:ietf:params:xml:ns:yang:iana-power-and-energy |
+-----------+---------------------------------------------------+
| Prefix | ianaeo |
+-----------+---------------------------------------------------+
| Reference | RFC XXX |
+-----------+---------------------------------------------------+
Table 1
Note to IANA: RFC XXX must be replaced by the newly assigned RFC
number.
All registries defined in this document are part of the "Power and
Energy" registry group.
9.1. GREEN Certification Type Registry
This document requests IANA to create a new registry called "Power
and Energy Certification Types" within the "Power and Energy"
registry group.
This document defines the initial version of the IANA-maintained
certification-type identity in the iana-power-and-energy YANG module.
The registry assigns string identity names for power and energy
efficiency certification types, for use as identityref values in
"ietf-power-and-energy" YANG module. The registered value is the
unqualified identity name (e.g., energy-star, c80-plus, etc). No
numeric code points are assigned by this registry.
New entries to "Power and Energy Certification Types" registry
require Expert Review [RFC8126]. The Designated Expert(s) should
verify that:
* The certification is issued by a recognized and independent
standards body, testing laboratory, regulatory authority, or
equivalent organization.
* The certification has a stable, publicly accessible reference.
* The proposed identity name SHOULD be a short mnemonic derived from
the official certification name.
Benoit, et al. Expires 5 January 2027 [Page 34]
Internet-Draft GREEN-PEM-YANG July 2026
When a new certification type is added to the registry, a new
identity statement MUST be added to the iana-power-and-energy YANG
module. The following substatements to the identity statement MUST
be defined:
* base: MUST contain the value certification-type.
* status: Include only if a registration has been deprecated (use
the value deprecated) or obsoleted (use the value obsolete).
* description: MUST include the full name of the certification
program and a brief description of its energy efficiency scope.
Lines MUST NOT exceed 72 characters.
* reference: MUST include a stable URI to the certification
program's official documentation or registry.
Unassigned or reserved values MUST NOT be present in the module.
When the "Power and Energy Certification Types" registry is updated
with a new entry, a corresponding new identity statement MUST be
added to the iana-power-and-energy YANG module, and a new revision
statement MUST be added in front of the existing revision statements.
IANA is requested to add the following note to the "Power and Energy
Certification Types" registry:
Certification types MUST NOT be directly added to the iana-power-and-
energy YANG module. They MUST instead be added to the "Power and
Energy Certification Types" registry. When this registry is updated,
the iana-power-and-energy YANG module MUST be updated as defined in
RFC XXX.
10. Acknowledgments
This work has benefited from the regular discussions on the GREEN
Design Meetings. The authors wish to thank the WG chairs, Rob Wilton
and Diego Lopez, for organizing the recurring calls and progressing
the work. The authors also wish to thank the following individuals,
who provided helpful comments and reviews to this document.
11. References
11.1. Normative References
[I-D.ietf-green-terminology-02]
Chen, G., Boucadair, M., Wu, Q., Contreras, L. M., and M.
P. Palmero, "Terminology for Energy Efficiency Network
Benoit, et al. Expires 5 January 2027 [Page 35]
Internet-Draft GREEN-PEM-YANG July 2026
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>.
[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/rfc/rfc2119>.
[RFC4252] "The Secure Shell (SSH) Authentication Protocol", January
2006, <https://datatracker.ietf.org/doc/html/rfc4252>.
[RFC6241] "Network Configuration Protocol (NETCONF)", June 2011,
<https://datatracker.ietf.org/doc/html/rfc6241>.
[RFC7460] Chandramouli, M., Claise, B., Schoening, B., Quittek, J.,
and T. Dietz, "Monitoring and Control MIB for Power and
Energy", RFC 7460, DOI 10.17487/RFC7460, March 2015,
<https://www.rfc-editor.org/rfc/rfc7460>.
[RFC7950] "The YANG 1.1 Data Modeling Language", August 2016,
<https://datatracker.ietf.org/doc/html/rfc7950>.
[RFC8040] "RESTCONF Protocol", June 2017,
<https://datatracker.ietf.org/doc/html/rfc8040>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[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/rfc/rfc8174>.
[RFC8340] "YANG Tree Diagrams", March 2018,
<https://datatracker.ietf.org/doc/html/rfc8340>.
[RFC8341] "Network Configuration Access Control Model", March 2018,
<https://datatracker.ietf.org/doc/html/rfc8341>.
[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/rfc/rfc8348>.
Benoit, et al. Expires 5 January 2027 [Page 36]
Internet-Draft GREEN-PEM-YANG July 2026
[RFC8446] "The Transport Layer Security (TLS) Protocol Version 1.3",
August 2018,
<https://datatracker.ietf.org/doc/html/rfc8446>.
[RFC9000] "QUIC - A UDP-Based Multiplexed and Secure Transport", May
2021, <https://datatracker.ietf.org/doc/html/rfc9000>.
11.2. Informative References
[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-01, 17 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-green-
framework-01>.
[I-D.ietf-green-framework-01]
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-01, 17 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-green-
framework-01>.
[I-D.ietf-green-use-cases-01]
Stephan, E., Palmero, M. P., Claise, B., Wu, Q.,
Contreras, L. M., Bernardos, C. J., and X. Chen, "Use
Cases for Energy Efficiency Management", Work in Progress,
Internet-Draft, draft-ietf-green-use-cases-01, 22 January
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
green-use-cases-01>.
[RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M.
Chandramouli, "Entity MIB (Version 4)", RFC 6933,
DOI 10.17487/RFC6933, May 2013,
<https://www.rfc-editor.org/rfc/rfc6933>.
[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/rfc/rfc8342>.
Benoit, et al. Expires 5 January 2027 [Page 37]
Internet-Draft GREEN-PEM-YANG July 2026
[rfc8407bis]
Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for
Authors and Reviewers of Documents Containing YANG Data
Models", Work in Progress, Internet-Draft, draft-ietf-
netmod-rfc8407bis-28, 5 June 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
rfc8407bis-28>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/rfc/rfc9562>.
Authors' Addresses
Benoit Claise
Everything OPS
Email: benoit@everything-ops.net
Gen Chen
Huawei
Email: chengen@huawei.com
Marisol Palmero
Individual
Email: marisol.ietf@gmail.com
Jan Lindblad
All For Eco
Email: jan.lindblad@for.eco
Benoit, et al. Expires 5 January 2027 [Page 38]