Subject: Re: [eman] feedback on the eman-ietf-eman-requirements-04

From: Juergen Quittek <[email-masked]>
Date: Sun, 14 Aug 2011 15:08:22 -0700

Hi Benoit,

Thanks a lot for all the comments. Please find replies inline.

Am 26.07.2011 um 02:19 schrieb Benoit Claise:

> Dear all,
> 
> Here is my feedback regarding the EMAN requirement, as a contributor.
> Note that some points might have been made on the mailing list already.
> 
> A couple of big points
> - the outlet gang was mentioned by Chris Verges as a requirement. I don't think I've seen it mentioned.
>     Note: this could be solved by a specificEnergy Managed Object Relationships  (Metering, Power Source, Proxy, Dependency)

Since we do not have text for this requirements, let's list it as an open issue for now.

> - we would need some requirements about producer and/or consumer

A lot of the producer requirements are covered by the power outlet requirements.
But I fully agree. There may be specific requirements missing for generators.
Do you have any?

Also we need to check the entire text. Many sentences implicitly assume that we
are only dealing with consumers.

> - I've been thinking about the following requirement some more
> 7.3.  Reporting quantities accumulated over multiple powered entities 
> 
>    For powered entities reporting single values that are accumulated 
>    over multiple powered entities, the energy management standard must 
>    provide means for reporting the list of all powered entities from 
>    which contributions are included in the accumulated value. 
> And I wonder if we're not trying to make EMAN too complex by adding this aggregation function.
> Note: I've been involved in aggregation scheme (See RFC 5982, RFC 6183, and http://tools.ietf.org/html/draft-trammell-ipfix-a9n-03) and this is not straight forward to list all powered entities for which there is an aggregation.
> My point is that there is some debate whether or not a switch should aggregate all values for children, or if this is a NMS issue.
> Feedback?
> 
> See inline
>> Network Working Group                                    J. Quittek, Ed. 
>> Internet-Draft                                                 R. Winter 
>> Intended status: Informational                                  T. Dietz 
>> Expires: January 12, 2012                                NEC Europe Ltd. 
>>                                                                B. Claise 
>>                                                          M. Chandramouli 
>>                                                      Cisco Systems, Inc. 
>>                                                            July 11, 2011 
>> 
>> 
>>                    Requirements for Energy Management 
>>                     draft-ietf-eman-requirements-04 
>> 
>> Abstract 
>> 
>>    This document defines requirements for standards specifications for 
>>    energy management.  Defined requirements concern monitoring functions 
>>    as well as control functions.  Covered functions include 
>>    identification of powered entities, monitoring of their power state, 
>>    power inlets, power outlets, actual power, consumed energy, and 
>>    contained batteries.  Further included is control of powered 
>>    entities' power supply and power state.  This document does not 
>>    specify the features that must be implemented by compliant 
>>    implementations but rather features that must be supported by 
>>    standards for energy management. 
> This misses the power quality, or whatever name we want to call it.
> For example "power characteristics)"

OK. Let's add power quality for now.
We can revise it if we have found a better term.
Recent statements on the mailing lists questioned the ned for
power quality measurements. We should try to reach consensus on this issue.

>> Status of this Memo 
 
[snip]

>> 
>> 1.  Introduction 
>> 
>>    With rising energy cost and with an increasing awareness of the 
>>    ecological impact of running IT and networking equipment, energy 
>>    management is becoming an additional basic requirement for network 
>>    management systems and frameworks. 
>> 
>>    This document defines requirements for standards specifications for 
>>    energy management.  Defined requirements concern monitoring functions 
>>    as well as control functions.  Covered functions include 
>>    identification of powered entities, monitoring of their power state, 
>>    power inlets, power outlets, actual power, consumed energy, and 
>>    contained batteries.  Further included is control of powered 
>>    entities' power supply and power state.  Note that this document does 
>>    not specify the features that must be implemented by compliant 
>>    implementations but rather features that must be supported by 
>>    standards for energy management. 
> Same remark about power quality

Same reply: Let's add power quality for now.

