[eman] draft-ietf-eman-framework-10: WGLC comments

[Benoit Claise <[e-mail]>]

Dear all,

Here is my review.
Sorry for the delay.
>       Network Working Group                              J. Parello
>       Internet-Draft                                      B. Claise
>       Intended Status: Informational             Cisco Systems, Inc.
>       Expires: March 23, 2014                          B. Schoening
>                                              Independent Consultant
>                                                          J. Quittek
>                                                      NEC Europe Ltd
>       
>                                                  September 23, 2013
>       
>       
>                          
>
>
>   Energy Management Framework
>
>
>                         
>
>
>   draft-ietf-eman-framework-10
>
>
>       
>       
>       Status of this Memo
>       
>          This Internet-Draft is submitted in full conformance with
>          the provisions ofBCP 78  <http://tools.ietf.org/html/bcp78>  andBCP 79  <http://tools.ietf.org/html/bcp79>.
>       
>          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 athttp://www.ietf.org/shadow.html
>       
>          This Internet-Draft will expire on March 23, 2014.
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       Claise et al            Expires March 23, 2014        [Page 1]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-2>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>       Copyright Notice
>       
>          Copyright (c) 2013 IETF Trust and the persons identified as
>          the document authors. All rights reserved.
>       
>          This document is subject toBCP 78  <http://tools.ietf.org/html/bcp78>  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 inSection 4  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4>.e of the Trust Legal
>          Provisions and are provided without warranty as described
>          in the Simplified BSD License.
>       
>       Abstract
>       
>          This document defines a framework for providing Energy
>          Management for devices and device components within or
>          connected to communication networks.  The framework
>          presents a physical reference model and information model.
>          The information model consists of an Energy Management
>          Domain as a set of Energy Objects. Each Energy Object is
>          identified, classified and given context.  Energy Objects
>          can be monitored and controlled with respect to Power,
>          Power State, Energy, Demand, Power Attributes, and Battery.
>          Additionally the framework models relationships and
>          capabilities between Energy Objects.
On the top of Jürgen's feedback on the abstract, I'm wondering: What is 
a "physical" reference model?

>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       Claise et al.           Expires March 23, 2014       [Page 2]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-3>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>       Table of Contents
>       
>          1  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-1>. Introduction...........................................3  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-3>
>             1.1  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-1.1>. Energy Management Documents Overview..............4  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-4>
>          2  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-2>. Terminology............................................5  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-5>
>          3  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-3>. Concerns Specific to Energy Management................11  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-11>
>             3.1  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-3.1>. Target Devices...................................11  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-11>
>             3.2  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-3.2>. Physical Reference Model.........................12  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-12>
>             3.3  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-3.3>. Concerns Differing from Network Management.......13  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-13>
>             3.4  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-3.4>. Concerns Not Addressed...........................14  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-14>
>          4  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4>. Energy Management Abstraction.........................14  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-14>
>             4.1  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.1>. Conceptual Model.................................15  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-15>
>             4.2  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.2>. Energy Object....................................15  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-15>
>             4.3  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.3>. Energy Object Attributes.........................16  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-16>
>             4.4  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.4>. Measurements.....................................19  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-19>
>             4.5  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.5>. Control..........................................21  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-21>
>             4.6  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.6>. Relationships....................................26  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-26>
>          5  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-5>. Energy Management Information Model...................30  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-30>
>          6  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-6>. Modeling Relationships between Devices................34  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-34>
>             6.1  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-6.1>. Power Source Relationship........................34  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-34>
>             6.2  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-6.2>. Metering Relationship............................37  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-37>
>             6.3  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-6.3>. Aggregation Relationship.........................39  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-39>
>          7  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-7>. Relationship to Other Standards.......................40  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-40>
>          8  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-8>. Security Considerations...............................40  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-40>
>             8.1  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-8.1>. Security Considerations for SNMP.................41  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-41>
>          9  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-9>. IANA Considerations...................................42  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-42>
>             9.1  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-9.1>. IANA Registration of new Power State Sets........42  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-42>
>             9.2  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-9.2>. Updating the Registration of .. Power State Sets. 43
>          10  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-10>. References...........................................43  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-43>
>          11  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-11>. Acknowledgments......................................47  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-47>
>       
>       
>
>
>     1
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-1>.
>     Introduction
>
>
>       
>          Network management is often divided into the five main
>          areas defined in the ISO Telecommunications Management
>          Network model: Fault, Configuration, Accounting,
>          Performance, and Security Management (FCAPS) [X.700  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-X.700>].  Not
>          covered by this traditional management model is Energy
>          Management, which is rapidly becoming a critical area of
>          concern worldwide, as seen in [ISO50001  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-ISO50001>].
>       
>          This document defines an energy management framework for
>          devices within or connected to communication networks.  The
>          devices, or components of these devices (such as router
>          line cards, fans, disks), can then be monitored and
>          controlled.  Monitoring includes measuring power, energy,
>          demand, and attributes of power.  Energy control can be
>          performed by setting a devices' or components' power state.
power state -> Power State.
Some more instances: be consistent in terms of capitalization in the 
introduction.
>       
>       
>       Claise et al.           Expires March 23, 2014       [Page 3]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-4>
>       Internet-Draft              EMAN Framework      September 2013
>       
>          If a device contains batteries, these can also be monitored
>          and controlled.
>       
>          This framework further describes how to identify, classify
>          and provide context for such devices.  While the context
>          information is not specific to Energy Management, some
>          context attributes are specified in the framework,
>          addressing the following use cases: how important is a
>          device in terms of its business impact, how should devices
>          be grouped for reporting and searching, and how should a
>          device role be described.  These context attributes help in
>          fault management and impact analysis while controlling the
>          power states.  Guidelines for using context for energy
>          management are described.
>       
>          The framework introduces the concept of a power interface
>          that is analogous to a network interface. A power interface
>          is defined as an interconnection among devices where energy
>          can be provided, received, or both.
>       
>          The most basic example of Energy Management is a single
>          device reporting information about itself.  In many cases,
>          however, energy is not measured by the device itself, but
>          measured upstream in the power distribution tree.  For
>          example, a power distribution unit (PDU) may measure the
>          energy it supplies to attached devices and report this to
>          an energy management system.  Therefore, devices often have
>          relationships to other devices or components in the power
>          network.  An EnMS (Energy Management System) generally
>          requires an understanding of the power topology (who
>          provides power to whom), the metering topology (who meters
>          whom), and an understanding of the potential aggregation
>          (ex: does a meter aggregate values from other devices).
>       
We need to introduce that there are different relationship types, to 
solve the different problems.
>          The relationships build on the power interface concept. The
>          different relationships among devices and components,
>          specified in this document, include: power source
>          relationship, metering relationship, and aggregation
>          relationship.
>       
>       
>
>
>       1.1
>       <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-1.1>.
>       Energy Management Documents Overview
>
>
>       
>          The EMAN standard provides a set of specifications for
>          Energy Management.  This document specifies the framework,
>          per the Energy Management requirements specified in [EMAN-
>          REQ].
>       
>          The applicability statement document [EMAN-AS  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-EMAN-AS>] includes use
>          cases, a cross-reference between existing standards and the
>       
>       
>       Claise et al.           Expires March 23, 2014       [Page 4]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-5>
>       Internet-Draft              EMAN Framework      September 2013
>       
>          EMAN standard, and a description of this framework's
>          relationship to other frameworks.
>       
>          The Energy Object Context MIB [EMAN-OBJECT-MIB  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-EMAN-OBJECT-MIB>] specifies
>          objects for addressing Energy Object Identification,
>          classification, context information, and relationships from
>          the point of view of Energy Management.
>       
>          The Power and Energy Monitoring MIB [EMAN-MON-MIB  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-EMAN-MON-MIB>]
>          specifies objects for monitoring of Power, Energy, Demand,
>          Power Attributes, and Power States.
>       
>          The Battery Monitoring MIB [EMAN-BATTERY-MIB  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-EMAN-BATTERY-MIB>] defines
>          managed objects that provide information on the status of
>          batteries in managed devices.
>       
>       
>
>
>     2
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-2>.
>     Terminology
>
>
>       
>          The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
>          "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
>          and "OPTIONAL" in this document are to be interpreted as
>          described inRFC-2119  <http://tools.ietf.org/html/rfc2119>  [RFC2119  <http://tools.ietf.org/html/rfc2119>].
>       
>          In this document these words will appear with that
>          interpretation   only when in ALL CAPS. Lower case uses of
>          these words are not to be    interpreted as carryingRFC-  <http://tools.ietf.org/html/rfc2119>
>          2119  <http://tools.ietf.org/html/rfc2119>  significance.
>       
>          In this section some terms have a NOTE that is not part of
>          the definition itself, but accounts for differences between
>          terminologies of different standards organizations or
>          further clarifies the definition.
The final agreement on [EMAN-REQ] was 
http://www.rfc-editor.org/authors/rfc6988.txt

    The terms specified in the terminology section are capitalized
    throughout the document; the exceptions are the well-known terms
    "energy" and "power".  These terms are generic and are used in
    generated terms such as "energy-saving", "low-power", etc.


I suggest you do the same.


I searched for a specific term in the terminology section, and realized 
that the order is not alphabetical.
A sentence such as: "The terms in the terminology section are not 
classified alphabetically, but the order has been chosen to improve the 
document readiness, with terms building on the top of each others"


>       
>          $ Energy Management
Please change the "$" sign for all entries in the terminology section.
>            Energy Management is a set of functions for measuring,
>            modeling, planning, and optimizing networks to ensure
>            that the network and network attached devices use energy
>            efficiently and appropriately for the nature of the
>            application and the cost constraints of the organization.
>       
>            Reference: Adapted from [ITU-T-M-3400  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-ITU-T-M-3400>]
>       
>            NOTES:
>            1. Energy management refers to the activities, methods,
>            procedures and tools that pertain to measuring, modeling,
>            planning, controlling and optimizing the use of energy in
>            networked systems [NMF  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-NMF>].
>       
>       
>       
>       
>       Claise et al.           Expires March 23, 2014       [Page 5]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-6>
>       Internet-Draft              EMAN Framework      September 2013
>       
>            2. Energy Management is a management domain which is
>            congruent to any of the FCAPS areas of management in the
>            ISO/OSI Network Management Model [TMN  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-TMN>]. Energy Management
>            for communication networks and attached devices is a
>            subset or part of an organization's greater Energy
>            Management Policies.
>       
>          $ Energy Management System (EnMS)
>            An Energy Management System is a combination of hardware
>            and software used to administer a network with the
>            primary purpose of energy management.
>       
>            NOTES:
>            1. An Energy Management System according to [ISO50001  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-ISO50001>]
>            (ISO-EnMS) is a set of systems or procedures upon which
>            organizations can develop and implement an energy policy,
>            set targets, action plans and take into account legal
>            requirements related to energy use.  An ISO-EnMS allows
>            organizations to improve energy performance and
>            demonstrate conformity to requirements, standards, and/or
>            legal requirements.
>       
>            2. Example ISO-EnMS:  Company A defines a set of policies
>            and procedures indicating there should exist multiple
>            computerized systems that will poll energy measurements
>            from their meters and pricing / source data from their
>            local utility. Company A specifies that their CFO (Chief
>            Financial Officer) should collect information and
>            summarize it quarterly to be sent to an accounting firm
>            to produce carbon accounting reporting as required by
>            their local government.
>       
>            3. For the purposes of EMAN, the definition herein is the
>            preferred meaning of an Energy Management System (EnMS).
>            The definition from [ISO50001  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-ISO50001>] can be referred to as ISO
>            Energy Management System (ISO-EnMS).
>       
>          $ Energy Monitoring
>            Energy Monitoring is a part of Energy Management that
>            deals with collecting or reading information from Energy
>            Objects to aid in Energy Management.
>       
>          $ Energy Control
>            Energy Control is a part of Energy Management that deals
>            with directing influence over Energy Objects.
>       
>          $ Electrical Equipment
>            A general term including materials, fittings, devices,
>            appliances, fixtures, apparatus, machines, etc., used as
>       
>       
>       Claise et al.           Expires March 23, 2014       [Page 6]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-7>
>       Internet-Draft              EMAN Framework      September 2013
>       
>            a part of, or in connection with, an electric
>            installation.
>            Reference: [IEEE100  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEEE100>]
>       
>          $ Non-Electrical Equipment (Mechanical Equipment)
>            A general term including materials, fittings, devices,
>            appliances, fixtures, apparatus, machines, etc., used as
>            a part of, or in connection with, non-electrical power
>            installations.
>       
>            Reference: Adapted from [IEEE100  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEEE100>]
>       
>          $ Device
>            A piece of electrical or non-electrical equipment.
>            Reference: Adapted from [IEEE100  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEEE100>]
>       
>          $ Component
>            A part of an electrical or non-electrical equipment
>            (Device).
>            Reference: Adapted from [ITU-T-M-3400  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-ITU-T-M-3400>]
>       
>          $ Power Inlet
>            A Power Inlet (or simply inlet) is an interface at which
>            a device or component receives energy from another device
>            or component.
>       
>          $ Power Outlet
>            A Power Outlet (or simply outlet) is an interface at
>            which a device or component provides energy to another
>            device or component.
Are Power Inlets and Power Oulets Power Interfaces?
If yes, the definitions should be changed accordingly

         $ Power Inlet
           A Power Inlet (or simply inlet) is an Power Interface at which
           a device or component receives energy from another device
           or component.


