]> Everything OPS & Arrcus

benoit@everything-ops.net

Huawei

chengen@huawei.com

Individual

marisol.ietf@gmail.com

All For Eco

jan.lindblad@for.eco

OPS GREEN Internet-Draft GREEN YANG Power Energy This document defines a YANG data model for Power and Energy monitoring and control of devices within or connected to communication networks.

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 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 . The data model includes both the monitoring and control of Energy Objects for networked devices. This YANG data model is based on the "GREEN framework" , following the "GREEN terminology" . 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 Power Distribution Units (PDUs), and storage and compute servers. Where applicable, device monitoring extends to the Components of the device as well as software and services 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. For example, a router can contain Components such as a Line Processing Unit (LPU), a Switch Fabric Unit (SFU), and a Main Processing Unit (MPU).

Terminology This document makes use of the terms defined in :

• Power
• Nameplate Power
• Power State
• Power Interface
• Power Inlet
• Power Outlet
• Energy
• Energy Object
• Component
• Energy Monitoring
• Energy Efficiency
• Device Level Energy Efficiency (DLEE)
• Component Level Energy Efficiency (CLEE)
• Service Level Energy Efficiency (SLEE)

The terms reused from and are capitalized in this specification. This document defines the following term, which is also capitalized:

Power Cap:

An upper limit on the Power that an Energy Object receives, set by an administrator or a controller and enforced by the device, for example by reducing the clock frequency of a Component. Unlike the Nameplate Power, which is a fixed design value, a Power Cap can change during operation.

This document uses the terms Power and Energy in accordance with . 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 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 . The meanings of the symbols in the YANG tree diagrams are defined in .

The GREEN Framework The "GREEN framework" described in 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 the "GREEN reference model" in .

Power and Energy Data Model The Power and Energy Data Model reports the Power and Energy of each Energy Object, in fixed units per leaf (milliwatts for instantaneous Power and the Power Cap, watts for the Nameplate Power, and milliwatt-hours for Energy), together with the measurement accuracy, etc. Power and Energy are reported per direction, as unsigned values. Received is the Power or Energy flowing into the Energy Object through its Power Inlets, and provided is the Power or Energy flowing out of it to other Energy Objects through its Power Outlets. Both can be non-zero at the same time: a power supply receives Power from its source and provides Power to the device, and the difference is its loss. The same Power Interface can act as a Power Inlet and a Power Outlet: a battery receives Power while charging and provides Power while discharging. The state of a battery, such as its charge and capacity, is out of scope of this document; it is covered by the Battery MIB . For Power over Ethernet, the Power provided by a switch is measured at its PoE ports, and the Power received by a powered device at its own Power Inlet; the difference is dissipated mainly in the cable and connectors. The net Power of an Energy Object is its received Power minus its provided Power, so that Power passed from one Energy Object to another is not counted twice when the net Power of several Energy Objects is summed. An example is given in . A containment tree view of the Power and Energy Monitoring is presented. The model uses the admin and oper leaves within the power-state container to represent the intended (administrative) and operational (actual) 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 ) was considered, it is not adopted in this document. The model also allows an administrator or controller to request a Power Cap on an Energy Object, for example to cap the Power of a GPU in a cluster. The requested limit is configured in the power-cap container in /energy-control. The device enforces the requested limit, or the closest value that the Energy Object supports, and reports the limit in effect in the power-cap container of the Power attributes in /energy-objects. Discovering the range of limits that an Energy Object supports is out of scope of this document. The existence of a Power Cap and its effect are reported separately. The power-cap container in /energy-objects is present only while a cap is enforced, and the Energy Object then does not draw more Power than the enforced limit. The limiting leaf indicates whether the cap is constraining the Energy Object at this time, that is, whether the Energy Object would draw more Power without the cap, so that its operation is reduced to stay within the limit. For example, with a cap of 300 W, a GPU that would draw 80 W when idle, or 200 W with a light workload, is not constrained (limiting is false), whereas a GPU that would draw 450 W during a training job is held at 300 W and runs more slowly (limiting is true). A management system cannot reliably derive the limiting indication by comparing the received Power with the enforced limit: the Power that the Energy Object would draw without the cap is not observable, caps are typically enforced as an average over a time window, and the measurement accuracy blurs the comparison. The device, which applies the cap, knows whether it is constraining the Energy Object. The id of an entry in /energy-control/energy-objects/energy-object SHOULD be the id of an existing or anticipated entry in /energy-objects/energy-object. This allows an administrator or controller to correlate a configured Power State intent with the Energy Object being monitored. The id is a leafref with require-instance false, so that the configuration can be created before the Energy Object is introduced and remains after it has disappeared from the system. If the referred Energy Object does not currently exist, the configuration item for it has no effect. 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 . 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 preferably the peer's UUID; if the UUID is not known, another identifier can be used, together with human-readable details captured in the details leaf. 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-object 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 . 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. /hw:hardware/component/name | +--ro power | | +--ro instantaneous-power-received? uint64 | | +--ro instantaneous-power-provided? uint64 | | +--ro nameplate-power? uint32 | | +--ro data-source-accuracy? identityref | | +--ro power-factor? power-factor | | +--ro measurement-local? boolean | | +--ro power-cap! | | +--ro limit uint64 | | +--ro limiting? boolean | +--ro energy | | +--ro total-energy-received? uint64 | | +--ro total-energy-provided? uint64 | | +--ro data-source-accuracy? identityref | | +--ro measurement-local? boolean | +--ro certifications* identityref | +--ro power-state | | +--ro oper? identityref | +--ro relationship* [type] | +--ro type identityref | +--ro peer* [id] | +--ro id string | +--ro details? string +--rw energy-control +--rw energy-objects +--rw energy-object* [id] +--rw id -> /energy-objects/energy-object/id +--rw power-state | +--rw admin? identityref | +--rw oper? | -> /energy-objects/energy-object | /power-state/oper +--rw power-cap +--rw limit? uint64 ]]>