>> 
>>    The main subject of energy management are powered entities that 
>>    consume electric energy.  Powered entities include devices that have 
>>    an IP address and can be addressed directly, such as hosts, routers, 
>>    and middleboxes, as well as devices indirectly connected to an IP 
>>    network, for which a proxy with an IP address provides a management 
>>    interface, for example, devices in a building management 
>>    infrastructure using BACNET or MODBUS protocols. 
>> 
>>    The requirements specified in this document explicitly concern the 
>>    standards specification process and not the implementation of 
>>    specified standards.  All requirements in this document must be 
>>    reflected by standards specifications to be developed.  But which of 
>>    the features specified by these standards will be mandatory, 
>>    recommended, or optional for compliant implementations is to be 
>>    defined by the concrete standards track document(s) and not in this 
>>    document. 
>> 
>>    This document first discusses general objectives of energy management 
>>    in Section 3.  Requirements for an energy management standard are 
>>    specified in Sections 4 to 8. 
>> 
>> 1.1.  Conventional requirements for energy management 
> I don't know what "conventional" is supposed to mean.

Conventional in EMAN are requirements of a kind that we use 
to have for many other network management issues: 
You measure quantities at a device, make them available in MIB modules, 
read them from an NMS, send control commands if needed. 
I will add text on this.

Special in EMAN are requirements resulting from the fact that you may 
have to speak to other devices in order to measure the power for a device 
or to control its power supply.

I am fine with replacing "conventional" with another term. 
Are there proposals? "device-centric"?

>> 
>>    The specification of requirements for an energy management standard 
>>    starts with Section 4 addressing the identification of powered 
>>    entities and the granularity of reporting of energy-related 
>>    information. 
> I don't understand why we have that sentence here and not in the identifier in section 4.

Well this is the introduction explaining the structure of the document.
Here the content of Section 4 is explained, below you find the content 
of sections 5 and 6 summarized.

>> A standard must support unique identification of 
>>    powered entities.  Furthermore, it must support more than just 
>>    reporting per powered device.  Support is required for also reporting 
>>    energy-related information on individual components of a device or 
>> 
>> 
>> 
>> Quittek, et al.         Expires January 12, 2012                [Page 4] 
>> 
>> Internet-Draft     Requirements for Energy Management          July 2011 
>> 
>> 
>>    subtended devices.  This is why this draft uses the more general term 
>>    "powered entity" rather than "powered device".  A powered entity may 
>>    be a device or a component of a device. 
>> 
>>    Section 5 specifies requirements related to monitoring of powered 
>>    entities.  This includes general (type, context) information and 
>>    specific information on power states, power inlets, power outlets, 
>>    power, energy, and batteries.  Control power state and power supply 
>>    of powered entities is covered by requirements specified in 
>>    Section 6. 
>> 
>> 1.2.  Specific requirements for energy management 
>> 
>>    At first glance the rather conventional requirements summarized above 
>>    seem to be all that would be needed for energy management.  But it 
>>    turns out that there are some significant differences between energy 
>>    management and most of the well known conventional network management 
>>    functions.  The most significant difference from many other 
>>    management functions is the need for some devices to report on other 
>>    entities.  There are three major reasons for this. 
>>    o  For monitoring and controlling a particular powered entity in 
>>       general it is not sufficient to communicate with the powered 
> "sufficient" is not the right wording.
> In some cases, this is just impossible to communicate with the powered entity.
> Example: proxy.

This case is covered by the following bullet item.

> 
>>       entity only, but in many cases also communication with other 
>>       powered entities along the power distribution path may be 
>>       necessary, for example, with power switches and power meters. 
>>       Indeed, there are situations where a power or energy meter is not 
>>       located in the powered entity, but in a different physical 
>>       location.  For example, a Power Distribution Unit (PDU), which 
>>       supplies power for a server connected to a PDU socket, would meter 
>>       the power supplied, while the server may not have the capability 
>>       to measure its power consumption. 
> new text: In specific cases, the monitoring and controlling of powered entities must be done by another entity along the power distribution domain. For example. 
> And you remove "a second example" below

Please check the revision of the  first bullet.
I don't think the word "must" is appropriate.

