Subject: [eman] comments on draft-ietf-eman-framework-02, part 1

From: Juergen Quittek <[email-masked]>
Date: Mon, 25 Jul 2011 00:11:27 -0400

Dear all,

Attached please find my comments on sections 1-3 of the framework draft version -02. 
Comments on the remaining sections will follow in separate emails.

 [snip]
>                          Energy Management Framework 
>                         draft-ietf-eman-framework-02 
 [snip]
>      Abstract 
> 
>         This document defines a framework for providing Energy 
>         Management for devices within or connected to communication 
>         networks.  The framework defines a domain of Energy Management 
>         devices that is a logical unit of Energy Management. Within a 

This is difficult to parse: "A domain of devices is a unit of energy management"?

>         domain each device is identified, classified and given context.   
>         Devices can be monitored and/or controlled with respect to 
>         power, power state, energy, demand, electrical quality, and 
>         battery.  Additionally the framework models relationships and 
>         capabilities between devices in a domain.   
>          
>          
>         TO DO/OPEN ISSUE 
>         - IPFIX or not? Initially IPFIX was mentioned in [EMAN-REQ], 
>         then we see now: "A solution for this is that the concerned 
>         entity or another entity closely interacting with the concerned 
>         entity collect time series of power values and make them 
>         available via push or pull mechanisms to receivers of the 
>         information.". So, the questions are: Is IPFIX a requirement?  
>         What other mechanism do we have to PUSH time series of power 
>         values (no, SNMP notifications are not suitable)? So should we 
>         or not include IPFIX in this document? 

PUSH mode is a requirement for time series of measurements. 
Whether IPFIX is the only protocol that can do so in the right way
is not a question of requirements. If the framework brings arguments
why IPFIX is the best choice, it should include IPFIX as solution. 
Otherwise, it still may include IPFIX as candidate protocol for PUSH mode.

>         - Power Monitor has been renamed to Energy Managed Object. Get

I don't think that this is a good choice.
"Managed Object" is the term specified to be used for objects defined in MIB modules.
"Energy Managed Objects" sounds like a kind of MIB objects.
  
>           consensus on the terminology. Another example is Power 
>           Quality 

I think the term power quality is the right term and we should easily find an agreed definition. 
We just should avoid applying it to things that are not related to power quality.
         
>      1. Introduction 
> 
>         Network management is divided into the five main areas defined 
>         in the ISO Telecommunications Management Network model: Fault, 
>         Configuration, Accounting, Performance, and Security Management 
>         (FCAPS).   Absent from this management model is any 

I would add ITU X.700 as reference for FCAPS.

>         consideration of Energy Management, which is now becoming a 
>         critical area of concern worldwide as seen in [ISO50001].  
>          
>         This document defines a framework for providing Energy 
>         Management for devices within or connected to communication 
>         networks.  The framework describes how to identity, classify and 

identity -> identify

>         provide context for a device in a communications network from 
>         the point of view of Energy Management.   
>          
>         The identified device can then be monitored for Energy 
>         Management by obtaining measurements for power, energy, demand 
>         and electrical quality.  If a device contains a battery(s) the 
>         characteristics and performance of the battery(s) can also be 
>         managed.  A device's state can be monitored or controlled by 
>         providing an interface expressed as one or more Power State 
>         Sets.  The most basic example of energy management is a single 
>         device reporting information about itself.  However, in many 
>         cases, energy is not measured by the device itself, but by a 
>         meter located upstream in the power distribution tree.  An 
>         example is a power distribution unit (PDU) that measures energy 
>         consumption of attached devices and may report this to an Energy 
>         Management System.  Therefore, devices are recognized as having 
>         relationships to other devices in the network from the point of 
>         view of Energy Management.  These relationships include 
>         Aggregation, Metering, Power Source(s), Proxy, and Dependency.  
>       
>                              
>      1.1. Energy Management Document Overview 
> 
>       
>         The EMAN standard provides a set of specifications that together 
>         provide Energy Management.  This document specifies the 

Specifications do no never provide energy management.