>       
>          $ Energy
>            That which does work or is capable of doing work. As used
>            by electric utilities, it is generally a reference to
>            electrical energy and is measured in kilowatt hours
>            (kWh).
>       
>            Reference: [IEEE100  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEEE100>]
>       
>            NOTES
>            1. Energy is the capacity of a system to produce external
>            activity or perform work [ISO50001  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-ISO50001>]
>       
>          $ Provide Energy
>            A device (or component) "provides" energy to another
>            device if there is an energy flow from this device to the
>            other one.
>       
>          $ Receive Energy
>       
>       
>       Claise et al.           Expires March 23, 2014       [Page 7]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-8>
>       Internet-Draft              EMAN Framework      September 2013
>       
>            A device (or component) "receives" energy from another
>            device if there is an energy flow from the other device
>            to this one.
>       
>          $ Meter (energy meter)
>            a device intended to measure electrical energy by
>            integrating power with respect to time.
>       
>            Reference: Adapted from [IEC60050  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEC60050>]
>       
>          $ Battery
>            one or more cells (consisting of an assembly of
>            electrodes, electrolyte, container, terminals and usually
>            separators)  that are a source and/or store of electric
>            energy.
>       
>            Reference: Adapted from [IEC60050  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEC60050>]
>       
>          $ Power
>            The time rate at which energy is emitted, transferred, or
>            received; usually expressed in watts (joules per second).
>       
>            Reference: [IEEE100  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEEE100>]
>       
>          $ Nameplate Power
>            The Nameplate Power is the nominal Power of a device as
>            specified by the device manufacturer.
s/a device/an Electrical Device?
>       
>          $ Power Attributes
>            Measurements of the electrical current, voltage, phase
>            and frequencies at a given point in an electrical power
>            system.
>            Reference: Adapted from [IEC60050  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEC60050>]
>       
>            NOTES:
>            1. Power Attributes are not intended to be judgmental
>            with respect to a reference or technical value and are
>            independent of any usage context.
>       
>          $ Power Quality
>            Characteristics of the electrical current, voltage, phase
>            and frequencies at a given point in an electric power
>            system, evaluated against a set of reference technical
>            parameters. These parameters might, in some cases, relate
>            to the compatibility between electricity supplied in an
>            electric power system and the loads connected to that
>            electric power system.
>       
>            Reference: [IEC60050  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEC60050>]
>       
>       
>       Claise et al.           Expires March 23, 2014       [Page 8]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-9>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>            NOTES:
>            1. Electrical characteristics representing power quality
>            information are typically required by customer facility
>            energy management systems. It is not intended to satisfy
>            the detailed requirements of power quality monitoring.
>            Standards typically also give ranges of allowed values;
>            the information attributes are the raw measurements, not
>            the "yes/no" determination by the various standards.
>       
>            Reference: [ASHRAE-201  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-ASHRAE-201>]
>       
>          $ Demand
>            The average value of power or a related quantity over a
>            specified interval of time. Note: Demand is expressed in
>            kilowatts, kilovolt-amperes, kilovars, or other suitable
>            units.
>       
>            Reference: [IEEE100  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEEE100>]
>       
>            NOTES:
>            1. For EMAN we use kilowatts.
>       
>          $ Power State
>            A Power State is a condition or mode of a device that
>            broadly characterizes its capabilities, power
>            consumption, and responsiveness to input.
>       
>            Reference: Adapted from [IEEE1621  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEEE1621>]
>       
>          $ Power State Set
>            A Power State Set is a collection of Power States that
>            comprises a named or logical control grouping.
>       
>          $ Energy Object
>            An Energy Object (EO) is an information model (class)
>            that represents a piece of equipment that is part of, or
>            attached to, a communications network which is monitored,
>            controlled, or aids in the management of another device
>            for Energy Management.
>       
>          $ Power Interface
>            A Power Interface (or simply interface) is an information
>            model (class) that represents the interconnections among
>            devices or components where energy can be provided,
>            received, or both.
>       
>          $ Energy Management Domain
>       
>       
>       
>       Claise et al.           Expires March 23, 2014       [Page 9]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-10>
>       Internet-Draft              EMAN Framework      September 2013
>       
>            An Energy Management Domain is a set of Energy Objects
>            that is considered one unit of management.
>       
>          $ Energy Object Identification
>            Energy Object Identification is a set of attributes that
>            enable an Energy Object to be universally unique or
>            linked to other systems.
>       
>          $ Energy Object Context
>            Energy Object Context is a set of attributes that allow
>            an Energy Management System to classify an Energy Object
>            within an organization.
>       
>          $ Energy Object Relationship
>            An Energy Object Relationship is an association among
>            Energy Objects.
>       
>            NOTES
>            1. Relationships can be named and could include
>            Aggregation, Metering, and Power Source.
>            Reference: Adapted from [CHEN  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-CHEN>]
>       
>          $ Power Source Relationship
>            A Power Source Relationship is an Energy Object
>            Relationship where one Energy Object provides power to
>            one or more Energy Objects. These Energy Objects are
>            referred to as having a Power Source Relationship.
>       
>          $ Metering Relationship
>            A Metering Relationship is an Energy Object Relationship
>            where one Energy Object measures power, energy, demand or
>            power attributes of one or more other Energy Objects. The
>            measuring Energy Object has a Metering Relationship with
>            each of the measured objects.
>       
>          $ Aggregation Relationship
>            An Aggregation Relationship is an Energy Object
>            Relationship where one Energy Object aggregates Energy
>            Management information of one or more other Energy
>            Objects. The aggregating Energy Object has an Aggregation
>            Relationship with each of the other Energy Objects.
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 10]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-11>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>       
>
>
>     3
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-3>.
>     Concerns Specific to Energy Management
>
>
>       
>          This section explains areas of concern for Energy
>          Management that do not exist in traditional Network
>          Management. This section describes target devices, outlines
>          physical reference models, and lists the major concerns
Again "physical" reference model.
>          specific to Energy Management.
>       
>       
>
>
>       3.1
>       <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-3.1>.
>       Target Devices
>
>
>       
>          With Energy Management, there exists a wide variety of
>          devices that may be contained in the same deployment as
>          communication network but comprise a separate facility,
>          home, or power distribution network.
>       
>          Energy Management has special challenges because a power
>          distribution network supplies energy to devices and
>          components, while a separate communications network
>          monitors and controls the power distribution network.
>       
>          The target devices for Energy Management are all devices
>          that can be monitored or controlled (directly or
>          indirectly) by an Energy Management System (EnMS). These
>          target devices include:
>             o     Simple electrical appliances and fixtures
>             o     Hosts, such as a PC, a server, or a printer
>             o     Switches, routers, base stations, and other
>                network equipment and middle boxes
>             o     Components within devices, such as a battery
>                inside a PC, a line card inside a switch, etc.
>             o     Power over Ethernet (PoE) endpoints
>             o     Power Distribution Units (PDU)
>             o     Protocol gateway devices for Building Management
>                Systems (BMS)
>             o     Electrical meters
>             o     Sensor controllers with subtended sensors
I'm confused by the Device definition in the terminology, which is NOT 
used in this text, while "device" (paragraph above) and "target device" 
are used
>       
>          Target devices will primarily communicate via Internet
>          Protocols (IP). The target devices may also include those
>          communicating via non-IP protocols deployed among the power
>          distribution and IP communication network. These types of
>          target devices are expect to be managed through gateways or
>          proxies that can communicate using IP.
>       
>       
>       
>       
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 11]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-12>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>       
>
>
>       3.2
>       <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-3.2>.
>       Physical Reference Model
>
>
>       
>          The following reference models describe physical power
>          topologies that exist in parallel to the communication
>          topology. While many more permutations of topologies can be
Permutation of topologies or permutations of elements, which in turn, 
create different topologies?
I believe you meant the latter.
>          created the following are some basic ones that show how
>          Energy Management topologies differ from Network Management
>          topologies.
>       
>          Basic Energy Management
>       
>                                 +--------------------------+
>                                 | Energy Management System |
>                                 +--------------------------+
>                                             ^  ^
>                                  monitoring |  | control
>                                             v  v
>                                         +---------+
>                                         | device  |
>                                         +---------+
>       
>          Basic Power Supply
>       
>                      +-----------------------------------------+
>                      |         energy management system        |
>                      +-----------------------------------------+
>                            ^  ^                       ^  ^
>                 monitoring |  | control    monitoring |  | control
>                            v  v                       v  v
>                      +--------------+        +-----------------+
>                      | power supply |########|      device     |
>                      +--------------+        +-----------------+
>       

energy management system -> Energy Management System

Pay attention to the terms capitalization in the figures as well. Here, we speak about
	device -> Device,
	monitoring -> Energy Monitoring
	control -> Energy Control

You removed the fact that ######## is energy.

Device versus device versus target device?

I'm wondering if we should not add the Power Interfaces in the figures.
  

