Internet-Draft POWEFF May 2024
Lindblad, et al. Expires 8 November 2024 [Page]
Workgroup:
OPSA Working Group
Internet-Draft:
draft-opsawg-poweff-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
J. Lindblad
Cisco Systems
S. Mitrovic
Cisco Systems
M. Palmero
Cisco Systems
G. Salgueiro
Cisco Systems

Power and Energy Efficiency

Abstract

This document specifies a device YANG “dashboard” data model that allows devices to report which power measurement and control functions they offer. This basic YANG model is applicable to any kind of device, regardless of whether the device itself has any support for YANG-based management interfaces or not. The YANG model simply allows a device to describe what it can report, and which interfaces are available to request this data. Devices that lack any on-board YANG-based management interfaces provide this information in form of a YANG instance data file. This file may be readable from an on-board web server on the device, or hosted anywhere else.

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 8 November 2024.

▲

Table of Contents

1. Introduction

As highlighted during the IAB workshop on environmental impacts, visibility is a very important first step. Paraphrasing Peter Drucker’s mantra of “You cannot improve what you don’t measure”. During the workshop the need for standardized metrics was established, to avoid proprietary, redundant and even contradictory metrics across vendors.

POWEFF is considered a first step, part of the Sustainability Telemetry Specification referred as part of the Sustainability Insights [I-D.draft-almprs-sustainability-insights-02] IETF draft (a newer version may exist). That is where the overall problem statement, solution principles and other components of the proposed solution can be found. Specifically, this work is meant to fit in with the [I-D.draft-lindblad-tlm-philatelist-01] framework.

This Power Consumption and Energy Efficiency Telemetry Specification (POWEFF) provides a way for a controller to understand what a device offers in terms of power related sensors and controls. It also provides machine readable metadata for the sensors, such as which units of measurement are used, what is included in the reported data, the precision of the data, etc. This is referred to as the device dashboard.

This document also contains embryonic definitions of recommended datasets and attributes defining a common data model to report Power Consumption and Energy Efficiency on assets, with multuple implementation levels, that new devices may choose to implement. Standardized calculations utilizing the specified datasets and attributes which will yield a power consumption value for any asset or network element, and standardized calculations utilizing the specified datasets and attributes which will yield the energy efficiency value for any asset or network element.

1.1. Requirements language

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Terminology

Terminology and abbreviations used in this document:

Asset
Refers to hardware, software, applications, or services. An asset can be physical or virtual, as defined in the Asset Lifecycle Management and Operations [I-D.draft-palmero-ivy-ps-almo-01] IETF draft.
Scope 1
Emissions directly caused by actions of the organization, such as when fossil fuels are burned when the organization is operating a fossil vehicle. See Greenhouse Gas protocol.
Scope 2
Emissions indirectly caused by actions of the organization, but under control of the organization. For example, when electric energy is purchased, causing a provider utility to make emissions on behalf of the organization. See Greenhouse Gas protocol.
Scope 3
Emissions the organization indirectly causes others to make, but outside the organizations direct control. Examples include the energy customers consume when operating the organization’s products, or when employees commute to work at the organization. See Greenhouse Gas protocol.
Scope 4
Refers to the term used in Greenhouse Gas (GHG) accounting and reporting to describe emissions that occur as a result of an organization’s value chain activities, but are not directly controlled or owned by the organization. Scope 4 emissions are considered indirect emissions and are typically associated with activities that are upstream or downstream from a organization’s operations. Such as when equipment provided by the organization enables a video conference, without which greater emissions from business travel would have happened.
CO2eq
Carbon dioxide equivalents, a measure of the disruptive force of greenhouse gas emissions.
Power
Refers to the (e.g. electrical or optical) energy per unit of time, supplied to operate an asset, such as a smartphone. It is usually measured in units of Watts.
Energy Efficiency
refers to the ability of an asset to perform its intended functions while minimizing energy consumption. It refers to the ratio between the useful output energy and input energy given by an asset. In a router or a switch, it is a measure of how efficiently the network element utilizes energy resources to transmit and process data or perform other network-related tasks. See Energy efficiency wikipedia.

3. Motivation

The main objective of POWEFF is to enable Network Controllers to measure, report and control power and energy related metrics from networks with many and diverse devices, providing the necessary insights to improve the overall CO2eq emission for use cases of which the asset is part. Basically emissions that address direct use-phase emissions of Scope 3, Category 11 “use of sold products”.

It includes emissions from the use of goods and services sold by the reporting company or vendor in the reporting year. A vendor’s Scope 3 emissions from use of sold products include the scope 1 and scope 2 emissions of end users. End users include both consumers and business customers that use final assets. It is important to note that Scope 3 category 11, reports around 75% of the total Scopes 1, 2 and 3 reported by a given asset. See Cisco ESG Reporting Hub.

Power and energy consumption Telemetry data available for different infrastructure vendors today is characterized by inconsistency and best effort:

3.1. Proposed Solution Outline

Formulate a Power and Energy Efficiency Telemetry Specification to promote consistency:

Data
Definition of datasets and attributes that will define a common data model to report power and energy consumption on hardware and software assets
Calculation
Define a standardized calculation utilizing the specified datasets and attributes which will yield an energy consumption value for any asset.

Implementing any Sustainability Solution at scale for customers with a broad range of equipment requires at minimum consistently available Power Consumption/Energy Efficiency Telemetry. Telemetry standardization will benefit numerous stakeholders, including Corporate Social Responsibility (CSR), who have a need for Power Consumption Telemetry data for a variety of purposes.

3.2. Use Cases

  • Monitoring power and energy efficiency based on common metrics.

  • Enhance reporting and provide a comprehensive overview for potentially improving power usage during the operational phase.

  • Consumption per device, e.g. wireless environment.

  • Capabilities to optimize energy consumption when assets are not in use, e.g. idle and allocated power.

  • Hardware Lifecycle. Circular economy enables to restore product value at the end of life, there are several options, reuse, remanufacturing, recycling, repurpose, etc.