>         framework, per the Energy Management requirements specified in 
>         [EMAN-REQ] 
>          
>         The applicability statement document [EMAN-AS] provides a list 
>         of use cases, cross-reference between existing standards and the 
>         EMAN standard, and shows how the this relates to other 
>         frameworks. 
>          
>         The [EMAN-AWARE-MIB] provides objects for addressing 

provides -> specifies or defines

>         identification, classification, context information, and 
>         relationships form the point of view of Energy Management. 
>                            
>         The Power and Energy Monitoring MIB [EMAN-MON-MIB] contains  
>         objects for monitoring of Power, Energy, Demand, Electrical 
>         Quality and Power State Sets. 
>          
>         Definition of Managed Objects for Battery Monitoring [EMAN-
>         BATTERY-MIB] defines managed objects that provide information on 
>         the status of batteries in managed devices. 
>       
>         EDITOR'S NOTE: [EMAN-MON-MIB] and [EMAN-AS] are not EMAN working 
>         group documents.  Hence, these references will be changed in the 
>         future. 
>          
>      2. Requirements & Use Cases  
> 
>         Requirements for power and energy monitoring for networking 
>         devices are specified in [EMAN-REQ].  The Energy Management use 
>         cases covered by this framework are covered in the EMAN 
>         applicability statement document in [EMAN-AS].  Typically 
>         requirements and use cases for communication networks cover the 
>         devices that make up the communication network and endpoints.  
>          
>         With Energy Management, there exists a wide variety of devices 
>         that may be contained in the same deployments as a communication 
>         network but comprise a separate facility, home, or power 
>         distribution network.  
>          
>         For example, target devices for this specification can include 
>         (but are not limited to):

I am not sure it makes sure having this list. 
It is always incomplete. I would rather state that
"Target devices for the energy management framework are all devices that can directly or indirectly be monitored or controlled by an energy management system using the Internet protocol."

>  
>             - Simple electrical appliances / fixtures  
>             - Hosts, such as a PC or a datacenter server 

"a PC or a datacenter server"
--> a PC, a datacenter server, or a printer"

>             - Routers  
>             - Switches 
>             - Switches with line card components  
>             - Power over Ethernet (PoE) endpoints, 
>             - Power Distribution Units (PDU)  
>             - Protocol gateways devices for Building Management Systems 
>         (BMS) 
>             - Electrical Meters 
>             - Sensor controllers with subtended sensors 
>       
>         There may also exist varying protocols deployed among these 
>         parallel networks.  

To what does "these parallel networks" refer?

>         For an Energy Management framework to be useful, it should also 
>         apply to these types of separate networks as they connect and 
>         interact with a communications network.  
>          
>       
>          
>      3. Terminology 

There is a section 4 titled "Energy Management Reference Model". But actually, most of the model's fundamentals are only explained in this terminology section. I don't think this is a good structure and I don't think this is sufficient. Basic concepts, such as the Energy Managed Object, the EMO relationships should be elaborated in section 4.

> 
>         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
>         NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
>         "OPTIONAL" in this document are to be interpreted as described 
>         in RFC 2119 [RFC2119]. 
>          
>         This section contains definitions of terms used throughout this 
>         specification. Defined terms have their first letter 
>         capitalized.  Entities, relationships and or capabilities are 

I am not in favor of the capitalization of terms.
Particularly for terms such as "energy", "power", "demand" which we are using fully in line with their common meaning it appears to be very confusing for a reader when (s)he needs to think: "Is capitalized "Energy" anyhow different from lower case "energy"?

>         defined with respect to well known software patterns as 
>         described in [GAMMA] and [EIPATT] 

Why this? IMHO definitions for entities and relationships are better taken from standards (for example UML) than from books written by individual authors. The books referred to above may be useful when design patterns are used. But I do not see any of their design patterns being relevant for a standards on energy management, at least not more that for standards for IP traffic management and control where these books hardly appear as references in standards documents.
      
> 
>         Energy Management System (EnMS) 
>          
>         An EnMS is a set of systems or procedures upon which 
>         organizations can develop and implement an energy policy, set 
>         targets, action plans and take into account legal requirements 
>         related to energy use.  An EnMS allows organizations to improve 
>         energy performance and demonstrate conformity to requirements, 
>         standards and/or legal requirements.  This definition is in line 
>         with the definition of "Energy management systems - Requirements 
>         with guidance for use" [ISO50001]. 