Relationship to the Hardware YANG Data Model To enable stable component identification across systems with the 'uuid' YANG leaf from the ietf-hardware YANG Data Model for Hardware Management , the ietf-hardware YANG module is required in connection with the 'source-component-id'. In the Power and Energy YANG Module defined in this specification, the leaf 'source-component-id' refers to a hardware component defined in the ietf-hardware module . The ietf-hardware module provides three identifiers for hardware components: 'name', 'physical-index', and 'uuid'. The 'name' leaf is the list key and uniquely identifies a component within a single device, but carries no uniqueness guarantee across different devices or management systems. The 'physical-index' leaf optionally matches entPhysicalIndex in the Entity MIB when the entity-mib feature is supported. The 'uuid' leaf is a Universally Unique Identifier , intended to be unique across space and time, and therefore suitable for stable identification of a component across management systems. The GREEN YANG module imports the ietf-hardware module and uses the 'uuid' leaf as the value of 'source-component-id', enabling unambiguous component identification across management systems independent of device-local naming conventions. The mapping between energy-object entries in this YANG Module and the hardware-components in ietf-hardware YANG module is designed to be 1:1, architecturally aligning each energy-object entry with exactly one physical hardware component via source-component-id. As no hardware class exists for hardware accelerators such as GPUs, this document requests a new "accelerator" hardware class (see ). There are also cases where controllers 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. In general, the devices (such as routers) generate the UUID, and the controller can query it. The ietf-hardware YANG module 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).

