Internet DRAFT - draft-opsawg-poweff
draft-opsawg-poweff
OPSA Working Group J. Lindblad
Internet-Draft S. Mitrovic
Intended status: Standards Track M. Palmero
Expires: 22 April 2024 G. Salgueiro
Cisco Systems
20 October 2023
Power and Energy Efficiency
draft-opsawg-poweff-00
Abstract
This document motivates and specifies a data model to report power
and energy efficiency of an asset. As highlighted during the IAB
workshop on environmental impacts
(https://datatracker.ietf.org/doc/html/draft-iab-ws-environmental-
impacts-report-00), 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, double counting and
even contradictory metrics across vendors.
This Power and Energy Efficiency Telemetry Specification (POWEFF) is
required to promote consistency across vendors and consumers, based
on: 1. The definition of datasets and attributes defining a common
data model utilized by the standard calculation to yield power and
energy efficiency value for any asset or network element. 2. The
standard calculations utilizing the specified datasets and attributes
which will yield energy consumption and energy efficiency value for
any asset or network element.
The model provides information and data requirements for calculating
the Power and Energy Efficiency for specific assets. Assets can
include hardware (physical or virtual), software, applications, or
services.
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/.
Lindblad, et al. Expires 22 April 2024 [Page 1]
Internet-Draft POWEFF October 2023
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 22 April 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Proposed Solution Outline . . . . . . . . . . . . . . . . 6
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Information Model . . . . . . . . . . . . . . . . . . . . . . 7
6. Data Models . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1.1. ietf-poweff-asset-ext . . . . . . . . . . . . . . . . 8
6.1.2. ietf-poweff-static . . . . . . . . . . . . . . . . . 8
6.1.3. ietf-poweff-environment . . . . . . . . . . . . . . . 9
6.1.4. ietf-poweff-traffic . . . . . . . . . . . . . . . . . 9
6.1.5. ietf-poweff-derived . . . . . . . . . . . . . . . . . 9
6.1.6. ietf-poweff-sensors . . . . . . . . . . . . . . . . . 9
6.1.7. ietf-poweff-types . . . . . . . . . . . . . . . . . . 9
6.1.8. ietf-sustainability-insights-common . . . . . . . . . 9
6.2. YANG data models of POWEFF modules . . . . . . . . . . . 9
6.2.1. Asset Extension Module . . . . . . . . . . . . . . . 9
6.2.2. Power Environment Module . . . . . . . . . . . . . . 11
6.2.3. Power Static Module . . . . . . . . . . . . . . . . . 13
6.2.4. Power Traffic Module . . . . . . . . . . . . . . . . 14
6.2.5. Power Derived Module . . . . . . . . . . . . . . . . 18
6.2.6. Power Sensors Module . . . . . . . . . . . . . . . . 20
6.2.7. Power Types Module . . . . . . . . . . . . . . . . . 27
Lindblad, et al. Expires 22 April 2024 [Page 2]
Internet-Draft POWEFF October 2023
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
9.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 34
9.2. The YANG Module Names Registry . . . . . . . . . . . . . 35
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Normative References . . . . . . . . . . . . . . . . . . 35
10.2. Informative References . . . . . . . . . . . . . . . . . 35
Change log . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction
The ability to speak a common language of how to measure power
consumption, and how to use those measurements in calculations to
derive meaningful data is an important business objective and central
to developing customer insights. Today, vendors work independently
to create methods of measurement and algorithms to calculate similar,
yet inconsistent common data elements. When different business
entities, responsible for developing multiple products and solutions,
do not coordinate efforts, varying results causes confusion to
downstream consumers of the data.
The Power and Energy Efficiency Telemetry Specification seeks to
address this inconsistency by providing a single reference for these
important activities, aiming to create value through insights.
POWEFF is considered a first phase of the Sustainability Telemetry
Specification, as defined in the Sustainability Insights
[I-D.draft-almprs-sustainability-insights-02] IETF draft.
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
Lindblad, et al. Expires 22 April 2024 [Page 3]
Internet-Draft POWEFF October 2023
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-00] 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
(https://ghgprotocol.org/).
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
(https://ghgprotocol.org/).
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 (https://ghgprotocol.org/).
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
Lindblad, et al. Expires 22 April 2024 [Page 4]
Internet-Draft POWEFF October 2023
Refers to the electrical energy per unit 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
(https://en.wikipedia.org/wiki/Energy_efficiency).
3. Motivation
The main objective of POWEFF is to measure and report power and
energy related metrics and provide the necessary insights to improve
the overall CO2eq emission for use cases of which the asset
contributes during its use. Following product Lifecycle Accounting
(LCA), POWEFF focuses on the Use stage defined by the GHG Protocol
Accounting and Reporting Standard, which is in accordance with the
ISO 14040:44 standards. It includes emissions from the use of goods
and services sold by the reporting organization 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
(https://www.cisco.com/c/m/en_us/about/csr/esg-hub/environment/
goals.html#scope-1-3-emissions).
Power and energy consumption Telemetry data available for different
infrastructure vendors today is characterized by inconsistency and
best effort:
* Availability of primary data. Data is often only available on a
case by case basis.
* Varying APIs. Where Telemetry might be available, access methods,
data contents and formats are specific to platforms or elements.
* Limitations. Some useful or essential data items are never
collected by the relevant hardware or software.
* Precision. Data often contains significant margins of error, both
from random noise and systematic errors.
Lindblad, et al. Expires 22 April 2024 [Page 5]
Internet-Draft POWEFF October 2023
* Varying definitions. Calculated values use differing inputs and
algorithms, limiting the value of any possible comparison and
aggregation.
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 needs.
4. 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.
Lindblad, et al. Expires 22 April 2024 [Page 6]
Internet-Draft POWEFF October 2023
5. Information Model
The broad metric classes defined in previous sections that quantify
power and energy efficiency can be modeled as shown in the
information POWEFF model below (Figure 1). There is an inventory of
all assets that the user or vendor possesses. The representation
proposes an extension of the inventory module, and include attributes
that provide insight to energy efficiency. Attributes defined as
"role" of an asset or "location" of a network equipment are
meaningful to compute energy efficiency and CO2eq footprint. Each
asset will have attributes that determines power usage measured in a
controlled environment, and energy consumption measured in
production, this includes metrics related to the data traffic being
processed by that particular asset. Based on those runtime and
static measurements, power and energy metrics will be deduced.
For example, when a user needs to measure the power utilization of a
specific type of asset, the power information might be retrieved from
a database. The asset state (active or not) will determine the
energy consumption. As different assets (modules or components)
might be part of a specific chassis, they are aggregated to provide
power related information as per the information model shown below
(Figure 1).
+---------------------+
| ietf-poweff-derived |
+--------+------------+
|
+----------------+----------------+
v | v
+------------+-------+ | +--------+------------+
| ietf-poweff-static | | | ietf-poweff-traffic |
+------------+-------+ | +------------+--------+
| v |
| +--------------+----------+ |
| | ietf-poweff-environment | |
| +--------------+----------+ |
| | |
+--------------------+----------------+
v
+-----------------------+
| ietf-poweff-asset-ext |
+-----------------------+
Figure 1: Information POWEFF Model
Lindblad, et al. Expires 22 April 2024 [Page 7]
Internet-Draft POWEFF October 2023
The functional block that refers to poweff-derived, contains the
logic to compute power consumed and energy efficiency by the specific
assets, as well as the units of measurement.
From a simplification of the diagram, poweff-types and poweff-sensors
have been excluded. They should be linked to poweff-environment, for
the runtime measurements and to poweff-static, covering measurements
given by the manufacturer. They described the sensor types, units of
measurements and other meaningful caracteristics of sensors.
6. Data Models
6.1. Overview
6.1.1. ietf-poweff-asset-ext
Describes and extends asset to cover sustainability use cases.
Aligned with the network inventory, asset refers to hardware,
software, applications, or services. An asset can be physical or
virtual. This model provides the extension grafting point on top of
an inventory model.
6.1.2. ietf-poweff-static
Evaluating systems should include benchmarks that can be standardized
as well as network-specific configurations which may include multiple
generations of hardware, a partially filled chassis, or different
traffic loads. These data normally corresponds to values provided by
the manufacturer.
Data for a specific asset that aligns to values provided by the
manufacturer can be classified as “static” since they are unlikely to
change.
It is important to note that those values have been measured under
certain conditions, including benchmarks that can be standardized,
and network-specific configurations that may include multiple
generations of hardware, a partially filled chassis, or different
traffic loads.
Each chassis is typically benchmarked for Idle, Typical=Operating,
and Maximum capacity that might consist of temperature, hardware
load, traffic, fans, CPU, memory, etc. For example, a particular
chassis is rated to function in a 27C(Typical), 40C(Operating), and
55C(Max) temperature environment. Note that environmental
temperature will not be the only required parameter required to
retrieve relevant static data for an asset.
Lindblad, et al. Expires 22 April 2024 [Page 8]
Internet-Draft POWEFF October 2023
6.1.3. ietf-poweff-environment
Describes the runtime values from the assets related to power
environment; comprising of reading Voltage, Current, Power (Watts),
Temperature, etc.
6.1.4. ietf-poweff-traffic
Describes the real-time interface and traffic reading from the asset.
This module might overlap with current YANG standards implemented at
the network device level, but this module offers a level of
abstraction to do not only cover networking equipment and a common
data module is proposed for consistency, which might map 1:1 to
current standards.
6.1.5. ietf-poweff-derived
Considers kpi's and metrics computed by an analytics engine, that
typically the values provided will be calculated on the collector,
even they could be also implemented by the asset.
6.1.6. ietf-poweff-sensors
Defines basic groupings for POWEFF sensor management
6.1.7. ietf-poweff-types
Defines basic quantities, measurement units and sensor types for the
POWEFF framework
6.1.8. ietf-sustainability-insights-common
Includes common attributes to extend sustainability related use cases
as defined in Sustainability Insights
[I-D.draft-almprs-sustainability-insights-02] IETF draft. , i.e.,
carbon intensity factor, cost per kwh, etc.
6.2. YANG data models of POWEFF modules
6.2.1. Asset Extension Module
<CODE BEGINS>
module ietf-poweff-asset-ext {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-asset-ext";
prefix ietf-poweff-asset-ext;
import ietf-lmo {
prefix ietf-lmo;
Lindblad, et al. Expires 22 April 2024 [Page 9]
Internet-Draft POWEFF October 2023
}
import ietf-lmo-assets {
prefix ietf-lmo-asset;
}
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 includes extra attributes which
complement sustainability for assets.
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 2023-10-12 {
description
"Initial revision to complement Asset Inventory Module as
part of the DMALMO YANG Model, with sustainability attributes";
reference
"RFC XXXX: DMALMO YANG Model";
}
augment /ietf-lmo:lmos/ietf-lmo:lmo/ietf-lmo:inst {
when "derived-from-or-self(../ietf-lmo:lmo-class, "+
" 'ietf-lmo-asset:asset')";
description
"Assets attributes related to sustainability";
leaf age {
Lindblad, et al. Expires 22 April 2024 [Page 10]
Internet-Draft POWEFF October 2023
type string;
description
"Age of the asset";
}
leaf site {
when "not(../ietf-lmo:parent/ietf-lmo:id)";
type string;
description
"location site name";
// FIXME: Make this a reference to a list of sites?
// FIXME: force this to be set for all assets that
// do not have a parent?
}
leaf modular {
type boolean;
description
"The asset is or is not modular";
}
leaf status {
type string;
description
"NEED to include: off, enabled, disabled, not present,
failed, reserved-on, standby";
//FIXME status is simply the most inconsistent field
//with wide variety of values reported. It is better
//to make this a Enum with fixed set list of states.
}
leaf slot {
type string;
mandatory "true";
description
"Defines the slot where the asset is placed in the chasssis.
Used to map the sensor to particular UID.";
}
leaf device-family {
type string;
description
"Device Family - may be derived from the product name or
product id. It is to be used for immplementation
purpose - filtering capability and future optimization
purposes";
}
}
}
<CODE ENDS>
6.2.2. Power Environment Module
Lindblad, et al. Expires 22 April 2024 [Page 11]
Internet-Draft POWEFF October 2023
<CODE BEGINS>
module ietf-poweff-environment {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-environment";
prefix ietf-poweff-environment;
import ietf-poweff-sensors {
prefix ietf-poweff-sensors;
}
import ietf-lmo {
prefix ietf-lmo;
}
import ietf-lmo-assets-inventory {
prefix ietf-lmo-asset;
}
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 includes the live reading from the network
devices related to the power environment. Dynamic/real-time
data read from the network device, basically reading Voltage,
Current, Power (Watts), and Temperature.
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.";
Lindblad, et al. Expires 22 April 2024 [Page 12]
Internet-Draft POWEFF October 2023
revision 2023-10-12 {
description
"Initial revision to document power environmental related data";
reference
"RFC XXXX: ...";
}
augment /ietf-lmo:lmos/ietf-lmo:lmo/ietf-lmo:inst {
when "derived-from-or-self(../ietf-lmo:lmo-class, "+
" 'ietf-lmo-asset:asset')";
description
"Assets attributes related to power environment";
uses ietf-poweff-sensors:sensors-g;
}
}
<CODE ENDS>
6.2.3. Power Static Module
<CODE BEGINS>
module ietf-poweff-static {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-static";
prefix ietf-poweff-static;
import ietf-poweff-sensors {
prefix ietf-poweff-sensors;
}
import ietf-lmo {
prefix ietf-lmo;
}
import ietf-lmo-assets-inventory {
prefix ietf-lmo-asset;
}
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 includes power and energy efficiency
Product Data. Data for a specific asset that aligns to values
Lindblad, et al. Expires 22 April 2024 [Page 13]
Internet-Draft POWEFF October 2023
provided by the manufacturer can be classified as “static”
since they are unlikely to change during the lifetime of the
product/asset.
They are typically available in a form of data sheets or any kind
of simulation tools.
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 2023-10-12 {
description
"Initial revision to document power static data";
reference
"RFC XXXX: ...";
}
augment /ietf-lmo:lmos/ietf-lmo:lmo/ietf-lmo:inst {
when "derived-from-or-self(../ietf-lmo:lmo-class, "+
" 'ietf-lmo-asset:asset')";
description
"Assets attributes related to power static attributes";
uses ietf-poweff-sensors:power-static-g;
}
}
<CODE ENDS>
6.2.4. Power Traffic Module
<CODE BEGINS>
module ietf-poweff-traffic {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-traffic";
prefix ietf-poweff-traffic;
import ietf-yang-types {
prefix yang;
}
Lindblad, et al. Expires 22 April 2024 [Page 14]
Internet-Draft POWEFF October 2023
import ietf-interfaces {
prefix if;
}
import ietf-lmo-assets-inventory {
prefix ietf-lmo-asset;
}
import ietf-lmo {
prefix ietf-lmo;
}
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 describes the live interface and traffic related
metrics. It should be based on rfc7223,
https://datatracker.ietf.org/doc/rfc7223/
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.
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 2023-10-12 {
Lindblad, et al. Expires 22 April 2024 [Page 15]
Internet-Draft POWEFF October 2023
description
"Initial revision to document power traffic data";
reference
"RFC XXXX: ...";
}
augment /ietf-lmo:lmos/ietf-lmo:lmo/ietf-lmo:inst {
when "derived-from-or-self(../ietf-lmo:lmo-class, "+
" 'ietf-lmo-asset:asset')";
description
"Traffic attributes related to sustainability";
container interfaces {
description "Interface parameters";
list interface {
key "name";
leaf name {
type leafref {
path "/if:interfaces/if:interface/if:name";
require-instance false;
}
description
"The name of the interface.";
}
leaf description {
type string;
description
"A textual description of the interface.
A server implementation MAY map this leaf to the ifAlias
MIB object. Such an implementation needs to use some
mechanism to handle the differences in size and characters
allowed between this leaf and ifAlias. The definition of
such a mechanism is outside the scope of this document.
Since ifAlias is defined to be stored in non-volatile
storage, the MIB implementation MUST map ifAlias to the
value of 'description' in the persistently stored
configuration.";
reference
"RFC 2863: The Interfaces Group MIB - ifAlias";
}
leaf if-index {
type int32;
description
"The ifIndex value for the ifEntry represented by this
interface";
reference
"RFC 2863: The Interfaces Group MIB - ifIndex";
}
Lindblad, et al. Expires 22 April 2024 [Page 16]
Internet-Draft POWEFF October 2023
leaf interface-type {
type string;
//TO_DO adjust type to identy interface-type or similar
description
"The type of the interface.
When an interface entry is created, a server MAY
initialize the type leaf with a valid value, e.g., if it
is possible to derive the type from the name of the
interface.
If a client tries to set the type of an interface to a
value that can never be used by the system, e.g., if the
type is not supported or if the type does not match the
name of the interface, the server MUST reject the request.
A NETCONF server MUST reply with an rpc-error with the
error-tag 'invalid-value' in this case.";
reference
"RFC 2863: The Interfaces Group MIB - ifType";
}
leaf bandwidth {
type yang:gauge64;
units "kbits/s";
description
"It is considered to be the Max bandwidth of the interface,
in kbps, it could also be called capacity";
}
leaf speed {
type yang:gauge64;
units "kbits/s";
description
"It is considered to be current bandwidth of the interface,
in kbps, it could also be called capacity";
}
leaf data-rate-frequency {
type string;
//TO_DO normalized to do not be string, as different devices
//will provide different implementation
description
"The length of time for which data is used to compute load
statistics, load-interval command in interface
configuration. Default value is 5min";
}
container statistics {
description "A collection of interface-related statistics
objects.";
leaf input-data-rate {
type uint64;
Lindblad, et al. Expires 22 April 2024 [Page 17]
Internet-Draft POWEFF October 2023
units "kbits/s";
mandatory "true";
description
"Input data rate in 1000's of bps. Average number of bits
received per second in the last load period
(300 sec by default)";
}
leaf input-packet-rate {
type uint64;
units "packet/s";
description
"Input packets per second. Average number of packets
received per second in the last load period
(300 sec by default)";
}
leaf output-data-rate {
type uint64;
units "kbits/s";
mandatory "true";
description
"Output data rate in 1000's of bps. Average number of bits
sent per second in the last load period
(300 sec by default)";
}
leaf output-packet-rate {
type uint64;
units "packet/s";
description
"Output packets per second. Average number of packets
sent per second in the last load period
(300 sec by default)";
}
}
description "Interface parameters for a specific interface";
}
}
}
}
<CODE ENDS>
6.2.5. Power Derived Module
<CODE BEGINS>
module ietf-poweff-derived {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-derived";
prefix ietf-poweff-derived;
Lindblad, et al. Expires 22 April 2024 [Page 18]
Internet-Draft POWEFF October 2023
import ietf-poweff-sensors {
prefix ietf-poweff-sensors;
}
import ietf-lmo {
prefix ietf-lmo;
}
import ietf-lmo-assets-inventory {
prefix ietf-lmo-asset;
}
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 includes power derived values per asset.
Typically, power derived values will be calculated on the
receiver, even those values may be provided by the devices as
well.
Typically we expect chassis to report total psu-input-power and
psu-output-power but ptr-bps-ratio may be derived on the receiver
side.
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 2023-10-12 {
description
"Initial revision to document power derived data";
reference
Lindblad, et al. Expires 22 April 2024 [Page 19]
Internet-Draft POWEFF October 2023
"RFC XXXX: ...";
}
augment /ietf-lmo:lmos/ietf-lmo:lmo/ietf-lmo:inst {
when "derived-from-or-self(../ietf-lmo:lmo-class, "+
" 'ietf-lmo-asset:asset')";
description
"Power derived attributes related to assets";
uses ietf-poweff-sensors:power-derived-g;
}
}
<CODE ENDS>
6.2.6. Power Sensors Module
<CODE BEGINS>
module ietf-poweff-sensors {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-sensors";
prefix ietf-poweff-sensors;
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 basic groupings for POWEFF sensor
management.
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
Lindblad, et al. Expires 22 April 2024 [Page 20]
Internet-Draft POWEFF October 2023
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 2023-10-12 {
description
"Initial revision of POWEFF sensors";
reference
"RFC XXXX: ...";
}
grouping sensors-g {
description "sensors grouping";
container sensors {
description "list of sensors";
list sensor {
key "sensor-type";
description "list of sensors attached to this asset";
leaf sensor-type {
type identityref {
base ietf-poweff-types:sensor-type;
}
// FIXME: Are we fine with a single sensor of each type
// for each asset? I.e. is there ever a need for more than
// one Vin-sensor on a particular asset? Ever more than one
// Temp-sensor? If so, we need to add a second key here.
description
"Type of sensor sending data per asset:
Vin, Iin, Vout, Iout, Pin, Pout, Palloc, Temp, etc.
Sensor type specifies which unit of measurement is used.";
}
leaf sensor-location {
type string;
mandatory "true";
description
"Indicates the current location where the sensor is located
in the chassis,typically refers to slot";
}
leaf sensor-state {
type string;
description
"Current state of the sensor";
// FIXME: What does this mean?
}
Lindblad, et al. Expires 22 April 2024 [Page 21]
Internet-Draft POWEFF October 2023
leaf sensor-current-reading {
type string;
config false;
description
"Current reading of the sensor";
}
leaf sensor-accuracy-eligible {
type boolean;
default false;
description
"Used to identify which sensor/assets reading shall be
included in real metrics";
}
leaf sensor-accuracy {
type string;
must "../sensor-accuracy-eligible = 'true'";
description
"Maximum deviation to be considered. This attribute mainly
will apply to drawn power, which corresponds to PSU PowerIn
measured power or calculated power; assuming discrepancy
between Real Power, power collected from a power meter, and
power measured or calculated from the metrics provided by
the sensors";
}
container sensor-thresholds {
description
"Threshold values for the particular sensor.
Default values shall beprovided as part of static data
but when configurable need to be pulledfrom the device.
Ideally, the sensor should allow configuing
thesethreshold values";
leaf minor-low {
type string;
description
"minor-low";
}
leaf minor-high {
type string;
description
"minor-high";
}
leaf major-low {
type string;
description
"major-low";
}
Lindblad, et al. Expires 22 April 2024 [Page 22]
Internet-Draft POWEFF October 2023
leaf major-high {
type string;
description
"major-high";
}
leaf critical-low {
type string;
description
"critical-low";
}
leaf critical-high {
type string;
description
"critical-high";
}
leaf shutdown {
type string;
description
"shutdown";
}
}
}
}
}
grouping power-derived-g {
description
"define derived metrics";
container power-derived {
config false;
description "power derived attributes";
leaf heat-dissipation {
type string;
description
"It refers to Heat Transfer, i.e. heat transferred from
hotter object to coolerobject (1W = 3.412BTU/h)";
}
leaf rated-input-pwr-value {
type string;
mandatory "true";
description
"Total Input Power for the chassis and specific inventory
inside. The sum for all assets for specific hardware
configuration. Can be calculated for Typical, Operating, or
Maximum anticipated Capacity Load. Mainly used for
dimensioning based on benchmark data";
}
Lindblad, et al. Expires 22 April 2024 [Page 23]
Internet-Draft POWEFF October 2023
leaf asset-input-pwr {
type string;
mandatory "true";
description
"For a given asset, assumed input power means the rate of
electricity consumption in Watts provided by the network
device or sensor. Conditionally derived - if
the device/sensor can give actualpower draw then this
calculation is not required, and will be taken directly
from the sensor.";
}
leaf asset-output-pwr {
type string;
description
"Watts provided to the internal components for a given
asset. Only applicable to assets that provide output power,
such as PSUs. This is present here to accommodate chassis
that don’t provide Watt value currently. Ideal
implementation should provide Pout sensor reading";
//FIXME: add condition this is mandatory for when asset is
//chassis or PSU and not LC or Port;
}
leaf psu-input-power {
type string;
mandatory "true";
description
"Total input power per chassis, rate of the electricity
consumption in Watts. Sum of asset-input-pwr when uid=PSU.
It considers all operational PSU'́s to the chassis";
}
leaf psu-output-power {
type string;
mandatory "true";
description
"Total input power for chassis, rate of the electricity
consumption inWatts. Sum of asset-output-pwr when uid=PSU.
It considers alloperational PSU's to the chassis";
}
leaf psu-pwr-ratio {
type string;
mandatory "true";
description
"Define dynamic (current) power ratio taking into
consideration total system real power input vs used. Not
expected to be the same as PSU efficiency. Formula:
(psu-output-power / psu-input-power) * 100.0.
It considers all operational PSU ́s to the chassis.";
}
Lindblad, et al. Expires 22 April 2024 [Page 24]
Internet-Draft POWEFF October 2023
leaf energy-traffic-ratio {
type string;
mandatory "true";
description
"How much Watts is spent to move 100Gigaytes per
chassis within thetime period; Formula:
psu-output-power [Watt] /SUM of all interfaces
(input-data-rate-bits + output-data-rate-bits).
Measured over a period of 1hr. energy-traffic-ratio is
the value considered for the complete chassis and all
operational LC ́s/interfaces.";
}
}
}
grouping power-static-g {
description
"define static attributes";
container power-static {
description "power static attributes";
leaf max-amp {
type string;
mandatory "true";
description
"For a given asset, it is the current in Amperes that the
asset could withdraw at Maximum capacity";
}
leaf output-amp {
type string;
mandatory "true";
description
"For a given asset, it is the current in Amperes that the
asset couldwithdraw at Operating capacity.";
}
leaf input-amp {
type string;
mandatory "true";
description
"Current of an asset at a typical power consumption of
switch in Amperes. Somethimes refered to as input-current";
}
leaf max-output-pwr {
type string;
mandatory "true";
description
"For a given asset, it is the maximum power in Watts that
the asset could draw at Maximum capacity";
Lindblad, et al. Expires 22 April 2024 [Page 25]
Internet-Draft POWEFF October 2023
}
leaf output-pwr {
type string;
mandatory "true";
description
"For a given asset, it is the power in Watts that the
asset could withdraw at Operating capacity";
}
leaf typical-output-pwr {
type string;
mandatory "true";
description
"This value is an estimation of the average power usage
in Watts that the same configuration will use at Typical
capacity";
}
leaf accuracy-pwr {
type string;
description
"If known, the maximum deviation of power to be considered.
BU shouldprovide an estimation";
}
leaf inline-pwr {
type string;
mandatory "true";
description
"Available PoE Power i.e the power which can be passed over
ethernet cables to power devices.";
}
leaf psu-efficiency {
type string;
mandatory "true";
description
"Rating the PSU has been certified for against 80plus
certification specification. The amount of the actual power
delivered to the assetdivided by the electrical power drawn
from the main supply socket.i.e. Output Power of System/
Input Power of PSU. The objective for psu-efficiency values
is to reach 80+ certification.
Please refer to https://www.clearesult.com/80plus";
}
leaf voltage-type {
type string;
mandatory "true";
description
"AC/DC/HVDC. Note: DC typically gives an accurate measure,
but AC, due to the nature of the metric is not accurate";
}
Lindblad, et al. Expires 22 April 2024 [Page 26]
Internet-Draft POWEFF October 2023
leaf idle-pwr {
type string;
mandatory "true";
description
"Initial power allocated to the asset with no traffic load";
}
leaf max-temperature {
type string;
mandatory "true";
description
"Operating temperature - i.e max temperature tolerance
(temperaturerange expands to approximately -40°C to 85°C).
If the asset exceeds themax temperature limit, it either
slows down or stops completely";
}
leaf pwr-saving-mode {
type string;
mandatory "true";
description
"Does the asset support any power-saving software feature Y/N.
Will beexpanded in future releases";
}
}
}
}
<CODE ENDS>
6.2.7. Power Types Module
<CODE BEGINS>
module ietf-poweff-types {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang: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 basic quantities, measurement units
Lindblad, et al. Expires 22 April 2024 [Page 27]
Internet-Draft POWEFF October 2023
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 2023-10-12 {
description
"Initial revision of POWEFF types";
reference
"RFC XXXX: ...";
}
identity sensor-class {
description "Sensor's relation to the asset it sits on.";
}
identity sc-input {
base sensor-class;
description "Sensor reports input quantity of the asset it sits
on.";
}
identity sc-output {
base sensor-class;
description "Sensor reports output quantity of the asset it sits
on.";
}
identity sc-allocated {
base sensor-class;
description "Sensor reports (maximum) allocated quantity of the
asset it sits on.";
}
identity sensor-quantity {
description "Sensor's quantity being measured.";
}
identity sq-voltage {
base sensor-quantity;
description "Sensor reports electric tension, voltage.";
Lindblad, et al. Expires 22 April 2024 [Page 28]
Internet-Draft POWEFF October 2023
}
identity sq-current {
base sensor-quantity;
description "Sensor reports electric current.";
}
identity sq-power {
base 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 sensor-quantity;
description "Sensor reports actual energy drawn by asset.";
}
identity sq-co2-emission {
base sensor-quantity;
description "Sensor reports CO2 (carbon dioxide) emission by
asset.";
}
identity sq-co2eq-emission {
base sensor-quantity;
description "Sensor reports CO2 (carbon dioxide) equivalent
emission by asset.";
}
identity sq-temperature {
base sensor-quantity;
description "Sensor reports temperature of asset.";
}
identity sensor-unit {
description "Sensor's unit of reporting.";
}
identity su-volt {
base sensor-unit;
base sq-voltage;
description "Sensor unit volt, V.";
}
identity su-ampere {
base sensor-unit;
base sq-current;
Lindblad, et al. Expires 22 April 2024 [Page 29]
Internet-Draft POWEFF October 2023
description "Sensor unit ampere, A.";
}
identity su-watt {
base sensor-unit;
base sq-power;
description "Sensor unit watt, W.";
}
identity su-voltampere {
base sensor-unit;
base sq-power;
description "Sensor unit Volt*Ampere, VA.";
}
identity su-kw {
base sensor-unit;
base sq-power;
description "Sensor unit kilowatt, kW.";
}
identity su-joule {
base sensor-unit;
base sq-energy;
description "Sensor unit joule, J.";
}
identity su-wh {
base sensor-unit;
base sq-energy;
description "Sensor unit watthour, Wh.";
}
identity su-kwh {
base sensor-unit;
base sq-energy;
description "Sensor unit kliowatthour, kWh.";
}
identity su-kelvin {
base sensor-unit;
base sq-temperature;
description "Sensor unit kelvin, K.";
}
identity su-celsius {
base sensor-unit;
base sq-temperature;
description "Sensor unit celsius, C.";
}
identity su-farenheit {
base sensor-unit;
base sq-temperature;
description "Sensor unit farenheit, F.";
}
identity su-gram {
Lindblad, et al. Expires 22 April 2024 [Page 30]
Internet-Draft POWEFF October 2023
base sensor-unit;
base sq-co2-emission;
description "Sensor unit gram, g.";
}
identity su-kg {
base sensor-unit;
base sq-co2-emission;
description "Sensor unit kliogram, kg.";
}
identity su-ton {
base sensor-unit;
base sq-co2-emission;
description "Sensor unit ton, t.";
}
identity sensor-type {
description "Sensor's type, i.e. combination of class, quantity and
unit.";
}
identity st-v-in {
base sensor-type;
base sc-input;
base sq-voltage;
base su-volt;
description "Sensor reporting Voltage In to asset.";
}
identity st-v-out {
base sensor-type;
base sc-output;
base sq-voltage;
base su-volt;
description "Sensor reporting Voltage Out of asset.";
}
identity st-i-in {
base sensor-type;
base sc-input;
base sq-current;
base su-ampere;
description "Sensor reporting Current In to asset.";
}
identity st-i-out {
base sensor-type;
base sc-output;
base sq-current;
base su-ampere;
description "Sensor reporting Current Out of asset.";
}
identity st-p-in-apparent-watt {
base sensor-type;
Lindblad, et al. Expires 22 April 2024 [Page 31]
Internet-Draft POWEFF October 2023
base 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 sensor-type;
base 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 sensor-type;
base 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 sensor-type;
base 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 sensor-type;
base sc-allocated;
base sq-power;
base su-watt;
description "Sensor reporting Allocated Power for asset.";
}
identity st-w-j {
base sensor-type;
base sq-energy;
base su-joule;
description "Sensor reporting energy draw of asset in J.";
}
identity st-w-wh {
base sensor-type;
base sq-energy;
base su-wh;
description "Sensor reporting energy draw of asset in Wh.";
}
identity st-w-kwh {
Lindblad, et al. Expires 22 April 2024 [Page 32]
Internet-Draft POWEFF October 2023
base sensor-type;
base sq-energy;
base su-kwh;
description "Sensor reporting energy draw of asset in kWh.";
}
identity st-t-k {
base sensor-type;
base sq-temperature;
base su-kelvin;
description "Sensor reporting Temperature of asset in K.";
}
identity st-t-c {
base sensor-type;
base sq-temperature;
base su-celsius;
description "Sensor reporting Temperature of asset in °C.";
}
identity st-t-f {
base sensor-type;
base sq-temperature;
base su-farenheit;
description "Sensor reporting Temperature of asset in °F.";
}
}
<CODE ENDS>
7. Deployment Considerations
POWEFF data models define the data schemas for power and energy
efficiency data. POWEFF data models are based on YANG.
YANG is protocol independent. YANG data models can be used
independently of the transport and can be converted into any encoding
format supported by the network configuration protocol.
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:
* The data structure to describe all metrics and quantify relevant
data consistently, i.e. specific formats like XML or JSON encoded
message would be deemed valid or invalid based on POWEFF models.
Lindblad, et al. Expires 22 April 2024 [Page 33]
Internet-Draft POWEFF October 2023
* The process to share and collect POWEFF data across the consumers
consistently, including the transport mechanism. The POWEFF YANG
models can be used with network management protocols such as
NETCONF [RFC6241], RESTCONF [RFC8040], streaming telemetry, etc.
OpenAPI specification could be considered to consume POWEFF
metrics.
* How the configuration of assets should be done.
8. 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.
9. IANA Considerations
9.1. The IETF XML Registry
This document registers URIs in the IETF XML registry [RFC3688].
Following the format in [RFC3688], the registrations defined below
are requested:
URI: urn:ietf:params:xml:ns:yang:ietf-lmo
Registrant Contact: The OPSA WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
Lindblad, et al. Expires 22 April 2024 [Page 34]
Internet-Draft POWEFF October 2023
9.2. The YANG Module Names Registry
This document registers YANG modules in the YANG Module Names
registry [RFC7950]. Following the format in [RFC7950], the
registrations defined below are requested:
name: ietf-poweff-environment
namespace: urn:ietf:params:xml:ns:yang:ietf-poweff-environment
maintained by IANA: N
prefix: ietf-poweff-environment
reference: RFC XXXX
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
10.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, 20 October 2023,
<https://datatracker.ietf.org/doc/html/draft-almprs-
sustainability-insights-02>.
[I-D.draft-palmero-ivy-ps-almo-00]
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-00, 20 October 2023,
<https://datatracker.ietf.org/doc/html/draft-palmero-ivy-
ps-almo-00>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/rfc/rfc3688>.
Lindblad, et al. Expires 22 April 2024 [Page 35]
Internet-Draft POWEFF October 2023
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/rfc/rfc6241>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/rfc/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/rfc/rfc8040>.
Change log
RFC Editor Note: This section is to be removed during the final
publication of the document.
version 00
* Initial version.
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
Email: jlindbla@cisco.com
Snezana Mitrovic
Cisco Systems
Email: snmitrov@cisco.com
Marisol Palmero
Cisco Systems
Email: mpalmero@cisco.com
Lindblad, et al. Expires 22 April 2024 [Page 36]
Internet-Draft POWEFF October 2023
Gonzalo Salgueiro
Cisco Systems
Email: gsalguei@cisco.com
Lindblad, et al. Expires 22 April 2024 [Page 37]