Wouldn't it be better to explicitly mention monitoring and control of energy consumption?
         
> 
>         With respect to communication networks these same goals will 
>         apply to the communications networks and attached devices within 
>         an organization. 

I would remove this paragraph. Either the first paragraph obviously applies already to communications networks or we need to change it.
>          
>         Energy Management 
>          
>         Energy Management is a set of functions for measuring, modeling, 
>         planning, and optimizing networks to ensure that the network 
>         elements and attached devices use energy efficiently and is 

I disagree. Even if I don't like it, I would not limit energy management systems to the ones that ensure energy efficiency. Energy management deals with assessing and influencing the consumption of energy. This is independent from an objective of ensuring energy efficiency.
 
> 
>         appropriate for the nature of the application and the cost 
>         Management is a system congruent to any of FCAPS area of 
>         management in the ISO/OSI Network Management Model [TMN] Energy 
>         Management for communication networks and attached devices is a 

"is a" --> "may be"

>         subset or part of an organization's greater EnMS. 

This is confusing, because it is completely different from the definition of EnMS
Why is energy management not
    "developing and implementing an energy policy, 
     setting targets, action plans and taking into account 
     legal requirements related to energy use."
?
This would be consistent with the EnMS definition above.
>         Energy Management Systems  

This is confusing. The same term with different acronym was already defined above. 
         
>         An Energy Management System (EMS) is congruent to a Network 

EMS --> EnMS

>         Management System (NMS) and is a combination of hardware and 
>         software used to administer a network with the primarily purpose 
>         being Energy Management. 

This paragraph needs to be merged with the previous definition of the term. 

>          
>         Energy Monitoring 
>          
>         Energy Monitoring is a part of Energy Management that deals with 
>         collecting or reading measurements from devices to aid in Energy 
>         Management.  This could include Energy, Power, Demand, Quality, 
>         Context and/or Battery information. 
>         Energy 
line to be deleted

>         Energy  
>          
>         Energy is the capacity of a system to produce external activity 
>         or perform work and can be electricity, fuels, steam, heat, 
>         compressed air, and other like media. Energy is typically 

This is certainly not taken from an IEEE or IEC dictionary: 
Energy is not steam, it is not fuel, it is not compressed air.
Let's take text from a dictionary.

>         expressed in watt hours or joules.  

can we restrict EMAN to electrical energy and power?
         
>         Power 
>          
>         Power is a rate of energy conversion.  As the unit of time 
>         approaches zero a power measurement is called an instantaneous 
>         power reading.  Typically when implementing Power monitoring in 
>         hardware, a measuring device may have to compute an average 
>         value per some unit of time to express a reading to approximate 
>         an instantaneous power measurement. 

This contradicts the definition of instantaneous power in the IEEE dictionary of standards terms where active power is "The time average of the instantaneous power over one period of the wave." This implies that the instantaneous power changes from zero to a maximum and back two times of a period, i.e. 100 or 120 times a second for common AC power. Typical meter implementations measure power over at least half a period. The result of their approximation is not called instantaneous power. It is the power over a (short) interval of time.

>          
>         Demand 
>          
>         Demand is an average of Power measurements over an interval(s) 

I disagree. Demand is a power measurement over a long time interval. There is no need for having multiple power measurements and averaging them. Of course I agree that this would be a way to implement demand measurements. But the definition of a term should not falsely restrict it to a certain implementation.
Please let's take IEEE or other bodies dictionary terms.

"an interval(s)" --> "an interval"

>         of time and typically expressed in kilowatt hours.  This 
>         measurement is significant because some utilities or energy 

remove "This measurement is significant because"

>         providers bill by Demand measurements as well as for maximum 
>         Demand per billing periods.  Power values may spike during 
>         short-terms by devices, but Demand measurements recognize that 
>         maximum Demand does not equal maximum Power during an interval. 
>          
>         Power Quality 
>          
>         EDITOR'S NOTE: This may be rephrased as Electrical 
>         Characteristics. 

Electrical characteristics seems to better match what the term has been used for in some drafts.
But the term power quality should still be here to refer to properties that are usually called so.