>> A second example is a Power 
>>       over Ethernet port, which provides power to the attached device, 
>>       and which can meter how much power/energy it delivers to the 
>>       attached device. 
>>    o  Energy management often extends its scope beyond powered entities 
>>       with IP network interfaces, for example toward non-IP building 
>>       networks, that are accessed via an IP gateway.  Requirements in 
>>       this document do not fully cover all these networks, but they 
>>       cover means for opening IP network management towards them. 
>>    o  For monitoring of particular powered entities, it is sometimes not 
>>       a scalable approach to communicate directly with all the powered 
>>       entities directly from a central energy management system as the 
>>       number of powered entities keeps increasing. 
>> 
>>    This specific issue of energy management and a set of further ones 
>>    are covered by requirements specified in Sections 7 and 8. 
>> 
>> 

 [snip]

>> 
>> 2.8.  Energy management 
>> 
>>    the definition of the term power is to be agreed on in the EMAN WG. 
>> 
>> 2.9.  Energy management standard 
> This doesn't look like a definition. At least, the first paragraph should be removed.

Right it does not look like a definition. 
I would suggest removing not the first paragraph, 
but just the first sentence and keep the rest of the first paragraph:
  "This term refers to a collections of documents specifying 
   standards for energy-related monitoring and control.  The energy 
   management standard specifies means for building energy management 
   systems."

This looks a little bit more like a definition.

The following two paragraphs are not really part of a definition.  
They are redundant because similar text is already the introduction. 
We should remove them.

>> 
>>    This document specifies requirements for an energy management 
>>    standard.  This term refers to a collections of documents specifying 
>>    standards for energy-related monitoring and control.  The energy 
>>    management standard specifies means for building energy management 
>>    systems. 
>> 
>>    Requirements specified in this document concern the means that an 
>>    energy management standard must provide.  It does not imply that all 
>>    required means must be implemented in all energy standard scenarios. 
>>    Which means and features must be implemented by compliant 
>>    implementations is to be specified by the energy management standard 
>>    itself, not by this requirements document. 
>> 
>>    Note that for meeting individual requirements specified in this 
>>    document, new standards are not necessarily required.  It is 
>>    recommended to rather use existing standards than specify new ones. 
> 
>> 
>> 
>> 
>> 
>> Quittek, et al.         Expires January 12, 2012                [Page 7] 
>> 
>> Internet-Draft     Requirements for Energy Management          July 2011 
>> 
>> 
>> 3.  General Objectives of Energy Management 
> Rename to "general considerations related to energy management"

Done.

>> 
>>    The basic objective of energy management is operating communication 
>>    networks and other equipment with minimal amount of energy, while 
>>    maintaining a certain level of service.  A set of use cases for 
>>    energy management can be found in 
>>    [I-D.tychon-eman-applicability-statement]. 
> It would read better if the content of section about trade-offs was next in this introduction (without having a specific section)
> Then 
>     3.1. Power States
>     3.2 Energy Monitoring versus Energy Savings

It is no "Energy Monitoring vs. Energy Savings" but rather 
"Maintaining service level agreements vs. Energy Savings"
But your title is good for renaming section 3.4.

>     3.3 Local versus network-wide energy management

done.

>     3.4. Overview of the energy management requirements

Yes. but this is section 3.5

> 
>> 
>> 3.1.  Power states 
>> 
>>    One approach to achieve this goal is by setting all powered entities 
>>    to an operational state that results in lower energy consumption, but 
>>    still meets the service level performance objectives.  The sufficient 
>>    performance level may vary over time and can depend on several 
>>    factors.  In principle, there are four basic types of power states 
>>    for a powered entity or for a whole system: 
>>    o  full power state 
>>    o  reduced power states (lower clock rate for processor, lower data 
>>       rate on a link, etc.) 
>>    o  sleep state (not functional, but immediately available) 
>>    o  off state (may imply requiring significant time for becoming 
>>       operational) 
>>    In actual implementations the number of power states and their 
>>    properties vary a lot.  Very simple powered entities may just have 
>>    only the extreme states, full power and off state.  Some 
>>    implementations might use IEEE1621 model of three states on, off, and 
>>    sleep.  However, more granular power states can be implemented with 
>>    many levels of off, sleep, and reduced power states. 
>> 
>> 3.2.  Trade-offs 
>> 
>>    While the general objective of energy management is quite clear, the 
>>    way to attain that goal is often difficult.  In many cases there is 
>>    no way of reducing power consumption without the consequence of a 
>>    potential performance, service, or capacity degradation.  Then a 
>>    trade-off needs to be dealt with between service level objectives and 
>>    energy efficiency.  In other cases a reduction of energy consumption 
>>    can easily be achieved while still maintaining sufficient service 
>>    level performance, for example, by switching powered entities to 
>>    lower power states when higher performance is not needed. 
>> 
>> 3.3.  Local and network-wide energy management 
>> 
>>    Many energy saving functions can be executed locally by a powered 
>>    entitiy.  The basic principle is that a powered entitiy monitors its 
>>    usage and dynamically adapts its energy consumption according to the 
>>    required performance.  It may switch to a sleep state when it is not 
>>    in use at all. 
> Well, not only when it's not in use.
> It could be based on the time of day, or any other energy saving policies.