>          Single Power Supply with Multiple Devices
>       
>                        +---------------------------------------+
>                        |       energy management system        |
>                        +---------------------------------------+
>                           ^  ^                       ^  ^
>                monitoring |  | control    monitoring |  | control
>                           v  v                       v  v
>                        +--------+        +------------------+
>                        | power  |########|         device 1 |
>                        | supply |   #    +------------------+-+
>                        +--------+   #######|         device 2 |
>                                       #    +------------------+-+
>                                       #######|         device 3 |
>                                              +------------------+
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 12]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-13>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>          Multiple Power Supplies with Single Devices
>       
>               +----------------------------------------------+
>               |          energy management system            |
>               +----------------------------------------------+
>                   ^  ^              ^  ^              ^  ^
>              mon. |  | ctrl.   mon. |  | ctrl.   mon. |  | ctrl.
>                   v  v              v  v              v  v
>               +----------+      +----------+      +----------+
>               | power    |######|  device  |######| power    |
>               | supply 1 |######|          |      | supply 2 |
>               +----------+      +----------+      +----------+
>       
>       
>
>
>       3.3
>       <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-3.3>.
>       Concerns Differing from Network Management
>
>
>       
>             o  Identification of the power source of a device may be
>                independent of the communication network and require
>                unique identifiers.
>       
>             o  Controlling power for a device may have to be
>                fulfilled by addressing the power source as opposed
>                to directing control to the device. For example
>                controlling a device by controlling the outlet of the
>                PDU or controlling a simple light by controlling its
>                outlet.
>       
>             o  Control of a device may need to be coordinated if
>                there are multiple power supplies.
>       
>             o  Modeling of power when the flow of energy can be bi-
>                directional and require a separate interface model
>                from Network Management. For example energy received
>                into a battery or energy provided from battery).
>       
>             o  Some devices may need out-of-band or proxy
>                capabilities to respond to communications request
>                even though it is in a non-operational power state.
>       
>             o  Estimates and source of measurements may vary among
>                devices. For example when devices do not have the
>                capability to measure power an estimate can be
>                provided from the device or estimated by the EnMS.
>                This may require annotation of a measurement.
>       
>             o  A device may require a separate abstract model to
>                describe its components and interconnections than a
>                model used to describe it for Network Management.
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 13]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-14>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>       
>
>
>       3.4
>       <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-3.4>.
>       Concerns Not Addressed
>
One line of intro please: "concerns not addressed" is vague
Which concerns? Is "concerns" the right term? Should we have some 
concerns that some concerns are not addressed? :-)
Not addressed by this framework, I guess.
What you want to say is "out of scope of this framework", right?
>       
>          Non-Electrical Equipment
>       
>          The primary focus of this framework is the management of
>          Electrical Equipment.  Some Non-Electrical Equipment may be
>          connected to communication networks and could have their
>          energy managed if normalized to the electrical units for
>          power and energy. Non-
>          Electrical equipment that do not convert-to or present-as
>          equivalent to Electrical Equipment is not addressed.

         Non-Electrical equipments that do not convert-to or present-as
         equivalent to Electrical Equipments are not addressed.

>       
>       
>          Energy Procurement and Manufacturing
>       
>          While an EnMS may be a central point for corporate
>          reporting, cost computation, environmental impact analysis,
>          and regulatory compliance reporting - Energy Management in
>          this framework excludes energy procurement and the
>          environmental impact of energy use.
>       
>          As such the framework does not include:
>             o  Cost in currency or environmental units of
>                manufacturing a device.
>             o  Embedded carbon or environmental equivalences of a
>                device
>             o  Cost in currency or environmental impact to dismantle
>                or recycle a device.
>             o  Supply chain analysis of energy sources for device
>                deployment
>             o  Conversion of the usage or production of energy to
>                units expressed from the source of that energy (such
>                as the greenhouse gas emissions associated with
>                1000kW from a diesel source).
>       
>       
>
>
>     4
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4>.
>     Energy Management Abstraction
>
>
>       
>          Network management is often divided into the five main
>          areas defined in the ISO Telecommunications Management
>          Network model: Fault, Configuration, Accounting,
>          Performance, and Security Management (FCAPS) [X.700  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-X.700>].  This
>          traditional management model does not cover Energy
>          Management.
>       
>          This section describes a conceptual model of information
>          that can be used for Energy Management. The classes and
>          categories of attributes in the model are described with
>          rationale for each.
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 14]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-15>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>       
>
>
>       4.1
>       <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.1>.
>       Conceptual Model
>
>
>       
>          This section describes an information model addressing
>          issues specific to Energy Management, which complements
>          existing Network Management models.
>       
>          An information model for Energy Management will need to
No need.
>          describe a means to report information, provide control,
>          and model the interconnections among physical entities
>          (equipment).
interconnections = relationships
We introduced the notion of relationships already
Proposal:

         describe a means to report information, provide control,
         and model the relationships among physical entities
         (equipment).

Here, it's physical entities (equipment).
We had already device, Device, target device, Electrical Object
Be consistent.

>       
>          Therefore, this section proposes a similar conceptual model
>          for physical entities to that used in Network Management:
>          devices, components, and interfaces. This section then
>          defines the additional attributes specific to Energy
>          Management for those entities that are not available in
>          existing Network Management models.
>       
>          For modeling the physical entities this section describes
>          three classes:  a Device, a Component, and a Power
>          Interface. These classes are sub-types of an abstract
>          Energy Object class.
I finally get it, I think.
You really want to Energy Object to be an (instance of the) Device, 
Component, or Power Interface class in the information model.
The readers start with the terminology and since they don't know you 
will need an information model, they're puzzled by the Energy Object 
definition.
Proposal: whenever you mean the information model class, just mention
     Device Class
     Component Class
     etc.
As you did with the subtitles below.
And no need to define Energy Object in the terminology section. If you 
really want, insert the definition in this information model section 
here, along with the Device Class definition. Same thing for component.
Btw, the Energy Object is not a class but an instance of the class.
>       
>          For modeling additional attributes, this section describes
>          attributes of an Energy Object for: identification,
>          classification, context, control, power and energy.
>       
>          Since the interconnections between physical entities for
interconnection = relationship
>          Energy Management may have no relation to the
>          interconnections for Network Management the Energy Object
interconnection = topology
>          classes contain a separate Relationships class as an
>          attribute to model these types of interconnections.
>       
>          The remainder of this section describes the conceptual
>          model of the classes and categories of attributes in the
>          information model. The formal definitions of the classes
>          and attributes are specified inSection 5  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-5>.
>       
>       
>
>
>       4.2
>       <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.2>.
>       Energy Object
>
>
>       
>          An Energy Object is an abstract class that contains the
>          base attributes for Energy Management.  There are three
>          types of Energy Objects: Device, Component and Power
>          Interface.
>       
>       
>       
>
>
>         4.2.1
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.2.1>.
>         Device Class
>
>
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 15]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-16>
>       Internet-Draft              EMAN Framework      September 2013
>       
>          The Device Class is a sub-class of Energy Object that
>          represents a physical piece of equipment.
>       
>          A Device Class instance may represent a device that is a
>          consumer, producer, meter, distributor, or store of energy.
>       
>          A Device Class instance may represent a physical device
>          that contains other components.
>       
>       
>
>
>         4.2.2
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.2.2>.
>         Component Class
>
>
>       
>          The Component Class is a sub-class of Energy Object that
>          represents a part of a physical piece of equipment.
>       
>       
>
>
>         4.2.3
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.2.3>.
>         Power Interface Class
>
>
>       
>          The power interface class is a sub-class of Energy Object
>          that represents the interconnection among devices and
>          components.
Does it?
It represents the attach point for the relationship. I see later:

         Power Source relationships are intended to identify the
         connections between Power Interfaces.

The Power Interface definition should be improved.

