Subject: Re: [eman] draft-tychon-eman-applicability-statement-05: review

From: Benoit Claise <[email-masked]>
Date: Mon, 19 Dec 2011 15:31:00 +0100

Brad,
> Benoit,
>
>
> A few comments on some of the larger points in your applicability
> statement review comments from last month...
>
> 1)      bclaise:  "Zigbee Smart Energy 2.0 is based on IP, right? This should
> be stressed."
>
> Zigbee 1.x is not based upon IP. But Zigbee 2.0, if adopted, is designed
> to interoperate with IP, but is still a draft at this point.  I think our
> applicability statement should probably focus on Zigbee 1.x which has seen
> wide deployment, with market forecasts for 36M Zigbee devices in 2011
> (source: On Research).
Don't you want to say a few words about Zigbee 2.0 anyway, as work in 
progress?

>
>
> 2)      bclaise:  "power caping is something that could be done in a management
> app using the EMAN Mib.  E.g., when polling for current usage, if this crosses a powercap use EMAN Mib to set the power state to a lower level."
>
> The more conventional use case seems to define the power cap on a device,
> and have that device enforce the power cap.  This seems to have derived
> from an HP product feature (Dynamic Power Capping - DPC) that has seen
> only limited adoption to date by other
> vendors.  The use of the term is almost always 'dynamic power capping',
> implying its autonomous.  EMAN could be used to set the power caps
> (although we lack an attribute for this at present), or monitor
> conformance with a power capping policy.  On the other hand, its biggest
> use case to-date is as an HP vendor proprietary feature.
>
> The use of power caping is also at variance with with ACPI and Intel's
> experience with CPU dynamic frequency and voltage scaling (DFVS).  Their
> experience show that "race to halt" was usually a more effective power
> management strategy than simply reducing the CPU frequency to reduce power
> usage.
>
> When the goal is to minimize energy consumption, capping power might not
> be the optional solution.[1]
>
>          1. http://www.ok-labs.com/_assets/ATC-161Paper_McCammon.pdf
Understood.
When I read section 2.15 "power capping", I'm wondering, as a reader, 
what is the link with EMAN.
This is what I was trying to clarify. I stand corrected with your 
explanation. However, the initial concern remains: please explain the 
link with EMAN, even if this case a statement such as "not covered by 
the current EMAN architecture" would be good enough.
>
>
> 3)      bclaise:  Question: what is the relationship with EMAN. If none,
> mentions it along with a list of pros/cons. I mean: why should an implementator chose EMAN versus DASH?
>
> DASH is a Web management (webem) protocol.  There should be no confusion
> that EMAN/SNMP and DASH/HTTP are entirely different protocols.  What we
> can stress is that while the protocols are incompatible, the EMAN data
> model can be aligned, where appropriate, with the DASH model.  Afterall,
> DASH has been itself been aligned with the prior power management standard
> ACPI.
>
> So, I propose adding something like:
>
>          "While the SNMP and WebEM communication protocols are incompatible, the
> EMAN data model should be aligned whenever possible, with the DASH model"
Well, this is an applicability statement, not a requirement draft, or an 
architecture.
So you have to explain the relationship, if any, between EMAN and DASH.
Some text around what you explained is more appropriate:

    DASH is a Web management (webem) protocol.  There should be no confusion
    that EMAN/SNMP and DASH/HTTP are entirely different protocols.  What we
    can stress is that while the protocols are incompatible, the EMAN data
    model can be aligned, where appropriate, with the DASH model.  Afterall,
    DASH has been itself been aligned with the prior power management standard
    ACPI.