More elaborate use cases, e.g. define carbon footprint for network’s usage, might also be derived from POWEFF model, even discussion and common understanding will be required.

4. Information Model

Implementors of this specification can choose the implementation level that is appropriate for their device at the current time. As the implementation matures, higher implementation levels may be chosen over time. Each implementation level is a superset of the previous level.

4.1. Level 0, Proprietary Dashboard Only

At level 0, the device implements only proprietary dashboards, without implmementing any dashboards with predefined content. This allows controllers to find the power sensors already present in the implementation, and read the associated metadata, but may not be well prepared to really understand the meaning of the data being read. The dashboard may be provided by an on-board YANG-based management protocol, or delivered as a YANG instance data file from an on-board webserver, or delievered as a file by some other mechanism (e.g. web server elsewhere).

For level 0, the Network Element implements the Philatelist YANG module ietf-tlm-philatelist-provider. This gives the controller one or more proprietary dashboard with whatever contents the implementor sees fit.

4.2. Level 1, Current Total Power Draw

At level 1, the device implements a very small, but well defined dashboard, and lists it using the Philatelist ietf-tlm-philatelist-provider module. The level 1 dashboard consists of a single dashboard item. This dashboard item provides a way for the Network Controller to read the current total power draw of the Network Element.

module: ietf-poweff-level-1
  +--rw poweff
     +--ro stats
        +--ro device-current-total-power-draw?   uint32
Figure 1: YANG tree diagram of the Level 1 Dashboard.

The following requirements MUST be fulfilled by the Network Element implementing the level 1 and higher dashboards. + The reported telemetry data MUST be correct with regards to what is included and not included for all reported telemetry data values + The metadata MUST be correct with regards to measurement units for all reported telemetry data values + The metadata MUST be correct with regards to apparent/real RMS power, for all reported power and energy data values + The power consumption values reported MUST NOT be underestimated over time in actual field use

If Network Elements declaring conformance to the level 1, or higher, dashboard of this specification, do not actually fulfill the conditions required in this document, that may be construed as violating the EU Green Claims Directive (GCD), EU 2023/0085(COD)

4.3. Level 2, Add Energy and Susbsystem Breakdown

At level 2, on top of all level 1 reporting, the Network Element also reports the gross energy usage over time (the integral over time of the power draw), and the power draw can be further inspected for each major subsystem within the device.

module: ietf-poweff-level-2

  augment /ietf-poweff-level-1:poweff/ietf-poweff-level-1:stats:
    +--ro device-total-energy-spent?         uint32
    +--ro device-total-energy-spent-since?   yang:date-and-time
    +--ro subsystem* [name]
       +--ro name                  subsys-name-t
       +--ro current-power-draw?   uint32
       +--ro children*             -> ../../subsystem/name
Figure 2: YANG tree diagram of the Level 2 Dashboard.

4.4. Level 3, Add Fundamental Power Control

From this level onward, a YANG-based management protocol is required, since standards based configuration control of the device is required.

At level 3, all the reporting functions of level 2 are required, and also basic control over device global power-save modes. The controller may choose one of several power saving modes for the Network Element. Network Element implementors or Standards Defining Organizations (SDOs) may also augment the mode selection with additional power saving modes.

The basic principle for the power saving controls is for the Network Controller to specify how much degradation of the maximum possible delivered performace it could tolerate, and for the Network Element to decide on what power saving measures that can be taken, while still fulfilling expectations. The Network Element SHOULD also provide an estimate of how much power can be saved under the given conditions.

This document specifies four power save modes and two power-save conditions that apply generally to the power save modes.

fully-powered
The subsystem is fully powered, i.e. does not take any power-saving measures that would risk lowering the performance below normal levels.
powered-off
The subsystem is completely powered off, i.e. it is drawing no or little power while also delivering zero performance.
napping
The subsystem is napping, i.e. is taking frequent but brief pauses in the service it provides. The Network Controller may specify a max-additional-latency. This determines the maximum tolerated length of the pauses with reduced performance. This means the maximum additional delay that this subsystem would incur on e.g. detecting incoming traffic or performing its function.
throttling
The subsystem is throttling, i.e. is running with reduced capacity in the service it provides. The Network Controller may specify a max-capacity-reduction. This determines the maximum tolerated reduction of performance.

For example, if a Network Controller applied throttling with a max-capacity-reduction value at 50% onto a transport subsystem or service that consists of 3 underlaying links of equal capacity, the Network Element might decide to shut down one of the three links.

For all the power-save modes (except the fully-powered mode, in which these have no effect) the two following general conditions also apply:

max-time-to-cancel-power-save
The maximum time the Controller allows the subsystem to recover full performance. The subsystem should not engage in power-saving measures that take longer than this time to revert to full performance.
estimated-power-reduction
The subsystem’s own estimate on how much of its own power draw that is reduced by the power-saving measures in effect.

For example, if a Network Controller applied throttling with a max-capacity-reduction value at 50% onto a transport subsystem or service that consists of 3 underlaying links of equal capacity, the Network Element might decide to shut down one of the three links. The Network Element might then report an estimated-power-reduction of 33%.

module: ietf-poweff-level-3

  augment /ietf-poweff-level-1:poweff:
    +--rw power-save
       +--rw subsystem* [name]
          +--rw name                   -> /poweff/stats/subsystem/name
          +--rw (selected-power-save-mode)?
          |  +--:(fully-powered)
          |  |  +--rw fully-powered?               empty
          |  +--:(powered-off)
          |  |  +--rw powered-off?                 empty
          |  +--:(napping)
          |  |  +--rw napping
          |  |     +--rw max-additional-latency?   microseconds
          |  +--:(throttling)
          |     +--rw throttling
          |        +--rw max-capacity-reduction?   percent
          +--rw max-time-to-cancel-power-save?     microseconds
          +--ro estimated-power-reduction?         uint32
