Subject: [eman] draft-tychon-eman-applicability-statement-01.txt

From: Benoit Claise <[email-masked]>
Date: Tue, 22 Mar 2011 18:23:23 +0100

Dear draft-tychon-eman-applicability-statement-01 authors,

Thanks for your draft.

In preparation for our EMAN WG next week, I've reviewed the draft, 
specifically in light of the charter

    6. Applicability statement
    The EMAN WG will develop an applicability statement, describing the
    variety of applications that can use the energy framework and associated
    MIB modules. Potential examples are building networks, home energy
    gateway, etc. Finally, the document will also discuss _relationships _of
    the framework to other architectures and frameworks (such as smartgrid).
    The applicability statement will explain the _relationship _between the
    work in this WG and the other existing standards such as those from the
    IEC, ANSI, DMTF, and others.

First of, as mentioned in 
http://www.ietf.org/mail-archive/web/eman/current/msg00407.html, 
IEEE/ISTO Printer Working Group and ODVA should be mentioned.
Second, there are still a few valid points at: 
http://www.ietf.org/mail-archive/web/eman/current/msg00101.html
>
>      Energy Management Working Group                               E. 
> Tychon
>      Internet Draft                                               M. 
> Laherty
>      Intended status: Informational                      Cisco 
> Systems, Inc.
>      Expires: September 15, 2011                                B. 
> Schoening
>                                                       Independent 
> Consultant
>
>                                                               March 
> 15, 2011
>
>
>
>
>                   Energy Management (EMAN) Applicability Statement
>                   draft-tychon-eman-applicability-statement-01.txt
>
>
>      Status of this Memo
>
>         This Internet-Draft is submitted in full conformance with the
>         provisions of BCP 78 and BCP 79.
>
>         This Internet-Draft is submitted in full conformance with the
>         provisions of BCP 78 and BCP 79. This document may not be 
> modified,
>         and derivative works of it may not be created, and it may not be
>         published except as an Internet-Draft.
>
>         This Internet-Draft is submitted in full conformance with the
>         provisions of BCP 78 and BCP 79. This document may not be 
> modified,
>         and derivative works of it may not be created, except to 
> publish it
>         as an RFC and to translate it into languages other than English.
>
>         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 September 15, 2011.
>
>
>
>
> <Tychon, et Al.>       Expires September 15, 2011               [Page 1]
>
>
>      Internet-Draft       EMAN Applicability Statement            
> March 2011
>
>
>      Copyright Notice
>
>         Copyright (c) 2011 IETF Trust and the persons identified as the
>         document authors. All rights reserved.
>
>         This document is subject to BCP 78 and the IETF Trust's Legal
>         Provisions Relating to IETF Documents
>         (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 Energy Management (EMAN) framework will work on the 
> management
A lot of sentences use the future tense. Since the applicability 
statement is the last of our series of document, you should be using the 
present. Anyway, when published, the EMAN framework and MIB modules must 
be available.
>         of energy-aware devices. In this document we describe the
In IETF draft, we don't use "we"
>         applicability of the EMAN framework for a variety of 
> applications.
>         We show how network elements and applications can use EMAN. 
What do you mean "use EMAN". The framework, the MIB module?
This is a generic statement for the draft. Sometimes, I'm not clear if 
you refer the concepts in the framework, or the MIB modules, or both.
> We
>         furthermore describe relations of the EMAN framework to other
>         architectures and frameworks.
>
>
>
>      Table of Contents
>
>         1. 
> Introduction...................................................3
>            1.1. Energy 
> Measurement........................................4
>            1.2. Energy 
> Control............................................4
>            1.3. 
> Examples..................................................5
>               1.3.1. Corporate 
> Networks...................................5
>               1.3.2. Building 
> Networks....................................5
>               1.3.3. Home Energy 
> Gateways.................................5
>               1.3.4. 
> Datacenters..........................................5
>               1.3.5. Intelligent Power 
> Strips.............................6
>         2. Relation of EMAN to Other Frameworks and 
> Technologies..........6
>            2.1. 
> IEC.......................................................6
>            2.2. 
> ISO.......................................................7
>            2.3. ANSI 
> C12..................................................7
>            2.4. 
> EnergyStar................................................8
>            2.5. 
> DMTF......................................................8
>               2.5.1. Common Information Model 
> Profiles....................9
>               2.5.2. Desktop And Mobile Architecture for System Hardware
>               
> (DASH)......................................................9
>            2.6. 
> SmartGrid.................................................9
>
>
> <Tychon, et Al.>       Expires September 15, 2011               [Page 2]
>
>
>      Internet-Draft       EMAN Applicability Statement            
> March 2011
>
>
>            2.7. NAESB, ASHRAE and 
> NEMA...................................10
>            2.8. 
> ZigBee...................................................11
>         3. 
> Limitations...................................................12
>         4. Security 
> Considerations.......................................12
>            4.1. 
> SmartGrid................................................12
>         5. IANA 
> Considerations...........................................13
>         6. 
> References....................................................13
>            6.1. Normative 
> References.....................................13
>            6.2. Informative 
> References...................................13
>         7. 
> Acknowledgments...............................................13
>
>
>
>         (Beginning of section to be removed from the final version)
>
>         TO DO
>
>
>
>         (End of section to be removed from the final version)
>
>
>
>      1. Introduction
>
>         The EMAN framework describes how energy information can be
>         retrieved, controlled and monitored from IP-enabled consumers 
> with
>         traditional methods such as Simple Network Management Protocol
>         (SNMP). In essence, the framework defines Management Information
>         Base (MIBs) for SNMP.
>
>         In this document, we describe typical applications of the EMAN
>         framework; we will show opportunities and limitations of the
>         framework. Furthermore, we describe other standards that are 
> similar
>         to EMAN but addresses different domains or users.
>
>         EMAN will enable heterogeneous energy consumers to report 
> their own
>         consumption, and to a lesser extent, external system to control
>         them. 
There is also the case, as discussed these days on the mailing list, of 
a device consumption being monitored by an another device. For example, PoE.
> There are multiple scenarios where this is desirable,
>         particularly today considering the increased importance of 
> limiting
>         consumption of finite energy resources and reducing operational
>         expenses.
>
>      1.1. EMAN Documents Overview
>
>         The EMAN working group is actively working on a series of 
> documents.
>         (TODO: list existing documents)
>
>
> <Tychon, et Al.>       Expires September 15, 2011               [Page 3]
>
>
>      Internet-Draft       EMAN Applicability Statement            
> March 2011
>
>
>
>
>      1.2. Energy Measurement
>
>         More and more devices today are able to measure and report 
> their own
>         energy consumption.
power and energy
> Smart power strips and some current generation
>         Power-over-Ethernet switches are already able to meter 
> consumption
>         of the connected devices.  However, when managed and reported
>         through proprietary means, this information is not really 
> useful at
>         the enterprise level.
Can you expand why?
>
>         The primary goal of EMAN is to enable reporting and management
>         within a standard framework that is applicable to the wide 
> variety
>         of today's end devices, meters and proxies.
>
>         Being able to know who's consuming what, when and how at any 
> time by
what do you mean "how"?
>         leveraging existing networks, and across various equipment is one
>         pillar of the EMAN framework.
>
>      1.3. Energy Control
>
>         There are many cases where reducing energy consumption is 
> desirable,
>         such as when the demand is already high, when there's no one 
> using
>         the resource, and so on.
>
>         In some cases, you can't simply turn it off without 
> considering the
>         context. For instance you cannot turn off all phones, because 
> some
>         still need to be available in case of emergency. You can't turn
>         office cooling off totally during non-work hours, but you can 
> reduce
>         the comfort level, and so on.
>
>         In other cases, there are intermediate power levels between 
> off and
>         on, such as standby, sleep or soft-off modes [DQERM].
>
>         The EMAN framework will provide a control mechanism that is
>         generalized for all devices, power states, and allows for fine-
>         grained priority control, and emergency function.
>
>         Power control requires flexibility and support for different 
> polices
>         and mechanisms; including centralized management with a network
>         management station, autonomous management by individual 
> devices, and
>         alignment with dynamic demand-response mechanisms.
>
>
>
> <Tychon, et Al.>       Expires September 15, 2011               [Page 4]
>
>
>
>      Internet-Draft       EMAN Applicability Statement            
> March 2011
>
>
>      1.4. Examples
>
>      1.4.1. Corporate Networks
>
>         Corporate networks connect computers, printers, phones, network
>         equipment and other devices over local and wide area networks.
>         These networks are typically centrally managed and operate 24x7.
>
>         Today, no standard MIB exists for monitoring and control of 
> energy
>         in enterprise network using SNMP.
Generic statement for all the examples.
You should really explain how the EMAN framework can be applied... or not.
When I read this section 1.4.*, it seems like I read the EMAN 
requirements draft.
>
>      1.4.2. Building Networks
>
>         Buildings are big energy consumers, and companies are looking 
> into
>         ways to reduce their energy consumption, as well as to react
>         positively in case of an emergency, such as a brownout risk day.
>
>         While building networks may be IP enabled, most use older network
>         technologies including serial RS-485 and token ring technologies.
>         Within these networks, gateways may connect the building system
>         protocol to IP networks for management and control.
>
>         Air conditioning, lighting and so on can all be metered and
>         controlled using the EMAN framework. 
Coming back the previous comment. Here is _an example_ of what I believe 
is needed.
"For example, by implementing the ENERGY-AWARE MIB module on the 
aggregator and monitoring building specific devices as Power Monitor 
Children, actually acting as proxy between IP on one side and building 
management specific protocols."
> EMAN can, for instance, act as
>         a communication protocol between a presence system to 
> deactivate the
>         cooling and phones when there's no one on the floor.
>
>      1.4.3. Home Energy Gateways
>
>         Home Energy Gateways (HEG) are devices with remote metering
>         capabilities, and will let service providers and utility 
> companies
>         respond to demand by varying pricing according to time of usage.
>
>         The HEG itself may use specific protocols, but using the EMAN
>         framework, 
same comment again.
> it will be able to report usage, pricing or other
>         indicators to the user using SNMP. Using a simple application 
> on its
>         home network, the consumer is now empowered to see and decide 
> how to
>         use energy.
>
>      1.4.4. Datacenters
>
>         Datacenters too are big energy consumers. All that equipment
>         generates heat, and heat needs to be evacuated though a HVAC
>         (Heating, Ventilating, and Air Conditioning) system. 
> Controlling the
>         datacenter consumption means slowing down or turning off 
> equipment
>         and cooling.
>
>
> <Tychon, et Al.>       Expires September 15, 2011               [Page 5]
>
>
>      Internet-Draft       EMAN Applicability Statement            
> March 2011
>
>
>         The EMAN framework will enable a new level of control by 
> providing a
>         unified means of communication between heterogeneous devices 
> over a
>         network.
>
>      1.4.5. Intelligent Power Strips
>
>         Intelligent Power Strips are power distribution units with IP
>         communication capability to remotely enable / disable a 
> particular
>         outlet, and often have the ability to measure power 
> consumption for
>         each outlet.
>
>         These devices are currently supporting either their own 
> proprietary
>         protocol or a proprietary SNMP MIB, but EMAN will provide a 
> uniform
>         framework designed for power control and monitoring for all 
> vendors.
How?
Do we have to give specific example of the outlet gang and dual power 
supplies case here?
>
>      2. Relation of EMAN to Other Frameworks and Technologies
>
>         EMAN as a framework is tied with other standards and efforts 
> in the
>         area. We will try to re-use existing standards as much as 
> possible,
>         as well as providing control to adjacent technologies such as 
> Smart
>         Grid.
>
>         We have listed most of them with a brief description of their
>         objectives and the current state. 
For most the section 2.X, I miss the relationship to EMAN.
>
>      2.1. IEC
>
>         The International Electrotechnical Commission (IEC) has 
> developed a
>         broad set of standards for power management.  Among these, the 
> most
>         applicable to our purposes 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 in the US and worldwide
>
>         This set of standards was originally conceived to automate 
> control
>         of a substation. An electrical substation is a subsidiary 
> station of
>         an electricity generation, transmission and distribution system
>         where voltage is transformed from high to low or the reverse 
> using
>         transformers. While the original domain of 61850 is substation
>         automation, the extensive model that resulted has been widely 
> used
>         in other areas, including Energy Management Systems (EMS) and 
> forms
>         the core of many Smart Grid standards.
>
>         IEC TC57 WG19 is an ongoing working group to harmonize the CIM 
> data
>         model and 61850 standards.
What about the IEC61968?
Is there a relationship to EMAN?
>
>
>
> <Tychon, et Al.>       Expires September 15, 2011               [Page 6]
>
>
>
>      Internet-Draft       EMAN Applicability Statement            
> March 2011
>
>
>         With its broad installed base and foundational data model for 
> recent
>         smart grid efforts, it's highly advisable that the EMON model 
> reuse
>         as much as possible from the IEC standards.
Done already in 
http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-07.
Btw, EMON = EMAN? ;-)
>
>      2.2. ISO
>
>         The ISO is developing an energy management standard called ISO
>         50001.  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 is not expected to define the way in
>         which devices report energy and consume energy. The IETF effort
>         would be complementary.
Good.
This is the type of information we need in this draft.
>
>         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 will include
>
>        - Integrating energy efficiency into management practices and
>           throughout the supply chain.
>        - Energy management best practices and good energy management
>           behaviors
>        - benchmarking, measuring, documenting, and reporting energy
>           intensity improvements and their projected impact on 
> reductions in
>           greenhouse gas (GHG) emissions
>        - Evaluating and prioritizing the implementation of new energy-
>           efficient technologies
>
>        ISO 50001 is being developed by ISO project committee ISO/PC 242,
>        Energy management and is expected to be published as an 
> International
>        Standard by 2011.
>
>         http://www.iso.org/iso/pressrelease.htm?refid=Ref1337
>
>      2.3. 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 the IEC.
>
>
>
>
> <Tychon, et Al.>       Expires September 15, 2011               [Page 7]
>
>
>      Internet-Draft       EMAN Applicability Statement            
> March 2011
>
>
>         ANSI C12.20 defines accuracy classes for watt-hour meters.  
> Typical
>         accuracy classes are class 0.5, class 1, and class 3; which
>         correspond to +/- 0.5%, +/- 1% and +/- 3% accuracy thresholds.
>
>         All of these standards are oriented toward the meter itself, 
> and are
>         therefore very specific and used by electricity distributors and
>         producers.
>
>         The EMON standard should be compatible with existing ANSI C.12
>         standards.
EMAN?
>
>      2.4. EnergyStar
>
>         The US Environmental Protection Agency (EPA) and US Department of
>         Energy (DOE) jointly sponsor the Energy Star program.  The 
> program
>         promotes the development of energy efficient products and 
> practices.
>
>         To earn Energy Star approval, appliances in the home or business
>         must meet specific energy efficiency targets.  The Energy Star
>         program also provides planning tools and technical 
> documentation to
>         help homeowners design more energy efficient homes. Energy 
> Star is a
>         program; it's 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.
>
>         http://www.energystar.gov/index.cfm?c=about.ab_history
>
>      2.5. DMTF
>
>         The DMTF has standardized management solutions for 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.
>
>         Through various Working Group efforts these specifications 
> continue
>         to evolve and advance in features and functionalities.  The full
>         specifications can be found at the DMTF web site:
>
>         http://www.dmtf.org
>
>
>
> <Tychon, et Al.>       Expires September 15, 2011               [Page 8]
>
>
>      Internet-Draft       EMAN Applicability Statement            
> March 2011
>
>
>      2.5.1. Common Information Model Profiles
>
>         The DMTF uses CIM-based (Common Information Model) 'Profiles' to
>         represent and manage power utilization and configuration of a
>         managed element.  The key profiles are 'Power Supply' (DSP 1015),
>         '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.
>
>         Power saving modes can be established as static or dynamic.  
> Static
>         modes are fixed policies that limit power to a utilization or
>         wattage limit.  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.
that's a good description, but what's the relationship to EMAN
>
>      2.5.2. Desktop And Mobile Architecture for System Hardware (DASH)
>
>         DMTF DASH (DSP0232) has addressed the challenges of managing
>         heterogeneous desktop and mobile systems (including power) via 
> in-
>         band and out-of-band environments.  Utilizing the DMTF's WS-
>         Management web services and the CIM data model, DASH provides
>         management and control of managed elements like power, CPU etc.
>
>         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.
Relationship with EMAN? Can we use DASH in the EMAN framework since the 
communication between Parent and Child is out of the scope?
>
>      2.6. SmartGrid
>
>         The Smart Grid standards efforts underway in the United States 
> are
>         overseen by the US National Institute of Standards and Technology
>         [NIST].  NIST was given the charter to oversee the development of
>         smart grid related standards by the Energy Independence and 
> Security
>         Act of 2007.  NIST is responsible for coordinating a 
> public-private
>
>
>
> <Tychon, et Al.>       Expires September 15, 2011               [Page 9]
>
>      Internet-Draft       EMAN Applicability Statement            
> March 2011
>
>
>         partnership with key energy and consumer stakeholders in order to
>         facilitate the development of smart grid standards.
>
>         The smart grid standards activity (sponsored and hosted by 
> NIST) is
>         monitored and facilitated by the SGIP (Smart Grid 
> Interoperability
>         Panel).  This group has several sub groups called working groups.
>         These teams examine smaller parts of the smart grid.  They 
> include
>         B2G, I2G, and H2G and others (Building to Grid; Industrial to 
> Grid
>         and Home to Grid).
>
>         http://collaborate.nist.gov/twiki-
>         sggrid/bin/view/SmartGrid/SGIPWorkingGroupsAndCommittees
>
>         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).  The PAP is a private-public partnership with a 
> charter
>         to close a specific gap.  There are currently 17 Priority Action
>         Plans (PAP).
>
>         PAP 10 Addresses "Standard Energy Usage Information".
>
>         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.
>         Similarly, brown-outs, air quality alerts, and peak demand limits
>         can be managed through the smart grid data models, based upon IEC
>         61850.
Relationship to EMAN? We can control the IT devices to consume less when 
SmartGrid requires it.
>
>      2.7. NAESB, ASHRAE and NEMA
>
>         As an output of the PAP10's work on the standard information 
> model,
>         multiple stakeholders agreed to work on a utility centric 
> model in
>         NAESB (North American Electric Standards Board) and the building
>         side information model in a joint effort by American Society of
>         Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) 
> and
>         National Electrical Manufacturers Association (NEMA).
>
>         The NAESB effort is a NAESB REQ/WEQ.
>         http://www.naesb.org/smart_grid_PAP10.asp
>
>         The ASHRAE effort is SPC201.   http://collaborate.nist.gov/twiki-
>         sggrid/bin/view/SmartGrid/PAP17Information
>
>         The output of both ANSI approved SDO's 
Do you mean NAESB and ASHRAE?
> is an information model. 
Sometimes you speak about information model, sometimes about data model 
in this section.
Please refer to RFC3444.