Right. I extended the sentence accordingly.

>> Potential interactions with an energy management 
>> 
>> 
>> 
>> Quittek, et al.         Expires January 12, 2012                [Page 8] 
>> 
>> Internet-Draft     Requirements for Energy Management          July 2011 
>> 
>> 
>>    system for such an entity include the observation of the entity's 
>>    power state and the configuration of power saving policies, for 
>>    example, by setting thresholds for power state changes. 
>> 
>>    Energy savings can also be achieved with policies implemented by a 
>>    network management system that controls power states of managed 
>>    entities.  In order to make policy decisions properly, information 
>>    about the energy consumption of powered entities in different power 
>>    states is required.  Often this information is acquired best through 
>>    monitoring. 
>> 
>>    Both methods, network-wide and local energy management, have 
>>    advantages and disadvantages.  Most buildings use both of them.  In 
>>    some cases for example, significant energy savings can be achieved by 
>>    simply setting all powered entities in a network to sleep, when the 
>>    network is not needed.  However, in general it is dangerous to set 
>>    all powered entities of a group to the same state, because there is a 
>>    risk that such actions ignore specifics of individual powered 
>>    entities or violate local service level agreements. 
> Can you please expand the previous sentence.
> I'm not sure that I agree.

I suggest removing it and polishing the entire paragraph:

        "Both methods, network-wide and local energy management,
        have advantages and disadvantages and often it is a good coice 
        to combine them. Central management is often favourable for 
        setting power states of a large number of entities at the same
        time, for example, at beginning and end of business hours in a 
        building. Local management appears often to be preferable for
        dynamic power saving measures based on local observations, such 
        as high or low load of an entity."

>> 
>> 3.4.  Energy monitoring 
> rename to "energy monitoring versus energy savings"

Done.

>> 
>>    It should be noted that only monitoring energy consumption and power 
>>    states is obviously not a means to reduce the energy consumption of a 
>>    powered entitiy.  In fact, it is likely to increase the power 
>> 

 [snip]

>> 3.5.  Overview of energy management requirements 
>> 
>>    From the considerations described above the following basic 
>>    management functions appear to be required for energy management: 
>>    o  monitoring power states 
>>    o  monitoring power (energy consumption rate) 
>>    o  monitoring (accumulated) energy consumption 
>>    o  setting power states 
>>    o  setting and enforcing power saving policies 
> And again the comment about the power quality

Added.

>> 
>>    It should be noted that active power control is complementary (but 
> what does the "active" power control mean?

I don't know. I suggest removing "active".

>>    essential) to other energy savings measures such as low power 
>>    electronics, energy saving protocols (for example, IEEE 802.3az), 
>>    energy-efficient device design (for example, sleep and low-power 
>>    modes for individual components of a device), and energy-efficient 
>>    network architectures.  Measurement of energy consumption may also 
>>    provide useful input for developing these technologies. 
>> 
>> 
>> 4.  Identification of Powered Entities 
>> 
>>    As already stated Section 1.1, powered entities on which energy- 
>>    related information is provided
> add a comma

fixed.