Figure 3: YANG tree diagram of the Level 3 Dashboard.

4.5. Level 4, Add Service Attribution

At level 4, the Network Element also provides a list of services/tenants/clients/domains/functions that it delivers value towards, and attributes the Network Element’s power draw to each of the services. The list of services may include one “overhead/idle/other/unknown” entry that absorbs any overhead not attributable to a particular service. The power draw MAY be further subdivided for each service by using a dot notation.

One service instance called ‘-idle-‘ may be present in the list and absorb any overhead/idle/other/unknown kind of power draw that the system would not allocate to any service. It is up to the implementor to decide what a ‘service’ means for this type of system. It may be any kind of service that it delivers user value towards.

For example, if a system serves three customers, X, Y and Z, their power draw could be declared as follows:

Table 1
name current-power-draw children
X 45 vpn
X.vpn 39 eth1/16 eth2/33 eth3/11
X.vpn.eth1/16 14  
X.vpn.eth2/33 12  
X.vpn.eth3/11 9  
Y 26  
Z 19  
-idle- 48  

The sum of the current-power-draw top level entries (in this example: X, Y, Z and -idle-, with values 45 + 26 + 19 + 48 = 138) must match the value provided in ietf-poweff-level-1:device-current-total-power-draw

The sub-service values (e.g. X.vpn, 39W) need to be lower than or equal to (but do not necessarily need to match) their parent level (e.g. X, 45W).

Note: the name of the children have been abbreviated in the diagram above. In the actual payload, the full names would always be used, e.g. ‘eth1/16’ above would actually be communicated as ‘X.vpn.eth1/16’.

module: ietf-poweff-level-4

  augment /ietf-poweff-level-1:poweff/ietf-poweff-level-1:stats:
    +--ro service* [name]
       +--ro name                  string
       +--ro current-power-draw?   uint32
       +--ro children*             -> ../../service/name
Figure 4: YANG tree diagram of the Level 4 Dashboard.

4.6. Level 5, Add Service Level Power Control

At level 5, the device additionally implements power-save modes per delivered service. The structure is exactly the same as the level 3 structure, except that it is for services rather than subsystems. A service would be something that is relevant and meaningful from a customer’s or user’s perspective. It is up to the Network Element implementor to decide exactly what constitutes a service.

module: ietf-poweff-level-5

  augment /ietf-poweff-level-1:poweff/ietf-poweff-level-3:power-save:
    +--rw service* [name]
       +--rw name                        -> /poweff/stats/service/name
       +--rw (selected-power-save-mode)?
       |  +--:(fully-powered)
       |  |  +--rw fully-powered?               empty
       |  +--:(powered-off)
       |  |  +--rw powered-off?                 empty
       |  +--:(napping)
       |  |  +--rw napping
       |  |     +--rw max-additional-latency?   microseconds
       |  +--:(throttling)
       |     +--rw throttling
       |        +--rw max-capacity-reduction?   percent
       +--rw max-time-to-cancel-power-save?     microseconds
       +--ro estimated-power-reduction?         uint32
Figure 5: YANG tree diagram of the Level 5 Dashboard.

5. YANG Modules

5.1. Module ietf-poweff-types.yang 

module ietf-poweff-types {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-types";
  prefix ietf-poweff-types;

  import ietf-tlm-philatelist-types {
    prefix ietf-tlm-philatelist-types;
  }

  organization
    "IETF OPSA (Operations and Management Area) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/opsawg/>
     WG List:  <mailto:opsawg@ietf.org>
     Editor:  Jan Lindblad
              <mailto:jlindbla@cisco.com>
     Editor:  Snezana Mitrovic
              <mailto:snmitrov@cisco.com>
     Editor:  Marisol Palmero
              <mailto:mpalmero@cisco.com>";
  description
    "This YANG module defines basic quantities, measurement units
     and sensor types for the POWEFF framework.

     Copyright (c) 2021 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 Simplified 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 2024-04-16 {
    description
      "Restructured to use the Telemetry Philatelist framework";
    reference
      "RFC XXXX: ...";
  }

  typedef something {
    // FIXME: Used when we haven't decided the type yet
    type string;
    description "FIXME";
  }
  typedef xpath {
    type string;
    // FIXME: Proper type needed
    description "FIXME";
  }
  typedef sample-frequency {
    type string;
    // FIXME: Proper type needed
    description "FIXME";
  }

  // ========== SENSOR-QUANTITY ==============================
  identity sq-voltage {
    base ietf-tlm-philatelist-types:sensor-quantity;
    description
      "Sensor reports electric tension, voltage.
      ";
  }
  identity sq-current {
    base ietf-tlm-philatelist-types:sensor-quantity;
    description
      "Sensor reports electric current.
      ";
  }
  identity sq-power {
    base ietf-tlm-philatelist-types:sensor-quantity;
    description
      "Sensor reports power draw (energy per unit of time).
      ";
  }
  identity sq-power-apparent {
    base sq-power;
    description
      "Sensor reports apparent power, i.e. average electrical
      current times voltage (in VA).
      ";
  }
  identity sq-power-true {
    base sq-power;
    description
      "Sensor reports true power, i.e. integral over current
      and voltage at each instant in time.
      ";
  }
  identity sq-energy {
    base ietf-tlm-philatelist-types:sensor-quantity;
    description
      "Sensor reports actual energy drawn by asset.
      ";
  }
  identity sq-co2-emission {
    base ietf-tlm-philatelist-types:sensor-quantity;
    description
      "Sensor reports CO2 (carbon dioxide) emission by asset.
      ";
  }
  identity sq-co2eq-emission {
    base ietf-tlm-philatelist-types:sensor-quantity;
    description
      "Sensor reports CO2 (carbon dioxide) equivalent
      emission by asset.
      ";
  }
  identity sq-temperature {
    base ietf-tlm-philatelist-types:sensor-quantity;
    description
      "Sensor reports temperature of asset.
      ";
  }
  identity sq-time {
    base ietf-tlm-philatelist-types:sensor-quantity;
    description
    "Sensor reports time duration.
    ";
  }

