Internet-Draft GREEN-PEM-YANG September 2026
Benoit, et al. Expires 13 March 2027 [Page]
Workgroup:
GREEN
Internet-Draft:
draft-ietf-green-power-and-energy-yang-04
Published:
Intended Status:
Standards Track
Expires:
Authors:
C. Benoit
Everything OPS
C. Gen
Huawei
M. Palmero
Individual
J. Lindblad
All For Eco

Power and Energy YANG Module

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 13 March 2027.

Table of Contents

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.

This YANG data model is based on the "GREEN framework" [I-D.ietf-green-framework], following the "GREEN terminology" [I-D.ietf-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 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]:

- Power
- Energy
- Energy Object
- 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)

The terms reused from [I-D.ietf-green-terminology] and [I-D.ietf-green-framework] are capitalized in this specification.

This document uses the terms Power and Energy in accordance with [I-D.ietf-green-terminology]. 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 [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] 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].

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 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 [RFC8342]) was considered, it is not adopted in this document.

Entries in /energy-control/energy-objects/energy-object SHOULD reference the /energy-objects/energy-object/id using a leafref with require-instance false. This allows an administrator or controller to correlate a configured power state intent with the Energy Object being monitored. The require-instance false statement allows the configuration to remain after an energy-object has disappeared from the system, or before it has been introduced. 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 [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]. 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.

module: ietf-power-and-energy
  +--ro energy-objects
  |  +--ro energy-object* [id]
  |     +--ro id                     string
  |     +--ro source-component-id?   -> /hw:hardware/component/name
  |     +--ro power
  |     |  +--ro instantaneous-power?    int64
  |     |  +--ro nameplate-power?        uint32
  |     |  +--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 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

4. 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 [RFC8348], the ietf-hardware YANG module [RFC8348] 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 [RFC8348].

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 [RFC6933] when the entity-mib feature is supported. The 'uuid' leaf is a Universally Unique Identifier [RFC9562] that is globally unique and therefore suitable for stable identification of a component across management systems.

The GREEN YANG module imports the ietf-hardware module [RFC8348] 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 [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.

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

     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%
          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 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 millwatts,
       which is less than the absolute threshold of 10 milliwatts.";
  }
  identity accuracy-unknown {
    base data-source-accuracy;
    description
      "The accuracy of the power data is unknown.";
  }
  identity accuracy-unavailable {
    base accuracy-unknown;
    description
      "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";
  }
  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
       |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
       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 {
    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/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";
  }
  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 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'.";
  }
  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";
      }

      container power {
        description
          "Container for power measurement attributes.";

        leaf instantaneous-power {
          type int64;
          units "mWatts";
          mandatory false;
          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 milliwatts (mW). 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 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 {
          type uint64;
          units "Watt-hours";
          description
           "The total cumulative energy consumed by the energy
            object since the last reset. This value is specified as
            milliwatt-hours (mWh). 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
            milliwatt-hours (mWh). 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 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, 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 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.";
        }
      }

      list relationship {
        key "type";
        config false;
        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
              "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 ('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.";
          }
        }
      }
    }
  }
}



<CODE ENDS>

The IANA-requested identities for power and energy class are separately described below.

<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
      "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";
  }

  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

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.

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. Hardware Component Identification

The GREEN YANG module relies on the ietf-hardware module [RFC8348] for hardware component identification. Among the three identifiers that ietf-hardware provides for each component: 'name', 'physical-index', and 'uuid', only uuid is globally unique. 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 [RFC6933], 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 [RFC9562]. 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.

7.2. 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)

      • 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 (UC 15: AI Training)

      • 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 non-zero digits are significant/valid.

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) refer to milliwatts. -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.

7.3. 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-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:

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:

This document does not define any RPC operations or YANG notifications.

9. IANA Considerations

This document requests IANA to perform the following actions.

9.1. YANG Module Name and URI Registry

IANA is requested to register the following URI in the "IETF XML Registry" [RFC3688].

Table 1: IETF URI Registry
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 module in the "YANG Module Names" registry [RFC6020] [RFC9890] within the "YANG Parameters" registry group.

Table 2: IETF YANG Module Name Registry
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 XXX

Note to IANA: RFC XXX must be replaced by the newly assigned RFC number.

9.2. 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, c80-plus, etc). No numeric code points are assigned by this registry. Registry Template is as follows.

Table 3: IETF Power and Energy Certification Types Registry
Field Value
Registry Name Power and Energy Certification Types
Reference RFC XXX
Registration Procedure Expert Review [RFC8126]
Available Values Unqualified identity names as strings
Table 4: Initial Registries
Identity Name Description Reference
80plus 80 PLUS Power Supply Certification RFC XXX
energy-star ENERGY STAR certification RFC XXX
epeat Electronic Product Environmental Assessment Tool ratings RFC XXX
eu-energy-level EU Energy Label: European efficiency ratings RFC XXX
cn-energy-level CN Energy Label: China efficiency ratings RFC XXX

Note to IANA: RFC XXX must be replaced by the newly assigned RFC number.

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.

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]
Chen, G., Boucadair, M., Wu, Q., Contreras, L. M., and M. P. Palmero, "Terminology for Energy Efficiency Network Management", Work in Progress, Internet-Draft, draft-ietf-green-terminology-02, , <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, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4252]
"The Secure Shell (SSH) Authentication Protocol", , <https://datatracker.ietf.org/doc/html/rfc4252>.
[RFC6241]
"Network Configuration Protocol (NETCONF)", , <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, , <https://www.rfc-editor.org/rfc/rfc7460>.
[RFC7950]
"The YANG 1.1 Data Modeling Language", , <https://datatracker.ietf.org/doc/html/rfc7950>.
[RFC8040]
"RESTCONF Protocol", , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8340]
"YANG Tree Diagrams", , <https://datatracker.ietf.org/doc/html/rfc8340>.
[RFC8341]
"Network Configuration Access Control Model", , <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, , <https://www.rfc-editor.org/rfc/rfc8348>.
[RFC8446]
"The Transport Layer Security (TLS) Protocol Version 1.3", , <https://datatracker.ietf.org/doc/html/rfc8446>.
[RFC9000]
"QUIC - A UDP-Based Multiplexed and Secure Transport", , <https://datatracker.ietf.org/doc/html/rfc9000>.
[RFC9562]
Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, , <https://www.rfc-editor.org/rfc/rfc9562>.

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-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-green-framework-02>.
[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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc8342>.
[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, , <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28>.

Authors' Addresses

Benoit Claise
Everything OPS
Gen Chen
Huawei
Marisol Palmero
Individual
Jan Lindblad
All For Eco