>         Power Quality is defined as a set of values to describe the 
>         electrical characteristics of Power as provided by an electrical 
>         source as seen by the Energy Managed Object.  For example: AC 
>         phase, apparent and reactive power, etc. 

Yes. Phase, apparent and reactive power are not typical power quality issues. Power quality issues include the deviation of actual voltage from nominal/design voltage, the deviation of AC frequency from the nominal frequency, harmonic distortions, etc.
>          
>         Energy Control 
>          
>         Energy Control is a part of Energy Management that deals with 
>         modifying or setting the state of an Energy Managed Object in 
>         order to optimize or ensure its efficiency. 

I disagree. Energy Control is not limited to optimization of efficiency. "in order to optimize or ensure its efficiency" should be removed. A function that increases energy consumption needs also to be covered by the term energy control.

What woud be the difference between modifying and setting a state? I don't make a suggestion for an alternative here. We should put ALL terms on the mailing list and discuss them until we reach something that comes closer to a reasonable definition.

>         Energy Managed Object  
>          
>         An Energy Managed Object (EMO) is a device that is part of or 
>         attached to a communications network that is monitored, 
>         controlled, or aids in the management of another device for 
>         Energy Management.  

Two issues: 
1. the term "managed object" is already in common use for the objects defined in a MIB module. Since we are also defining MIB modules, we will run into ambiguities and risk confusion of readers if we re-use the term here.
2. The attribute "managed" is confusing, because the term refers also to "unmanaged" objects that are neither monitored or controlled, but just "aid" in the management of other devices. These seem to be rather "managing" objects than "managed" objects.

>         Energy Aware Object  
>          
>         An Energy Managed Object may not have the capability to provide 
>         information necessary for Energy Management itself. If an Energy 
>         Managed Object can provide Energy Management Context, Energy 
>         Monitor and optionally Energy Control values for itself then the 

Monitor --> Monitoring

>         Energy Managed Object is said to be an Energy Aware Object 

I don't see good reasons for using the term energy awareness. IPFIX did all its specifications well without ever needing the term flow-awareness and the SNMP Interface MIB module never needed the term packet-awareness for interfaces that meter bytes and packets.

BTW, I wonder why a device that only reports its energy consumption is not called energy-aware.
It is only called energy-aware if it can also report its energy context. Why is this so?

My strongest concern is the following. What I would call energy aware would be a device that not just reports on its energy consumption, but rather tries to optimize its energy consumption by its own control logic, for example a TV sets that switches of the screen when its sensors indicates that the last watchers has left the room. If this TV should be called energy-aware even if it does not report anything to any management system.

I strongly suggest either to replace the term "energy aware" by "energy reporting" or something similar, or better, not to use the term at all. We don't need it.

>         For example: as the most simplistic example, a set of light 
>         bulbs where all values are provided by an EMS through estimation 
>         and or catalogue information are not Energy Aware. In contrast a 
>         set of network switches that can report the same information 
>         based upon hardware sensing is said to be Energy Aware. 

Would you also call it energy aware if the device can report its energy information only using a non-IP protocol?
         
>         Energy Managed Object Identification 
>          
>         Energy Managed Object Identification is a set of attributes that 
>         enable an Energy Managed Object to be: uniquely identified among 
>         all Energy Management Domains; linked to other systems; 

Among all domains? 
This means globally unique. 
Do you really mean this? 
Do we need this?

What means "linked to other systems"? 

>         classified as to type model and or manufacturer. 

I do think it is impossible to invent a type of identifier that enables all kinds of energy managed objects to derive their type model and manufacturer from it. This is particularly difficult for devices that do not have a particular or model type model or manufacturer that is registered somewhere.

>         RFC EDITOR'S: the uniqueness must be clarified in [EMAN-REQ] 
>           
>         Energy Managed Object Context 
>          
>         Energy Managed Object Context is a set of attributes that allow 
>         an Energy Management system to classify the use of the Energy 
>         Managed Object within an organization.  The classification 
>         contains use and/or ranking of the Energy Managed Object as 
>         compared to other Energy Managed Objects in the Energy 
>         Management Domain. 