  // ========== SENSOR-UNIT ==============================
  identity su-volt {
    base ietf-tlm-philatelist-types:sensor-unit;
    base sq-voltage;
    description
    "Sensor unit volt, V.
    ";
  }
  identity su-ampere {
    base ietf-tlm-philatelist-types:sensor-unit;
    base sq-current;
    description
      "Sensor unit ampere, A.
      ";
  }
  identity su-watt {
    base ietf-tlm-philatelist-types:sensor-unit;
    base sq-power;
    description
      "Sensor unit watt, W.
      ";
  }
  identity su-voltampere {
    base ietf-tlm-philatelist-types:sensor-unit;
    base sq-power;
    description
      "Sensor unit Volt*Ampere, VA.
      ";
  }
  identity su-kw {
    base ietf-tlm-philatelist-types:sensor-unit;
    base sq-power;
    description
      "Sensor unit kilowatt, kW.
      ";
  }
  identity su-joule {
    base ietf-tlm-philatelist-types:sensor-unit;
    base sq-energy;
    description
      "Sensor unit joule, J.
      ";
  }
  identity su-wh {
    base ietf-tlm-philatelist-types:sensor-unit;
    base sq-energy;
    description
      "Sensor unit watthour, Wh.
      ";
  }
  identity su-kwh {
    base ietf-tlm-philatelist-types:sensor-unit;
    base sq-energy;
    description
      "Sensor unit kliowatthour, kWh.
      ";
  }
  identity su-kelvin {
    base ietf-tlm-philatelist-types:sensor-unit;
    base sq-temperature;
    description
      "Sensor unit kelvin, K.
      ";
  }
  identity su-celsius {
    base ietf-tlm-philatelist-types:sensor-unit;
    base sq-temperature;
    description
      "Sensor unit celsius, C.
      ";
  }
  identity su-farenheit {
    base ietf-tlm-philatelist-types:sensor-unit;
    base sq-temperature;
    description
      "Sensor unit farenheit, F.
      ";
  }
  identity su-gram {
    base ietf-tlm-philatelist-types:sensor-unit;
    base sq-co2-emission;
    description
      "Sensor unit gram, g.
      ";
  }
  identity su-kg {
    base ietf-tlm-philatelist-types:sensor-unit;
    base sq-co2-emission;
    description
      "Sensor unit kliogram, kg.
      ";
  }
  identity su-ton {
    base ietf-tlm-philatelist-types:sensor-unit;
    base sq-co2-emission;
    description
      "Sensor unit ton, t.
      ";
  }
  identity su-second {
    base ietf-tlm-philatelist-types:sensor-unit;
    base sq-time;
    description
      "Sensor unit second, s.
      ";
  }
  identity su-millisecond {
    base ietf-tlm-philatelist-types:sensor-unit;
    base sq-time;
    description
      "Sensor unit millisecond, ms.
      ";
  }
  identity su-microsecond {
    base ietf-tlm-philatelist-types:sensor-unit;
    base sq-time;
    description
      "Sensor unit microsecond, us.
      ";
  }

  // ========== SENSOR-TYPE ==============================
  extension sensor-type {
    argument identity-name;
    description
      "YANG Extension used to declare which sensor type
      (as in input/output, quantity and unit) it has in a
      standardized machine readable way.
      See ietf-tlm-philatelist-types:sensor-type.
      ";
  }
  identity st-v-in {
    base ietf-tlm-philatelist-types:sensor-type;
    base ietf-tlm-philatelist-types:sc-input;
    base sq-voltage;
    base su-volt;
    description
      "Sensor reporting Voltage In to asset.
      ";
  }
  identity st-v-out {
    base ietf-tlm-philatelist-types:sensor-type;
    base ietf-tlm-philatelist-types:sc-output;
    base sq-voltage;
    base su-volt;
    description
      "Sensor reporting Voltage Out of asset.
      ";
  }
  identity st-i-in {
    base ietf-tlm-philatelist-types:sensor-type;
    base ietf-tlm-philatelist-types:sc-input;
    base sq-current;
    base su-ampere;
    description
      "Sensor reporting Current In to asset.
      ";
  }
  identity st-i-out {
    base ietf-tlm-philatelist-types:sensor-type;
    base ietf-tlm-philatelist-types:sc-output;
    base sq-current;
    base su-ampere;
    description
      "Sensor reporting Current Out of asset.
      ";
  }
  identity st-p-in-apparent-watt {
    base ietf-tlm-philatelist-types:sensor-type;
    base ietf-tlm-philatelist-types:sc-input;
    base sq-power-apparent;
    base su-voltampere;
    description
      "Sensor reporting Power In to asset as apparent (I*U)
      power.
      ";
  }
  identity st-p-out-apparent-watt {
    base ietf-tlm-philatelist-types:sensor-type;
    base ietf-tlm-philatelist-types:sc-output;
    base sq-power-apparent;
    base su-voltampere;
    description
      "Sensor reporting Power Out of asset as apparent (I*U)
      power.
      ";
  }
  identity st-p-in-true-watt {
    base ietf-tlm-philatelist-types:sensor-type;
    base ietf-tlm-philatelist-types:sc-input;
    base sq-power-true;
    base su-watt;
    description
      "Sensor reporting Power In to asset as true power.
      ";
  }
  identity st-p-out-true-watt {
    base ietf-tlm-philatelist-types:sensor-type;
    base ietf-tlm-philatelist-types:sc-output;
    base sq-power-true;
    base su-watt;
    description
      "Sensor reporting Power Out of asset as true power.
      ";
  }
  identity st-p-allocated-watt {
    base ietf-tlm-philatelist-types:sensor-type;
    base ietf-tlm-philatelist-types:sc-allocated;
    base sq-power;
    base su-watt;
    description
      "Sensor reporting Allocated Power for asset.
      ";
  }
  identity st-w-j {
    base ietf-tlm-philatelist-types:sensor-type;
    base sq-energy;
    base su-joule;
    description
      "Sensor reporting energy draw of asset in J.
      ";
  }
  identity st-w-wh {
    base ietf-tlm-philatelist-types:sensor-type;
    base sq-energy;
    base su-wh;
    description
      "Sensor reporting energy draw of asset in Wh.
      ";
  }
  identity st-w-kwh {
    base ietf-tlm-philatelist-types:sensor-type;
    base sq-energy;
    base su-kwh;
    description
      "Sensor reporting energy draw of asset in kWh.
      ";
  }
  identity st-t-k {
    base ietf-tlm-philatelist-types:sensor-type;
    base sq-temperature;
    base su-kelvin;
    description
      "Sensor reporting Temperature of asset in K.
      ";
  }
  identity st-t-c {
    base ietf-tlm-philatelist-types:sensor-type;
    base sq-temperature;
    base su-celsius;
    description
      "Sensor reporting Temperature of asset in °C.
      ";
  }
  identity st-t-f {
    base ietf-tlm-philatelist-types:sensor-type;
    base sq-temperature;
    base su-farenheit;
    description
      "Sensor reporting Temperature of asset in °F.
      ";
  }