>          There are some similarities between Power Interfaces and
>          network interfaces.  A network interface can be set to
>          different states, such as sending or receiving data on an
>          attached line.  Similarly, a Power Interface can be
>          receiving or providing power.
>       
>          Physically, a Power Interface instance can represent an AC
>          power socket, an AC power cord attached to a device, or an
>          8P8C (RJ45) PoE socket, etc.
>       
>       
>
>
>       4.3
>       <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.3>.
>       Energy Object Attributes
>
>
>       
>          This section describes categories of attributes for an
>          Energy Object.
>       
>       
>
>
>         4.3.1
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.3.1>.
>         Identification
>
>
>       
>          A Universal Unique Identifier (UUID) [RFC4122  <http://tools.ietf.org/html/rfc4122>] is used to
>          uniquely and persistently identify an Energy Object.
>          Ideally the UUID is used to distinguish the Energy Object
>          within the EnMS.
>       
>          Every Energy Object has an optional unique printable name.
>          Possible naming conventions are: textual DNS name, MAC
>          address of the device, interface ifName, or a text string
>          uniquely identifying the Energy Object.  As an example, in
>          the case of IP phones, the Energy Object name can be the
>          device's DNS name.
>       
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 16]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-17>
>       Internet-Draft              EMAN Framework      September 2013
>       
>          Additionally an alternate key is provided to allow an
>          Energy Object to be optionally linked with models in
>          different systems.
>       
>       
>
>
>         4.3.2
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.3.2>.
>         Context in General
>
>
>       
>          In order to aid in reporting and in differentiation between
>          Energy Objects, each object optionally contains information
>          establishing its business, site, or organizational context
>          within a deployment.
>       
>          Energy Objects contain a category attribute that broadly
>          describes how the object is used in a deployment. The
>          category indicates if the Energy Object is primarily
>          functioning as a consumer, producer, meter, distributor or
>          store of energy.
>       
>          Given the category and context of an object, an EnMS can
>          summarize or analyze measurements. For example, metered
>          usage reported by a meter and consumption usage reported by
>          a device connected to that meter may measure the same
>          usage. With the two measurements identified by category and
>          context an EnMS can make summarizations and inferences.
Shouldn't this text be part of 4.3.4?
>       
>       
>
>
>         4.3.3
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.3.3>.
>         Context: Importance
>
>
>       
>          An Energy Object can provide an importance value in the
>          range of 1 to 100 to help rank a device's use or relative
>          value to the site.  The importance range is from 1 (least
>          important) to 100 (most important).  The default importance
>          value is 1.
>       
>          For example: A typical office environment has several types
>          of phones, which can be rated according to their business
>          impact.  A public desk phone has a lower importance (for
>          example, 10) than a business-critical emergency phone (for
>          example, 100).  As another example: A company can consider
>          that a PC and a phone for a customer-service engineer are
>          more important than a PC and a phone for lobby use.
>       
>          Although EnMS and administrators can establish their own
>          ranking, the following example is a broad recommendation
>          for commercial deployments [CISCO-EW  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-CISCO-EW>]:
>       
>             90 to 100 Emergency response
>             80 to 90 Executive or business-critical
>             70 to 79 General or Average
>             60 to 69 Staff or support
>             40 to 59 Public or guest
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 17]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-18>
>       Internet-Draft              EMAN Framework      September 2013
>       
>             1  to 39 Decorative or hospitality
>       
>       
>
>
>         4.3.4
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.3.4>.
>         Context: Keywords
>
>
>       
>          An Energy Object can provide a set of keywords.  These
>          keywords are a list of tags that can be used for grouping,
>          summary reporting within or between Energy Management
>          Domains, and for searching.  All alphanumeric characters
>          and symbols (other than a comma), such as #, (, $, !, and
>          &, are allowed.  Potential examples are: IT, lobby,
>          HumanResources, Accounting, StoreRoom, CustomerSpace,
>          router, phone, floor2, or SoftwareLab.  There is no default
>          value for a keyword.
>          Multiple keywords can be assigned to a device.  White
>          spaces before and after the commas are excluded, as well as
>          within a keyword itself. In such cases, commas separate the
>          keywords and no spaces between keywords are allowed.  For
>          example, "HR,Bldg1,Private".
>       
>       
>
>
>         4.3.5
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.3.5>.
>         Context: Role
>
>
>       
>          An Energy Object contains a "role description" string that
>          indicates the purpose the Energy Object serves in the
>          deployment.  This could be a string describing the context
>          the device fulfills in deployment.
>       
>          Administrators can define any naming scheme for the role of
>          a device.  As guidance, a two-word role that combines the
>          service the device provides along with type can be used
>          [IPENERGY  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IPENERGY>].
>       
>          Example types of devices: Router, Switch, Light, Phone,
>          WorkStation, Server, Display, Kiosk, HVAC.
>       
>          Example Services by Line of Business:
>       
>             Line of Business     Service
>             Education            Student, Faculty, Administration,
>                                  Athletic
>             Finance              Trader, Teller, Fulfillment
>             Manufacturing        Assembly, Control, Shipping
>             Retail               Advertising, Cashier
>             Support              Helpdesk, Management
>             Medical              Patient, Administration, Billing
>       
>          Role as a two-word string: "Faculty Desktop", "Teller
>          Phone", "Shipping HVAC", "Advertising Display", "Helpdesk
>          Kiosk", "Administration Switch".
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 18]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-19>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>
>
>         4.3.6
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.3.6>.
>         Context: Domain
>
>
>       
>          An Energy Object contains a string to indicate membership
>          in an Energy Management Domain. An Energy Management Domain
>          can be any collection of devices in a deployment, but it is
>          recommended to map 1:1 with a metered or sub-metered
>          portion of the site.
>       
>          In building management, a meter refers to the meter
>          provided by the utility used for billing and measuring
>          power to an entire building or unit within a building.  A
>          sub-meter refers to a customer- or user-installed meter
>          that is not used by the utility to bill but is instead used
>          to get measurements from sub portions of a building.
>          An Energy Object should be a member of a single Energy
>          Management Domain therefore one attribute is provided.  The
>          Energy Management Domain may be configured on an Energy
>          Object.
>       
>       
>
>
>       4.4
>       <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.4>.
>       Measurements
>
>
>       
>          An Energy Object contains attributes to describe power,
>          energy and demand measurements.
>       
>          For the purposes of this framework, energy will be limited
>          to electrical energy in watt-hours.  Other forms of Energy
>          Objects that use or produce non-electrical energy may be
>          modeled as an Energy Object but must provide information
>          converted to and expressed in watt-hours.
>       
>          An analogy for understanding power versus energy
>          measurements can be made to speed and distance in
>          automobiles. Just as a speedometer indicates the rate of
>          change of distance (speed), a power measurement indicates
>          the rate of transfer of energy. The odometer in an
>          automobile measures the cumulative distance traveled and
>          similarly an energy measurement indicates the accumulated
>          energy transferred.
>       
>          Demand measurements are averages of power measurements over
>          time. So using the same analogy to an automobile: measuring
>          the average vehicle speed over multiple intervals of time
>          for a given distance travelled, demand is the average power
>          measured over multiple time intervals for a given energy
>          value.
>       
>       
>
>
>         4.4.1
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.4.1>.
>         Measurements: Power
>
>
>       
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 19]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-20>
>       Internet-Draft              EMAN Framework      September 2013
>       
>          Each Energy Object contains a Nameplate Power attribute
>          that describes the nominal power as specified by the
>          manufacturer. The EnMS can use the Nameplate Power for
>          provisioning, capacity planning and (potentially) billing.
>       
>          Each Energy Object will have information that describes the
In the future, avoid the future tense for future RFCs. :-)
>          present power information, along with how that measurement
>          was obtained or derived (e.g., actual, estimated, or
>          static).
>       
>          A power measurement is qualified with the units, magnitude
>          and direction of power flow, and is qualified as to the
>          means by which the measurement was made.
>       
>          Power measurement magnitude conforms to the [IEC61850  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEC61850>]
>          definition of unit multiplier for the SI (System
>          International) units of measure.  Measured values are
>          represented in SI units obtained by BaseValue * (10 ^
>          Scale).  For example, if current power usage of an Energy
>          Object is 3, it could be 3 W, 3 mW, 3 KW, or 3 MW,
>          depending on the value of the scaling factor.  3W implies
>          that the BaseValue is 3 and Scale = 0, whereas 3mW implies
>          BaseValue = 3 and ScaleFactor = -3.
>       
>          An Energy Object indicates how the power measurement was
>          obtained with a caliber attribute that indicates:
>             o  Whether the measurements were made at the device
>                itself or at a remote source.
>             o  Description of the method that was used to measure
>                the power  and whether this method can distinguish
>                actual or estimated values.
>             o  Accuracy for actual measured values
>       
>       
>
>
>         4.4.2
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.4.2>.
>         Measurements: Power Attributes
>
>
>       
>          Optionally, an Energy Object describes the Power
>          measurements with Power Attribute information reflecting
>          the electrical characteristics of the measurement. These
>          Power Attributes adhere to the [IEC-61850-7-2] standard for
>          describing AC measurements.
>       
>       
>
>
>         4.4.3
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.4.3>.
>         Measurements: Energy
>
>
>       
>          Optionally, an Energy Object that can report actual power
>          readings will have energy attributes that provide the
>          energy used, produced, or stored in kWh.
>       
>       
>
>
>         4.4.4
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.4.4>.
>         Measurements: Demand
>
>
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 20]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-21>
>       Internet-Draft              EMAN Framework      September 2013
>       
>          Optionally, an Energy Object will provide demand
>          information over time. Demand measurements can be provided
>          when the Energy Object is capable of measuring actual
>          power.
>       
>       
>
>
>       4.5
>       <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.5>.
>       Control
>
>
>       
>          An Energy Object can be controlled by setting a Power
>          State.  An Energy Object implements at least one set of
>          Power States consisting of at least two states, an on state
>          and an off state.
>       
>          Each Energy Object should indicate the sets of Power States
>          that it implements.
that it supports
This is more precise.
> Well-known Power State Sets are
>          registered with IANA.
>       
>          When a device is set to a particular Power State, it may be
>          busy. The device will set the desired Power State and then
>          update the actual Power State when it changes.  There are
>          then two Power State control variables: actual and
>          requested.
>          There are many existing standards for and implementations
>          of Power States.  An Energy Object can support a mixed set
>          of Power States defined in different standards. A basic
>          example is given by the three Power States defined in
>          IEEE1621 [IEEE1621  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEEE1621>]: on, off, and sleep. The DMTF [DMTF  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-DMTF>],
>          ACPI [ACPI  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-ACPI>], and PWG define larger numbers of Power States.
>       
>          The semantics of a Power State are specified by
>             a) the functionality provided by an Energy Object in
>          this state,
>             b) a limitation of the power that an Energy Object uses
>          in this state,
>             c) a combination of a) and b)
>       
>          The semantics of a Power State should be clearly defined.
>          Limitation (curtailment) of the power used by an Energy
>          Object in a state may specified by:
>             o  an absolute power value
>             o  a percentage value of power relative to the energy
>                object's nameplate power
>             o  an indication of power relative to another power
>                state. For example: Specify that power in state A is
>                less than in state B.
>             o  For supporting Power State management an Energy
>                Object provides statistics on Power States including
>                the time an Energy Object spent in a certain Power
>                State and the number of times an Energy Object
>                entered a power state.
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 21]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-22>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>          When requesting an Energy Object to enter a Power State an
>          indication of the Power State's name or number can be used.
>          Optionally an absolute or percentage of Nameplate Power can
>          be provided to allow the Energy Object to transition to a
>          nearest or equivalent Power State.
>       
>       
>
>
>         4.5.1
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.5.1>.
>         Power State Sets
>
>
>       
>          There are several standards and implementations of Power
>          State Sets.  An Energy Object can support one or multiple
>          Power State Set implementation(s) concurrently.
>       
>          There are currently three Power State Sets advocated:
>            IEEE1621(256) - [IEEE1621  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEEE1621>]
>            DMTF(512)     - [DMTF  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-DMTF>]
>            EMAN(768)     - [EMAN-MON-MIB  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-EMAN-MON-MIB>]
>       
>          The respective specific states related to each Power State
>          Set are specified in the following sections. The guidelines
>          for the modification of Power State Sets are specified in
>          the IANA Considerations Section.
>       
>       
>
>
>         4.5.2
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.5.2>.
>         Power State Set: IEEE1621
>
>
>       
>          The IEEE1621 Power State Set [IEEE1621  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEEE1621>] consists of 3
>          rudimentary states: on, off or sleep.
>       
>             o  on(0)    - The device is fully On and all features of
>                the device are in working mode.
>             o  off(1)   - The device is mechanically switched off
>                and does not consume energy.
>             o  sleep(2) - The device is in a power saving mode, and
>                some features may not be available immediately.
>       
>       
>
>
>         4.5.3
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.5.3>.
>         Power State Set: DMTF
>
>
>       
>          The DMTF [DMTF  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-DMTF>] standards organization has defined a power
>          profile standard based on the CIM (Common Information
>          Model) model that consists of 15 power states:
>       
>          {ON (2), SleepLight (3), SleepDeep (4), Off-Hard (5), Off-
>          Soft (6), Hibernate(7), PowerCycle Off-Soft (8), PowerCycle
>          Off-Hard (9), MasterBus reset (10), Diagnostic Interrupt
>          (11), Off-Soft-Graceful (12), Off-Hard Graceful (13),
>          MasterBus reset Graceful (14), Power-Cycle Off-Soft
>          Graceful (15), PowerCycle-Hard Graceful (16)}
>       
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 22]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-23>
>       Internet-Draft              EMAN Framework      September 2013
>       
>          The DMTF standard is targeted for hosts and computers.
>          Details of the semantics of each Power State within the
>          DMTF Power State Set can be obtained from the DMTF Power
>          State Management Profile specification [DMTF  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-DMTF>].
>       
>          The DMTF power profile extends ACPI power states. The
>          following table provides a mapping between DMTF and ACPI
>          Power State Set:
>       
>               DMTF                              ACPI
>              Reserved(0)
>              Reserved(1)
>              ON (2)                             G0-S0
>              Sleep-Light (3)                    G1-S1 G1-S2
>              Sleep-Deep (4)                     G1-S3
>              Power Cycle (Off-Soft) (5)         G2-S5
>              Off-hard (6)                       G3
>              Hibernate (Off-Soft) (7)           G1-S4
>              Off-Soft (8)                       G2-S5
>              Power Cycle (Off-Hard) (9)         G3
>              Master Bus Reset (10)              G2-S5
>              Diagnostic Interrupt (11)          G2-S5
>              Off-Soft Graceful (12)             G2-S5
>              Off-Hard Graceful (13)             G3
>              MasterBus Reset Graceful (14)      G2-S5
>              Power Cycle off-soft Graceful (15) G2-S5
>              Power Cycle off-hard Graceful (16) G3
>       
>       
>
>
>         4.5.4
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.5.4>.
>         Power State Set: IETF EMAN
>
>
>       
>          An EMAN Power State Set represents an attempt at a standard
>          approach for modeling the different levels of power of a
>          device.  The EMAN Power States are an expansion of the
>          basic Power States as defined in [IEEE1621  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEEE1621>] that also
>          incorporates the Power States defined in [ACPI  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-ACPI>] and [DMTF  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-DMTF>].
>          Therefore, in addition to the non-operational states as
>          defined in [ACPI  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-ACPI>] and [DMTF  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-DMTF>] standards, several
>          intermediate operational states have been defined.
>       
>          An Energy Object may implement fewer or more Power States
>          than a particular EMAN Power State Set specifies. In this
>          case, the Energy Object implementation can determine its
>          own mapping to the predefined EMAN Power States within the
>          EMAN Power State Set.
>       
>          There are twelve EMAN Power States that expand on
>          [IEEE1621  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEEE1621>]. The expanded list of Power States is derived
>          from [CISCO-EW  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-CISCO-EW>] and is divided into six operational states
>          and six non-operational states.
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 23]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-24>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>          The lowest non-operational state is 1 and the highest is 6.
>          Each non-operational state corresponds to an [ACPI  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-ACPI>] Global
>          and System state between G3 (hard-off) and G1 (sleeping).
>          Each operational state represents a performance state, and
>          may be mapped to [ACPI  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-ACPI>] states P0 (maximum performance
>          power) through P5 (minimum performance and minimum power).
>       
>          In each of the non-operational states (from mechoff(1) to
>          ready(6)), the Power State preceding it is expected to have
>          a lower Power value and a longer delay in returning to an
>          operational state:
>       
>                   mechoff(1) : An off state where no Energy Object
>          features are available.  The Energy Object is unavailable.
>          No energy is being consumed and the power connector can be
>          removed.
>       
>                   softoff(2) : Similar to mechoff(1), but some
>          components remain powered or receive trace power so that
>          the Energy Object can be awakened from its off state.  In
>          softoff(2), no context is saved and the device typically
>          requires a complete boot when awakened.
>       
>                   hibernate(3): No Energy Object features are
>          available.   The Energy Object may be awakened without
>          requiring a complete boot, but the time for availability is
>          longer than sleep(4). An example for state hibernate(3) is
>          a save to-disk state where DRAM context is not maintained.
>          Typically, energy consumption is zero or close to zero.
>       
>                   sleep(4)    : No Energy Object features are
>          available, except for out-of-band management, such as wake-
>          up mechanisms.  The time for availability is longer than
>          standby(5). An example for state sleep(4) is a save-to-RAM
>          state, where DRAM context is maintained.  Typically, energy
>          consumption is close to zero.
>       
>                   standby(5) : No Energy Object features are
>          available, except for out-of-band management, such as wake-
>          up mechanisms.  This mode is analogous to cold-standby.
>          The time for availability is longer than ready(6).  For
>          example processor context is may not be maintained.
>          Typically, energy consumption is close to zero.
>       
>                   ready(6)    : No Energy Object features are
>          available, except for out-of-band management, such as wake-
>          up mechanisms. This mode is analogous to hot-standby.  The
>          Energy Object can be quickly transitioned into an
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 24]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-25>
>       Internet-Draft              EMAN Framework      September 2013
>       
>          operational state.  For example, processors are not
>          executing, but processor context is maintained.
>       
>                   lowMinus(7) : Indicates some Energy Object
>          features may not be available and the Energy Object has
>          taken measures or selected options to provide less than
>          low(8) usage.
>       
>                   low(8)      : Indicates some features may not be
>          available and the Energy Object has taken measures or
>          selected options to provide less than mediumMinus(9) usage.
>       
>                   mediumMinus(9): Indicates all Energy Object
>          features are available but the Energy Object has taken
>          measures or selected options to provide less than
>          medium(10) usage.
>       
>                   medium(10)  : Indicates all Energy Object features
>          are available but the Energy Object has taken measures or
>          selected options to provide less than highMinus(11) usage.
>                   highMinus(11): Indicates all Energy Object
>          features are available and power usage is less than
>          high(12).
>       
>                   high(12)    : Indicates all Energy Object features
>          are available and the Energy Object is consuming the
>          highest power.
>       
>       
>
>
>         4.5.5
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.5.5>.
>         Power State Sets Comparison
>
>
>       
>          A comparison of Power States from different Power State
>          Sets can be seen in the following table:
>            IEEE1621  DMTF         ACPI           EMAN
>       
>            Non-operational states
>            off       Off-Hard     G3, S5         MechOff(1)
>            off       Off-Soft     G2, S5         SoftOff(2)
>            sleep     Hibernate    G1, S4         Hibernate(3)
>            sleep     Sleep-Deep   G1, S3         Sleep(4)
>            sleep     Sleep-Light  G1, S2         Standby(5)
>            sleep     Sleep-Light  G1, S1         Ready(6)
>       
>            Operational states:
>            on        on           G0, S0, P5     LowMinus(7)
>            on        on           G0, S0, P4     Low(8)
>            on        on           G0, S0, P3     MediumMinus(9)
>            on        on           G0, S0, P2     Medium(10)
>            on        on           G0, S0, P1     HighMinus(11)
>            on        on           G0, S0, P0     High(12)
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 25]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-26>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>       
>
>
>       4.6
>       <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.6>.
>       Relationships
>
>
>       
>          Two Energy Objects can establish an Energy Object
>          Relationship to model the deployment topology with respect
>          to Energy Management.
>       
>          Relationships are modeled with a Relationship class that
>          contains the UUID of the participants in the relationship
>          and a description of the type of relationship. The types of
>          relationships are:  power source, metering, and
>          aggregations.
>       
>             o  The Power Source Relationship gives a view of the
>                physical wiring topology.  For example: a data center
>                server receiving power from two specific Power
>                Interfaces from two different PDUs.
>       
>                Note: A power source relationship may or may not
>                change as the direction of power changes between two
>                Energy Objects. The relationship may remain to
>                indicate the change of power direction was unintended
>                or an error condition.
>       
>             o  The Metering Relationship gives the view of the
>                metering topology.  Physical meters can be placed
>                anywhere in a power distribution tree.  For example,
>                utility meters monitor and report accumulated power
>                consumption of the entire building. Logically, the
>                metering topology overlaps with the wiring topology,
>                as meters are connected to the wiring topology.  A
>                typical example is meters that clamp onto the
>                existing wiring.
>       
>             o  The Aggregation Relationship gives a model of devices
>                that may aggregate (sum, average, etc) values for
>                other devices.  The Aggregation Relationship is
>                slightly different compared to the other
>                relationships as this refers more to a management
>                function.
>       
>          In some situations, it is not possible to discover the
>          Energy Object Relationships, and they must be set by an
>          EnMS or administrator.  Given that relationships can be
>          assigned manually, the following sections describes
>          guidelines for use.
>       
>       
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 26]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-27>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>
>
>         4.6.1
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.6.1>.
>         Relationship Conventions and Guidelines
>
>
>       
>          This Energy Management framework does not impose many
>          "MUST" rules related to Energy Object Relationships. There
>          are always corner cases that could be excluded with too
>          strict specifications of relationships. However, this
>          Energy Management framework proposes a series of
>          guidelines, indicated with "SHOULD" and "MAY".
>       
>       
>
>
>         4.6.2
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.6.2>.
>         Guidelines: Power Source
>
>
>       
>          Power Source relationships are intended to identify the
>          connections between Power Interfaces. This is analogous to
>          a Layer 2 connection in networking devices (a "one-hop
>          connection").
>       
>          The preferred modeling would be for Power Interfaces to
>          participate in Power Source Relationships. It some cases
>          Energy Objects may not have the capability to model Power
>          Interfaces.  Therefore a Power Source Relationship can be
>          established between two Energy Objects or two non-connected
>          Power Interfaces.
>       
>          While strictly speaking Components and Power Interfaces on
>          the same device do provide or receive energy from each
>          other, the Power Source relationship is intended to show
>          energy transfer between Devices. Therefore the relationship
>          is implied when on the same Device.
>       
>          An Energy Object SHOULD NOT establish a Power Source
>          Relationship with a Component.
>             o  A Power Source Relationship SHOULD be established
>                with the next known Power Interface in the wiring
>                topology.
>       
>             o  The next known Power Interface in the wiring topology
>                would be the next device implementing the framework.
>                In some cases the domain of devices under management
>                may include some devices that do not implement the
>                framework. In these cases, the Power Source
>                relationship can be established with the next device
>                in the topology that implements the framework and
>                logically shows the Power Source of the device.
>       
>       
>       
>       
>       
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 27]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-28>
>       Internet-Draft              EMAN Framework      September 2013
>       
>             o  Transitive Power Source relationships SHOULD NOT be
>                established.  For example, if an Energy Object A has
>                a Power Source Relationship "Poweredby" with the
>                Energy Object B, and if the Energy Object B has a
>                Power Source Relationship "Poweredby" with the Energy
>                Object C, then the Energy Object A SHOULD NOT have a
>                Power Source Relationship "Poweredby" with the Energy
>                Object C.
>       
>       
>
>
>         4.6.3
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.6.3>.
>         Guidelines: Metering Relationship
>
>
>       
>          Metering Relationships are intended to show when one Device
>          acting as a Meter is measuring the power or energy at a
>          point in a power distribution system. Since one point of a
>          power distribution system may cover many Devices within a
>          wiring topology, this relationship type can be seen as an
>          arbitrary set.
>       
>          Some Devices, however, may include measuring hardware for
>          components and Power Interfaces or for the entire Device.
>          For example, some PDUs may have the ability to measure
>          Power for each Power Interface (metered by outlet). Others
>          may be able to control power at each Power Interface but
>          can only measure Power at the Power Inlet and a total for
>          all Power Interfaces (metered by device).
>       
>          While the Metering Relationship SHOULD be used between
>          devices, in some cases the Device MAY be modeled as an
>          Energy Object that meters all of its Power Outlets and each
>          Power Outlet MAY be metered by the Energy Object
>          representing the Device.
>       
>          In general:
>             o  A Metering Relationship MAY be established with any
>                other Energy Object, Component, or Power Interface.
>       
>             o  Transitive Metering relationships MAY be used.
>       
>             o  When there is a series of meters for one Energy
>                Object, the Energy Object MAY establish a Metering
>                relationship with one or more of the meters.
>       
>       
>
>
>         4.6.4
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.6.4>.
>         Guidelines: Aggregation
>
>
>       
>          Aggregation relationships are intended to identify when one
>          device is used to accumulate values from other devices.
>          Typically this is for energy or power values among devices
>          and not for Components or Power Interfaces on the same
>          device.
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 28]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-29>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>          The intent of Aggregation relationships is to indicate when
>          one device is providing aggregate values for a set of other
>          devices when it is not obvious from the power source or
>          simple containment within a device.
>       
>          Establishing aggregation relationships within the same
>          device would make modeling more complex and the aggregated
>          values can be implied from the use of Power Inlets, outlet
>          and Energy Object values on the same device.
>       
>          Since an EnMS is naturally a point of aggregation it is not
>          necessary to model aggregation for Energy Management
>          Systems.
>       
>          Aggregation SHOULD be used for power and energy. It MAY be