Regards, Benoit (as a contributor)
>
>
> Regards,
>
>
>
> Brad Schoening
>
>>
>> -----Original Message-----
>> From: Benoit Claise (bclaise)
>> Sent: Saturday, November 12, 2011 8:25 PM
>> To: eman mailing list; Emmanuel Tychon (etychon); Mouli Chandramouli
>> (moulchan); Bruce Nordman; Brad Schoening
>> Subject: draft-tychon-eman-applicability-statement-05: review
>>
>> Dear authors,
>>
>> Thanks for producing this new version. Much appreciated.
>> I specifically like the structure you put in place with "target
>> devices", "how powered", "reporting"
>> See inline for some more comments.
>>
>> Regards, Benoit (as a contributor)
>>>        Energy Management Working Group                          E.
>> Tychon
>>>       Internet Draft                                  Cisco Systems
>> Inc.
>>>       Intended status: Informational                        B.
>> Schoening
>>>       Expires: April 31, 2012                     Independent
>> Consultant
>>>                                                       Mouli
>> Chandramouli
>>>                                                       Cisco Systems
>> Inc.
>>>                                                            Bruce
>> Nordman
>>>                                    Lawrence Berkeley National
>> Laboratory
>>>                                                         October 31,
>> 2011
>>>
>>>
>>>
>>>                  Energy Management (EMAN) Applicability Statement
>>>                    draft-tychon-eman-applicability-statement-05
>>>
>>>
>>>       Status of this Memo
>>>
>>>          This Internet-Draft is submitted to IETF in full conformance
>>>          with the provisions of BCP 78 and BCP 79.
>>>
>>>          Internet-Drafts are working documents of the Internet
>>>          Engineering Task Force (IETF), its areas, and its working
>>>          groups.  Note that other groups may also distribute working
>>>          documents as Internet-Drafts.
>>>
>>>          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."
>>>
>>>          The list of current Internet-Drafts can be accessed at
>>>          http://www.ietf.org/ietf/1id-abstracts.txt
>>>
>>>          The list of Internet-Draft Shadow Directories can be accessed
>> at
>>>          http://www.ietf.org/shadow.html
>>>
>>>          This Internet-Draft will expire on April 31, 2012.
>>>
>>>
>>>       Copyright Notice
>>>
>>>          Copyright (c) 2011 IETF Trust and the persons identified as
>> the
>>>          document authors. All rights reserved.
>>>
>>>
>>>
>>>
>>>
>>>
>> <Tychon, et Al.>               Expires April 31, 2012       [Page 1]
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          This document is subject to BCP 78 and the IETF Trust's Legal
>>>          Provisions Relating to IETF Documents
>>>          (http://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 Simplified BSD License text as described
>>>          in Section 4.e of the Trust Legal Provisions and are provided
>>>          without warranty as described in the Simplified BSD License.
>>>
>>>
>>>       Abstract
>>>
>>>          The objective of Energy Management (EMAN)is to provide an
>> energy
>>>          management framework for networked devices. This document
>>>          presents the applicability of the EMAN framework for a variety
>>>          of scenarios. This document lists use cases and target devices
>>>          that can potentially implement the EMAN framework and
>> associated
>>>          SNMP MIB modules. These use cases are useful for identifying
>>>          monitoring requirements that need to be considered. Further,
>> we
>>>          describe the relationship of the EMAN framework to relevant
>>>          other energy monitoring standards and architectures.
>>>
>>>
>>>       Table of Contents
>>>
>>>        1. Introduction
>> ................................................3
>>>          1.1. Energy Management Overview
>>> ..............................4
>>>          1.2. Energy Measurement
>>> ......................................5
>>>          1.3. Energy Management
>>> .......................................5
>>>          1.4. EMAN Framework Application
>>> ..............................6
>>>          1.5. EMAN WG Document Overview
>>> ...............................6
>>>        2. Scenarios and Target Devices
>>> ................................7
>>>          2.1. Network Infrastructure Energy Objects
>>> ...................7
>>>          2.2. Devices Powered and Connected to a Network Device
>>> .......8
>>>          2.3. Devices Connected to a Network
>>> ..........................9
>>>          2.4. Power Meters
>>> ............................................9
>>>          2.5. Mid-level Managers
>>> .....................................10
>>>          2.6. Gateways to Building Systems
>>> ...........................11
>>>          2.7. Home Energy Gateways
>>> ...................................12
>>>          2.8. Data Center Devices
>>> ....................................13
>>>
>>         2.9. Energy Storage Devices ................................14
>>>          2.10. Ganged Outlets on a PDU Multiple Power Sources
>> ........14
>>>          2.11. Industrial Automation Networks
>>>    ......................15
>>>          2.12. Printers
>>>             ...................................15
>>>          2.13. Off-Grid Devices
>>> ......................................17
>>>          2.14. Demand/Response
>>>    .....................................17
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 2]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          2.15. Power Capping
>>>    ........................................18
>>>        3. Use Case Patterns
>>>   ..........................................18
>>>          3.1. Metering
>>>   ...............................................18
>>>          3.2. Metering and Control
>>>   ...................................19
>>>          3.3. Power Supply, Metering and Control
>>>   .....................19
>>>          3.4. Multiple power sources
>>>   .................................19
>>>        4. Relationship of EMAN to other Standards
>>>   ....................19
>>>          4.1. Data Model and Reporting
>>>   ...............................20
>>>                4.1.1. IEC - CIM.
>> ......................................20
>>>                4.1.2. DMTF
>> ............................................20
>>>                4.1.3. ODVA
>> ............................................21
>>>                4.1.4. Ecma SDC
>> ........................................22
>>>                4.1.5. IEEE-ISTO Printer Working Group (PWG)
>> ...........22
>>>                4.1.6. ASHRAE
>> ..........................................23
>>>                4.1.7. ZigBee
>> ..........................................24
>>>          4.2. Measurement
>>>   ............................................24
>>>                4.2.1. ANSI C12
>> ........................................24
>>>                4.2.2. IEC62301
>> ........................................24
>>>          4.3. Other
>>>   ..................................................25
>>>                4.3.1. ISO
>> .............................................25
>>>                4.3.2. EnergyStar
>> ......................................26
>>>                4.3.3. SmartGrid
>> .......................................26
>>>        5. Limitations
>>>   ................................................27
>>>        6. Security Considerations
>>>   ....................................27
>>>        7. IANA Considerations
>>>   ........................................27
>>>        8. Acknowledgements
>>>   ...........................................27
>>>        9. Open Issues
>>>    ...............................................28
>>>        10. References
>>>   ................................................28
>>>          10.1. Normative References
>>>   ..................................28
>>>          10.2. Informative References
>>>   ................................29
>>>
>>>
>>>
>>>       1. Introduction
>>>
>>>          The focus of the Energy Management (EMAN) framework is energy
>>>          monitoring and management of energy objects [EMAN-DEF].  The
>>>          scope of devices considered are network equipment and its
>>>
>>         components, and devices connected directly or indirectly to
>>>          the network. The EMAN framework enables monitoring i.e.;
>>>          heterogeneous devices to report their energy consumption, and
>>>          secondly, if permissible, enables control policies for energy
>>>          savings.  There are multiple scenarios where this is
>>>          desirable, particularly considering the increased importance
>>>          of limiting consumption of finite energy resources and
>>>          reducing operational expenses.
>>>
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 3]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement      October 2011
>>>
>>>          The EMAN framework describes how energy information can be
>> Introduce a reference.
>>>          retrieved from IP-enabled devices using Simple Network
>>>          Management Protocol (SNMP), specifically, Management
>> Information
>>>          Base (MIBs) for SNMP.
>>>
>>>          This document describes typical applications of the EMAN
>>>          framework, as well as its opportunities and limitations. Other
>>>          standards that are similar to EMAN but address different
>> domains
>>>          are described. This document contains references to those
>> other
>>>          standards and describes how they relate to the EMAN framework.
>>>
>>>       1.1. Energy Management Overview
>>>
>>>          First, a brief introduction to the definitions of Energy and
>>>          Power are presented. A draft on terminology has been submitted
>>>          so that to reach a consensus on the definitions of commonly
>> used
>>>          terms in the EMAN WG. While energy is available in many forms,
>>>          EMAN addresses only the electrical energy consumed by devices
>>>          connected to a network.
>>>
>>>          Energy is the capacity to perform work. Electrical energy is
>>>          typically expressed in kilowatt-hour units (kWh) or other
>>>          multiples of watt-hours (Wh). One kilowatt-hour is the
>>>          electrical energy used by a 1 kilowatt device for one hour.
>>>          Power is the rate of electrical energy flow. In other words,
>>>          power = energy / time. Power is often measured in watts.
>> Billing
>>>          is based on electrical energy (measured in kWh) supplied by
>> the
>>>          utility.
>>>
>>>          Towards the goal of increasing the energy efficiency in
>> networks
>>>          and buildings, a first step is to enable energy objects to
>>>          report their energy usage over time. The EMAN framework
>>>          addresses this problem with an information model for some
>>>          electrical equipment: energy object identification, energy
>>>          object context, power measurement and power measurement
>>>          attributes.
>> and power quality (even if we need a consensus on the name)
>>>          The EMAN WG framework defines SNMP MIB modules based on the
>>>          information model.  By implementing the SNMP MIB modules, any
>>>          energy object can report its energy consumption according to
>> the
>>>          information model. In that context, it is important to
>>>          distinguish energy objects that can report their own energy
>>>          usage from parent devices that can also collect and aggregate
>>>          energy usage of children energy objects.
>>>
>>>          The list of target devices and scenarios considered for Energy
>>>          Management are presented in Section 2 with detailed examples.
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 4]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement      October 2011
>>>
>>>
>>>       1.2. Energy Measurement
>>>
>>>          More and more devices are able to measure and report their own
>>>          energy consumption. Smart power strips and some Power over
>>>          Ethernet (PoE) switches can meter consumption of connected
>>>          devices.  However, when managed and reported through
>> proprietary
>>>          means, this information is minimally useful at the enterprise
>>>          level.
>>>
>>>          The primary goal of the EMAN MIBs is to enable reporting and
>>>          management within a standard framework that is applicable to a
>>>          wide variety of end devices, meters, and proxies. This enables
>> a
>>>          management system to know who's consuming what, when, and how
>> at
>>>          any time by leveraging existing networks, across various
>>>          equipment, in a unified and consistent manner.
>>>
>>>          Given that an energy object can consume energy and/or provide
>>>          energy to other devices, there are three types of meters for
>>>          energy measurement: energy input to a device, energy supplied
>> to
>>>          other devices, and net (resultant) energy consumed (the
>>>          difference between energy input and provided).
>>>
>>>       1.3. Energy Management
>>>
>>>          Beyond energy monitoring, the EMAN framework provides
>> mechanisms
>>>          for energy control.
>>>
>>>          There are many cases where reducing energy consumption of
>>>          devices is desirable, such as when the device utilization
>> islow
>> islow ->  is low
>>>          or when the electricity is expensive or in short supply.
>>>
>>>          In some cases, energy control requires considering the energy
>>>          object context. For instance, in a building: all phones would
>>>          not usually be turned off to keep some still available in case
>>>          of emergency; office cooling is usually not turned off totally
>>>          during non-work hours, but the comfort level is reduced; and
>> so
>>>          on.
>>>
>>>          Energy object control requires flexibility and support for
>>>          different polices and mechanisms: from centralized management
>>>          with a network management station, to autonomous management by
>>>          individual devices, and alignment with dynamic demand-response
>>>          mechanisms.
>>>
>>>          The EMAN framework can be used as a tool for the
>> demand/response
>>>          scenario where in response to time-of-day fluctuation of
>> energy
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 5]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement      October 2011
>>>
>>>          costs or possible energy shortages, it is possible to respond
>>>          and reduce the energy consumption for the network devices,
>>>          effectively changing its power state.
>>>
>>>
>>>       1.4. EMAN Framework Application
>>>
>>>
>>>          A Network Management System (NMS) is the entity that requests
>>>          information from compatible devices using SNMP protocol. It
>> may
>>>          be a system which also implements other network management
>>>          functions, e.g. security management, identity management and
>> so
>>>          on), or one that only deals exclusively with energy in which
>>>          case it is called EnMS, Energy Management System. It may be
>>>          limited to monitoring energy use, or it may also implement
>>>          control functions. In a typical application of the EMAN
>>>          framework, management software collects energy information for
>>>          devices in the network.
>>>
>>>          Energy management can be implemented by extending existing
>> SNMP
>>>          support to the EMAN specific MIBs. SNMP provides an industry
>>>          proven and well-known mechanism to discover, secure, measure,
>>>          and control SNMP-enabled end devices.  The EMAN framework
>>>          provides an information and data model to unify access to a
>>>          large range of devices. The scope of the target devices and
>> the
>>>          network scenarios considered for energy management are listed
>> in
>>>          Section 2.
>>>
>>>       1.5. EMAN WG Document Overview
>> I would move this section in 1.2, because you refer multiple times to
>> the documents
>>>          The EMAN working group charter calls for producing a series of
>>>          Internet standard drafts in the area of energy management. The
>>>          following drafts are currently under discussion in the working
>>>          group.
>> Write sentences as if the WG did the work already.
>>>            Applicability Statement [EMAN-AS] This draft presents the
>> use
>> Same comment. Change draft ->  document
>> Note that there are multiple instances of this open issue.
>>>            cases and scenarios for energy monitoring.  In addition,
>> other
>>>            relevant energy standards and architectures are listed.
>>>
>>>            Requirements [EMAN-REQ] This draft presents the requirements
>>>            of Energy Monitoring and the scope of the devices
>> considered.
>> Energy Monitoring ->  Energy Management
>>>            Framework [EMAN-FRAMEWORK] This draft defines the
>> terminology
>>>            and explains the different concepts associated with energy
>>>            monitoring; these are used in the MIB modules.
>> [EMAN-FRAMORK] says
>>
>>     This document defines a framework for providing Energy
>>          Management for devices within or connected to communication
>>          networks.
>>
>> Energy Monitoring ->  Energy Management
>> Note: multiple instance of this issue, please check "Energy Monitoring"
>> throughout the draft.
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 6]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement      October 2011
>>>
>>>            Energy-Aware MIB [EMAN-AWARE-MIB] This draft proposes a MIB
>>>            module that characterizes a device's identity and context.
>>>
>>>            Monitoring MIB [EMAN-MONITORING-MIB] This draft defines a
>> MIB
>>>            module for monitoring the power and energy consumption of a
>>>            device. In addition, the MIB module contains an optional
>>>            module for power quality metrics.
>>>
>>>            Battery MIB [EMAN-BATTERY-MIB] This draft contains a MIB
>>>            module for monitoring characteristics of an internal
>> battery.
>>>            Energy Management Terminology [EMAN-DEF] This draft lists
>> the
>>>            definitions and terms used in the Energy Management Working
>>>            Group.
>>>
>>>       2. Scenarios and Target Devices
>>>
>>>          In this section a selection of scenarios for energy management
>>>          are presented. The fundamental objective of the use cases is
>> to
>>>          list important network scenarios that the EMAN framework
>> should
>>>          solve. These use cases then drive the requirements for the
>> EMAN
>>>          framework.
>>>
>>>          Each scenario lists target devices for which the energy
>>>          management framework can be applied, as well as how the
>>>          reported-on devices are powered, and how the reporting is
>>>          accomplished.    While there may be some overlap between some
>> of
>>>          the use cases, the use cases serve as illustrative network
>>>          scenarios EMAN framework should solve.
>>>
>>>       2.1. Network Infrastructure Energy Objects
>>>
>>>          This scenario covers network devices and their components.
>> Power
>>>          management of energy objects is considered as a fundamental
>>>          requirement of energy management of networks.
>>>
>>>          It can be important to monitor the power state and energy
>>>          consumption of these energy objects at a granularity level
>> finer
>>>          than just the entire device. For these devices, the chassis
>>>          draws power from one or more sources and feeds all its
>> internal
>>>          components. It is highly desirable to have monitoring
>> available
>>>          for individual components, such as line cards, processors, and
>>>          hard drives as well as peripherals like USB devices.
>>>
>>>          As an illustrative example, consider a switch with the
>> following
>>>          grouping of sub-entities for which energy monitoring could be
>>>          useful.
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 7]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement      October 2011
>>>
>>>
>>>            .  physical view: chassis (or stack), line cards, service
>>>               modules of the switch
>> You should explain
>>      that the ENTITY-MIB provides the containment tree,
>>      that the MIB modules are based on the ENTITY-MIB indexing,
>>      that a component might be EO and that the ENTITY-containment tree
>> will express if it belongs to another EO (example: line card EO in a
>> chassis EO, assuming that both EOs can meter the power consumption)
>>>            .  component view: CPU, ASICs, fans, power supply, ports
>>>               (single port and port groups), storage and memory
>>>            .  logical view: system, data-plane, control-plane, etc.
>> Question: how can we get the logical view?
>>>          The essential properties of this use case are:
>>>
>>>            . Target devices: Network devices such as routers, switches
>>>               and their components.
>>>            . How powered: Typically by a PDU on a rack or from a wall
>>>               outlet. The components of a device are powered by the
>>>               device chassis.
>>>            . Reporting: Direct power measurement can be performed at a
>>>               device level. Components can report their power
>> consumption
>>>               directly or the chassis/device that can report on behalf
>> of
>>>               some components.
>>>
>>>       2.2. Devices Powered and Connected to a Network Device
>>>
>>>
>>>          This scenario covers Power over Ethernet (PoE) devices. A PoE
>>>          Power Sourcing Equipment (PSE) device (e.g. a PoE switch)
>> Should refer to the POE RFC for the terms such PSE and PD
>>>          provides power to a Powered Device (PD) (e.g. a desktop
>> phone).
>>>          For each port, the PSE can control the power supply (switching
>>>          it on and off) and monitor actual power provided. PoE devices
>>>          obtain network connectivity as well as the power supply for
>> the
>>>          device over a single connection so the PSE can determine which
>>>          device to allocate each port's power to.
>>>
>>>          PoE ports on a switch are commonly connected to IP phones,
>>>          wireless access points, and IP cameras. The switch powers
>>>          itself, as well as supplies power to downstream PoE ports.
>>>          Monitoring the power consumption of the switch (Energy Object
>>>          Parent) and the power consumption of the PoE end-points(Energy
>>>          Object Children) is a simple use case of this scenario.
>>>
>>>          The essential properties of this use case are:
>>>
>>>            . Target devices: Power over Ethernet devices such as IP
>>>               Phones, Wireless Access Points, and IP cameras.
>>>            . How powered: PoE devices are connected to the switch port
>>>               which supplies power to those devices.
>>>            . Reporting:  PoE device power consumption is often measured
>>>               and reported at the switch (PSE) port which supplies
>> power
>>>               for the PoE device.
>> As I said, I like this structure but what you're missing is:
>>                 . Parent/Child: explains who is the parent and who is
>> the child, if applicable
>>                 . Relationship: explains which relationship are
>> applicable, if any (*)
>>
>> (*) this is really missing for some of the examples below
>> Actually, it would even be better if the different use cases would
>> contain drawings such as
>> http://www.ietf.org/proceedings/81/slides/eman-4.pdf ->  slide 14 and 15
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 8]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement      October 2011
>>>
>>>
>>>          In this case, the PoE devices do not need to directly support
>>>          the EMAN framework, only the Power Sourcing Equipment (PSE)
>>>          does.
>> Not correct. The answer is "it depends". If the PD, along with its own
>> UUID,  might be represented in the PSE
>>>
>>>       2.3. Devices Connected to a Network
>>>
>>>          The use case covers the metering relationship between an
>> energy
>> "metering relationship". This should prove my point that you should add
>> Relationship in your bullet points.
>>>          object receiving power from a source such as a power brick,
>> and
>>>          have an independent network connection to a parent energy
>> object
>>>          such as a switch.
>>>
>>>          In continuation to the previous example is a switch port that
>> previous example ->  example in the section 2.2
>>>          has both a PoE connection powering an IP Phone, and a PC has a
>>>          daisy-chain connection to the IP Phone for network
>> connectivity.
>>>          The PC has a network connection from the switch, but draws
>> power
>>>          from the wall outlet, in contrast to the IP phone draws power
>>>          from the switch.
>>>
>>>          It is also possible to consider a simple example of PC which
>> has
>>>          a network connection but draws power from the wall outlet or
>>>          PDU.
>>>
>>>          The PC in this case, is an non-PoE device, can report power
>>>          usage by itself, for instance through the EMAN framework.
>>>
>>>          The essential properties of this use case are:
>>>
>>>            . Target devices:  Abroad set of energy objects that have a
>>>               network connection, but receive power supply from the
>> wall
>>>               outlet.
>>>            . How powered:  These devices receive power supply from the
>>>               wall outlet or a PDU.
>> "these devices" ->  make sure that you distinguish which one you're
>> talking about. Switch, POE phone, PC
>>>            . Reporting:  There are two models: devices that can measure
>>>               and report the power consumption directly via the EMAN
>>>               framework, and those that communicate it to the network
>>>               device (switch) and the switch can report the device's
>>>               power consumption via the EMAN framework.
>>>
>>>       2.4. Power Meters
>>>
>>>          Some electrical devices are not equipped with instrumentation
>> to
>>>          measure their own power and accumulated energy consumption.
>>>          External meters can be used to measure the power consumption
>> of
>>>          such electrical devices.
>>>
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 9]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement      October 2011
>>>
>>>          This use case covers the proxy relationship of energy objects
>>>          able to measure or report the power consumption of external
>>>          electrical devices, not natively connected to the network.
>>>          Examples of such metering devices are smart PDUs and smart
>>>          meters.
>>>
>>>          Three types of external metering are relevant to EMAN: PDUs,
>>>          standalone meters, and utility meters.  External meters can
>>>          measure these properties for a single device or for a set of
>>>          devices.
>> NEW:
>>          External meters can measure these properties for a single
>> device or for a set of
>>          devices. Three types of external metering are relevant to EMAN:
>>
>> PDUs,
>>          standalone meters, and utility meters.
>>
>>>          Power Distribution Unit (PDUs) in a rack have inbuilt meters
>> for
>>>          each socket and the PDUs can measure the power supplied to
>> each
>>>          device in an equipment rack. The PDUs have remote management
>>>          functionality which can be used to measure and possibly
>> control
>>>          the power supply of each outlet.
>>>
>>>          Standalone meters can be placed anywhere in a power
>> distribution
>>>          tree, and can measure the power consumption.
>>>          Utility meters monitor and report accumulated power
>> consumption
>>>          of the entire building. There can be sub-meters to measure the
>>>          power consumption of a portion of the building.
>>>
>>>          The essential properties of this use case are:
>>>
>>>            . Target devices:  PDUs and Smart Meters.
>> confused by the two examples, while you speak about 3 types of external
>> metering
>>>            . How powered:  From traditional mains power but as passed
>>>               through a PDU or meter.
>>>            . Reporting:  The PDUs reports power consumption of
>>>               downstream devices. There is commonly only one device
>>>               downstream of each outlet, but there could be many.
>> There
>>>               can be external meters in between the power supply and
>>>               device and the meters can report the power consumption of
>>>               the device.
>>>
>>>       2.5. Mid-level Managers
>>>
>>>          This use case covers aggregation of energy management data at
>>>          "mid-level managers" that can provide energy management
>>>          functions for themselves as well as associated devices.
>>>
>>>          A switch can provide energy management functions for all
>> devices
>>>          connected to its ports, whether or not these devices are
>> powered
>>>          by the switch or whether the switch provides immediate network
>>>          connectivity to the devices; such a switch is a mid-level
>>>          manager, offering aggregation of power consumption data for
>>>          devices it does not supply power to them.  Devices report
>> their
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 10]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          EMAN data to the switch and the switch aggregates the data for
>>>          these data.
>>>
>>>          The essential properties of this use case are summarized as
>>>          follows:
>>>
>>>            . Target devices: network devices which can perform
>>>               aggregation; commonly a switch or a proxy
>>>            . How powered:  Mid-level managers can be are commonly
>>>               powered by a PDU or from a wall outlet but there is no
>>>               limitation.
>> Some common language would be nice. "any method" is used in section 2.11
>>>            . Reporting:  The middle-manager aggregates the energy data
>>>               and reports that data to a NMS or higher mid-level
>> manager.
>>>       2.6. Gateways to Building Systems
>>>
>>>          This use case describes energy management of buildings.
>> Building
>>>          Management Systems (BMS) have been in place for many years
>> using
>>>          legacy protocols not based on IP. In these buildings, a
>> gateway
>>>          can provide a proxy relationship between IP and legacy
>> building
>>>          automation protocols. The gateway can provide an interface
>>>          between the EMAN framework and relevant building management
>>>          protocols.
>>>
>>>          Due to the potential energy savings, energy management of
>>>          buildings has received significant attention. There are
>> gateway
>>>          network elements to manage the multiple components ofa
>> building
>>>          energy management system such as Heating, Ventilation, and Air
>>>          Conditioning (HVAC), lighting, electrical, fire and emergency
>>>          systems, elevators, etc. The gateway device uses legacy
>> building
>>>          protocols to communicate with those devices, collects their
>>>          energy usage, and reports the results.
>>>
>>>          The gateway performs protocol conversion between many facility
>>>          management devices. The gateway communicates via RS-232/RS-485
>>>          interfaces, Ethernet interfaces, and protocols specific to
>>>          building management such as BACNET, MODBUS, or Zigbee.
>> References please
>>>          The essential properties of this use case are :
>>>
>>>            . Target devices: Building energy management devices - HVAC
>>>               systems, lighting, electrical, fire and emergency
>> systems.
>>>               There are meters for each of the sub-systems and the
>> energy
>>>               data is communicated to the proxy using legacy protocols.
>>>            . How powered: Any method, including directly from mains
>>>               power or via a UPS.
>>>
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 11]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>            . Reporting: The gateway collects energy consumption of non-
>>>               IP systems and communicates the data via the EMAN
>>>               framework.
>>>
>>>       2.7. Home Energy Gateways
>>>
>>>          This use case describes the scenario of energy management of a
>>>          home. The home energy gateway is another example of a proxy
>> that
>>>          interfaces to the electrical appliances and other devices in a
>>>          home and also has an interface to the utility. This gateway
>> can
>>>          monitor and manage electrical equipment (refrigerator,
>>>          heating/cooling, washing machine etc.) possibly using one of
>> the
>>>          many protocols (ZigBee, Smart Energy, ...) that are being
>>>          developed for the home area network products and considered in
>>>          standards organizations.
>>>
>>>          In its simplest form, metering can be performed at home.
>> Beyond
>>>          the metering, it is also possible implement energy saving
>>>          policies based on energy pricing from the utility grid. From
>> an
>>>          EMAN point of view, the information model that been
>> investigated
>>>          can be applied to the protocols under consideration for energy
>>>          monitoring of a home.
>>>
>>>
>>>
>>>          The essential properties of this use case are:
>>>
>>>            . Target devices: Home energy gateway and Smart meters in a
>>>               home.
>> In terms of capitalization, there are sometimes some strange things. See
>>
>> "Smart" above.
>>>            . How powered:  Any method.
>>>            . Reporting: Home energy gateway can collect power
>>>               consumption of device in a home and possibly report the
>>>               metering reading to the utility.
>>>
>>>          Beyond the canonical setting of a home drawing power from the
>>>          utility, it is also possible to envision an energy neutral
>>>          situation wherein the buildings/homes that can produce and
>>>          consume energy without importing energy from the utility grid.
>>>          There are many energy production technologies such as solar
>>>          panels, wind turbines, or micro generators. This use case
>>>          illustrates the concept of self-contained energy generation
>> and
>>>          consumption and possibly the aggregation of the energy use of
>>>          homes.
>>>
>>>
>>>
>>>
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 12]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>         2.8. Data Center Devices
>>>
>>>          This use case describes energy management of a Data Center
>>>          network.
>>>
>>>          Energy efficiency of data centers has become a fundamental
>>>          challenge of data center operation, as datacenters are big
>>>          energy consumers and their infrastructure is expensive. The
>>>          equipment generates heat, and heat needs to be evacuated
>> though
>>>          a HVAC system.
>>>
>>>          A typical data center network consists of a hierarchy of
>>>          electrical energy objects.  At the bottom are servers mounted
>> on
>> Replace . by ;
>>>          a rack; these are connected to the top-of-the-rack switches;
>>>          these are connected to aggregation switches; those in turn
>>>          connected to core switches.  Power consumption of all network
>>>          elements and the servers in the Data center should be
>> measured.
>>>          In addition, there are also network storage devices. Energy
>>>          management can be implemented on different aggregation levels,
>>>          such as network level, Power Distribution Unit (PDU) level,
>> and
>>>          server level.
>>>
>>>          The Data center network contains UPS to provide back-up power
>>>          for the network devices in the event in the event of power
>>>          outages. Thus from a Data center energy management point of
>>>          view, in addition, to monitoring the energy usage of network
>>>          devices, it is also important to monitor the remaining
>> capacity
>>>          of the UPS.
>> "see some more information about the UPS in section 2.9"
>>>          In addition to monitoring the power consumption, at a data
>>>          center level, additional metrics such as power quality, power
>>>          characteristics can be important metrics. The dynamic
>> variations
>>>          in the input power supply from the grid referred to as power
>>>          quality is one metric. Secondly, how the devices use the power
>>>          can be referred to as power characteristics and it is also
>>>          useful to monitor these metrics. Lastly, the power plate set
>>>          will make it possible to know an aggregate of the potential
>>>          worst-case power usage and compare it to the budgeted power in
>>>          the data center.
>>>
>>>          The essential properties of this use case are:
>>>
>>>            . Target devices: All network devices in a data center, such
>>>               as network equipment, servers, and storage devices.
>>>            . How powered: Any method but commonly by a PDUs in racks.
>>>            . Reporting: Devices may report on their own behalf, or for
>>>               other connected devices as described in other use cases.
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 13]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>
>>>       2.9. Energy Storage Devices
>>>
>>>          There are two types of devices with energy storage: those
>> whose
>>>          primary function is to provide power to another device (e.g. a
>>>          UPS), and those with a different primary function, but have an
>>>          energy storage as a component as an alternate internal power
>>>          source (e.g. a notebook).  EMAN covers both types of products
>> in
>>>          this use case.
>>>
>>>          The energy storage can be a battery, or any other means to
>> store
>>>          electricity such as a hydrogen cell.
>>>
>>>          Some devices have an internal battery as a back-up or
>>>          alternative source of power to mains power. When the
>> connection
>>>          to the power supply of the device is disconnected, the device
>>>          can run on the internal battery. As batteries have a finite
>>>          capacity and lifetime, means for reporting the actual charge,
>>>          age, and state of a battery are required.
>>>
>>>          UPS can provide backup power for many devices in a data
>> centers
>>>          for a finite period of time. Energy monitoring of such energy
>>>          storage devices is vital from a data center network operations
>>>          point of view. The UPS MIB provides a framework for monitoring
>>>          the remaining capacity of the UPS.
>>>
>>>          There are also battery systems for mobile towers particularly
>>>          for use in remote locations. It is important to monitor the
>>>          remaining battery life and raise an alarm when the battery
>> life
>>>          is below a threshold.
>> Explain that the battery is a component, which containment can be
>> tracked thanks to the ENTITY-MIB.
>>
>> We would need a special paragraph for the UPS. What is the link with the
>>
>> UPS-MIB.
>>>          The essential properties of this use case are:
>>>
>>>            . Target devices: Devices that have an internal battery such
>>>               as notebook PC and other mobile devices.
>>>            . How powered: From internal batteries or mains power.
>>>            . Reporting:  The device reports on its internal battery.
>>>
>>>
>>>       2.10. Ganged Outlets on a PDU Multiple Power Sources
>>>
>>>          This use case describes the scenario of multiple power sources
>>>          of a devices and logical groupings of devices in a PDU.
>>>
>>>          Some PDUs allow physical entities like outlets to be "ganged"
>>>          together as a logical entity to simplify management.
>>>
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 14]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          This is particularly useful for servers with multiple power
>>>          supplies, where each power supply is connected to a different
>>>          physical outlet. Other implementations allow "gangs" to be
>>>          created based on common ownership of outlets, such as business
>>>          units, load shed priority, or other non-physical
>> relationships.
>>>          Current implementations allow for an "M-to-N" mapping between
>>>          outlet "gangs" and physical outlets, as with this example:
>>>
>>>            . Outlet 1 - physical entity
>>>            . Outlet 2 - physical entity
>>>            . Outlet 3 - physical entity
>>>            . Outlet 4 - physical entity
>>>            . Outlet Gang A - virtual entity
>>>            . Outlet Gang B - virtual entity
>>>
>>>                 o Gang A ->   Outlets 1, 2 and 3
>>>                 o Gang B ->   Outlets 3 and 4
>>>
>>>          Note the allowed overlap on Outlet 3, which belongs to both
>>>          "gangs."
>>>
>>>          Each "Outlet Gang" entity reports the aggregated data from the
>>>          individual outlet entities that comprise it and enables a
>> single
>>>          point of control for all the individual outlet entities.
>>>
>>>
>>>       2.11. Industrial Automation Networks
>>>
>>>          Energy consumption statistics in the industrial sector are
>>>          staggering. The industrial sector alone consumes about half of
>>>          the world's total delivered energy, making it the largest end-
>>>          use sector. Thus, the need for optimization of energy usage in
>>>          this sector is natural.
>>>          Industrial facilities consume energy in process loads, and in
>>>          non-process loads.
>>>          The essential properties of this use case are:
>>>
>>>            . Target devices: Devices used in industrial automation
>>>            . How powered: Any method.
>>>            . Reporting: Currently, CIP protocol is currently used for
>>>               reporting energy for these devices
>>>
>>>       2.12. Printers
>>>
>>>          This use case describes the scenario of energy monitoring and
>>>          management of Printer devices.
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 15]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>
>>>          Printers in this use case stand in for all imaging equipment,
>>>          also including multi-function devices (MFDs), copiers,
>> scanners,
>>>          fax machines, and mailing machines.  Energy use of printers
>> has
>>>          been an industry concern for several decades, and they usually
>>>          have sophisticated power management with a variety of
>> low-power
>>>          modes, particularly for managing energy-intensive thermo-
>>>          mechanical components. Printers also have long made extensive
>>>          use of SNMP for end-user system interaction and for management
>>>          generally, and cross-vendor management systems are available
>>>          today to manage fleets of printers in enterprises.  Power
>>>          consumption during active modes can vary widely, with high
>> peak
>>>          levels.
>>>
>>>          Printers today can expose detailed power state information,
>>>          distinct from operational state information, with some
>> printers
>>>          reporting transition states between stable long-term states.
>>>          Many also support active setting of power states, and setting
>> of
>>>          policies such as delay times when no activity will cause
>>>          automatic transition to a lower power mode.  Other features
>>>          include reporting on components of imaging equipment, counters
>>>          for state transitions, and typical power levels by state,
>>>          scheduling, and events/alarms.
>>>
>>>          Some large printers also have a "Digital Front End" which is a
>>>          computer that performs functions on behalf of the physical
>>>          imaging system.  These will typically have their own presence
>> on
>>>          the network and are sometimes separately powered.
>>>
>>>          There are some unique characteristics of Printers from the
>> point
>>>          of view energy monitoring. While the printer is not in use,
>>>          there are timer based low power states (sleep, stand-by),
>> which
>>>          consume very little power. On the other hand, while the
>> printer
>>>          is printing or copying the cylinder needs to be heated so that
>>>          power consumption is quite high but only for a short period of
>>>          time (duration of the print job). Given this work load,
>> periodic
>>>          polling of energy consumption would not suffice.
>>>
>>>          Target Devices: All imaging equipment.
>>>
>>>          How Powered: Typically via mains AC from a wall outlet
>>>
>>>          Reporting: Devices report for themselves
>> Thinking some more about this "Reporting", I believe that that we should
>>
>> tell what the implementers shoud do.
>> For example: "Devices report for themselves by implementing [EMAN-MON]"
>> Note that this is a generic comment for all use cases.
>>>
>>>
>>>
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 16]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>       2.13. Off-Grid Devices
>>>
>>>          This use case concerns self-contained devices that use energy
>>>          but are not connected to an infrastructure power delivery
>> grid.
>>>          These devices typically scavenge energy from environmental
>>>          sources such as solar energy or wind power. The device
>> generally
>>>          contains a closely coupled combination of
>>>
>>>            . power scavenging or generation component(s)
>>>            . power storage component(s) (e.g., battery)
>>>            . power consuming component(s)
>>>
>>>          With scavenged power, the energy input is often dependent on
>> the
>>>          random variations of the weather. These devices therefore
>>>          require energy management both for internal control and remote
>>>          reporting of their state. In order to optimize the performance
>>>          of these devices and minimize the costs of the generation and
>>>          storage components, it is desirable to vary the activity
>> level,
>>>          and, hopefully, the energy requirements of the consuming
>>>          components in order to make best use of the available stored
>> and
>>>          instantaneously generated energy.  With appropriate energy
>>>          management, the overall device can be optimized to deliver an
>>>          appropriate level of service without over provisioning the
>>>          generation and storage components.
>>>
>>>          In many cases these devices are expected to operate
>>>          autonomously, as continuous communications for the purposes of
>>>          remote control is either impossible or would result in
>> excessive
>>>          power consumption.  Non continuous polling requires the
>> ability
>>>          to store and access later the information collected while the
>>>          communication was not possible.
>>>
>>>          Target Devices:  Remote network devices (mobile network) that
>>>          consume and produce energy
>>>
>>>          How Powered: Can be battery powered or using natural energy
>>>          sources
>>>
>>>          Reporting: Devices report their power usage but only
>>>          occasionally.
>>>
>>>
>>>       2.14. Demand/Response
>>>
>>>          Demand/Response from the utility or grid is a common theme
>> that
>>>          spans across some of the use cases. In some situations, in
>>>          response to time-of-day fluctuation of energy costs or sudden
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 17]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          energy shortages due power outages, it may be important to
>>>          respond and reduce the energy consumption of the network.
>>>          From EMAN use case perspective, the demand/response scenario
>> can
>>>          apply to a Data Center or a Building or a residential home. As
>> a
>>>          first step, it may be important to monitor the energy
>>>          consumption in real-time of a Data center or a building or
>> home
>>>          which is already discussed in the previous use cases. Then
>> based
>>>          on the potential energy shortfall, the Energy Management
>> System
>>>          (EMS) could formulate a suitable response, i.e., the EMS could
>>>          shut down some selected devices that may be considered
>>>          discretionary or uniformly reduce the power supplied to all
>>>          devices. For multi-site data centers it may be possible to
>>>          formulate policies such as follow-the-moon type of approach,
>> by
>>>          scheduling the mobility of VMs across Data centers in
>> different
>>>          geographical locations.
>>          Target Devices:  ...
>>
>>          How Powered: ...
>>
>>          Reporting: ...
>>>       2.15. Power Capping
>>>
>>>          Power capping is a technique to limit the total power
>>>          consumption of a server. This technique can be useful for
>> power
>>>          limited data centers. Based on workload measurements, the
>> server
>>>          can choose the optimal power state of the server in terms of
>>>          performance and power consumption. When the server operates at
>>>          less than the power supply capacity, it runs at full speed.
>> When
>>>          the server power would be greater than the power supply
>>>          capacity, it runs at a slower speed so that its power
>>>          consumption matches the available power supply capacity. This
>>>          gives vendors the option to use smaller, cost-effective power
>>>          supplies that allow real world workloads to run at nominal
>>>          frequency.
>> power caping is something that could be done in a management app using
>> the EMAN Mib.  E.g., when polling for current usage, if this crosses a
>> powercap use EMAN Mib to set the power state to a lower level.
>>
>>          Target Devices:  ...
>>
>>          How Powered: ...
>>
>>          Reporting: ...
>>>
>>>
>>>
>>>
>>>       3. Use Case Patterns
>> You have in the introduction somewhere what the section contains.
>> Because, reading that far, I was not obvious that you wanted to
>> summarize the different patterns in section 3.
>> If the intro had mentioned it, I would have the text with that in mind.
>>>          The use cases presented above can be abstracted to the
>> following
>>>          broad patterns.
>>>
>>>       3.1. Metering
>>>
>>>          -energy objects which have capability for internal metering
>> add a space
>>>          - electrical devices which are metered by an external device
>>>
>>>
>>>
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 18]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>       3.2. Metering and Control
>>>
>>>          - entities objects that do not supply power, butcan perform
>> only
>> butcan ->  but can
>>>          power metering for other devices
>> entity object ->  energy objects
>> (multiple instances of this issue)
>>>          - entities objects that do not supply power, can perform both
>>>       metering and control for other devices
>>>
>>>
>>>       3.3. Power Supply, Metering and Control
>>>
>>>          - entities devices that supply power for other devices but do
>>>          not perform power metering for those devices
>>>
>>>          - entities that supply power for other devices and also
>> perform
>>>          power metering
>>>
>>>          - entities supply power for other devices and also perform
>> power
>>>          metering and control for other devices
>>>
>>>
>>>
>>>       3.4. Multiple power sources
>>>
>>>          - entities that have multiple power sources and metering and
>>>          control is performed by one source
>>>
>>>          - entities that have multiple power sources and metering is
>>>          performed by one source and control another source
>> Thinking some more about this section 3, aren't we covering all the
>> possible combinations of relationships from [EMAN-FMWK]?
>> Any gaps?
>>>
>>>
>>>       4. Relationship of EMAN to other Standards
>>>
>>>          EMAN as a framework is tied to other standards and efforts
>> that
>>>          deal with energy. Existing standards are leveraged when
>>>          possible.  EMAN helps enable adjacent technologies such as
>> Smart
>>>          Grid.
>>>
>>>          The standards most relevant and applicable to EMAN are listed
>>>          below with a brief description of their objectives, the
>> current
>>>          state and how that standard can be applied to EMAN.
>> "how that standard can be applied to EMAN."  I don't think it's the
>> goal.
>> We want to explain the relationship/connection with EMAN
>>>
>>>
>>>
>>>
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 19]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>       4.1. Data Model and Reporting
>>>
>>>       4.1.1. IEC - CIM
>>>
>>>          The International Electro-technical Commission (IEC) has
>>>          developed a broad set of standards for power management.
>> Among
>>>          these, the most applicable to EMAN is IEC 61850,a standard for
>>>          the design of electric utility automation.  The abstract data
>>>          model defined in 61850 is built upon and extends the Common
>>>          Information Model (CIM). The complete 61850 CIM model includes
>>>          over a hundred object classes and is widely used by utilities
>>>          worldwide.
>>>
>>>          This set of standards was originally conceived to automate
>>>          control of a substation (facilities which transfer electricity
>>>          from the transmission to the distribution system). While the
>>>          original domain of 61850 is substation automation, the
>> extensive
>>>          data model has been widely used in other domains, including
>>>          Energy Management Systems (EMS).
>>>
>>>          IEC TC57 WG19 is an ongoing working group to harmonize the CIM
>>>          data model and 61850 standards.
>>>
>>>          Concepts from IEC Standards have been reused in the EMAN WG
>>>          drafts. In particular, AC Power Quality measurements have been
>>>          reused from IEC 61850-7-4. The concept of Accuracy Classes for
>>>          measurement of power and energy has been reused IEC 62053-21
>> and
>>>          IEC 62053-22.
>> Is this inline with what you wrote before "The EMAN standard references
>> ANSI C12 accuracy classes."?
>>>       4.1.2. DMTF
>>>
>>>          The Distributed Management Task Force (DMTF)[DMTF] has
>>>          standardized management solutions for managing servers and
>> PCs,
>>>          including power-state configuration and management of elements
>>>          in a heterogeneous environment.  These specifications provide
>>>          physical, logical and virtual system management requirements
>> for
>>>          power-state control.
>>>
>>>          The EMAN standard references the DMTF Power Profile and Power
>>>          State Series.
>>>
>>>       4.1.2.1. Common Information Model Profiles
>>>
>>>          The DMTF uses CIM-based (Common Information Model) 'Profiles'
>> to
>>>          represent and manage power utilization and configuration of
>>>          managed elements (note that this is not the 61850 CIM).  Key
>>>          profiles for energy management are 'Power Supply' (DSP 1015),
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 20]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          'Power State' (DSP 1027) and 'Power Utilization Management'
>> (DSP
>>>          1085).These profiles define monitoring and configuration of a
>>>          Power Managed Element's static and dynamic power saving modes,
>>>          power allocation limits and power states, among other
>> features.
>>>          Reduced power modes can be established as static or dynamic.
>>>          Static modes are fixed policies that limit power use or
>>>          utilization. Dynamic power saving modes rely upon internal
>>>          feedback to control power consumption.
>>>
>>>          Power states are eight named operational and non operational
>>>          levels.  These are On, Sleep-Light, Sleep-Deep, Hibernate,
>> Off-
>>>          Soft, and Off-Hard.  Power change capabilities provide
>>>          immediate, timed interval, and graceful transitions between
>> on,
>>>          off, and reset power states.  Table 3 of the Power State
>> Profile
>>>          defines the correspondence between the ACPI and DMTF power
>> state
>>>          models, although it is not necessary for a managed element to
>>>          support ACPI. Optionally, a TransitingToPowerState property
>> can
>>>          represent power state transitions in progress.
>>>
>>>       4.1.2.2. DASH
>> We need references for all entries in 4.*
>>>          DMTF DASH (DSP0232) (Desktop And Mobile Architecture for
>> System
>>>          Hardware) addresses managing heterogeneous desktop and mobile
>>>          systems (including power) via in-band and out-of-band
>>>          communications.  DASH provides management and control of
>> managed
>>>          elements like power, CPU, etc. using the DMTF's WS-Management
>>>          web services and CIM data model.
>>>
>>>          Both in service and out-of-service systems can be managed with
>>>          the DASH specification in a fully secured remote environment.
>>>          Full power lifecycle management is possible using out-of-band
>>>          management.
>> Question: what is the relationship with EMAN. If none, mentions it along
>>
>> with a list of pros/cons. I mean: why should an implementator chose EMAN
>>
>> versus DASH?
>>>       4.1.3. ODVA
>>>
>>>          The Open DeviceNet Vendors Association (ODVA) is an
>> association
>>>          for industrial automation companies and defines the Common
>>>          Industrial Protocol (CIP). Within ODVA, there is a special
>>>          interest group focused on energy.
>>>
>>>          There are many similar concepts between the ODVA and EMAN
>>>          frameworks towards monitoring and management of energy aware
>>>          devices. In particular, one of the concepts being considered
>>>          different energy meters based on if the device consumes
>>>          electricity or produces electricity or a passive device.
>> Express that the concept has been reused from ODVA since some ODVA
>> members were involved in the WG.
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 21]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          The Open DeviceNet Vendors Association (ODVA) is developing an
>>>          energy management framework for the industrial sector.  There
>>>          are synergies between the ODVA and EMAN approaches to energy
>>>          management.
>> move that paragraph one place up
>>>          ODVA defines a three-part approach towards energy management:
>>>          awareness of energy usage, consuming energy more efficiently,
>>>          and exchanging energy with the utility or others. Energy
>>>          monitoring and management promote efficient consumption and
>>>          enable automating actions that reduce energy consumption.
>>>
>>>          The foundation of the approach is the information and
>>>          communication model for entities. An entity is a network-
>>>          connected, energy-aware device that has the ability to either
>>>          measure or derive its energy usage based on its native
>>>          consumption or generation of energy, or report a nominal or
>>>          static energy value.
>>>
>>>
>>>
>>>       4.1.4. Ecma SDC
>> Ecma stands for?
>>>          The Ecma International committee on Smart Data Centre
>> (TC38-TG2
>>>          SDC [Ecma-SDC]) is in the process of defining semantics for
>>>          management of entities in a data center such as servers,
>>>          storage, and network equipment.  It covers energy as one of
>> many
>>>          functional resources or attributes of systems for monitoring
>> and
>>>          control. It only defines messages and properties, and does not
>>>          reference any specific protocol. Its goal is to enable
>>>          interoperability of such protocols as SNMP, BACNET, and HTTP
>> by
>>>          ensuring a common semantic model across them. Four power
>> states
>>>          are defined, Off, Sleep, Idle and Active. The standard does
>> not
>>>          include actual power measurements in kWor kWh.
>> kWor ->  kW or
>>>          The 14th draft of SDC process was published in March 2011 and
>>>          the development of the standard is still underway. When used
>>>          with EMAN, the SDC standard will provide a thin abstraction on
>>>          top of the more detailed data model available in EMAN.
>>>
>>>       4.1.5. IEEE-ISTO Printer Working Group (PWG)
>>>
>>>
>>>          The IEEE-ISTO Printer Working Group (PWG) defines SNMP MIB
>>>          modules for printer management and has recently defined a "PWG
>>>          Power Management Model for Imaging Systems v1.0" [PWG5106.4]
>> and
>>>          a companion SNMP binding in the "PWG Imaging System Power MIB
>>>          v1.0" [PWG5106.5].  This PWG model and MIB are harmonized with
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 22]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement        October 2011
>>>
>>>          the DMTF CIM Infrastructure [DSP0004] and DMTF CIM Power State
>>>          Management Profile [DSP1027] for power states and alerts.
>>>
>>>
>>>          The PWG would like its MIBs to be harmonized as closely as
>>>          possible with those from EMAN.  The PWG covers many topics in
>>>          greater detail than EMAN, as well as some that are specific to
>>>          imaging equipment.  The PWG also provides for vendor-specific
>>>          extension states (i.e., beyond the standard DMTF CIM states.)
>>>
>>>
>>>
>>>       4.1.6. ASHRAE
>>>
>>>          In the U.S., there is an extensive effort to coordinate and
>>>          develop standards related to the "Smart Grid".  The Smart Grid
>>>          Interoperability Panel, coordinated by the government's
>> National
>>>          Institute of Standards and Technology, identified the need for
>> a
>>>          building side information model (as a counterpart to utility
>>>          models) and specified this in Priority Action Plan (PAP) 17.
>>>          This was designated to be a joint effort by American Society
>> of
>>>          Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE)
>>>          and National Electrical Manufacturers Association (NEMA), both
>>>          ANSI approved SDO's.  The result is to be an information
>> model,
>>>          not a device level monitoring protocol.
>>>
>>>          The ASHRAE effort addresses data used only within a building
>> as
>>>          well as data that may be shared with the grid, particularly as
>>>          it relates to coordinating future demand levels with the needs
>>>          of the grid.  The model is intended to be applied to any
>>>          building type, both residential and commercial.  It is
>> expected
>>>          that existing protocols will be adapted to comply with the new
>>>          information model, as would any new protocols.
>>>
>>>          There are four basic types of entities in the model:
>> generators,
>>>          loads, meters, and energy managers.
>>>
>>>          The metering part of this model overlaps with the EMAN
>> framework
>>>          to a large degree, though there are features unique to each.
>>>          The load part speaks to control capabilities well beyond what
>>>          EMAN covers.  Details of generation and of the energy
>> management
>>>          function are outside of EMAN scope.
>>>
>>>          A public review draft of the ASHRAE standard is expected soon,
>>>          and at that point detailed comparison of the two models can be
>>>          made.  There are no apparent major conflicts between the two
>>>          approaches, but there are likely areas where some
>> harmonization
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 23]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          is possible, and regardless, a description of the
>>>          correspondences would be helpful to create.
>>>
>>>
>>>       4.1.7. ZigBee
>>>
>>>          The Zigbee Smart Energy 2.0 effort[ZIGBEE] focuses on wireless
>>>          communication to appliances and lighting.  It is intended to
>>>          enable building energy management and enable direct load
>> control
>>>          by utilities.
>>>
>>>          ZigBee protocols are intended for use in embedded applications
>>>          requiring low data rates and low power consumption. ZigBee
>>>          defines a general-purpose, inexpensive, self-organizing mesh
>>>          network that can be used for industrial control, embedded
>>>          sensing, medical data collection, smoke and intruder warning,
>>>          building automation, home automation, etc.
>>>
>>>          Zigbee is currently not an ANSI recognized SDO.
>>>
>>>          The EMAN framework addresses the needs of IP-enabled networks
>>>          through the usage of SNMP, while Zigbee looks for completely
>>>          integrated and inexpensive mesh solution.
>> Zigbee Smart Energy 2.0 is based on IP, right? This should be stressed.
>>>       4.2. Measurement
>>>
>>>
>>>       4.2.1. ANSI C12
>>>
>>>          The American National Standards Institute (ANSI) has defined a
>>>          collection of power meter standards under ANSI C12.  The
>> primary
>>>          standards include communication protocols (C12.18, 21 and 22),
>>>          data and schema definitions (C12.19), and measurement accuracy
>>>          (C12.20). European equivalent standards are provided by IEC
>>>          62053-22.ANSI C12.20 defines accuracy classes for watt-hour
>>>          meters.
>>>
>>>          All of these standards are oriented toward the meter itself,
>> and
>>>          are therefore very specific and used by electricity
>> distributors
>>>          and producers.
>>>
>>>          The EMAN standard references ANSI C12 accuracy classes.
>>>
>>>       4.2.2. IEC62301
>>>
>>>          IEC 62301, "Household electrical appliances  Measurement of
>>>          standby power", specifies a power level measurement procedure.
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 24]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          While nominally for appliances and low-power modes, many
>> aspects
>>>          of it apply to other device types and modes and it is commonly
>>>          referenced in test procedures for energy using products.
>>>
>>>          While the standard is intended for laboratory measurements of
>>>          devices in controlled conditions, many aspects of it are
>>>          informative to those implementing measurement in products that
>>>          ultimately report via EMAN.
>>>
>>>
>>>
>>>
>>>       4.3. Other
>>>
>>>       4.3.1. ISO
>>>
>>>          The ISO [ISO] is developing an energy management standard, ISO
>>>          50001, to complement ISO 9001 for quality management, and ISO
>>>          14001 for environment management. The intent of the framework
>> is
>>>          to facilitate the creation of energy management programs for
>>>          industrial, commercial and other entities.  The standard
>> defines
>>>          a process for energy management at an organization level.  It
>>>          does not define the way in which devices report energy and
>>>          consume energy.
>>>
>>>          EMAN is complementary to ISO 9001.
>> move that paragraph at the end of hte section
>>>          ISO 50001 is based on the common elements found in all of
>> ISO's
>>>          management system standards, assuring a high level of
>>>          compatibility with ISO 9001 (quality management) and ISO 14001
>>>          (environmental management). ISO 50001 benefits includes:
>>>
>>>         o Integrating energy efficiency into management practices and
>>>            throughout the supply chain
>>>         o Energy management best practices and good energy management
>>>            behaviors
>>>         o benchmarking, measuring, documenting, and reporting energy
>>>            intensity improvements and their projected impact on
>>>            reductions in greenhouse gas (GHG) emissions
>>>         o Evaluating and prioritizing the implementation of new energy-
>>>            efficient technologies
>>>
>>>          ISO 50001 has been developed by ISO project committee ISO/PC
>>>          242, Energy management.
>>>
>>>
>>>
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 25]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>       4.3.2. EnergyStar
>>>
>>>          The US Environmental Protection Agency (EPA) and US Department
>>>          of Energy (DOE) jointly sponsor the Energy Star program
>> [ESTAR].
>>>          The program promotes the development of energy efficient
>>>          products and practices.
>>>
>>>          To qualify as Energy Star, products must meet specific energy
>>>          efficiency targets. The Energy Star program also provides
>>>          planning tools and technical documentation to encourage more
>>>          energy efficient building design. Energy Star is a program; it
>>>          is not a protocol or standard.
>>>
>>>          For businesses and data centers, Energy Star offers technical
>>>          support to help companies establish energy conservation
>>>          practices.  Energy Star provides best practices for measuring
>>>          current energy performance, goal setting, and tracking
>>>          improvement.  The Energy Star tools offered include a rating
>>>          system for building performance and comparative benchmarks.
>>>
>>>          There is no immediate link between EMAN and EnergyStar, one
>>>          being a protocol and the other a set of recommendations to
>>>          develop energy efficient products.  However, Energy Star could
>>>          include EMAN standards in specifications for future products,
>>>          either as required or rewarded with some benefit.
>>>
>>>       4.3.3. SmartGrid
>>>
>>>          The Smart Grid standards efforts underway in the United States
>>>          are overseen by the US National Institute of Standards and
>>>          Technology [NIST].NIST is responsible for coordinating a
>> public-
>> insert space
>>>          private partnership with key energy and consumer stakeholders
>> in
>>>          order to facilitate the development of smart grid standards.
>> The
>>>          NIST smart grid standards activities are monitored and
>>>          facilitated by the SGIP (Smart Grid Interoperability Panel).
>>>          This group has working groups for specific topics including
>>>          homes, commercial buildings, and industrial facilities as they
>>>          relate to the grid.
>>>
>>>          When a working group detects a standard or technology gap, the
>>>          team seeks approval from the SGIP for the creation of a
>> Priority
>>>          Action Plan (PAP), a private-public partnership to close the
>>>          gap.  There are currently 17 PAPs.  PAP 17 is discussed in
>>>          section 4.1.6.
>>>
>>>          PAP 10 addresses "Standard Energy Usage Information".
>>>
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 26]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>          Smart Grid standards will provide distributed intelligence in
>>>          the network and allow enhanced load shedding.  For example,
>>>          pricing signals will enable selective shutdown of non critical
>>>          activities during peak-load pricing periods.  These actions
>> can
>>>          be effected through both centralized and distributed
>> management
>>>          controls.
>>>
>>>          There is an obvious functional link between SmartGrid and EMAN
>>>          in the form of demand response, even if the EMAN framework
>> does
>>>          not take any specific step toward SmartGrid communication.
>>>
>> "However, the EMAN framework, with its Energy Object Power State
>> control, offers a solution for the smart grid demand/response use case"
>>
>>>       5. Limitations
>>>
>>>          EMAN Framework shall address the needs of energy monitoring in
>> shall address ->  addresses
>>
>> Regards, Benoit.
>>>          terms of measurement and, considers limited control
>> capabilities
>>>          of energy monitoring of networks.
>>>
>>>          EMAN does not create a new protocol stack, but rather defines
>> a
>>>          data and information model useful for measuring and reporting
>>>          energy and other metrics over SNMP.
>>>
>>>          The EMAN framework does not address questions regarding
>>>          SmartGrid, electricity producers, and distributors even if
>> there
>>>          is obvious link between them.
>>>
>>>       6. Security Considerations
>>>
>>>          EMAN shall use SNMP protocol for energy monitoring and thus
>> has
>>>          the functionality of SNMP's security capabilities. SNMPv3
>>>          [RFC3411] provides important security features such as
>>>          confidentiality, integrity, and authentication.
>>>
>>>       7. IANA Considerations
>>>
>>>          This memo includes no request to IANA.
>>>
>>>       8. Acknowledgements
>>>
>>>          The authors would like to thank Jeff Wheeler, Benoit Claise,
>>>          Juergen Quittek, Chris Verges, John Parello, and Matt Laherty,
>>>          for their valuable contributions.
>>>
>>>          The authors would like to thank Georgios Karagiannis for use
>>>          case involving energy neutral homes, Elwyn Davies for off-grid
>>>          electricity systems, and Kerry Lynn for the comment on the
>>>          Demand/Response scenario.
>>>
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 27]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>       9. Open Issues
>>>
>>>          "EDITOR NOTE: use the latest definition from
>> draft-parello-eman-
>>>          definitions"
>>>
>>>          OPEN ISSUE 1: Relevant IEC standards for application for EMAN
>>>            Applicability Statement document can provide guidance on the
>>>            issue of what is appropriate standard used by EMAN
>>>
>>>            IEC 61850-7-4 has been extensively used in EMAN WG
>> documents.
>>>            The other IEC documents referred for possible use are IEC
>>>            61000-4-30, IEC 62053-21 and IEC 62301.
>>>
>>>            There is feedback that IEC 61850-7-4 applies only to sub-
>>>            stations ?
>>>
>>>
>>>
>>>          OPEN ISSUE 2: Should review ASHRAE SPC 201P standard when it
>> is
>>>          released for public review
>>>
>>>            . Need to review ASHRAE information model and the use cases
>>>               and how it relates to EMAN
>>>
>>>
>>>
>>>          OPEN ISSUE 3: Review ALL requirements to ensure that they can
>> be
>>>          traced to a use case
>>>            . Missing is an use case for power quality
>>>
>>>          OPEN ISSUE 4: Question for the WG. Should we have unique use
>>>          cases that introduce specific requirements ? or can there be
>>>          some overlap between use cases ?
>>>
>>>          Any use cases out of scope scenarios ?
>>>
>>>
>>>
>>>       10. References
>>>
>>>       10.1. Normative References
>>>
>>>          [RFC3411] An Architecture for Describing Simple Network
>>>                  Management Protocol (SNMP) Management Frameworks, RFC
>>>                  3411, December 2002.
>>>
>>>
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 28]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>       10.2. Informative References
>>>
>>>
>>>          [DASH] "Desktop and mobile Architecture for System Hardware",
>>>                  http://www.dmtf.org/standards/mgmt/dash/
>>>
>>>          [NIST]  http://www.nist.gov/smartgrid/
>>>
>>>          [Ecma-SDC] Ecma TC38 / SDC Task Group, "Smart Data Centre
>>>                  Resource Monitoring and Control (DRAFT)", March 2011.
>>>
>>>          [ENERGY] http://en.wikipedia.org/wiki/Kilowatt_hour
>>>
>>>          [EMAN-AS] Tychon, E., B. Schoening,MouliChandramouli, Bruce
>>>                  Nordman, "Energy Management (EMAN) Applicability
>>>                  Statement", draft-tychon-eman-applicability-statement-
>>>                  04.txt, work in progress, October 2011.
>>>
>>>          [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and
>>>                  M. Chandramouli, "Requirements for Energy Management
>> ",
>>>                  draft-ietf-eman-requirements-04 (work in
>> progress),July
>>>                  2011.
>>>
>>>          [EMAN-MONITORING-MIB] M. Chandramouli, Schoening, B., Dietz,
>> T.,
>>>                  Quittek, J. and B. Claise  "Energy and Power
>> Monitoring
>>>                  MIB ", draft-ietf-eman-monitoring-mib-00,August 2011.
>>>
>>>          [EMAN-AWARE-MIB] J. Parello, and B. Claise, "draft-ietf-eman-
>>>                  energy-aware-mib-02", work in progress, July 2011.
>>>
>>>          [EMAN-FRAMEWORK] Claise, B., Parello, J., Schoening, B., and
>> J.
>>>                  Quittek, "Energy Management Framework", draft-ietf-
>>>                  eman-framework-02 ,July 2011.
>>>
>>>          [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz,
>>>                  "Definition of Managed Objects for Battery Monitoring"
>>>                  draft-ietf-eman-battery-mib-02.txt, July 2011.
>>>
>>>          [EMAN-DEF] J. Parello"Energy Management Terminology", draft-
>>>                  parello-eman-definitions-03
>>>
>>>          [DMTF] "Power State Management ProfileDMTFDSP1027  Version
>> 2.0"
>>>                  December2009.
>>>
>> http://www.dmtf.org/sites/default/files/standards/docum
>>>                  ents/DSP1027_2.0.0.pdf
>>>
>>>          [ESTAR]  http://www.energystar.gov/
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 29]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>
>>>          [ISO]    http://www.iso.org/iso/pressrelease.htm?refid=Ref1434
>>>
>>>          [SGRID]  http://collaborate.nist.gov/twiki-
>>>
>> sggrid/bin/view/SmartGrid/SGIPWorkingGroupsAndCommittee
>>>                  s
>>>
>>>
>>>          [ASHRAE] http://collaborate.nist.gov/twiki-
>>>                  sggrid/bin/view/SmartGrid/PAP17Information
>>>
>>>          [PAP17] http://collaborate.nist.gov/twiki-
>>>
>> sggrid/bin/view/SmartGrid/PAP17FacilitySmartGridInforma
>>>                  tionStandard
>>>
>>>          [ZIGBEE] http://www.zigbee.org/
>>>
>>>          [ISO]  http://www.iso.org/iso/pressrelease.htm?refid=Ref1337
>>>
>>>          [DSP0004] DMTF Common Information Model (CIM) Infrastructure,
>>>                  DSP0004, May 2009.
>>>
>> http://www.dmtf.org/standards/published_documents/DSP00
>>>                  04_2.5.0.pdf
>>>
>>>          [DSP1027] DMTF Power State Management Profile, DSP1027,
>> December
>>>                  2009.
>>>
>> http://www.dmtf.org/standards/published_documents/DSP10
>>>                  27_2.0.0.pdf
>>>
>>>          [PWG5106.4]IEEE-ISTO PWG Power Management Model for Imaging
>>>                  Systems v1.0, PWG Candidate Standard 5106.4-2011,
>>>                  February 2011.ftp://ftp.pwg.org/pub/pwg/candidates/cs-
>>>                  wimspower10-20110214-5106.4.mib
>>>
>>>          [PWG5106.5] IEEE-ISTO PWG Imaging System Power MIB v1.0, PWG
>>>                  Candidate Standard 5106.5-2011, February 2011.
>>>
>>>          [IEC62301] International Electrotechnical Commission, "IEC
>> 62301
>>>                  Household electrical appliances  Measurement of
>> standby
>>>                  power", Edition 2.0, 2011.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 30]
>>>
>>>
>>      Internet-Draft     EMAN Applicability Statement       October 2011
>>>
>>>
>>>
>>>       Authors' Addresses
>>>
>>>          Emmanuel Tychon
>>>          Cisco Systems, Inc.
>>>          De Keleetlaan, 6A
>>>          B1831 Diegem
>>>          Belgium
>>>          Email: [email-masked]
>>>
>>>
>>>          Brad Schoening
>>>          44 Rivers Edge Drive
>>>          Little Silver, NJ 07739
>>>          USA
>>>          Email:[email-masked]
>>>
>>>
>>>          MouliChandramouli
>>>          Cisco Systems, Inc.
>>>          Sarjapur Outer Ring Road
>>>          Bangalore,
>>>          India
>>>          Phone: +91 80 4426 3947
>>>          Email: [email-masked]
>>>
>>>
>>>          Bruce Nordman
>>>          Lawrence Berkeley National Laboratory
>>>          1 Cyclotron Road, 90-4000
>>>          Berkeley  94720-8136
>>>          USA
>>>
>>>          Phone: +1 510 486 7089
>>>          Email: [email-masked]
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> <Tychon, et al.>              Expires April 31, 2012        [Page 31]
>>>
>>>
>>>
>
>