  // ========== TSDB-PATH ======================================
  extension tsdb-path {
    argument tsdb-path;
    description
      "YANG Extension for declaring the TSDB path that a given
      YANG leaf would have.
      ";
  }
  // ========== COLLECTION-METHOD ==============================
  // None defined here

  // ========== POWER-SAVE UNITS ===============================
  typedef microseconds {
    type uint32;
    units us;
    description
      "Time unit, millionths of a second. 10^-6 seconds.
      ";
  }
  typedef percent {
    type uint32 {
      range 0..100;
    }
    units %;
    description
      "Percent fraction, 1/100 of something.
      ";
  }
}

5.2. Module ietf-poweff-level-1.yang 

module ietf-poweff-level-1 {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-level-1";
  prefix ietf-poweff-level-1;

  import ietf-poweff-types {
    prefix ietf-poweff-types;
  }

  organization
    "IETF OPSA (Operations and Management Area) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/opsawg/>
     WG List:  <mailto:opsawg@ietf.org>
     Editor:  Jan Lindblad
              <mailto:jlindbla@cisco.com>
     Editor:  Snezana Mitrovic
              <mailto:snmitrov@cisco.com>
     Editor:  Marisol Palmero
              <mailto:mpalmero@cisco.com>";
  description
    "This YANG module defines the POWEFF Level 1.

    Copyright (c) 2024 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.

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

  revision 2024-04-16 {
    description
      "Initial revision of POWEFF Level 1";
    reference
      "RFC XXXX: ...";
  }

  container poweff {
    description
      "Top level container for POWEFF.
      ";
    container stats {
      config false;
      description
        "Statistics (read-only) branch of POWEFF.
        ";
      leaf device-current-total-power-draw {
        type uint32;
        units W;
        ietf-poweff-types:sensor-type
          ietf-poweff-types:st-p-in-true-watt;
        ietf-poweff-types:tsdb-path
          poweff.stats.device_current_total_power_draw;
        description
          "The current power draw of the device that the
          management server pertains to, including power supplies.
          Does not include power draw of external cooling systems
          that may be required to operate this system.

          The power draw MUST be reported in Watts, and MUST be the
          true RMS power. The reported value MUST NOT be lower than
          the actual power draw. Any violations of these conditions
          may be legally construed as greenwashing, as defined by
          EU Green Claims Directive (GCD), EU 2023/0085(COD).
          ";
      }
    }
  }
}

5.3. Module ietf-poweff-level-2.yang 

module ietf-poweff-level-2 {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-level-2";
  prefix ietf-poweff-level-2;

  import ietf-yang-types {
    prefix yang;
  }
  import ietf-poweff-types {
    prefix ietf-poweff-types;
  }
  import ietf-poweff-level-1 {
    prefix ietf-poweff-level-1;
  }

  organization
    "IETF OPSA (Operations and Management Area) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/opsawg/>
     WG List:  <mailto:opsawg@ietf.org>
     Editor:  Jan Lindblad
              <mailto:jlindbla@cisco.com>
     Editor:  Snezana Mitrovic
              <mailto:snmitrov@cisco.com>
     Editor:  Marisol Palmero
              <mailto:mpalmero@cisco.com>";
  description
    "This YANG module defines the POWEFF Level 2.

    Copyright (c) 2024 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.

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

  revision 2024-04-16 {
    description
      "Initial revision of POWEFF Level 2";
    reference
      "RFC XXXX: ...";
  }

  typedef subsys-name-t {
    type union {
      type enumeration {
        enum sys {
          description "The name of the top level object is 'sys'.";
        }
      }
      type string {
        pattern '[a-zA-Z]+[a-zA-Z0-9_/\.:-]*[a-zA-Z0-9_/]+';
      }
    }
    description
      "Type for subsystem names. Must start with an ASCII
      alpabetic characters. The characters following may also be
      numeric characters, dash, underscore, forward slash. Parts of
      the name may be interpunctuated with a dot or colon.
      Interpunctuation must not be the last character in the name.";
  }