>> are identified in a sufficiently 
>>    unique way.  This holds in particular for powered entities that are 
>>    components of managed devices and in case that one powered entity 
>>    reports information on another one, see Section 7.  For powered 
>>    entities that control other powered entities it is important to 
>>    identify the powered entities they control, see Section 8. 
>> 
>>    Also stated already in Section 1.1 is the requirement of providing 
>>    means for reporting energy-related information on components of a 
>>    managed device.  An entity in this document may be an entire managed 
>>    device or just a component of it.  Examples of components of interest 
>>    are a hard drive, a battery, or a line card.  For controlling 
>>    entities it may be required to be able to address individual 
>>    components in order to save energy.  For example, server blades can 
>>    be switched off when the overall load is low or line cards at 
>>    switches may be powered down at night times. 
>> 
>>    Instrumentation for measuring energy consumption of a device is 
>>    typically more expensive than instrumentation for retrieving the 
>>    devices power state.  It may be a reasonable compromise in many cases 
>>    to provide power state information for all individually switchable 
>>    components of a device separately, while the energy consumption is 
>>    only measured for the entire device. 
>> 
>>    Detailed Requirements: 
>> 
>> 
>> 
>> 
>> Quittek, et al.         Expires January 12, 2012               [Page 10] 
>> 
>> Internet-Draft     Requirements for Energy Management          July 2011 
>> 
>> 
>> 4.1.  Identifying powered entities 
>> 
>>    The energy management standard must provide means for uniquely and 
>>    persistently identifying powered entities that are monitored or 
>>    controlled by an energy management system.  Uniqueness must be given 
>>    in a domain that is large enough to avoid collisions of identities at 
>>    potential receivers of monitored information. 
> We want to remove "and persistently" from the sentence, as this is covered in 4.3

Done.

> We should have a requirement about a UUID for powered entities.
> Let's cover that during the WG.

Replaced last sentence with
   "In order to avoid collisions of identities at potential receivers of 
   monitored information, a univesally unique identifier must be used."

>> 
>> 4.2.  Identifying components of powered devices 
>> 
>>    The energy management standard must provide means for identifying not 
>>    just entire devices as powered entities, but also individual 
>>    components of powered devices. 
>> 
>> 4.3.  Persistency of Identifiers 
>> 
>>    The energy management standard must provide means for indicating 
>>    whether identifiers of powered entities are persistent across a re- 
>>    start of the powered entitiy that provides the identifiers. 
>> 
>> 
>> 5.  Information on Powered Entities 
>> 
>>    This section describes energy-related information on powered entities 
>>    for which an energy management standard must provide means for 
>>    retrieving and reporting. 
>> 
>>    Note that the fact that an energy management standard provides 
>>    required means does not imply that all of them must be implemented by 
>>    every compliant implementation.  The concrete specification of 
>>    standards based on these requirements may label individual features 
>>    as mandatory, recommended, or optional. 
> Remove this paragraph above, as this is already covered before, and this is not specific to this section 5.

OK.

>> 
>>    Required information on powered entities can be structured into six 
>>    groups.  Section 5.1 specifies requirements for general information 
>>    on powered entities, such as type of powered entity or context 
>>    information.  Section 5.2 covers requirements related to entities' 
>>    power states.  Requirements for information on power inlets and power 
>>    outlets of powered entities are specified in Section 5.3.  Monitoring 
>>    of power and energy is covered by Sections 5.4 and 5.5, respectively. 
>>    Finally, Section 5.6 specified requirements for monitoring batteries. 
>> 
>> 5.1.  General information on powered entities 
>> 
>>    For energy management it may be required to understand the role and 
>>    context of a powered entitiy.  When monitoring, it may be helpful to 
>>    group energy consumption per kind of entity.  When controlling and 
>>    setting power states it may be helpful to understand the kind and 
>> 
>> 
>> 
>> Quittek, et al.         Expires January 12, 2012               [Page 11] 
>> 
>> Internet-Draft     Requirements for Energy Management          July 2011 
>> 
>> 
>>    role of a powered entitiy in a network, for example, in order to 
>>    avoid switching off vital network components. 
>> 
>>    Detailed Requirements: 
>> 
>> 5.1.1.  Type of powered entity 
>> 
>>    The energy management standard must provide means to retrieve and 
>>    report the type of powered entities according to a standrdized 
>>    classification scheme. 
> see the email thread on the mailing list.