Just questions: 
Are there already standards defining contexts of devices?
Or is this something new? 
Is IANA maintaining a list of standardized contexts?
Are we planning to establish one? 
Or is a context just a string with arbitrary content?
          
> 
>         Energy Management Domain 
>          
>         An Energy Management Domain is a name or name space that 

If a domain were a name, we could call it name.
A domain is not a name. It may have one.

>         logically groups Energy Managed Objects into a zone of Energy 
>         Management.  Typically, this zone will have as members all 

What is a zone of energy management? 
Is it different in any way from a domain?

>         Energy Managed Objects that are powered from the same electrical 
>         panel(s) for which there is a meter or sub meter.

What is a sub meter? 
What would be the difference between having a meter or a sub meter at a panel?
  
> 
>         For example: All Energy Managed Objects drawing power from the 
>         same distribution panel with the same AC voltage within a 
>         building, or all Energy Managed Objects in a building for which 
>         there is one main meter, would comprise an Energy Management 
>         Domain.  

I would not use this example over five lines of text in the definition. It should be rather mentioned when the trem is explained in the description of the reference model.
>  
>         From the standpoint of Energy Management, it is useful to report 
>         Energy as the sum of the Energy of all the Energy Managed 
>         Objects within an Energy Management Domain and then correlate 
>         that value with metered values.  

The same for this use case: It belongs to the description of the reference model.
         
> 
>         Energy Managed Object Relationships 
>          
>         Energy Managed Objects may have functional relationships to each 
>         other within an Energy Management Domain.  The functional 

Can't this be cross domain?
In our company, we have fuse cabinets equipped with power meters that have up to eight current claps and measure power for up to eight power distribution trees. Is the meter than member of all eight domains
at the same time because it measures in them. Note that the meter is powered by just one of the distribution trees or be neither of them.
Another case would be an energy management system that uses different domains for servers, PCs, phones, and switches. Still, a switch should be able to power a phone cross domain using PoE.

>         relationships include Aggregation, Metering, Power Source(s), 
>         Proxy, and Dependency.  One device will provide a capability or 
>         functional value in the relationship and another will be the 
>         receiver of the capability.  These capabilities include

I do not understand why a PDU metering its output provides a capability?
Even less do I understand why a device (host, switch, light bulb) for which power is measured would receive any capability when this is done.

>         Aggregation, Metering, Power Source, Proxy and Dependency.  

Which capability is provided in the dependency relationship?

>         Aggregation Relationship 
>       
>         An Energy Managed Object may aggregate the Energy Management 
>         information of one or more Energy Managed Objects and is 
>         referred to as an Aggregation Relationship.  An Energy Managed 

The previous paragraph stated that objects may HAVE relations ships. This paragraph states that an object IS REFERRED TO  as relationship. This is not consistent.
 
>         Object may be aggregated by another Energy Managed Object(s).  
>         Aggregate values are obtained by reading values from multiple 
>         Energy Managed Objects and producing a single value of more 

I think it does not need to be just a single value. It can be multiple.
The definition should not focus on the number of values. A good indicator for an aggregation action is the presence of operations on multiple given values. Whether the operation(s) produce one or more values is not highly relevant for the definition.

>         significant meaning such as average, count, maximum, median, 

I would not limit aggregation to operations generating values with more significant meanings. Even if the meaning is less significant, it still should be called aggregation.

>         minimum, mode and most commonly sum.  
>          
>         Metering Relationship 
>          
>         An Energy Managed Object may measure the Energy of another 
>         Energy Managed Object(s) and is referred to as a Metering 

I think it is important for the EnMS to distinguish two cases: A meter measures the energy of individual EMOs separately, or it measures just the accumulated energy and power for these devices, for example in the fuse cabinet.In the latter case, information on individual EMOs would not be available. This is a significant qualitative difference and should be modeled.

>         Relationship.  An Energy Managed Object may be metered by 

Again, "the EMO is referred to as metering relationship" does not seem to be what is intended to b said.

>         another Energy Managed Object(s).  Example: a PoE port on a 

Remove second sentence. It is redundant. Or use the following replacement:
"another Energy Managed Object(s)" --> "multiple Energy Management Objects and a single EMO may meter multiple other EMOs."