  augment /ietf-poweff-level-1:poweff/ietf-poweff-level-1:stats {
    description
      "Level 2 extends the Level 1 defintions with additional content.
      ";
    leaf device-total-energy-spent {
      type uint32;
      units J;
      ietf-poweff-types:sensor-type
        ietf-poweff-types:st-w-j;
      ietf-poweff-types:tsdb-path
        poweff.stats.device_total_energy_spent;
      description
        "The total energy spent by the device since the point
        in time specified by ../device-total-energy-spent-since.
        This is the integral over time of the power draw as specified
        by ../ietf-poweff-level-1:device-current-total-power-draw.

        The energy used MUST be reported in Joule. The reported value
        MUST NOT be lower than the actual energy used.
        Any violations of these conditions
        may be legally construed as greenwashing, as defined by
        EU Green Claims Directive (GCD), EU 2023/0085(COD).";
    }
    leaf device-total-energy-spent-since {
      type yang:date-and-time;
      description
        "The point in time at which the energy couting started.
        Typically at the most recent system initalization.";
    }
    list subsystem {
      key name;
      description
        "List of subsystems, in a tree structure, as defined by the
        system implementor. There MUST be an entry called 'sys',
        which MUST have a current-power-draw value equal to the
        ../ietf-poweff-level-1:device-current-total-power-draw value.
        ";
      leaf name {
        type subsys-name-t;
        description
          "The name of the subsystem. The name is built from the name
          of its ancestors joined with a dot (.). The root object of
          tree is called 'sys'.

          An example of a valid tree structure:
           - sys
           - sys.main-board
           - sys.main-board.cpu0
           - sys.main-board.cpu1
           - sys.linecard1
           - sys.linecard1.eth0/1
           - sys.psu0
           - sys.psu0.fan0
           - sys.psu0.fan1
          ";
      }
      leaf current-power-draw {
        type uint32;
        units W;
        ietf-poweff-types:sensor-type
          ietf-poweff-types:st-p-in-true-watt;
        ietf-poweff-types:tsdb-path
          poweff.stats.subsystem.current_power_draw;
        description
          "Current power draw of the subsystem in Watts.
          This value MUST be larger than or equal to the sum of the
          power draw of all children listed in ../children, if any.";
      }
      leaf-list children {
        type leafref {
          path ../../subsystem/name;
        }
        description
          "Children of this subsystem, each contributing to the power
          draw of this subsystem.";
      }
    }
  }
}

5.4. Module ietf-poweff-level-3.yang 

module ietf-poweff-level-3 {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-level-3";
  prefix ietf-poweff-level-3;

  import ietf-poweff-types {
    prefix ietf-poweff-types;
  }
  import ietf-poweff-level-1 {
    prefix ietf-poweff-level-1;
  }
  import ietf-poweff-level-2 {
    prefix ietf-poweff-level-2;
  }

  organization
    "IETF OPSA (Operations and Management Area) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/opsawg/>
     WG List:  <mailto:opsawg@ietf.org>
     Editor:  Jan Lindblad
              <mailto:jlindbla@cisco.com>
     Editor:  Snezana Mitrovic
              <mailto:snmitrov@cisco.com>
     Editor:  Marisol Palmero
              <mailto:mpalmero@cisco.com>";
  description
    "This YANG module defines the POWEFF Level 3.

    Copyright (c) 2024 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.

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

  revision 2024-04-16 {
    description
      "Initial revision of POWEFF Level 3";
    reference
      "RFC XXXX: ...";
  }

  augment /ietf-poweff-level-1:poweff {
    description
      "Level 3 extends the Level 1 & 2 defintions with additional
      content.
      ";
    container power-save {
      description
        "Container for power-save control functions that the
        Network Controller may use to ask this Network Element
        to employ zero or more power-saving techniques.
        ";

      list subsystem {
        key name;
        description
          "List of subsystems that offer power-saving functions.
          ";
        leaf name {
          type leafref {
            path "/ietf-poweff-level-1:poweff/" +
            "ietf-poweff-level-1:stats/"+
            "ietf-poweff-level-2:subsystem/"+
            "ietf-poweff-level-2:name";
            require-instance false;
          }
          description
            "Name of the subsystem that offers power-saving
            functionality. This name normally matches one of the
            names in the poweff/stats subsystem list, but it is
            possible that a subsystem is not listed there e.g.
            because it has not started yet, during the system
            initialization.
            ";
        }
        choice selected-power-save-mode {
          description
            "Choice of power saving modes that the Controller
            may select. Additional power-saving modes may be
            augmented into this choice by implementors, but may
            not be known/understood by the controller.
            ";
          leaf fully-powered {
            type empty;
            description
              "The subsystem is fully powered, i.e. does not take
              any power-saving measures that would risk lowering the
              performance below normal levels.
              ";
          }
          leaf powered-off {
            type empty;
            description
              "The subsystem is completely powered off, i.e. it is
              drawing no or little power while also delivering zero
              performance.
              ";
          }
          container napping {
            description
              "The subsystem is napping, i.e. is taking frequent but
              brief pauses in the service it provides.
              ";
            leaf max-additional-latency {
              type ietf-poweff-types:microseconds;
              description
                "Determines the maximum tolerated length of the pauses
                with reduced performance. This means the maximum
                additional delay that this subsystem would incur on
                e.g. detecting incoming traffic or performing its
                function.
                ";
            }
          }
          container throttling {
            description
              "The subsystem is throttling, i.e. is running with
              reduced capacity in the service it provides.
              ";
            leaf max-capacity-reduction {
              type ietf-poweff-types:percent;
              description
                "Determines the maximum tolerated reduction of
                performance. If this setting is applied to a bundle
                interface, for example, that consists of 3 underlaying
                links of equal capacity, and the controller sets the
                max-capacity-reduction value to 50%, the bundle
                interface could shut down one of the links.
                ";
            }
          }
        }
        leaf max-time-to-cancel-power-save {
          type ietf-poweff-types:microseconds;
          description
            "The maximum time the Controller allows the subsystem
            to recover full performance. The subsystem should not
            engage in power-saving measures that take longer than
            this time to revert to full performance.
            ";
        }
        leaf estimated-power-reduction {
          type uint32;
          config false;
          description
            "The subsystem's own estimate on how much of its own
            power draw that is reduced by the power-saving
            measures in effect.
            If the controller sets a bundle interface that consists of
            3 underlaying links of equal capacity, for example, into
            50% throttling mode, the subsystem might shut down one of
            the underlaying links and report an
            estimated-power-reduction of 33%.
            ";
        }
      }
    }
  }
}