Relationship to the EMAN Work The EMAN IETF Working Group (https://datatracker.ietf.org/wg/eman/about/) is a concluded Working Group that produced several 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 . 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 as a starting point to discuss the solution to the different use cases in . 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 data nodes are added, and some legacy MIB objects are removed accordingly. For example, the signed eoPower object of is replaced by the Power received and the Power provided, as unsigned values, in the same way as the Energy counters.

Power and Energy YANG Module Note to the RFC Editor: Please replace all occurrences of "XXXX" in this document with the RFC number assigned to this document, and the revision date of both YANG modules with the date of publication of this document. Please remove this note before publication. This YANG Module is used to monitor and control Power and Energy usage of network devices and the Components on these devices. WG List: Author: Benoit Claise Author: Gen Chen Author: Marisol Palmero Author: Jan Lindblad "; description "This YANG module defines a data model for Power and Energy monitoring and control of devices within or connected to communication networks. The capitalized terms used in this module (for example, Power, Energy, Energy Object, Component, Power State, Nameplate Power, and Power Inlet) are defined in I-D.ietf-green-terminology, except Power Cap, which is defined in RFC XXXX. 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). 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-11-01 { description "Initial revision"; reference "RFC XXXX: Power and Energy YANG Module"; } 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% gold: +/- 5% red: +/- 2% In addition, the accuracy-measured-ones identity indicates a Power or Energy 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 milliwatts, under accuracy-measured-gold-10. This indicates that the actual Power value is between 15437.5 and 17062.5 milliwatts, since 5% of 16250 milliwatts is 812.5 milliwatts, which is greater than the absolute threshold of 10 milliwatts. At another time, the same sensor might report a value of 150 milliwatts, under accuracy-measured-gold-10. This indicates that the actual Power value is between 140 and 160 milliwatts, since 5% of 150 milliwatts is only 7.5 milliwatts, which is less than the absolute threshold of 10 milliwatts."; } identity accuracy-unknown { base data-source-accuracy; description "The accuracy of the Power or Energy data is unknown."; } identity accuracy-unavailable { base accuracy-unknown; description "The Power or Energy 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 or Energy data is the same as the accuracy of the same data for the parent Energy Object. The parent Energy Object is found by following the 'parent' leaf of ietf-hardware up the containment tree towards the root, starting from the Component that this Energy Object describes (see source-component-id): it is the Energy Object of the first Component found that has one. This identity is useful for hierarchical Energy Objects where child objects inherit the accuracy characteristics. If there is no parent Energy Object, the accuracy is unknown, as for accuracy-unknown."; reference "RFC 8348: A YANG Data Model for Hardware Management RFC 6933: Entity MIB (Version 4)"; } identity accuracy-estimated { base data-source-accuracy; description "The Power or Energy 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 or Energy 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 or Energy data is based on historical measurement data for this specific system and usage pattern."; } identity accuracy-learned { base accuracy-estimated; description "The Power or Energy data is based on a machine learning model prediction."; } identity accuracy-measured { base data-source-accuracy; description "The Power or Energy data is a direct, real-time measurement from a sensor."; } identity accuracy-measured-bronze { base accuracy-measured; description "The Power or Energy 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"; } identity accuracy-measured-bronze-1 { base accuracy-measured-bronze; description "The Power or Energy 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 or Energy 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 or Energy 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 or Energy 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 or Energy 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 or Energy 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 or Energy data is a direct, real-time measurement from a sensor with precision and accuracy such that |actual-sensor| <= sensor * 10% OR |actual-sensor| <= 10"; } identity accuracy-measured-silver-100 { base accuracy-measured-silver; description "The Power or Energy 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 or Energy 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 or Energy 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 or Energy 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 or Energy 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 or Energy 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 or Energy data is a direct, real-time measurement 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 or Energy 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 or Energy 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 or Energy 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 or Energy 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 or Energy 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 or Energy 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 { 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-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/"; } 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/"; } 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/"; } 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; 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'."; } grouping power-values { description "A set of Power measurement values that are associated with an Energy Object. This grouping is defined so that other modules, for example a controller-side module collecting and aggregating Power data from devices, can reuse the same leaf definitions instead of redefining them."; container power { description "Container for Power measurement attributes."; leaf instantaneous-power-received { type uint64; units "milliwatts"; mandatory false; description "The Power that the Energy Object receives right now, summed over all its Power Inlets. It includes the Power that the Energy Object uses itself and the Power that it converts, passes on, or stores, for example in a power supply or a charging battery. If the device can measure this value, it MUST report it."; } leaf instantaneous-power-provided { type uint64; units "milliwatts"; mandatory false; description "The Power that the Energy Object provides right now to other Energy Objects, summed over all its Power Outlets, for example the output of a power supply, Power over Ethernet, or a discharging battery. The difference between the received and the provided Power is the Power that the Energy Object dissipates or stores. An Energy Object without Power Outlets does not report this leaf; otherwise, if the device can measure this value, it MUST report it."; } leaf nameplate-power { type uint32; units "watts"; description "The Nameplate Power of the Energy Object: the maximum continuous Power the Energy Object is designed to consume or deliver, as specified by the manufacturer. For an Energy Object that provides Power, such as a power supply, it is the rated provided Power. It is a rated design value, not an expected operating value or an observed maximum, and does not change during operation. Used for power budget calculations and capacity planning."; reference "I-D.ietf-green-terminology: Terminology for Energy Efficiency Network Management"; } 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 (see accuracy-like-parent), facilitating hierarchical accuracy definitions without the need to specify accuracy at every level. An Energy Object without a parent Energy Object, such as the one at the top of the containment tree, SHOULD report this leaf explicitly. A module that reuses this grouping outside a device can refine the default, for example to accuracy-unknown. It applies to both the received and the provided Power; when their accuracy differs, it reports the accuracy of the less accurate of the two. 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 measured at the Power Inlets of the Energy Object. This information is important for understanding the electrical characteristics of the Energy Object and for correctly interpreting the received 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 power-cap { presence "A Power Cap is enforced for this Energy Object. When this container is absent, no cap is enforced and the Nameplate Power is the upper limit."; description "Container for the Power Cap in effect for this Energy Object."; leaf limit { type uint64; units "milliwatts"; mandatory true; description "The upper limit on the Power that this Energy Object receives, currently enforced: the Energy Object does not draw more Power than this limit, whether or not the cap is constraining it at this time (see 'limiting'). It differs from the requested limit when the requested limit is outside the range that the Energy Object supports."; } leaf limiting { type boolean; description "True if the cap is currently constraining the Energy Object: without the cap, it would draw more Power than the limit, so its operation (for example, its clock frequency) is reduced to stay within the limit. False if the Energy Object would not draw more Power than the limit even without the cap, so the cap has no effect at this time. Absent if the device cannot determine whether the cap is constraining the Energy Object."; } } } } grouping energy-values { description "A set of Energy measurement values that are associated with an Energy Object. This grouping is defined so that other modules, for example a controller-side module collecting and aggregating Energy data from devices, can reuse the same leaf definitions instead of redefining them."; container energy { description "Container for Energy measurement attributes."; leaf total-energy-received { type uint64; units "milliwatt-hours"; description "The total cumulative Energy received by the Energy Object since the last reset, in the same direction as instantaneous-power-received. This value is useful for tracking overall Energy usage over time for billing, reporting, or optimization purposes. If the device can measure this value, it MUST report it."; } leaf total-energy-provided { type uint64; units "milliwatt-hours"; description "The total cumulative Energy provided by the Energy Object to other Energy Objects since the last reset, in the same direction as instantaneous-power-provided. This value is relevant for Energy Objects that provide Energy, such as power supplies, PoE switches, batteries, or renewable energy sources. An Energy Object without Power Outlets does not report this leaf; otherwise, if the device can measure this value, it MUST report it."; } 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 unavailable and also the accuracy level of the data source. By default, the accuracy is inherited from the parent Energy Object (see accuracy-like-parent), facilitating hierarchical accuracy definitions without the need to specify accuracy at every level. An Energy Object without a parent Energy Object, such as the one at the top of the containment tree, SHOULD report this leaf explicitly. A module that reuses this grouping outside a device can refine the default, for example to accuracy-unknown. It applies to both the received and the provided Energy; when their accuracy differs, it reports the accuracy of the less accurate of the two. 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."; } } } grouping certifications { description "The certifications that apply to an Energy Object. Defined as a separate grouping so that it can be reused independently of the Power and Energy values."; 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."; } } grouping relationships { description "A set of relationships between an Energy Object and its peer Energy Objects. A device uses this grouping to report relationships such as powering, powered-by, metering, metered-by, aggregating, aggregated-by, enabling and enabled-by. A controller uses this grouping to represent the relationships collected from devices. This grouping is defined so that other modules, for example a controller-side module collecting relationships from devices, can reuse the same relationship structure instead of redefining it."; list relationship { key "type"; description "Relationships for this Energy Object."; 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 "The identifier of the peer Energy Object that this Energy Object is powering/powered-by/metering/ metered-by, etc., preferably its Universally Unique Identifier (UUID). If the UUID is not known, another identifier MAY be used, together with human-readable details in the 'details' leaf."; reference "RFC 9562: Universally Unique IDentifiers (UUIDs)"; } leaf details { type string; description "Additional details about the relationship."; } } } } container energy-objects { config false; description "Energy Objects container for Power and Energy attributes."; list energy-object { key "id"; description "Power and Energy entry for an Energy Object, indexed by Energy Object id. Each entry contains the complete set of Power and Energy attributes for a specific physical component."; leaf id { type string; description "An identifier that uniquely identifies the Energy Object"; } 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"; } uses power-values; uses energy-values; uses certifications; container power-state { description "Container for Power State monitoring."; leaf oper { type identityref { base power-state; } description "The current operational Power State of this Component, as reported by the device. The leaf reflects the actual observed Power State."; } } uses relationships; } } container energy-control { description "Energy control configuration, mirroring monitored objects. The operational tree ('list energy-object' in /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."; container energy-objects { description "Configuration container for the list of administratively provisioned Energy Objects."; list energy-object { key "id"; description "Control entry for a specific Energy Object."; leaf id { type leafref { path "/energy-objects/energy-object/id"; require-instance false; } description "An identifier that uniquely identifies the Energy Object."; } container power-state { description "Container for Power State management."; leaf admin { type identityref { base power-state; } description "The administratively requested Power State for this Component. This leaf represents the management system intended Power State. When the 'admin' and the respective 'oper' YANG leaf values differ, a transition toward the 'admin' Power State is in progress. Absence of a configured value indicates that the Component operates at its default Power State."; } leaf oper { type leafref { path "/energy-objects/energy-object/power-state/oper"; require-instance false; } description "The current operational Power State of this Component, as reported by the device. References the corresponding operational Energy Object instance in the monitoring tree."; } } container power-cap { description "Container for the Power Cap of this Energy Object."; leaf limit { type uint64; units "milliwatts"; description "The administratively requested upper limit on the Power that this Energy Object may receive. The device enforces it by adjusting the operation of the Energy Object, for example by lowering its clock frequency. Absence of a configured value means that no cap is requested. If the requested limit is outside the range that the Energy Object supports, the device enforces the closest supported value, which is reported in the power-cap container in /energy-objects."; } } } } } } ]]> The IANA-maintained identities for certification types are defined in the following module.

Operational Considerations 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-received and instantaneous-power-provided) and Energy (total-energy-received and total-energy-provided) values to avoid skewing Device Level Energy Efficiency (DLEE) metrics. The device reports the Power and Energy that each Energy Object receives and provides, not a single consumption value. The consumption of an Energy Object is its net value, received minus provided, which a management system or a controller computes when needed. For a power supply, this net value is its loss (see ). For implementers familiar with , the following table maps its Power and Energy objects to this module. The values in are scaled by a unit multiplier, while this module uses fixed units, and the Energy objects of cover a configured interval, while the Energy counters of this module are cumulative since the last reset. Mapping of RFC 7460 Power and Energy Objects

RFC 7460 object	This module
eoPower	instantaneous-power-received minus instantaneous-power-provided
eoEnergyConsumed	total-energy-received
eoEnergyProvided	total-energy-provided

Operators might not always be interested in the accuracy of individual Components; what matters is the accuracy at the device or domain level. The accuracy-like-parent identity is introduced for this purpose. The parent Energy Object is determined by the containment tree , which ietf-hardware represents with the parent leaf: starting from the Component of an Energy Object and following the parent leaf up the containment tree towards the root, the first Component that has an Energy Object provides the parent Energy Object. The Energy Object at the top of the containment tree has no parent, so its accuracy should be reported explicitly. A module that reuses the power-values or energy-values groupings outside a device, such as a controller-side module, can refine the default of data-source-accuracy, for example to accuracy-unknown. From an implementation point of view, to facilitate data collection and aggregation at runtime and to avoid post-aggregation data confidence interval issues, operators and implementers should use the accuracy-like-parent identity as much as possible. 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.

Hardware Component Identification The GREEN YANG module relies on the ietf-hardware module for hardware component identification. Among the three identifiers that ietf-hardware provides for each component: 'name', 'physical-index', and 'uuid', only uuid is intended to be unique beyond a single device. The 'name' leaf, while serving as the list key within a device, is meaningful only in the context of that specific device. The 'physical-index' leaf, where present, provides a mapping to the legacy Entity MIB , but its availability depends on whether the entity-mib feature is supported. For these reasons, the 'source-component-id' leaf in this module is bound to the 'uuid' leaf of the corresponding ietf-hardware component, as defined in . This choice ensures that Energy Objects can be unambiguously referenced and correlated across devices, management systems, and administrative domains without relying on device-local naming conventions.

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 legacy devices, as described in the "Incremental Application of the GREEN Framework" use case in )
    • Identity: accuracy-static
  • Historic estimates: Based on prior measurements of this specific system under similar conditions
    • Identity: accuracy-historic
  • Learned estimates: Generated by machine learning models predicting consumption from workload patterns (see the "Energy-Efficient Management of Distributed AI Training Workloads" use case in )
    • Identity: accuracy-learned
• Measured Data: Direct, real-time sensor measurements with quantified precision:
  • Bronze: +/-30% accuracy for typical values.
  • Silver: +/-10% accuracy for typical values.
  • Gold: +/-5% accuracy for typical values.
  • Red: +/-2% accuracy for typical values.
  • Ones: All digits are valid, except trailing zeros.

Percentage-based accuracy fails for small values. For example, +/-5% of 100 mW is only 5 mW, 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) are expressed in the unit of the qualified value: milliwatts for Power, and milliwatt-hours for Energy. For example, -10 means +/-10 milliwatts for a Power value. Example - A sensor with accuracy-measured-gold-10 reports:

• 16.25 W -> actual value between 15.4375 W and 17.0625 W (5% = 0.8125 W > 0.010 W threshold)
• 0.15 W -> actual value between 0.140 W and 0.160 W (5% = 0.0075 W < 0.010 W threshold, so +/-10 mW 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 (see the "Double Accounting" use case in )
• Cross-domain correlation: Map accuracy expectations when integrating with external systems like 3GPP energy KPIs (see the "Consideration of other domains for obtention of end-to-end metrics" use case in )

The accuracy hierarchy uses YANG identities for extensibility, allowing vendors to define manufacturer-specific accuracy classes while maintaining interoperability through standardized base types.

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.
• 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 (80 PLUS certified; at the Platinum level, >=92% efficient at 50% load, independently verified. The identity does not convey the level.)
• Measurement Accuracy: accuracy-measured-silver (+/-10% sensor precision on real-time Power readings)

The certification tells operators that the Energy Object (for example, a power supply unit) is designed to be efficient; the measurement accuracy tells them how precisely they can monitor its actual performance.

Security Considerations This section is modeled after the template described in Section 3.7.1 of . The Power and Energy YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF and RESTCONF . These YANG-based management protocols (1) have to use a secure transport layer (e.g., SSH , TLS , and QUIC ) and (2) have to use mutual authentication. The Network Configuration Access Control Model (NACM) 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 are two writable data nodes defined in this YANG module that may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations:

• /energy-control/energy-objects/energy-object/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 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.
• /energy-control/energy-objects/energy-object/power-cap/limit: Unauthorized write access to this leaf allows an attacker to set a very low Power Cap on an Energy Object, degrading or disrupting its operation (resulting in denial of service), or to remove a cap that protects the power budget of a site. 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-object/power and /energy-objects/energy-object/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-object/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.

IANA Considerations This document requests IANA to perform the following actions.

YANG Module Name and URI Registry IANA is requested to register the following URIs in the "IETF XML Registry" . IETF URI Registry: ietf-power-and-energy

Field	Value
URI	urn:ietf:params:xml:ns:yang:ietf-power-and-energy
Registrant Contact	The IESG
XML	N/A; the requested URI is an XML namespace.

IETF URI Registry: iana-power-and-energy

Field	Value
URI	urn:ietf:params:xml:ns:yang:iana-power-and-energy
Registrant Contact	The IESG
XML	N/A; the requested URI is an XML namespace.

IANA is also requested to register the following YANG modules in the "YANG Module Names" registry within the "YANG Parameters" registry group. IETF YANG Module Name Registry: ietf-power-and-energy

Field	Value
Name	ietf-power-and-energy
Maintained by IANA?	N
Namespace	urn:ietf:params:xml:ns:yang:ietf-power-and-energy
Prefix	eo
Reference	RFC XXXX

IETF YANG Module Name Registry: iana-power-and-energy

Field	Value
Name	iana-power-and-energy
Maintained by IANA?	Y
Namespace	urn:ietf:params:xml:ns:yang:iana-power-and-energy
Prefix	ianaeo
Reference	RFC XXXX

Accelerator Hardware Class IANA is requested to add the following enumeration to the IANAPhysicalClass textual convention in the IANA-maintained IANA-ENTITY-MIB module : As the iana-hardware YANG module reflects IANA-ENTITY-MIB , IANA is also requested to add the following identity to the iana-hardware YANG module, with a new revision statement: Note to IANA: the value 16, the next unassigned IANAPhysicalClass value, is suggested for TBD1.

Power and Energy Certification Types Registry IANA is requested to create a new registry named "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 or c80-plus). No numeric code points are assigned by this registry. Registry Template is as follows. IETF Power and Energy Certification Types Registry

Field	Value
Registry Name	Power and Energy Certification Types
Reference	RFC XXXX
Registration Procedure	Expert Review
Available Values	Unqualified identity names as strings

Initial Registries

Identity Name	Description	Reference
c80-plus	80 PLUS Power Supply Certification	RFC XXXX
energy-star	ENERGY STAR certification	RFC XXXX
epeat	Electronic Product Environmental Assessment Tool ratings	RFC XXXX
eu-energy-label	EU Energy Label: European efficiency ratings	RFC XXXX
cn-energy-label	CN Energy Label: China efficiency ratings	RFC XXXX
cqc	China Quality Certification for energy efficiency	RFC XXXX

New entries to "Power and Energy Certification Types" registry require Expert Review . 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.

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 XXXX.

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 Rob Wilton, Diego Lopez, Tony Li, Per Andersson, Qin Wu, Chih-Tsung Huang, Alex Huang Feng, and Amanda Baber for their helpful comments and reviews of this document.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Huawei Orange Huawei Telefonica Individual Energy-efficient network management is primarily meant to enhance conventional network management with energy-related management capabilities that optimize overall network energy consumption. To that aim, specific features and capabilities are required to control (and thus optimize) the energy use of involved network elements and their components. This document defines a set of key terms used within the IETF when discussing energy efficiency in network management. Such reference document helps framing discussion and agreeing upon a set of main concepts in this area. This document defines a YANG data model for the management of hardware on a single server. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single Simple Network Management Protocol (SNMP) agent. This document specifies version 4 of the Entity MIB. This memo obsoletes version 3 of the Entity MIB module published as RFC 4133. This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References Orange Individual Huawei Huawei Telefonica Universidad Carlos III de Madrid China Mobile This document groups use cases for Energy efficiency Management of network devices. Discussion Venues Source of this draft and an issue tracker can be found at https://github.com/emile22/draft-ietf-green-use-cases Everything OPS Telefonica All For Eco Independent Orange Huawei Recognizing the urgent need for energy efficiency, this document specifies a management framework focused on networks, devices and device components within, or connected to, interconnected systems. The framework aims to enable energy usage optimization, based on the network condition while achieving the network's functional and performance requirements (e.g., improving overall network utilization) and also ensure interoperability across diverse systems. Leveraging data from existing use cases, it delivers actionable metrics to support effective energy management and informed decision- making. Furthermore, the framework defines mechanisms for representing and organizing timestamped telemetry data using YANG data models and metadata, enabling transparent and reliable monitoring. This structured approach facilitates improved energy efficiency through consistent energy management practices. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects that provide information on the status of batteries in managed devices. Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.

Example: Modeling a 750 W Power Supply This appendix shows how a 750 W power supply is modeled. The power supply, psu-1, is fed by outlet 7 of a PDU and powers the chassis of the device. Both are Components in the ietf-hardware module , and psu-1 is contained in the chassis. The values are illustrative: the power supply receives 400 W from the PDU and provides 376 W to the chassis, an efficiency of 94% at about half its Nameplate Power, and the Energy counters cover 30 days at that load. The following instance data is encoded in JSON . Power is in milliwatts and Energy in milliwatt-hours, and the uint64 values are encoded as JSON strings. From these values, a management system derives:

• the loss of the power supply: 400 W - 376 W = 24 W;
• its efficiency: 376 W / 400 W = 94%, which the Energy counters confirm over the period (270,720 Wh / 288,000 Wh);
• the Power drawn from the PDU, by summing the net Power of the Energy Objects: 24 W for the power supply plus 376 W for the chassis, that is 400 W, without counting twice the Power passed from the power supply to the chassis.

A battery is modeled in the same way: it reports received Power and Energy while charging, and provided Power and Energy while discharging.