"Aggregation SHOULD be used for power and energy" is misleading
I guess you mean: "The Aggregation Relationship is intended for power and energy"

For the rest below.
Section 6 is a series of examples
I'm fine with section 7, 8, and 9 (IANA, which I wrote)

Regards, Benoit

>          used for aggregation of other values from the information
>          model, but the rules and logical ability to aggregate each
>          attribute is out of scope for this document.
>       
>          In general:
>             o  A Device SHOULD NOT establish an Aggregation
>                Relationship with Components contained on the same
>                device.
>             o  A Device SHOULD NOT establish an Aggregation
>                Relationship with the Power Interfaces contained on
>                the same device.
>             o  A Device SHOULD NOT establish an Aggregation
>                Relationship with an EnMS.
>             o  Aggregators SHOULD log or provide notification in the
>                case of errors or missing values while performing
>                aggregation.
>       
>       
>
>
>         4.6.5
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.6.5>.
>         Energy Object Relationship Extensions
>
>
>       
>          This framework for Energy Management is based on three
>          relationship types: Aggregation , Metering, and Power
>          Source.
>          This framework is defined with possible future extension of
>          new Energy Object Relationships in mind.
>          For example:
>             o  Some Devices that may not be IP connected. This can
>                be modeled with a proxy relationship to an Energy
>                Object within the domain. This type of proxy
>                relationship is left for further development.
>       
>       
>       
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 29]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-30>
>       Internet-Draft              EMAN Framework      September 2013
>       
>             o  A Power Distribution Unit (PDU) that allows physical
>                entities like outlets to be "ganged" together as a
>                logical entity for simplified management purposes,
>                could be modeled with an extension called a "gang
>                relationship", whose semantics would specify the
>                Energy Objects' grouping.
>       
>       
>
>
>     5
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-5>.
>     Energy Management Information Model
>
>
>       
>          This section presents an information model expression of
>          the concepts in this framework as a reference for
>          implementers. The information model is implemented as a MIB
>          in the different related IETF EMAN documents.  However,
>          other programming structures with different data models
>          could be used as well.
>       
>          Data modeling specifications of this information model may
>          where needed specify which attributes are required or
>          optional.
>       
>          EDITORs NOTE:  The working group is converging on the use
>          of code/pseudo-code rather than ascii UML diagram. IF so we
>          would have to define priimitve type as reference (eg. Int,
>          string, etc)If agreeable we can either indicate a BNF
>          syntax in a formal syntax section or use the following
>          table if obvious:
>       
>          Syntax
>       
>            UML Construct
>            [ISO-IEC-19501-2005  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-ISO-IEC-19501-2005>] Equivalent Notation
>            -------------------- ------------------------------------
>            Notes                // Notes
>            Class
>            (Generalization)     CLASS name {member..}
>            Sub-Class
>            (Specialization)     CLASS subclass
>                                       EXTENDS superclass {member..}
>            Class Member
>            (Attribute)          attribute : type
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 30]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-31>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>          Model
>       
>          CLASS EnergyObject {
>       
>             // identification / classification
>             index        : int
>             identifier   : uuid
>             alternatekey : string
>       
>             // context
>             domainName      : string
>             role            : string
>             keywords [0..n] : string
>             importance      : int
>       
>             // relationship
>             relationships [0..n] : Relationship
>       
>             // measurements
>             nameplate    : Nameplate
>             power     : PowerMeasurement
>             energy    : EnergyMeasurment
>             demand    : DemandMeasurement
>       
>             // control
>             powerControl [0..n] : PowerStateSet
>          }
>       
>          CLASS Device EXTENDS EnergyObject {
>                eocategory   : enum { producer, consumer, meter,
>          distributor, store }
>          }
>       
>          CLASS Component EXTENDS EnergyObject
>                eocategory   : enum { producer, consumer, meter,
>          distributor, store }
>          }
>       
>          CLASS Interface EXTENDS EnergyObject{
>                eoIfType : enum ( inlet, outlet, both}
>          }
>       
>          CLASS Nameplate {
>                nominalPower : PowerMeasurement
>                details      : URI
>          }
>       
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 31]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-32>
>       Internet-Draft              EMAN Framework      September 2013
>       
>          CLASS Relationship {
>                relationshipType    : enum { meters, meteredby,
>          powers, poweredby, aggregates, aggregatedby }
>                relationshipObject  : uuid
>          }
>       
>          CLASS Measurement {
>                multiplier: enum { -24..24}
>                caliber   : enum { actual, estimated, static }
>                accuracy  : enum { 0..10000} // hundreds of percent
>          }
>       
>          CLASS PowerMeasurement EXTENDS Measurement {
>                value          : long
>                units          : "W"
>                powerAttribute : PowerAttribute
>          }
>       
>          CLASS EnergyMeasurement EXTENDS Measurement {
>                startTime : time
>                units     : "kWh"
>                provided  : long
>                used      : long
>                produced  : long
>                stored    : long
>          }
>       
>          CLASS TimedMeasurement EXTENDS Measurement {
>                startTime  : timestamp
>                value      : Measurement
>                maximum    : Measurement
>          }
>       
>          CLASS TimeInterval {
>                value      : long
>                units      : enum { seconds, miliseconds,...}
>          }
>       
>          CLASS DemandMeasurement EXTENDS Measurement {
>                intervalLength : TimeInte
>          rval
>                interval       : long
>                intervalMode   : enum { periodic, sliding, total }
>                intervalWindow : TimeInterval
>                sampleRate     : TimeInterval
>                status         : enum { active, inactive }
>                measurements[0..n] : TimedMeasurements
>          }
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 32]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-33>
>       Internet-Draft              EMAN Framework      September 2013
>       
>          CLASS PowerStateSet {
>                powerSetIdentifier : int
>                name               : string
>                powerStates [0..n] : PowerState
>                operState          : int
>                adminState         : int
>                reason             : string
>                configuredTime     : timestamp
>          }
>       
>          CLASS PowerState {
>                powerStateIdentifier  : int
>                name             : string
>                cardinality      : int
>                maximumPower     : PowerMeasurement
>                totalTimeInState : time
>                entryCount       : long
>          }
>       
>          CLASS PowerAttribute {
>       
>             // container for attributes
>                   acQuality   : ACQuality
>          }
>       
>          CLASS ACQuality {
>             acConfiguration : enum {SNGL, DEL,WYE}
>             avgVoltage   : long
>             avgCurrent   : long
>             frequency    : long
>             unitMultiplier  : int
>             accuracy    : int
>             totalActivePower   : long
>             totalReactivePower : long
>             totalApparentPower : long
>             totalPowerFactor : long
>             phases [0..2]  : ACPhase
>          }
>       
>          CLASS ACPhase {
>             phaseIndex : long
>             avgCurrent : long
>             activePower : long
>             reactivePower : long
>             apparentPower : long
>             powerFactor : long
>          }
>       
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 33]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-34>
>       Internet-Draft              EMAN Framework      September 2013
>       
>          CLASS DelPhase EXTENDS ACPhase {
>             phaseToNextPhaseVoltage  : long
>             thdVoltage : long
>             thdCurrent : long
>          }
>       
>          CLASS WYEPhase EXTENDS ACPhase {
>             phaseToNeutralVoltage : long
>             thdCurrent : long
>             thdVoltage : long
>          }
>       
>       
>
>
>     6
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-6>.
>     Modeling Relationships between Devices
>
>
>       
>          In this section we give examples of how to use the Energy
>          Management framework relationships to model physical
>          topologies.  Where applicable, we show how the framework
>          can be applied when Devices have the capability to model
>          Power Interfaces.  We also show how the framework can be
>          applied when devices cannot support Power Interfaces but
>          only monitor information or control the Device as a whole.
>          For instance, a PDU may only be able to measure power and
>          energy for the entire unit without the ability to
>          distinguish among the inlets or outlet.
>       
>       
>
>
>       6.1
>       <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-6.1>.
>       Power Source Relationship
>
>
>       
>          The Power Source relationship is used to model the
>          interconnections between Devices, Components and/Power
>          Interfaces to indicate the source of energy for an Energy
>          Object. In the following examples we show variations on
>          modeling the reference topologies using relationships.
>       
>          Given for all cases:
>       
>          Device W: A computer with one power supply. Power interface
>          1 is an inlet for Device W.
>       
>          Device X: A computer with two power supplies. Power
>          interface 1 and power interface 2 are both inlets for
>          Device X.
>       
>          Device Y: A PDU with multiple Power Interfaces numbered
>          0..10. Power interface 0 is an inlet and power interface
>          1..10 are outlets.
>       
>          Device Z: A PDU with multiple Power Interfaces numbered
>          0..10. Power interface 0 is an inlet and power interface
>          1..10 are outlets.
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 34]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-35>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>          Case 1: Simple Device with one Source
>       
>          Physical Topology:
>       
>             o  Device W inlet 1 is plugged into Device Y outlet 8.
>       
>          With Power Interfaces:
>       
>             o  Device W has an Energy Object representing the
>                computer itself as well as one Power Interface
>                defined as an inlet.
>             o  Device Y would have an Energy Object representing the
>                PDU itself (the Device), with a Power Interface 0
>                defined as an inlet and Power Interfaces 1..10  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-10>
>                defined as outlets.
>       
>          The interfaces of the devices would have a Power Source
>          Relationship such that:
>          Device W inlet 1 is powered by Device Y outlet 8.
>       
>             +-------+------+       poweredBy +------+----------+
>             | PDU Y | PI 8 |-----------------| PI 1 | Device W |
>             +-------+------+ powers          +------+----------+
>       
>          Without Power Interfaces:
>       
>             o  Device W has an Energy Object representing the
>                computer.
>             o  Device Y would have an Energy Object representing the
>                PDU.
>       
>          The devices would have a Power Source Relationship such
>          that:
>          Device W is powered by Device Y.
>       
>       
>             +----------+       poweredBy +------------+
>             |  PDU Y   |-----------------|  Device W  |
>             +----------+ powers          +------------+
>       
>          Case 2: Multiple Inlets
>       
>          Physical Topology:
>             o  Device X inlet 1 is plugged into Device Y outlet 8.
>             o  Device X inlet 2 is plugged into Device Y outlet 9.
>       
>          With Power Interfaces:
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 35]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-36>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>             o  Device X has an Energy Object representing the
>                computer itself. It contains two Power Interfaces
>                defined as inlets.
>             o  Device Y would have an Energy Object representing the
>                PDU itself (the Device), with a Power Interface 0
>                defined as an inlet and Power Interfaces 1..10  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-10>
>                defined as outlets.
>       
>          The interfaces of the devices would have a Power Source
>          Relationship such that:
>          Device X inlet 1 is powered by Device Y outlet 8.
>          Device X inlet 2 is powered by Device Y outlet 9.
>       
>             +-------+------+        poweredBy+------+----------+
>             |       | PI 8 |-----------------| PI 1 |          |
>             |       |      |powers           |      |          |
>             | PDU Y +------+        poweredBy+------+ Device X |
>             |       | PI 9 |-----------------| PI 2 |          |
>             |       |      |powers           |      |          |
>             +-------+------+                 +------+----------+
>       
>          Without Power Interfaces:
>       
>             o  Device X has an Energy Object representing the
>                computer. Device Y has an Energy Object representing
>                the PDU.
>       
>       
>          The devices would have a Power Source Relationship such
>          that:
>          Device X is powered by Device Y.
>       
>             +----------+       poweredBy +------------+
>             |  PDU Y   |-----------------|  Device X  |
>             +----------+ powers          +------------+
>       
>          Case 3: Multiple Sources
>       
>          Physical Topology:
>             o  Device X inlet 1 is plugged into Device Y outlet 8.
>             o  Device X inlet 2 is plugged into Device Z outlet 9.
>       
>          With Power Interfaces:
>       
>       
>       
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 36]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-37>
>       Internet-Draft              EMAN Framework      September 2013
>       
>             o  Device X has an Energy Object representing the
>                computer itself. It contains two Power Interface
>                defined as inlets.
>             o  Device Y would have an Energy Object representing the
>                PDU itself  (the Device), with a Power Interface 0
>                defined as an inlet and Power Interfaces 1..10  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-10>
>                defined as outlets.
>             o  Device Z would have an Energy Object representing the
>                PDU itself  (the Device), with a Power Interface 0
>                defined as an inlet and Power Interfaces 1..10  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-10>
>                defined as outlets.
>       
>          The interfaces of the devices would have a Power Source
>          Relationship such that:
>          Device X inlet 1 is powered by Device Y outlet 8.
>          Device X inlet 2 is powered by Device Z outlet 9.
>       
>             +-------+------+        poweredBy+------+----------+
>             | PDU Y | PI 8 |-----------------| PI 1 |          |
>             |       |      |powers           |      |          |
>             +-------+------+                 +------+          |
>                                                     | Device X |
>             +-------+------+        poweredBy+------+          |
>             | PDU Z | PI 9 |-----------------| PI 2 |          |
>             |       |      |powers           |      |          |
>             +-------+------+                 +------+----------+
>       
>          Without Power Interfaces:
>       
>             o  Device X has an Energy Object representing the
>                computer. Device Y and Z would both have respective
>                Energy Objects representing each entire PDU.
>       
>          The devices would have a Power Source Relationship such
>          that:
>          Device X is powered by Device Y and powered by Device Z.
>       
>             +----------+           poweredBy +------------+
>             |  PDU Y   |---------------------|  Device X  |
>             +----------+ powers              +------------+
>       
>             +----------+           poweredBy +------------+
>             |  PDU Z   |---------------------|  Device X  |
>             +----------+ powers              +------------+
>       
>       
>
>
>       6.2
>       <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-6.2>.
>       Metering Relationship
>
>
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 37]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-38>
>       Internet-Draft              EMAN Framework      September 2013
>       
>          Case 1: Metering between two Devices
>       
>          The metering topology between two devices is closely
>          related to the power source topology.  It is based on the
>          assumption that in many cases the power provided and the
>          power received is the same for both peers of a power source
>          relationship.
>       
>          We define in this case a Metering Relationship between two
>          Devices or Power Interfaces of Devices that have a power
>          source relationship.  Power and energy values measured at
>          one peer of the power source relationship are reported for
>          the other peer as well.
>       
>          The Metering Relationship is independent of the direction
>          of the Power Source Relationship.  The most common case is
>          that values measured at the power provider are reported for
>          the power receiver.
>       
>          +-----+---+    meteredBy +--------+   poweredBy +-------+
>          |Meter| PI|--------------| switch |-------------| phone |
>          +-----+---+ meters       +--------+ powers      +-------+
>                  |                                           |
>                  |                                 meteredBy |
>                  +-------------------------------------------+
>                   meters
>       
>          Case 2: Metering among many Devices
>       
>          A Sub-meter in a power distribution system can logically
>          measure the
>          power or energy for all devices downstream from the meter
>          in the power distribution system.  As such, a Power
>          metering relationship can be seen as a relationship between
>          a meter Device and all of the devices downstream from the
>          meter.
>       
>          We define in this case a Power Source relationship between
>          a metering device and devices downstream from the meter.
>       
>          In cases where the Power Source topology cannot be
>          discovered or derived from the information available in the
>          Energy Management Domain, the Metering Topology can be used
>          to relate the upstream meter to the downstream devices in
>          the absence of specific power source relationships.
>       
>          A Metering Relationship can occur between devices that are
>          not directly connected, as shown in the following figure:
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 38]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-39>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>                             +---------------+
>                             |   Device 1    |
>                             +---------------+
>                             |      PI       |
>                             +---------------+
>                                     |
>                             +---------------+
>                             |     Meter     |
>                             +---------------+
>                                     .
>                                     .
>                                     .
>                    meters        meters           meters
>              +----------+   +----------+   +-----------+
>              | Device A |   | Device B |   | Device C  |
>              +----------+   +----------+   +-----------+
>       
>          An analogy to communications networks would be modeling
>          connections between servers (meters) and clients (devices)
>          when the complete Layer 2 topology between the servers and
>          clients is not known.
>       
>       
>
>
>       6.3
>       <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-6.3>.
>       Aggregation Relationship
>
>
>       
>          Some devices can act as aggregation points for other
>          devices.  For example, a PDU controller device may contain
>          the summation of power and energy readings for many PDU
>          devices.  The PDU controller will have aggregate values for
>          power and energy for a group of PDU devices.
>       
>          This aggregation is independent of the physical power or
>          communication topology.
>          An Aggregation Relationship is an Energy Object
>          Relationship where one Energy Object (called the Aggregate
>          Energy Object) aggregates the Energy Management information
>          of one or more other Energy Objects.  These Energy Objects
>          are said to have an Aggregation Relationship.
>       
>          The functions that the aggregation point may perform
>          include the calculation of values such as average, count,
>          maximum, median, minimum, or the listing (collection) of
>          the aggregation values, etc.
>          Based on the experience gained on aggregations at the IETF
>          [draft-ietf-ipfix-a9n-08  <http://tools.ietf.org/html/draft-ietf-ipfix-a9n-08>], the aggregation function in the
>          EMAN framework is limited to the summation.
>       
>          When aggregation occurs across a set of entities, values to
>          be aggregated may be missing for some entities.  The EMAN
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 39]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-40>
>       Internet-Draft              EMAN Framework      September 2013
>       
>          framework does not specify how these should be treated, as
>          different implementations may have good reason to take
>          different approaches.  One common treatment is to define
>          the aggregation as missing if any of the constituent
>          elements are missing (useful to be most precise). Another
>          is to treat the missing value as zero (useful to have
>          continuous data streams).
>       
>          The specifications of aggregation functions are out of
>          scope of the EMAN framework, but must be clearly specified
>          by the equipment vendor.
>       
>       
>
>
>     7
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-7>.
>     Relationship to Other Standards
>
>
>       
>          This Energy Management framework uses, as much as possible,
>          existing standards especially with respect to information
>          modeling and data modeling [RFC3444  <http://tools.ietf.org/html/rfc3444>].
>       
>          The data model for power- and energy-related objects is
>          based on [IEC61850  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEC61850>].
>       
>          Specific examples include:
>             o  The scaling factor, which represents Energy Object
>                usage magnitude, conforms to the [IEC61850  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEC61850>]
>                definition of unit multiplier for the SI (System
>                International) units of measure.
>             o  The electrical characteristic is based on the ANSI
>                and IEC Standards, which require that we use an
>                accuracy class for power measurement.  ANSI and IEC
>                define the following accuracy classes for power
>                measurement:
>             o  IEC 62053-22  60044-1 class 0.1, 0.2, 0.5, 1  3.
>             o  ANSI C12.20 class 0.2, 0.5
>             o  The electrical characteristics and quality adhere
>                closely to the [IEC61850-7-2  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEC61850-7-2>] standard for describing
>                AC measurements.
>             o  The power state definitions are based on the DMTF
>                Power State Profile and ACPI models, with operational
>                state extensions.
>       
>       
>
>
>     8
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-8>.
>     Security Considerations
>
>
>       
>          Regarding the data attributes specified here, some or all
>          may be considered sensitive or vulnerable in some network
>          environments. Reading or writing these attributes without
>          proper protection such as encryption or access
>          authorization may have negative effects on the network
>          capabilities.
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 40]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-41>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>
>
>       8.1
>       <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-8.1>.
>       Security Considerations for SNMP
>
>
>       
>          Readable objects in MIB modules (i.e., objects with a MAX-
>          ACCESS other than not-accessible) may be considered
>          sensitive or vulnerable in some network environments.  It
>          is important to control GET and/or NOTIFY access to these
>          objects and possibly to encrypt the values of these objects
>          when sending them over the network via SNMP.
>       
>          The support for SET operations in a non-secure environment
>          without proper protection can have a negative effect on
>          network operations.
>       
>          For example:
>             o  Unauthorized changes to the Energy Management Domain
>                or business context of a device may result in
>                misreporting or interruption of power.
>             o  Unauthorized changes to a power state may disrupt the
>                power settings of the different devices, and
>                therefore the state of functionality of the
>                respective devices.
>             o  Unauthorized changes to the demand history may
>                disrupt proper accounting of energy usage.
>       
>          With respect to data transport, SNMP versions prior to
>          SNMPv3 did not include adequate security.  Even if the
>          network itself is secure (for example, by using IPsec),
>          there is still no secure control over who on the secure
>          network is allowed to access and GET/SET
>          (read/change/create/delete) the objects in these MIB
>          modules.
>       
>          It is recommended that implementers consider the security
>          features as provided by the SNMPv3 framework (see
>          [RFC3410], section 8  <http://tools.ietf.org/html/rfc3410#section-8>), including full support for the
>          SNMPv3 cryptographic mechanisms (for authentication and
>          privacy).
>          Further, deployment of SNMP versions prior to SNMPv3 is not
>          recommended.  Instead, it is recommended to deploy SNMPv3
>          and to enable cryptographic security.  It is then a
>          customer/operator responsibility to ensure that the SNMP
>          entity giving access to an instance of these MIB modules is
>          properly configured to give access to the objects only to
>          those principals (users) that have legitimate rights to GET
>          or SET (change/create/delete) them.
>       
>       
>       
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 41]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-42>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>
>
>     9
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-9>.
>     IANA Considerations
>
>
>       
>
>
>       9.1
>       <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-9.1>.
>       IANA Registration of new Power State Sets
>
>
>       
>          This document specifies an initial set of Power State Sets.
>          The list of these Power State Sets with their numeric
>          identifiers is given isSection 4  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4>. IANA maintains the lists
>          of Power State Sets.
>       
>          New assignments for Power State Set are administered by
>          IANA through Expert Review [RFC5226  <http://tools.ietf.org/html/rfc5226>], i.e., review by one
>          of a group of experts designated by an IETF Area Director.
>          The group of experts MUST check the requested state for
>          completeness and accuracy of the description. A pure vendor
>          specific implementation of Power State Set shall not be
>          adopted; since it would lead to proliferation of Power
>          State Sets.
>       
>          Power states in a Power State Set are limited to 255
>          distinct values. New Power State Set must be assigned the
>          next available numeric identifier that is a multiple of
>          256.
>       
>       
>
>
>         9.1.1
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-9.1.1>.
>         IANA Registration of the IEEE1621 Power State Set
>
>
>       
>          This document specifies a set of values for the IEEE1621
>          Power State Set [IEEE1621  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-IEEE1621>].  The list of these values with
>          their identifiers is given inSection 4.6.2  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.6.2>.  IANA created
>          a new registry for IEEE1621 Power State Set identifiers and
>          filled it with the initial list of identifiers.
>       
>          New assignments (or potentially deprecation) for the
>          IEEE1621 Power State Set is administered by IANA through
>          Expert Review [RFC5226  <http://tools.ietf.org/html/rfc5226>], i.e., review by one of a group of
>          experts designated by an IETF Area Director.  The group of
>          experts must check the requested state for completeness and
>          accuracy of the description.
>       
>       
>
>
>         9.1.2
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-9.1.2>.
>         IANA Registration of the DMTF Power State Set
>
>
>       
>          This document specifies a set of values for the DMTF Power
>          State Set.  The list of these values with their identifiers
>          is given inSection 4  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4>. IANA has created a new registry for
>          DMTF Power State Set identifiers and filled it with the
>          initial list of identifiers.
>       
>          New assignments (or potentially deprecation) for the DMTF
>          Power State Set is administered by IANA through Expert
>          Review [RFC5226  <http://tools.ietf.org/html/rfc5226>], i.e., review by one of a group of experts
>          designated by an IETF Area Director.  The group of experts
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 42]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-43>
>       Internet-Draft              EMAN Framework      September 2013
>       
>          must check the conformance with the DMTF standard [DMTF  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#ref-DMTF>],
>          on the top of checking for completeness and accuracy of the
>          description.
>       
>       
>
>
>         9.1.3
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-9.1.3>.
>         IANA Registration of the EMAN Power State Set
>
>
>       
>          This document specifies a set of values for the EMAN Power
>          State Set.  The list of these values with their identifiers
>          is given inSection 4.6.4  <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-4.6.4>.  IANA has created a new registry
>          for EMAN Power State Set identifiers and filled it with the
>          initial list of identifiers.
>       
>          New assignments (or potentially deprecation) for the EMAN
>          Power State Set is administered by IANA through Expert
>          Review [RFC5226  <http://tools.ietf.org/html/rfc5226>], i.e., review by one of a group of experts
>          designated by an IETF Area Director.  The group of experts
>          must check the requested state for completeness and
>          accuracy of the description.
>       
>       
>
>
>         9.1.4
>         <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-9.1.4>.
>         Batteries Power State Set
>
>
>       
>          Batteries have operational and administrational states that
>          could be represented as a power state set. Since the work
>          for battery management is parallel to this document, we are
>          not proposing any Power State Sets for batteries at this
>          time.
>       
>       
>
>
>       9.2
>       <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-9.2>.
>       Updating the Registration of Existing Power State Sets
>
>
>       
>          With the evolution of standards, over time, it may be
>          important to deprecate some of the existing the Power State
>          Sets, or to add or deprecate some Power States within a
>          Power State Set.
>       
>          The registrant shall publish an Internet-draft or an
>          individual submission with the clear specification on
>          deprecation of Power State Sets or Power States registered
>          with IANA.  The deprecation or addition shall be
>          administered by IANA through Expert Review [RFC5226  <http://tools.ietf.org/html/rfc5226>], i.e.,
>          review by one of a group of experts designated by an IETF
>          Area Director. The process should also allow for a
>          mechanism for cases where others have significant
>          objections to claims on deprecation of a registration.
>       
>       
>
>
>     10
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-10>.
>     References
>
>
>       
>       Normative References
>       
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 43]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-44>
>       Internet-Draft              EMAN Framework      September 2013
>       
>          [RFC2119]  Bradner, S., "Key words for use in RFCs to
>                    Indicate Requirement Levels",BCP 14  <http://tools.ietf.org/html/bcp14>,RFC 2119  <http://tools.ietf.org/html/rfc2119>,
>                    March 1997
>       
>          [RFC3410]  Case, J., Mundy, R., Partain, D., and B.
>                    Stewart, "Introduction and Applicability
>                    Statements for Internet Standard Management
>                    Framework ",RFC 3410  <http://tools.ietf.org/html/rfc3410>, December 2002
>       
>          [RFC4122] Leach, P., Mealling, M., and R. Salz," A
>                    Universally Unique Identifier (UUID) URN
>                    Namespace",RFC 4122  <http://tools.ietf.org/html/rfc4122>, July 2005
>       
>          [RFC5226] Narten, T., and H. Alvestrand, "Guidelines for
>                    Writing an IANA Considerations Section in RFCs",
>                    RFC 5226  <http://tools.ietf.org/html/rfc5226>, May 2008
>       
>          [RFC6933]  Bierman, A. and K. McCloghrie, "Entity MIB
>                    (Version4)",RFC 6933  <http://tools.ietf.org/html/rfc6933>, May 2013
>       
>          [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences
>                    between Information Models and Data Models",RFC  <http://tools.ietf.org/html/rfc3444>
>                    3444  <http://tools.ietf.org/html/rfc3444>, January 2003
>       
>          [ISO-IEC-19501-2005] ISO/IEC 19501:2005, Information
>                    technology, Open Distributed Processing --
>                    Unified Modeling Language (UML), January 2005
>       
>       Informative References
>       
>          [RFC2578] McCloghrie, K., Perkins, D., and J.
>                    Schoenwaelder, "Structure of Management
>                    Information Version 2 (SMIv2",RFC 2578  <http://tools.ietf.org/html/rfc2578>, April
>                    1999
>       
>       
>          [RFC5101bis] Claise, B., Ed., and Trammel, T., Ed.,
>                    "Specification of the IP Flow Information Export
>                    (IPFIX) Protocol for the Exchange of IP Traffic
>                    Flow Information ",draft-ietf-ipfix-protocol-  <http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-08>
>                    rfc5101bis-08  <http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-08>, (work in progress), June 2013
>       
>          [RFC6020] M. Bjorklund, Ed., " YANG - A Data Modeling
>                    Language for the Network Configuration Protocol
>                    (NETCONF)",RFC 6020  <http://tools.ietf.org/html/rfc6020>, October 2010
>       
>          [ACPI] "Advanced Configuration and Power Interface
>                    Specification",http://www.acpi.info/spec30b.htm
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 44]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-45>
>       Internet-Draft              EMAN Framework      September 2013
>       
>          [IEEE1621]  "Standard for User Interface Elements in Power
>                    Control of Electronic Devices Employed in
>                    Office/Consumer Environments", IEEE 1621,
>                    December 2004
>       
>          [LLDP]  IEEE Std 802.1AB, "Station and Media Control
>                    Connectivity Discovery", 2005
>       
>          [LLDP-MED-MIB]  ANSI/TIA-1057, "The LLDP Management
>                    Information Base extension module for TIA-TR41.4
>                    media endpoint discovery information", July 2005
>       
>          [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B.,
>                    and M. Chandramouli, "Requirements for Energy
>                    Management",draft-ietf-eman-requirements-14  <http://tools.ietf.org/html/draft-ietf-eman-requirements-14>,
>                    (work in progress), May 2013
>       
>          [EMAN-OBJECT-MIB] Parello, J., and B. Claise, "Energy
>                    Object Contet MIB",draft-ietf-eman-energy-aware-  <http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-08>
>                    mib-08  <http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-08>, (work in progress), April 2013
>       
>          [EMAN-MON-MIB] Chandramouli, M.,Schoening, B., Quittek, J.,
>                    Dietz, T., and B. Claise, "Power and Energy
>                    Monitoring MIB",draft-ietf-eman-energy-  <http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-05>
>                    monitoring-mib-05  <http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-05>, (work in progress), April 2013
>       
>          [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, "
>                    Definition of Managed Objects for Battery
>                    Monitoring",draft-ietf-eman-battery-mib-08  <http://tools.ietf.org/html/draft-ietf-eman-battery-mib-08>,
>                    (work in progress), February 2013
>       
>          [EMAN-AS] Schoening, B., Chandramouli, M., and B. Nordman,
>                    "Energy Management (EMAN) Applicability
>                    Statement",draft-ietf-eman-applicability-  <http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-03>
>                    statement-03  <http://tools.ietf.org/html/draft-ietf-eman-applicability-statement-03>, (work in progress), April 2013
>       
>          [ITU-T-M-3400] TMN recommandation on Management Functions
>                    (M.3400), 1997
>       
>          [NMF] "Network Management Fundamentals", Alexander Clemm,
>                    ISBN: 1-58720-137-2, 2007
>       
>          [TMN] "TMN Management Functions : Performance Management",
>                    ITU-T M.3400
>       
>          [IEEE100] "The Authoritative Dictionary of IEEE Standards
>                    Terms"
>                    http://ieeexplore.ieee.org/xpl/mostRecentIssue.js
>                    p?punumber=4116785
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 45]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-46>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>          [ISO50001] "ISO 50001:2011 Energy management systems -
>                    Requirements with guidance for use",
>                    http://www.iso.org/
>       
>          [IEC60050] International Electrotechnical Vocabulary
>                    http://www.electropedia.org/iev/iev.nsf/welcome?o
>                    penform
>       
>          [IEC61850] Power Utility Automation,
>                    http://www.iec.ch/smartgrid/standards/
>       
>          [IEC61850-7-2] Abstract communication service interface
>                    (ACSI),http://www.iec.ch/smartgrid/standards/
>       
>          [IEEE-802.3at] IEEE 802.3 Working Group, "IEEE Std 802.3at-
>                    2009 - IEEE Standard for Information technology -
>                    Telecommunications and information exchange
>                    between systems - Local and metropolitan area
>                    networks - Specific requirements - Part 3:
>                    Carrier Sense Multiple Access with Collision
>                    Detection (CSMA/CD) Access Method and Physical
>                    Layer Specifications - Amendment: Data Terminal
>                    Equipment (DTE) -  Power via Media Dependent
>                    Interface (MDI) Enhancements", October 2009
>       
>          [DMTF] "Power State Management Profile DMTF  DSP1027
>                    Version 2.0"  December 2009
>                    http://www.dmtf.org/sites/default/files/standards  <http://www.dmtf.org/sites/default/files/standards/documents/DSP1027_2.0.0.pdf>
>                    /documents/DSP1027_2.0.0.pdf  <http://www.dmtf.org/sites/default/files/standards/documents/DSP1027_2.0.0.pdf>
>       
>          [IPENERGY] R. Aldrich, J. Parello "IP-Enabled Energy
>                    Management", 2010, Wiley Publishing
>       
>          [X.700]  CCITT Recommendation X.700 (1992), Management
>                    framework for Open Systems Interconnection (OSI)
>                    for CCITT applications
>       
>          [ASHRAE-201] "ASHRAE Standard Project Committee 201
>                          (SPC 201)Facility Smart Grid Information
>                          Model",http://spc201.ashraepcs.org
>       
>          [CHEN] "The Entity-Relationship Model: Toward a Unified
>                    View of Data",  Peter Pin-shan Chen, ACM
>                    Transactions on Database Systems, 1976
>       
>       
>       
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 46]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-47>
>       Internet-Draft              EMAN Framework      September 2013
>       
>          [CISCO-EW] "Cisco EnergyWise Design Guide",  John Parello,
>                    Roland Saville, Steve Kramling, Cisco Validated
>                    Designs, September 2010,
>                    http://www.cisco.com/en/US/docs/solutions/Enterpr  <http://www.cisco.com/en/US/docs/solutions/Enterprise/Borderless_Networks/Energy_Management/energyw>
>                    ise/Borderless_Networks/Energy_Management/energyw  <http://www.cisco.com/en/US/docs/solutions/Enterprise/Borderless_Networks/Energy_Management/energyw>
>                    isedg.html
>       
>       
>       
>       
>
>
>     11
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#section-11>.
>     Acknowledgments
>
>
>       
>          The authors would like to Michael Brown for his editorial
>          work improving the text dramatically. Thanks to Rolf Winter
>          for his feedback and to Bill Mielke for feedback and very
>          detailed review. Thanks to Bruce Nordman for brainstorming
>          with numerous conference calls and discussions. Finally,
>          the authors would like to thank the EMAN chairs: Nevil
>          Brownlee, Bruce Nordman, and Tom Nadeau.
>       
>          This document was prepared using 2-Word-v2.0.template.dot.
>       
>       Authors' Addresses
>       
>          John Parello
>          Cisco Systems, Inc.
>          3550 Cisco Way
>          San Jose, California 95134
>          US
>       
>          Phone: [phone]
>          Email:[e-mail]
>       
>          Benoit Claise
>          Cisco Systems, Inc.
>          De Kleetlaan 6a b1
>          Diegem 1813
>          BE
>       
>          Phone: [phone]
>          Email:[e-mail]
>       
>       
>          Brad Schoening
>          44 Rivers Edge Drive
>          Little Silver, NJ 07739
>          US
>       
>          Phone:
>          Email:[e-mail]
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 47]
>       
>     <http://tools.ietf.org/html/draft-ietf-eman-framework-10#page-48>
>       Internet-Draft              EMAN Framework      September 2013
>       
>       
>       
>          Juergen Quittek
>          NEC Europe Ltd.
>          Network Laboratories
>          Kurfuersten-Anlage 36
>          69115 Heidelberg
>          Germany
>       
>          Phone: [phone]
>          EMail:[e-mail]
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       
>       Claise et al.           Expires March 23, 2014      [Page 48]
>