5.5. Module ietf-poweff-level-4.yang 

module ietf-poweff-level-4 {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-level-4";
  prefix ietf-poweff-level-4;

  import ietf-poweff-types {
    prefix ietf-poweff-types;
  }
  import ietf-poweff-level-1 {
    prefix ietf-poweff-level-1;
  }

  organization
    "IETF OPSA (Operations and Management Area) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/opsawg/>
     WG List:  <mailto:opsawg@ietf.org>
     Editor:  Jan Lindblad
              <mailto:jlindbla@cisco.com>
     Editor:  Snezana Mitrovic
              <mailto:snmitrov@cisco.com>
     Editor:  Marisol Palmero
              <mailto:mpalmero@cisco.com>";
  description
    "This YANG module defines the POWEFF Level 4.

    Copyright (c) 2024 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.

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

  revision 2024-04-16 {
    description
      "Initial revision of POWEFF Level 4";
    reference
      "RFC XXXX: ...";
  }

  augment /ietf-poweff-level-1:poweff/ietf-poweff-level-1:stats {
    description
      "Level 4 extends the Level 1, 2 & 3 defintions with
      power draw data broken down on services.
      ";
    list service {
      key name;
      description
        "List of services that the Network Element is aware of, and
        their current power draw. The power draw MAY be further
        subdivided for each service by using a dot notation.

        One service instance called '-idle-' may be present in the
        list and absorb any overhead/idle/other/unknown kind of power
        draw that the system would not allocate to any service.

        It is up to the implementor to decide what a 'service' means
        for this type of system. It may be any kind of service that it
        delivers user value towards.

        For example, if a system serves three customers, X, Y and Z,
        their power draw could be declared as follows:

        | name          | current- | children                    |
        |               | power-   |                             |
        |               | draw     |                             |
        |---------------|----------|-----------------------------|
        | X             |       45 | [ vpn ]                     |
        | X.vpn         |       39 | [ eth1/16 eth2/33 eth3/11 ] |
        | X.vpn.eth1/16 |       14 |                             |
        | X.vpn.eth2/33 |       12 |                             |
        | X.vpn.eth3/11 |        9 |                             |
        | Y             |       26 |                             |
        | Z             |       19 |                             |
        | -idle-        |       48 |                             |

        The sum of the current-power-draw top level entries
        (in this example: X, Y, Z and -idle-, with values
        45 + 26 + 19 + 48 = 138) must match the value provided in
        ietf-poweff-level-1:device-current-total-power-draw

        The sub-service values (e.g. X.vpn, 39W) need to be lower than
        or equal to (but do not necessarily need to match) their
        parent level (e.g. X, 45W).

        Note: the name of the children have been abbreviated in
        the diagram above. In the actual payload, the full names
        would always be used, e.g. 'eth1/16' above would actually be
        communicated as 'X.vpn.eth1/16'.
        ";
      leaf name {
        type string;
        description
          "Name of the service/tenant/client/domain/function that the
          system allocates power draw for. Power draw MAY be further
          subdivided for each service by using a dot notation.
          ";
      }
      leaf current-power-draw {
        type uint32;
        units W;
        ietf-poweff-types:sensor-type
          ietf-poweff-types:st-p-in-true-watt;
        ietf-poweff-types:tsdb-path
          poweff.stats.service.current_power_draw;
        description
          "The current power draw of the service provided in Watts.
          ";
      }
      leaf-list children {
        type leafref {
          path ../../service/name;
        }
        description
          "Child-services that contribute to the service's power draw.
          All leafref values must exactly match the names used in
          the name leaf.
          ";
      }
    }
  }
}

5.6. Module ietf-poweff-level-5.yang 

module ietf-poweff-level-5 {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-level-5";
  prefix ietf-poweff-level-5;

  import ietf-poweff-types {
    prefix ietf-poweff-types;
  }
  import ietf-poweff-level-1 {
    prefix ietf-poweff-level-1;
  }
  import ietf-poweff-level-3 {
    prefix ietf-poweff-level-3;
  }
  import ietf-poweff-level-4 {
    prefix ietf-poweff-level-4;
  }

  organization
    "IETF OPSA (Operations and Management Area) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/opsawg/>
     WG List:  <mailto:opsawg@ietf.org>
     Editor:  Jan Lindblad
              <mailto:jlindbla@cisco.com>
     Editor:  Snezana Mitrovic
              <mailto:snmitrov@cisco.com>
     Editor:  Marisol Palmero
              <mailto:mpalmero@cisco.com>";
  description
    "This YANG module defines the POWEFF Level 5.

    Copyright (c) 2024 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.

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

  revision 2024-04-16 {
    description
      "Initial revision of POWEFF Level 5";
    reference
      "RFC XXXX: ...";
  }