> It
>         is not a device level monitoring protocol.
>
>
> <Tychon, et Al.>       Expires September 15, 2011              [Page 10]
>
>
>
>      Internet-Draft       EMAN Applicability Statement            
> March 2011
>
>
>         After the ASHRAE SPC201 group formed as a result of initial work
>         done by the PAP 10, the SGIP added PAP17 in order to focus
>         specifically on in-building standards for energy using devices.
>
>         PAP 17 "will lead to development of a data model standard to 
> enable

>         energy consuming devices and control systems in the customer
>         premises to manage electrical loads and generation sources in
>         response to communication with the Smart Grid. It will be 
> possible
>         to communicate information about those electrical loads to
>         utilities, other electrical service providers, and market 
> operators.
>
>         The term "Facility Smart Grid Information" is intended to 
> convey the
>         nature of critical information originating from the customer
>         operated "facility" which deals with the representation and 
> dynamics
>         of loads including prediction, measurement and shedding. It also
>         helps to distinguish between this PAP and that of PAP10 which 
> deals
>         exclusively with the representation of energy usage.
>
>         This data model standard will complement the flow, aggregation,
>         summary, and forecasting of energy usage information being
>         standardized by NAESB in PAP10 through the definition of 
> additional
>         distinct model components. While the NAESB standard is 
> focusing on
>         "a single limited-scope information model" that "will not 
> cover all
>         interactions associated with energy in the home or commercial 
> space"
>         including, for example, load management ("Report to the SGIP
>         Governing Board: PAP10 plan," June 15, 2010), these new 
> components
>         will address load modeling and behavior necessary to manage 
> on-site
>         generation, demand response, electrical storage, peak demand
>         management, load shedding capability estimation, and responsive
>         energy load control."
>
>         http://collaborate.nist.gov/twiki-
>         
> sggrid/bin/view/SmartGrid/PAP17FacilitySmartGridInformationStandard
>
>
>
>      2.8. ZigBee
>
>         The "Zigbee Smart Energy 2.0 effort" currently focuses on 
> wireless
>         communication to smart home appliances.  It is intended to enable
>         home energy management and direct load control by utilities.
>
>         ZigBee protocols are intended for use in embedded applications
>         requiring low data rates and low power consumption. ZigBee's 
> current
>         focus is to define a general-purpose, inexpensive, 
> self-organizing
>         mesh network that can be used for industrial control, embedded
>
>
>
> <Tychon, et Al.>       Expires September 15, 2011              [Page 11]
>
>
>
>
>
>
>      Internet-Draft       EMAN Applicability Statement            
> March 2011
>
>
>         sensing, medical data collection, smoke and intruder warning,
>         building automation, home automation, etc.
>
>         It is not known if the Zigbee Alliance plans to extend support to
>         business class devices.  There also does not appear to be a 
> plan for
>         context aware marking.
>
>         Zigbee is currently not an ANSI recognized SDO -- but they are
>         working toward formal recognition.
>
>      3. Limitations
>
>         EMAN will address the needs of the network operators in term of
>         measurement and, to a lesser extend, control over IP networks.
>
>         It is not the purpose of EMAN to create a new protocol stack for
>         energy-aware endpoints, but rather to create a data model to 
> measure
>         and report energy and other metrics over SNMP.
>
>         Other legacy protocols may already exists (ModBus), but are not
>         designed initially to work on IP, even if in some cases it is
>         possible to transport them over IP with some limitations.
>
>         The EMAN framework does not aim to address questions regarding
>         Smartgrid, Electricity producers, distributors even if there is
>         obvious link between them.
it seems like a requirement statement.
The readers are interested in the relationship. How everything should 
work together.
>
>      4. Security Considerations
>
>         EMAN uses the SNMP protocol and is subject to its own 
> security. More
>         specifically, SNMPv3 [RFC3411] provides important security 
> features
>         such as confidentiality, integrity, and authentication.
>
>      4.1. SmartGrid
>
>         Even if discussing SmartGrid security is not the scope of this
>         document, NIST has found at least five standards that are 
> directly
>         related to smart grid security. That includes standards from 
> NERC,
>         IEEE, AMI System Security Requirements, UtilityAMI Home Area 
> Network
>         System Requirements and IEC standards.
>
>         The SmartGrid security issue is more difficult being actually an
>         open network, spawning entire territories and devices from smart
>         meters, secondary and primary sub stations, etc.
>
>         EDITOR'S NODE: TO BE EXPANDED
>
>
>
> <Tychon, et Al.>       Expires September 15, 2011              [Page 12]
>
>
>
>
>
>
>      Internet-Draft       EMAN Applicability Statement            
> March 2011
>
>
>      5. IANA Considerations
>
>         This memo includes no request to IANA.
>
>      6. References
>
>      6.1. Normative References
>
>         [RFC3411] An Architecture for Describing Simple Network 
> Management
>         Protocol (SNMP) Management Frameworks
I was expecting a coupe of EMAN references. At least the working group 
items.

Regards, Benoit.
>
>      6.2. Informative References
>
>          [DQERM] https://datatracker.ietf.org/doc/draft-quittek-eman-
>         reference-model/
>
>          [NIST]  http://www.nist.gov/smartgrid/
>
>
>
>
>
>      7. Acknowledgments
>
>         This document was prepared using 2-Word-v2.0.template.dot.
>
>         The authors would like to thank Jeff Wheeler for its 
> contribution to
>         the DMTF section.
>
>
>
>         Copyright (c) 2011 IETF Trust and the persons identified as 
> authors
>         of the code. All rights reserved.
>
>         Redistribution and use in source and binary forms, with or 
> without
>         modification, is permitted pursuant to, and subject to the 
> license
>         terms contained in, the Simplified BSD License set forth in 
> Section
>         4.c of the IETF Trust's Legal Provisions Relating to IETF 
> Documents
>         (http://trustee.ietf.org/license-info).
>
>
>
>
>
>
>
>
>
>
> <Tychon, et Al.>       Expires September 15, 2011              [Page 13]
>
>
>
>
>
>
>      Internet-Draft       EMAN Applicability Statement            
> March 2011
>
>
>      Authors' Addresses
>
>         Emmanuel Tychon
>         Cisco Systems, Inc.
>         De Keleetlaan, 6A
>         B1831 Diegem
>         Belgium
>         Email: [email-masked]
>
>
>         Matthew Laherty
>         Cisco Systems, Inc.
>         Email: [email-masked]
>
>
>         Brad Schoening
>         44 Rivers Edge Drive
>         Little Silver, NJ 07739
>         USA
>         Email: [email-masked]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> <Tychon, et Al.>       Expires September 15, 2011              [Page 14]
>
>
>
>
>
>
>

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 23 Mar 2011 07:47:46 -0500

Hello all,

Here is a review of draft-quittek-eman-reference-model-01. 

Thanks

Mouli

Firstly, the draft is very well organized and written.  The title seems
appropriate -a reference diagram for the monitoring scenarios.  The
second section covers Terminology of energy terms. The third section
proposes a - Reference model  - the notions of a power source, meter,
and  device are clearly explained.  Internal measurement and the
external measurement are illustrated for clarity.  Several different
monitoring scenarios have been considered.  For those scenarios, control
is added and illustrated. 

Firstly, the reference model described    as in Figure 1, is an useful
as a logical construction.  However, in the case of external
measurement, it is also possible to get additional information such as
power states from end-devices.  It is possible that the "Power- Monitor"
layer can communicate with the end-device, and report the usage
information and the power state information. I think this aspect can be
considered in the reference model, for externally powered/ metered
devices. 

While the logical separation of Source, Meter and Device  is useful, the
measurement at all these points should be the same ? Unless the
measurement points are geographically separated in physical distance; in
that scenario transmission loss comes in to play. 

In Section 4- Energy Management Reference Model - If there are 3 shades
of Cntrl - Power Source Cntrl, Power Meter Cntrl, and Power State
Control, there should be some co-ordination between these actions and
cannot be independent. A small nit -  the figure after figure 9 is not
indexed

In Section 4, in Figure 14. 15, how can Power-State be configured ?
Similarly, for devices beyond a gateway, as in Figure 16, how can
Power-States be configured on the device ? 

Power Source Terminology - it is not the source of power or generation
of power - It is only the power supply feed to the device. 

Not sure about if we should label Energy Monitoring protocol using SNMP
as  EMON ? 

I think there should be some information should be added for Security
consideration in view of configuration,  

The notion of energy management - power-states is it only restricted to
ON and OFF ?  in which case, the control can reside at the source or
switch which can be turn ON or OFF.

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 23 Mar 2011 11:59:42 -0500

Hello all, 

Here is my review of  draft-quittek-eman-battery-mib-00.txt

Thanks

Mouli

This draft is also well-written. This draft and has a good description
of the MIB objects for battery monitoring. 

I have a couple of comments and questions. 

First, the batteryIndex  - how can this be associated with an Entity
such as PC for which the battery is providing backup power ?   What if
there are two batteries for a device ? 

So, for a Data center use case, they should use the UPS MIB to monitor
the UPS capacity to ensure UPS is not drained out ? 

I have a basic question on barteryState. You have defined five states -
full(1),  partiallyCharged(2),  empty(3),  charging(4),
discharging(5),  unknown(6).   

Isn't this similar in spirit to PowerStates discussion for entities ?  

One possibility is to define FULL and Empty as states for a battery
similar to ON and OFF for an entity.

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Thu, 24 Mar 2011 00:46:54 -0500

Hi,

I would like to add a comment on Identity.   Thanks.  Mouli

The draft talks about 

"Identity is basic information about what a device is, in function, in
its specific instance of manufacture, and its specific local human-
readable name.".

Identity of network devices is the topic of the energy aware MIB -
Index (Name, unique ID, reference to other MIB index),  Context (Role
description, Keywords, Importance). 

The entPhysicalTable of the entity MIB has  references to   

                                            entPhysicalDescr  - A
textual description of physical entity.  This object  should contain a
string that identifies the manufacturer's name for the physical entity
and 

                                           entPhysicalVendorType is also
present - an enterprise-specific  registration identifier value
indicating the specific  equipment type.  

However, as Dan Romascanu has pointed out in another thread, these
variables need to be read by machines (NMS) and those provide
translations in human readable form. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mouli Chandramouli (moulchan)
Sent: Wednesday, March 23, 2011 6:18 PM
To: eman mailing list
Subject: [eman] Review of draft-quittek-eman-reference-model-01

Hello all,

Thanks

Mouli

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Thu, 24 Mar 2011 06:31:52 -0500

Hello all,

Here is my review of draft-nordman-eman-energy-perspective-01

Thanks

Mouli

This document provides a general overview of energy monitoring for a
wider audience as indicated in the Introduction.

Some general concepts are explained. I would think for applicability
statement for EMAN should have some more detail.

I think the overall document needs some more tightening up/rewriting for
an overview of Energy Monitoring.  

Here are some specific comments. 

While the Abstract talks about ANSI, there is no reference in the rest
of the document. 

In Section 1.1.  "The same protocol is used whether the NMS is
communicating with an intermediate or end use device." 

This may not be true. Often the protocol between an aggregator / Gateway
to the end-points can be proprietary; which is the present-day scenario.

In Section 1.1. "The NMS will commonly have an entire single building as
its scope, though

   in some cases will cover only a part of a building, or multiple
buildings."

There is a confusion notion of EMAN protocol. I would assume that
currently SNMP is considered as the mechanism for energy monitoring, 

which may not preclude other possible choices such as IPFIX or Syslog in
future.

In that context, the role of NMS should be defined appropriately. This
definition NMS  is not accurate and notion of buildings does not seem
correct
"The NMS will commonly have an entire single building as its scope,
though in some cases will cover only a part of a building, or multiple

   buildings".

In Section 1.2.  Usage Overview  - This section is not clear.  As the
opening sentence "The basic usage of the eman protocol is a building
operator

 installing software for collecting eman informatin on an existing
device in the building". 

As mentioned before, EMAN is not restricted to a building. Secondly, a
management MIB framework should be implemented by the devices (PCs,
network devices, PCs,). Then a management station can poll those devices
to collect the power or energy information. 

 "The NMS then determines how often to query each device for updates to
the energy information." vThe frequency of energy measurement collection
is configured by the network operator.

Section 2 - Terminology either should have a lot more concepts defined
or merged with some other section,  In particular, a more precise
definition of Energy could have been given. Other forms of energy such
as Methane, Steam do not seem relevant to this WG. 

If we are defining the terminology of  Building network - it is better
to define what it is - what are the components etc. 

In Section 3 - Use contexts 

Highly Managed,  Lightly Managed describe general concepts. Same with
Residential or Commercial buildings. 

It is not clear why Vehicles should be included for energy monitoring.
First, Electric cars are in future and have a battery.  Driver of an
electric car would want "local" energy status on the car dashboard. 

Regarding Identity, I had provided my comment in
http://www.ietf.org/mail-archive/web/eman/current/msg00417.html

---

From: Bruce Nordman <[email-masked]>
Date: Mon, 28 Mar 2011 00:36:45 +0200

A few comments.

On Wed, Mar 23, 2011 at 1:47 PM, Mouli Chandramouli (moulchan) <
[email-masked]> wrote:

> appropriate –a reference diagram for the monitoring scenarios.  The second
> section covers Terminology of energy terms. The third section  proposes a -
> Reference model  - the notions of a power source, meter, and  device are
> clearly explained.  Internal measurement and the external measurement are
> illustrated for clarity.  Several different monitoring scenarios have been
> considered.  For those scenarios, control is added and illustrated.
>
>
>
> Firstly, the reference model described    as in Figure 1, is an useful as a
> logical construction.  However, in the case of external measurement, it is
> also possible to get additional information such as power states from
> end-devices.  It is possible that the “Power- Monitor” layer can communicate
> with the end-device, and report the usage information and the power state
> information. I think this aspect can be considered in the reference model,
> for externally powered/ metered devices.
>
That does seem to be an additional possible scenario.

> measurement at all these points should be the same ? Unless the measurement
> points are geographically separated in physical distance; in that scenario
> transmission loss comes in to play.
>
The key point here is that these three functions can be accomplished by the
same device, by two devices, or by three (though three is likely to be
rare). Having the functionality based on the functions and not the devices
makes the framework more flexible and simpler to explain all scenarios.

>
>
> In Section 4- Energy Management Reference Model – If there are 3 shades of
> Cntrl – Power Source Cntrl, Power Meter Cntrl, and Power State Control,
> there should be some co-ordination between these actions and cannot be
> independent. A small nit -  the figure after figure 9 is not indexed
>
If one of these is set by control, then the others may well change based on
how the device operates, but I don't think that affects the eman model -
that is just how the device operates.

> Power-States be configured on the device ?
Per section 1.1, the lines without a caret are a protocol not specified by
EMAN, so the mechanism is whatever the other protocol provides for.

>
>
> Power Source Terminology – it is not the source of power or generation of
> power – It is only the power supply feed to the device.
>
The Power Source concept identifies the control over power source that some
PDUs have (and therefore monitoring of the state of that control).  I am
concerned that many readers will interpret "power supply" as the AC->DC
converter inside a device; "power source" avoids that likely confusion.

>
>
> Not sure about if we should label Energy Monitoring protocol using SNMP as
> EMON ?
>
I do think we will want some name - other suggestions encouraged.

> The notion of energy management - power-states is it only restricted to ON
> and OFF ?  in which case, the control can reside at the source or switch
> which can be turn ON or OFF.
>
This is for the state of the power source, not of the powered device.

Thanks much,

--Bruce

>
>
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman
>
>

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
[email-masked]
510-486-7089
m: 510-501-7943

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 28 Mar 2011 12:29:45 +0200

Dear Mouli,

Thank you for the review.
Please find replies to your comments inline.

    Juergen

Am 23.03.2011 um 13:47 schrieb Mouli Chandramouli (moulchan):

> Firstly, the draft is very well organized and written.  The title seems appropriate –a reference diagram for the monitoring scenarios.  The second section covers Terminology of energy terms. The third section  proposes a - Reference model  - the notions of a power source, meter, and  device are clearly explained.  Internal measurement and the external measurement are illustrated for clarity.  Several different monitoring scenarios have been considered.  For those scenarios, control is added and illustrated.
>  
> Firstly, the reference model described    as in Figure 1, is an useful as a logical construction.  However, in the case of external measurement, it is also possible to get additional information such as power states from end-devices.  It is possible that the “Power- Monitor” layer can communicate with the end-device, and report the usage information and the power state information. I think this aspect can be considered in the reference model, for externally powered/ metered devices.

Yes, and the text in the draft says so.
I should make sure that this becomes more clear.

> While the logical separation of Source, Meter and Device  is useful, the measurement at all these points should be the same ? Unless the measurement points are geographically separated in physical distance; in that scenario transmission loss comes in to play.

Transmission loss is indeed a problem. I do not have a good idea how relevant it is and how to deal with it.
I will mention it in the next revision.

> In Section 4- Energy Management Reference Model – If there are 3 shades of Cntrl – Power Source Cntrl, Power Meter Cntrl, and Power State Control, there should be some co-ordination between these actions and cannot be independent.

Yes, there should be coordination. But this is a task of the energy management system. No need to add this to the references model.

> A small nit -  the figure after figure 9 is not indexed

Only scenarios are indexed, but not other figures, such as the ones in section 3

> In Section 4, in Figure 14. 15, how can Power-State be configured ?  Similarly, for devices beyond a gateway, as in Figure 16, how can Power-States be configured on the device ?

Well, I just assumed that there will be many powered devices that do not allow configuring the power state remotely, such as, for example, several desktop IP phones. Scenarios 14 and 15 just assumes such devices. But of course there will be also many devices supporting remote state configuration. For these, you can easily add more scenarios that extend Scenarios 14 and 15 towards devices that support configuring their power states.

> Power Source Terminology – it is not the source of power or generation of power – It is only the power supply feed to the device.

We discussed using "power supply" instead of "power source" but found power source more appropriate. But I am open to use better terms here.
What would be your proposal?
 
> Not sure about if we should label Energy Monitoring protocol using SNMP as  EMON ?

We can more precisely define 'EMAN' as 'SNMP using EMAN MIB modules'.

> I think there should be some information should be added for Security consideration in view of configuration, 

Yes, right. But also for monitoring. I add it to the to do list.

> The notion of energy management - power-states is it only restricted to ON and OFF ?  in which case, the control can reside at the source or switch which can be turn ON or OFF.    

Why would you restrict power states of devices to on and off?
The situation is more restricted at the power source, for example at a PDU. 
There you often do not have more control beyond switching the supply for a powered device on and off.

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 28 Mar 2011 12:48:20 +0200

Hi Mouli,

Thanks again for another review!

Please find replies inline.

    Juergen

Am 23.03.2011 um 17:59 schrieb Mouli Chandramouli (moulchan):

> This draft is also well-written. This draft and has a good description of the MIB objects for battery monitoring.
>  
> First, the batteryIndex  - how can this be associated with an Entity such as PC for which the battery is providing backup power ?   What if there are two batteries for a device ?

The battery MIB module can be implemented by devices containing batteries. May be these batteries are used for back-up power, may be for something else. We do not discuss this. For these batteries, the MIB module offers means for reporting their states. If you have multiple batteries in your device, then you will have multiple index values.

> So, for a Data center use case, they should use the UPS MIB to monitor the UPS capacity to ensure UPS is not drained out ?

What is the data center use case?

If you operate a UPS you have the UPS MIB. If you would like to use the battery MIB in addition is something we will have to investigate. 

> I have a basic question on barteryState. You have defined five states -  full(1),  partiallyCharged(2),  empty(3),  charging(4),   discharging(5),  unknown(6).  
> Isn’t this similar in spirit to PowerStates discussion for entities ? 

Yes, it is similar. These are functional states with power implications.
We can think about using EMAN power states here. But these need to be states customized for batteries.

> One possibility is to define FULL and Empty as states for a battery similar to ON and OFF for an entity.

What do you mean with 'similar'?
OFF and EMPTY are different concepts with different implications.