Yes. It is still an open issue.

 [snip]

>> 5.2.1.  Actual power state 
>> 
>>    The energy management standard must provide means for reporting the 
>>    actual power state of a powered entitiy. 
>> 
>> 5.2.2.  List of supported power states 
>> 
>>    The energy management standard must provide means for retrieving the 
>>    list of all potential power states of a powered entitiy. 
>> 
>> 5.2.3.  Multiple power state sets 
>> 
>>    The energy management standard must provide means for supporting 
>>    multiple power state sets simultaneously at a powered entity. 
>> 
>> 5.2.4.  List of supported power state sets 
>> 
>>    The energy management standard must provide means for retrieving the 
>>    list of all power state sets supported by a powered entitiy. 
>> 
>> 5.2.5.  List of supported power states 
> 5.2.2 has got the same title.
> Proposal for 5.2.5 "List of supported power states within power state set"

Done.

>> 
>>    Referring to the "list of supported power state sets" requirement, 
>>    the energy management standard must provide means for retrieving the 
>>    list of all potential power states of a powered entitiy that belong 
>>    to a given power state set. 
> new text.
>     For the rest of the document, when the Power State term is used, it implicitly refers to a power state within a power state set.
> 
> Note that this comment might be part of the power State definition

Yes, let's rather add this to the definition of power states.
Here it seems to bee too late in the draft, because we talk a lot about power states before.
And it should not be just for the rest of the document, it should be for the full document.

>> 
>> 5.2.6.  Maximum and average power per power state 
>> 
>>    The energy management standard must provide means for retrieving the 
>>    maximum power and the average power as a typically static property 
>>    for each supported power state. 
>> 
>> 5.2.7.  Power state statistics 
>> 
>>    The energy management standard must provide means for monitoring 
>>    statistics per power state including at least the total time spent in 
>>    a power state, the number of times a state was entered and the last 
>>    time a state was entered.  More power state statistics are addressed 
>> 
>> 
>> 
>> Quittek, et al.         Expires January 12, 2012               [Page 13] 
>> 
>> Internet-Draft     Requirements for Energy Management          July 2011 
>> 
>> 
>>    by requirement 5.5.3. 
>> 
>> 5.2.8.  Power state changes 
>> 
>>    The energy management standard must provide means for generating a 
>>    notification when the actual power state of a powered entity changes. 
>> 
>> 5.3.  Power inlet and power outlet 
>> 
>>    Powered entities have power inlets at which they are supplied with 
>>    electric power.  Most powered entities just have a single power 
>>    inlet, while some have multiple ones.  Often different power inlets 
>>    are connected to separate power distribution trees.  For energy 
>>    monitoring, it is important information which power inlets a powered 
>>    entitiy has,
> what do you mean? the type, the number, or something else?

This was poorly phrased. Here is another try or the last sentence:

        "For energy monitoring, 
        it is useful to retrieve information on the number of inlets 
        of a powered entitiy, the availability of power at inlets 
        and which of them are actually in use."

>> if power is available at an inlet and which of them are 
>>    actually in use. 
>> 
>>    Some powered entities have power outlets for supplying other powered 
>>    entities with electric power.  A powered entitiy may have multiple 
>>    power outlets.  Examples are Power Distribution Units (PDUs) and 
>>    Power over Ethernet (PoE) Power Sourcing Equipment (PSE). 
> Remove the previous sentence, as this is already in the terminology section.

Done.

>> 
>>    For identifying and potentially controlling the source of power 
>>    received at an inlet, it may be required to identify the power outlet 
>>    of another powered entity at which the received power is provided. 
>>    Analogously, for each outlet it is of interest to identify the power 
>>    inlets that receive the power provided at a certain outlet. 
>> 
>>    Static properties of each power inlet and each power outlet are 
>>    required information for energy management.  Static properties 
>>    include the kind of electric current (Alternating Current (AC) or 
>>    Direct Current (DC)), the nominal voltage, the nominal AC frequency, 
>>    and the number of AC phases. 
> So "static properties" is what we called "power quality"?