  augment /ietf-poweff-level-1:poweff/ietf-poweff-level-3:power-save {
    description
      "Level 5 extends the Level 3 & 4 defintions with
      power control for each on service instance.
      ";
    list service {
      key name;
      description
        "List of services that offer power-saving functions.
        ";
      leaf name {
        type leafref {
          path "/ietf-poweff-level-1:poweff/" +
          "ietf-poweff-level-1:stats/"+
          "ietf-poweff-level-4:service/"+
          "ietf-poweff-level-4:name";
          require-instance false;
        }
        description
          "Name of the sservice instance that offers power-saving
          functionality. This name normally matches one of the
          names in the poweff/stats/service list, but it is
          possible that a service is not listed there e.g.
          because it has not started yet, or has been removed.
          ";
      }
      choice selected-power-save-mode {
        // FIXME: This is currently a copy of the level-3 power-save
        // modes. If it is to remain so, we should break it out into
        // a grouping. But maybe we want them to be different?
          description
            "Choice of power saving modes that the Controller
            may select. Additional power-saving modes may be
            augmented into this choice by implementors, but may
            not be known/understood by the controller.
            ";
          leaf fully-powered {
            type empty;
            description
              "The service is fully powered, i.e. does not take
              any power-saving measures that would risk lowering the
              performance below normal levels.
              ";
          }
          leaf powered-off {
            type empty;
            description
              "The service is completely powered off, i.e. it is
              drawing no or little power while also delivering zero
              performance.
              ";
          }
          container napping {
            description
              "The service is napping, i.e. is taking frequent but
              brief pauses in the service it provides.
              ";
            leaf max-additional-latency {
              type ietf-poweff-types:microseconds;
              description
                "Determines the maximum tolerated length of the pauses
                with reduced performance. This means the maximum
                additional delay that this service would incur on
                e.g. detecting incoming traffic or performing its
                function.
                ";
            }
          }
          container throttling {
            description
              "The service is throttling, i.e. is running with
              reduced capacity in the functionality it provides.
              ";
            leaf max-capacity-reduction {
              type ietf-poweff-types:percent;
              description
                "Determines the maximum tolerated reduction of
                performance. If this setting is applied to a bundle
                interface, for example, that consists of 3 underlaying
                links of equal capacity, and the controller sets the
                max-capacity-reduction value to 50%, the bundle
                interface could shut down one of the links.
                ";
            }
          }
        }
      leaf max-time-to-cancel-power-save {
        type ietf-poweff-types:microseconds;
        description
          "The maximum time the Controller allows the service
          to recover full performance. The service should not
          engage in power-saving measures that take longer than
          this time to revert to full performance.
          ";
      }
      leaf estimated-power-reduction {
        type uint32;
        config false;
        description
          "The service's own estimate on how much of its own
          power draw that is reduced by the power-saving
          measures in effect.
          If the controller sets a bundle interface that consists of
          3 underlaying links of equal capacity, for example, into
          50% throttling mode, the service might shut down one of
          the underlaying links and report a
          estimated-power-reduction of 33%.
          ";
      }
    }
  }
}

6. Deployment Considerations

POWEFF data models define the data schemas for power consumption and energy efficiency data. POWEFF data models are based on YANG. YANG data models can be used independently of the transport and can be converted into any encoding format supported by the network configuration protocol. YANG is therefore largely management protocol independent.

To enable the exchange of POWEFF data among all interested parties, deployment considerations that are out of the scope of this document, will need to include:

7. Security Considerations

The security considerations mentioned in section 17 of [RFC7950] apply.

POWEFF brings several security and privacy implications because of the various components and attributes of the information model. For example, each functional component can be tampered with to give manipulated data. POWEFF when used alone or with other relevant data, can identify an individual, revealing Personal Identifiable Information (PII). How the configuration of assets should be accomplished could lead to data being accessed by unauthorized entities.

Methods exist to secure the communication of management information. The transport entity of the functional model MUST implement methods for secure transport. This document also contains an Information model and Data-Model in which none of the objects defined are writable. If the objects are deemed sensitive in a particular environment, access to them MUST be restricted using appropriately configured security and access control rights. The information model contains several optional elements which can be enabled or disabled for the purpose of privacy and security. Proper authentication and audit trail MUST be included for all the users/processes that access POWEFF data.

8. IANA Considerations

9. References

9.1. Normative References

[I-D.draft-lindblad-tlm-philatelist-01]
Lindblad, J., "Philatelist, YANG-based Network Controller collection and aggregation framework integrating Telemetry data and Time Series Databases", Work in Progress, Internet-Draft, draft-lindblad-tlm-philatelist-01, , <https://datatracker.ietf.org/api/v1/doc/document/draft-lindblad-tlm-philatelist/>.
[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/info/rfc2119>.
[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/info/rfc8174>.

9.2. Informative References

[I-D.draft-almprs-sustainability-insights-02]
Andersson, P., Lindblad, J., Mitrovic, S., Palmero, M., Roure, E., Salgueiro, G., and S. Emile, "Sustainability Insights", Work in Progress, Internet-Draft, draft-almprs-sustainability-insights-02, , <https://datatracker.ietf.org/doc/html/draft-almprs-sustainability-insights-02>.
[I-D.draft-palmero-ivy-ps-almo-01]
Palmero, M., Brockners, F., Kumar, S., Cardona, C., and D. Lopez, "Asset Lifecycle Management and Operations: A Problem Statement", Work in Progress, Internet-Draft, draft-palmero-ivy-ps-almo-01, , <https://datatracker.ietf.org/doc/html/draft-palmero-ivy-ps-almo-01>.
[RFC6241]
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, , <https://www.rfc-editor.org/info/rfc6241>.
[RFC7950]
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, , <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, , <https://www.rfc-editor.org/info/rfc8040>.

Change log

RFC Editor Note: This section is to be removed during the final publication of the document.

Acknowledgments

This document was created by meaningful contributions from Per Andersson, Jeff Apcar, Derek Engi, Esther Roure Vila, Pascal Thubert, Klaus Verschure, Joel Goergen, Colin Seward, Michael King, Angelo Fienga and Suresh Krishnan.

The authors wish to thank them and many others for their helpful comments and suggestions.

Authors' Addresses

Jan Lindblad
Cisco Systems
Snezana Mitrovic
Cisco Systems
Marisol Palmero
Cisco Systems
Gonzalo Salgueiro
Cisco Systems