>         switch measure the Power it provides to the connected Energy 
>         Managed Object. 

Why is this "providing a service to the powered EMO"?
It is providing a service to the EnMS and obviously not to the EMO that may not even have an information on whether or not the measurement is performed. The powered EMO does not ask for such a service. The EnMS does. In my view. The PoE switch measures at its output and provides this information to the EnMS. The EMS is the free to use this information also as power information for the powered EMO.

>         Power Source Relationship 
>          
>         An Energy Managed Object may be the source of or distributor of 
>         power to another Energy Managed Object(s) and is referred to as 
>         a Power Source Relationship.  An Energy Managed Object may be 
>         powered by another Energy Managed Object(s).  Example: a PDU 

"another Energy Managed Object(s)" --> "multiple Energy Management Objects and a single EMO may power multiple other EMOs."

>         provides power for a connected host. 
>          
>         Proxy Relationship 
>          
>         An Energy Managed Object that provides Energy Management 
>         capabilities on behalf of another Energy Managed Object so that 
>         is appears to be Energy Aware is referred to a Proxy 

What sense would it make to have another object appear to be energy aware? Fooling the EnMS?
Whether or not an EMO is energy aware should be completely independent from whether or not there is a proxy for it. And it should be possible to have a proxy relationship without pretending an unaware device to be aware.

>         Relationship.  An Energy Managed Object may be proxied by 
>         another Energy Managed Object(s).  Example: a protocol gateways 

"another Energy Managed Object(s)" --> "multiple Energy Management Objects and a single EMO may proxy multiple other EMOs."

>         device for Building Management Systems (BMS) with subtended 
>         devices.  
>                    
>         Dependency Relationship 
>          
>         An Energy Managed Object may be a component of or rely 
>         completely upon another Energy Managed Object to operate and is 
>         referred to as a Dependency Relationship.  An Energy Managed 
>         Object may be dependent on another Energy Managed Object(s).  
>         Example: A Switch chassis with multiple line cards 

This is very foggy. 
What is the meaning of "rely completely upon another EMO to operate"?
Is a server in a datacenter completely dependent on the firewall(s) that connect the datacenter with the Internet? With a switched off firewall, the server cannot provide any service thus not operate.
How shall we detect all those dependencies. Wouldn't they be subject to dynamic changes?

>          
>         Energy Managed Object Parent 
>       
>         An Energy Managed Object Parent is an Energy Managed Object that 
>         provides one or more of the Energy Managed Object Relationships 
>         capabilities. 

I don't think that in the case of dependency, a capability is provided to a EMO. 
Neither in the case of metering.
>          
>         Energy Managed Object Child 
>          
>         An Energy Managed Object Child is an Energy Managed Object that 
>         has at least one Energy Managed Object Relationship capability 
>         provided by another Energy Managed Object.   

see previous comment.
>          
>         Power State 
>          
>         A Power State is a way to classify a Power setting on an Energy 

A power state is not a way.

>         Managed Object (e.g., on, off, or sleep).  A Power State can be 
>         viewed as a method for Energy Control 

A power state should not be viewed as a method for power control. It is a state, not a method.
         
>         Manufacturer Power State 
>          
>         A Manufacturer Power State is a device-specific way to classify 
>         a Power setting implemented on an Energy Managed Object.

See power state.
>    
>         Power State Set 
>          
>         A collection of Power States that comprise one named or logical 
>         grouping of control is a Power State Set.  For example, the 
>         states {on, off, and sleep} as defined in [IEEE1621], or the 16 
>         power states as defined by the [DMTF] can be considered two 
>         different Power State Sets. 

We should add that a power state set implemented on a device MUST at all times have exactly one 
state that the device is in.

>         Nameplate Power 
>          
>         The Nameplate Power is the maximal (nominal) Power that a device 
>         can support.  This is typically determined via load testing and 

remove "specified via load testing and is"

>         is specified by the manufacturer as the maximum value required 
>         to operate the device.  This is sometimes referred to as the 
>         worst-case Power.  The actual or average Power may be lower.  
>         The Nameplate Power is typically used for provisioning and 
>         capacity planning. 

Thanks,

    Juergen