I am not sure what was meant when the term power quality was used in discussions.
The current version of the Power Quality MIB contains several dynamic values that can 
be used to determine power quality. But it does not contain these static values.

>>    Detailed Requirements: 

 [snip]

>> 5.3.8.  Nominal AC frequency 
>> 
>>    The energy management standard must provide means for reporting the 
>>    nominal AC frequency for each power inlet and each power outlet of a 
>>    powered entity. 
>> 
>> 5.3.9.  number of AC phases 
> number -> Number

Fixed.

>> 
>>    The energy management standard must provide means for reporting the 
>>    number of AC phases for each power inlet and each power outlet of a 
>>    powered entity. 
>> 

[snip]

>> 5.6.  Battery State 
>> 
>>    Today more and more powered entities contain batteries that supply 
>>    them with power when disconnected from electrical power distribution 
>>    grids.  Common examples are nomadic and mobile devices, such as 
>>    notebook computers, netbooks, and smart phones.  The status of 
>>    batteries in such an powered entity, particularly the charging status 
>>    is typically controlled by automatic functions that act locally on 
>>    the powered entitiy and manually by users of the powered entity.  In 
>> 
>> 
>> 
>> Quittek, et al.         Expires January 12, 2012               [Page 19] 
>> 
>> Internet-Draft     Requirements for Energy Management          July 2011 
>> 
>> 
>>    addition to this, there is a need to monitor the battery status of 
>>    these entities by network management systems. 
>> 
>>    The management requirements discussed above in Sections 5.1 to 5.5 
>>    concern energy-related information on powered entities.  Powered 
>>    entities may be powered devices or components of powered devices. 
> I  believe that we mentioned that sentence already.

removed.

>>    Devices containing batteries can be modeled in two ways.  The entire 
>>    device can be modeled as a single powered entity on which energy- 
>>    related information is reported or the battery can be modeled as an 
>>    individual powered entity for which energy-related information is 
>>    monitored individually according to requirements in Sections 5.1 to 
>>    5.5. 
>> 
>> 

[snip]

>> 5.6.6.  Low battery charge notification 
>> 
>>    The energy management standard must provide means for generating a 
>>    notification when a the charge of a battery decreases below a given 
>>    threshold. 
> remove "a"

Fixed.

>> 
>> 5.6.7.  Battery replacement notification 
>> 
>>    The energy management standard must provide means for generating a 
>>    notification when the number of charging cycles of battery exceeds a 
>>    given threshold. 
>> 
>> 

 [snip]

>> 
>> 7.3.  Reporting quantities accumulated over multiple powered entities 
>> 
>>    For powered entities reporting single values that are accumulated 
>>    over multiple powered entities, the energy management standard must 
>>    provide means for reporting the list of all powered entities from 
>>    which contributions are included in the accumulated value. 
> See my comments at the beginning of the email

Yes. We need conclusion on the aggregation issue before finalizing this.

>> 
>> 7.4.  List of all powered entities on which is reported 
>> 
>>    The energy management standard must provide means for a powered 
>>    entitiy to report the list of all other powered entities on which it 
>>    can report energy-related information. 
>> 

 [snip]

>> 8.2.  Controlling power supply of other powered entities 
>> 
>>    Some powered entities may have control of the power supply of other 
>>    powered entities, for example, because the other powered entity is 
>>    supplied via a power outlet of the powered entitiy.  For this and 
>>    similar cases means are needed to make this control accessible to the 
>>    energy management system. 
>> 
>>    In addition to this, it is very required that a powered entitiy that 
> very required -> required

Fixed.

>>    has its supply controlled by other powered entities has means to 
>>    report the list of these other powered entities. 
>> 

 [snip]

>> 11.  Acknowledgements 
>> 
>>    The authors would like to thank Ralf Wolter for his first essay on 
>>    this draft.  Many thanks to William Mielke, John Parello, Bruce 
>>    Nordman, JinHyeock Choi, Georgios Karagiannis, and Michael Suchoff 
>>    for helpful comments on the draft. 
>> 
> I'll address the open issues in separate email threads.
> 
> Regards, Benoit.

Thanks a lot,

    Juergen