Subject: [OPSAWG] Review of draft-claise-energy-monitoring-mib-01

From: "Juergen Quittek" <[email-masked]>
Date: Tue, 9 Mar 2010 17:09:27 +0100

Dear all,

Plea find my review of draft-claise-energy-monitoing-mib-01 inline below.

After reviewng two short related draft rahter quickly,
it took me significantly more time to review his one,
because it is much more elaborated.

I look forward to the discssions we will have in Anaheim.

    Juergen

>      Network Working Goup                                  B. Claise
>      Internet-Draft                                  M. Chandramouli
>      Intended Status: Standads Track                      J. Parello
>      Expires: August 5, 2010                             B. Schoening
>                                                   Cisco Systems, Inc.
>                  
>                                                      Feruary 5, 2010
>       
>                              EnergyMonitoring MIB
>                      draft-laise-energy-monitoring-mib-01

 [snip]

>     Abstract 
> 
>         This documentdefines the Management Infrmation Base (MIB)

"the" -> "a portion of the"

>         for theenergy monitoring of network elements.

 [snip]

>      3. Terminology
> 
>         Energonitor Entity
>       
>       
>     <Claise, et. Al>        Expires August 5, 2011            [Pge 4]
>          
>      Internet-Draft        <Energy Montoring MIB>           Feb 2010
>          
>            An nergyMonitor Entity is a system of one or more

Wouldn't it be sufficientto call it just "EnergyMonitor". In the text
you call is mst times "EnergyMonitor Entity", but several times just
"EnergyMonitor".  think the latter is sufficient.

Why is"EnergyMonitor" one word and not two like "Enrgy Monitor"?
 
>            component, that provides power or draws power.  It can be
>            independently managed from a pwer monitoring and power state
>            configuration point of view.  This entitymay be represented
>           by a physical component referenced using the EntPhysicalTabl
>            from the Entity MIB RFC 2737.
>             
>           Examples of EnergyMonitor Entities are a router line card, a
>           motherboard with a CPU, etc.

In section 4 and in the MIB definition here is also the option mantion
included the EnergyMotor Entity is a meter. This should be overed here.
>          
>         EnergyMonitor Level
>          
>           A uniform way to classify power setings on an EnergyMonitor
>            Etity.  Levels are guidelines for the mnufacturers of

I don't thnk that levels by themselves can be guidelines.
But level specifications can be guidelines:
"Levels" -> "Level specifications"?

>            etity (e.g., shut, hibernate, sleep, standby).
>             
>          
         EnergyMonitor Scale
>          
>            A scale used to rpresent smaller or larger quantities of
>            EnergyMontor usage.  It conforms to the standard prefixe>            for the SI (System Interntional) units of measure.  Measured
>            values are reresented in SI units obtained by BaseValue * 10
>           raised to the power of Scale.
>            
>            For example, ifcurrent usage of an Energyonitor Entity is
>            3, it could be 3 W, 3 mW, 3 KW, 3 MW depeding on the value
>            of EnergyMonitoScale.
>             
>             
>        EnergyMonitor Domain
>          
>           AEnergyMonitor Domain is a name or name sace which
>           logically groups tgether EnergyMonitor Entities that
>          comprises a unit o manageable power consumption.  For
>           example, all phones i a floor, all EnergyMonitor Entities
>           from a specific building,or all EnergyMonitor Entities of a
>           specific device type for hich a common profile is deployed.

Grouping of devices that contain each other can be modeled in a better
Way by the entity ontainment tree of the Entity MIB module.

For vices that are physically separate, such as all phones on a floor,
I don't think that this information should be stored in the MIB module.
Grouing of separate devices is the job of the management system monitoring
Them. The management syste can do much more than the vague and fla
concept of a domainname offers. NMSs can(and actually do) group devices
according to veral aspects and use hierarchical or otherwie structured
Groupings. Also they can (and actually do) apply different grouping schemes
to he same set of devices for different purposes, for example an energy
Consumer group ad a provider group in parallel t one group per building
level.
For none o these schemes it is required to storethe group name(s) on the
dvice itself. Also, a relocation of a device from one floor to aother one
would require a re-configuration if the floor domain is stored on the
device.

>           From the point of monitoring power consumptin, it is useful

Power is an energy rate. Energy can be consumed. I dont say that power
cannot be consumed. But the consumption of a rate sounds like a non-trivial
concept that deserves further explanation. Probably, the all instances of
"power consumption" in this draft refer to "energy consmption" and can
be replaced accordingly.
 
>           to report the total energconsumed as the sum of energy
>           consumed by all th EnergyMonitor Entities of the
>           EergyMonitor Domain.
>       
>       
> 
> 
> >       
>       
>      <Claise, et. Al        Expires August 5, 2011           [Page 5]
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 201>      4. Concepts 
> 
>         EnergyMonitor Levels represent the e of twelve power
>         management states of an entity.  Each EnergyMonitor Level
>         corresponds to a global, system, andperformance state in the
>         ACPI model.
>          
>                   Level        ACPI Global/System      Name
>                                     State
>          
>         Non-operational states:
>          
>                     1               G3, S5           Mech Off
>                     2               G2, S5           Soft Off
>                     3               G1, S4          Hibernate
>                    4               G2, S3           Sleep, Save-to-RAM
                     5               G2, S2           Stadby
>                     6               G2, S1           Ready
>         Operational states:
>                     7               G0, S0, P5       Low
>                    8               G0, S0, P4       Frugal
>                     9              G0, S0, P3       Mediu
>                    10               G0, S0, P2       Reduced
>                   11               G0, S0, P1       High
>                   12               G0, S0, P0       Full

The non-operatioal states seem to be clear, but the operationa states
may be hard to apply in an ineroperable way to a router, a line card,
Etc. 

>         For example the energy state of the EnergyMonitor Enity is 9,
>         to indicate the entity is medium power consuption operational

"is medium" -> "is in edium"
 
>         state. 
>          
> 
>        The emEnergyUsageCategory MIB obect, specified as a read-only
>       object, specifies the enery usage type of the EnergyMonitor
>        Entity: energy consume, energy producer, or meter.  The

Maybe it would be better to place "producer" with "provider".
A battery, for example can wod act as consumer when charging
And as "provider" when discharging. "producer" would not be ppropriate
In such an example. Also a PoE switch may be seen as "provider" at ist
Pors, but not as "producer".

>        emEnergyUsage, specified as Intger32, can have a positive or
>        negatie value, corresponding with the uage type in
>        emEnergyUsageCategory, determining whethe the EnergyMonitor
>        Entity consumes or produces power in cae of "consumer" and
>        "producer".
> 
>        An Energ Monitor Entity should have an eName, and a unique
>        EnergyMonitor index emIndex, and potntially an

enMane ans emIndex should be introduced to the reader before usng it.

>        entityPhysicalIndex fom the ENTITY-MIB [RFC4133, if supported
>        by the EnergyMonitor Entity.  The emName canbe configured or
>        discovered by DNS.  Possible emName are: teual DNS name, MAC-

I am missing a statement like
  "If entPhysicalName iset for the entity, then emName should be empty".

>        address of thdevice, interface ifName, or a tex string
>        uniquely identifying the entty.  The emName should ideally be>        unique.  As an example, in the case of phones, emNamecan be
>        discovered by DNS and can be the IP address or MAC-ddress.  In
>        the case of router/switch line cards, th emName shall be text

"shall" o "SHALL"?

>        string.  That EnergyMonitor Entity can bea member of a
>        EnergyMonitor Domin.  The EnergyMonitor Domin could map 1-1
>        with a metered or sub-meered portion of the customers site.  It
>        can be usedto further sub divide the deployment dow to finer
>        EnergyMnitor Domains such as a lab, data center, rack, et.
> 
>         With the possible evolution of this draf, to a framework
>         document, thenotion of EnergyMonitor Doain shall be useful.
>          
>         For an nergyMonitor Entity, instantaneous energy usage is
         reported using emEnergyUsage an the unit magnitude of
>        measurement is specified in emEnergyUnits whch is based on
>         EnergyMonitorPowerScale.
>          
>        Nameplate power consumption of an EnergMonitor Entity is
>         specified by the vendor as the maximum capacity required to
>        safely power the device.  Often this label is a conservative
>         number an is the worst case power draw of all elements in a
>         flly configured system.  While th actual utilization of an
>         entity can be lower, Nameplate por consumption is important
>         for power provisioning, capacity planing and billing.
>         In addition, to measuremet of power consumption, an approach to
>         chaacterize the power demand is also presented in te MIB.  It
>         is well-known, in theelectrical utility perspective, the demand
>         harges can weigh on par with actual energy charge.  So, in
>         addition to measuring power cnsumption, it is useful to
>         characterize the demad.  The demand can be described as average
>         powe usage of an entity over a time window, called demand
>        interval, typically 15 minutes.  The highet peak demand
>         measured over a time horizon, say1 month or 1 year is often the
>         bass for usage charge.  For example, a single wndow of time of
>         high usage can penalize the poer consumption charges.  It is
>        relevant to measure the emand, only when there are actual power
>         measurements from an EnrgyMonitor Entity.  There are cases,
>         wherein th power measurement of an EnergyMonitor Entity i
>         assumed, or predicted as pointed in the MIB OID
>         EnergyUsagCaliber.

Object EnergyUsageCalier is not of type OID.
"in the MIB OID" -> "in the ESRIPTION clause of object"

>         Two tables ae introduced to characterize the energy demand -
>        emDemandTable and emDemandCntrolTable.  emDemandControl Table
>        consists of parametes of the duration of the demand interval
>         specified in seconds, mDemandControlIntervalLength, (for e.g.
>       
>      
>      <Claise, et. Al>        Expires August , 2011            [Page 7]
>          
>      Internet-Draft        <Energy Montoring MIB>           Feb 2010
>        15 minutes); The number of demand intervls kept in the
>         emDemandTable, emDemandCotrolIntervalNumber, ;
>         mDemandControlSampleRate which is intenal to the device to
>        calculate energy usage.  Judicious choice of SamplingRate would
>         help in accurae measurement of energy and ensure that it does
>         impose excessive polling buden.  The emDemandControlStatus is
>         useful to specify the powermeasurement is actual and thus to
>        indicate if the emDemandTable entries exist ornot.
>       
>         emDemand Table consists of measurements of energy
>         DmandIntervalEnergyUsed, the scale of energy measurement -
>         DemandIntervalEnergyScale and the maximum observed demand in a
>         window - emDemandIntervalMaxf
>          
>         Various efficiency metrics can be derived and tracked with the
>         uage data present in this MIB module.  For example,
>          
>          Per-packet energy costs for a networking device (router or
>          switch) can be calculated by an network management system.
>           The ackets count can be determined from the traffic usage in
>           the ifable,  [RFC2863], from the forwarding plane figure, or
>           fro the platform specifications
>         - Watt-hour energy use fromthis MIB can be combined with
>           utility energy sources to estimate carbon fotprint and other
>          emission statistics.
>          
>         An example is provided to illustrate he concepts.  For example,
>         a given EnergyMonitor Entity as escribed by the emIndex "7"
>         emPhysicalEntity "5" and emName  "sitch2.foo.com".  For that
>         EnergyMonitor Etity, the energy measurement and power state is
>         reported as folows: the units of measurement emEnergyUnits is
>         "watts" (value 1), theinstantaneous power usage enEnergyUsage

Watts is a unit of power, not  unit of energy.
"power usage" -> "energy usage"

>         is 100 watts, hile the maximum power consumption as prescribed

"powe consumption" -> "power"

>         by the vendor emEnergyNamePlate is 300 watts. The
>         emEnergyUsageCaliber indicates that the energy measurement is>         "actual".  The power state of that EnergyMonitor Entity
>        EmEnergyLevel is "9" to indicate medium power usage and
>         emEnegyUsageCategory indicates the type of EnergyMonitor Entity
>         consuer or producer of power or both.  In addition, the maximum

"of power" -> "f energy"

>         power consumption at the level emLevelMaxUsage is idicated as
>         150 watts.
>          
>         emDemandable and emDemandControlTable are illustrated,
>         following the same exmple.  Firstly, in order to estimate
>         demand, an interval to samle power usage should be specified,
>         i.e.  emDemandControlIntervalength can be "900 seconds" and the
>         number of consecutve intervals over which the maximum demand is
>         caculated emDemandControlIntervalNumber as "10".  The sampling
>         rate internal to the nergyMonitor Entity for measurement of
>       
>       
>      <Claise, et. Al>       Expires August 5, 2011            [Page 8]
>          
>      Internet-Draft       <Energy Monitoring MIB>           Feb 2010
>         energy usage, eDemandControlSampleRate, can be "1000
>         milliseconds", as set by he EnergyMonitor Entity as a
>         reasonable value.  Then, the eDemandControlStatus is set to
>         active (value 1) to indicatethat the EnergyMonitor Entity
>         should start monitor the usag as per the emDemandTable.
>          
>         For the indexes in the emmandTable are the emIndex, which
>         identifies the EnergyMonitor Entty and the

"idenstiufies" -> "identify"

>         emDemandIntervalStartTime, which denotes the start time of the
>         dnd measurement interval based on the sysUpime.
>         emDemandIntervalEnergUsed is the measurement of the energy
>         consumption over the time interval speciied
>         (emDemandControlIntervalLength) ased on the EnergyMonitor
>         Entity internal sampling rate (emDemandControlSampleRate).  Te
>         units are derived from emDemanIntervalEnergyScale is based
>         EnergyMonitorScale.  For example, emDemandIntervalEnergyUsed can
>         be "100" with emDemandIntervalEnergyScale equal to 0, the demand
>         s 100 watt-hours.  emDemandIntervalMax is the maximum demand
>         obsrved can be "150 watt-hors".
>          
>         The emDemandTable has a buffer to retain a certain number of
>         intervals, as defined by emDemandControlIntervalNumber.  If the
>         defaul value of "10" is kept, then the emDemndTable contains
>         10 demand measurements including the maximum.  A brief
>         explanation on how the maximum demand is calculated.  The first

"A brief ... Calculatd": This is not a complete sentence.

>         observed demandmeasurement value is taken to be the maximum.
>         With each measurement, based on numerical comparison, maximum
>         demnd may be updated.  The maximum value is retained as long as
>         the measurement is taking place.  Based on periodic polling, the
>         Network Manaement System can compute the maximum over a longer
>         period i.e. a month, 3 months, or a year.
>          
>        [POWER-MON-REQ] specifies some requirements about power states
>         such as "th current state - the time of the last change", "the
>         total ime spent in each state", "the number of transitions to
>        each state", etc...  Such requirements are fulfilled thanks to
>         the emLevelChange NTIFICATION-TYPE, indexed by the emIndex and
>         the emEnergyLevel, which is genrated when the value of
>         emEnergyLevel has changed for the EnergyMonitr Entity
>         represented by the emIndex.  Indeed, assumin that the SNMP
>         notifications arrives to Network Management Statin (NMS), the
>         NS can deduce all the information.
>       
>       
>      5. Structure of the IB
> 
>         The primary MIB object in this MIB module is
>         nergyMonitorMIBObjects.
>       
>       
>      
>      <Claise, et. Al>        Expires August 5, 2011            [Page 9]
>         
>      Internet-Draft        <Energy Monitoring MIB>           Feb 210
>         The emTable tabledefines the EnergyMonitor Entities, with a
>         potential link to the entPhysialIndex, when available.  The
>         EnergyMonitor Entities are used fr describing and configuring
>         the entities that re possible candidates for power management.
>         The specific EnergyMonitor Lvel can be configured in the
>         emTable. 
>          
>         TheemLevelTable table lists the maximum power usage at each
>         EnegyMonitor Level for eachEnergyMonitor Entity.
>          
>         Finally, the monitoring of all the EnergyMoitor Entities on the
>         SNMP agent canbe turned on/off with the emEnable MIB object.
>          
>                  
>      51. Link with the other IETF MIBs
> 
>      5.1.1. Link with the ENTITY-MIBand the ENTITY-SENSOR-MIB
> 
>         RFC 4133 [RFC4133] defines the Etity MIB module that lists the
>        physical entities of a networking device (route, switch) and
>         tose physical entities liste indexed by entPhysicalInde.
>         From an nergy management point of view, of interest are the
>        physical entities that consme or produce energy.
>          
>         RFC 3433 [RFC433] defines the ENTITY-SENSR MIB module that
>         provies a standardized way of obtaining information (current
>         value of the sensor, operaional status of the sensor, and the
>         data units precision) from sensors embeded in networking
>         devices.  Sensors are associated with each indx of
>         entPhysicalIndex ofthe Entity MIB [RFC4133].  While the focu
>         of the Energy Moitoring MIB, is on measement of energy
>         consumpti by networking equipment indexed by the entity MIB,
>        this MIB proposes a customize power scale for power measurement
>        and different power level tates of networking equment and a
>         functionality  configure the power level states.
>          
>        When this MIB module is used to moitor the energy consumption
>         of devices such as routers and switches, the ENTITY-MIB and
>         ENTITY-SENSOR-MIB should be implemented.  In such cases, the

"should" -> "SHULD" ?

>         EnergyMonitor Entities are modeled by the entPhysicalIndex
>         through the emPhysicalEntity MIB object specified in the
>         emTable. 
> 
>         However, the ENTITY-SENSOR-MIB doesn't have the ANSI C12.x
>         accuracy classes required for electricity, i.e., 1%, 2%, 0.5%
>         accuracy classes.  These ANSI and IEC Standards require that we
>         use an accuracy class, and not the precision model in RFC3433.

Two questions: 
Why are we required to use ANSI accuracy classes?
Why can't ANSI accuracy classes be represented by entPhysicalTable?

I am not saying that the statements above are incorrect,
So far but I cannot see from the text why they would be correct.

>         The emEnergyUsageAccuracy MIB object models this accuracy. Note
>         that the emEntEnergyScale represents the scale is a more logical
>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 10]
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010
>         representation (compared to entPhySensorScale), with the
>         mantissa and the exponent values X * 10 ^ Y.
> 
>         Finally, one cannot assume that the ENTITY-MIB and ENTITY-
>         SENSOR-MIB are implemented for all EnergyMonitor Entity that
>         needs to be monitored.  A typical example is a converged

Why? You cold just mandate that when you implement the Energy MIB
module, this implementation MUST include the Entity MIB it is not
available already.

>         building gateway, monitoring several other devices in the
>         building, doing the proxy between SNMP and a protocol such as
>         BACNET.  Another example is the home energy controller.

Why do these examples imply that if the Energy MIB is implemented, the
Entity MIB cannot be implemented as well? I don not see any reason for this.

>         In such cases, the emPhysicalEntity value contains the zero
>         value, thanks to PhysicalIndexOrZero textual convention.
>         As a consequence, the emEnergyMonitorId MIB object has been kept
>         as the unique Energy Monitor Entity index.  Finally, not that

"not" -> "note"

>         the emEntEnergyUsage is similar to entPhySensorValue [RFC3433]
>         and the emEntEnergyScale is similar to entPhySensorScale
>          
>         [EDITOR NOTE: the proxy table will be added in the next version
>         of the draft].
>          
>          
>      5.1.2. Link with the ENTITY-STATE-MIB
> 
>       
>         RFC 4268 [RFC4268] defines the Entity State MIB module that
>         gives the operational states (enabled, disabled, testing) and
>         alarm states and usage states (idle, active, busy) of the
>         entities in the entity MIB.  From an energy monitoring point of
>         view, different power states to indicate the power state of the
>         entities models need to be developed.  The Energy Monitoring MIB
>         proposes the power states of entities in the Entity MIB.

The Entity State MIB module has standby status values "unknown (1),
hotStandby (2), coldStandby (3), and providingService (4). These should not
be ignored in this section. It should be argued why they are not sufficient.
Certainly, they are more clear than the operational states defined above.
 
>      5.1.3. Link with the POWER-OVER-ETHERNET MIB
> 
>          
>         Power-over-Ethernet MIB [RFC-3621] provides energy monitoring
>         and configuration framework for power over Ethernet devices.
>         The RFC uses a concept of group of ports of a switch to define
>         power monitoring and management policy and does not use the
>         entPhysicalIndex as index.  For the purpose on hand, power
>         monitoring of components of networking devices, RFC 3621 can not
>         be applied.

Wouldn't it be sufficient to augment the table with power monitoring in
The PoE MIB module with an index of an entry in the physical entity table?
 
>      6. MIB Definitions
> 
>          
>         -- ************************************************************
>         --  
>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 11]
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010
>         --    
>         -- This MIB is used to monitor Energy Consumption of network
>         -- devices
>         --    
>         -- *************************************************************
>          
>         ENERGY-MONITOR-MIB DEFINITIONS ::= BEGIN
>          
>         IMPORTS 
>             MODULE-IDENTITY,
>             OBJECT-TYPE,
>             NOTIFICATION-TYPE,
>             mib-2,
>             Integer32, TimeTicks   FROM SNMPv2-SMI
>             MODULE-COMPLIANCE,
>             NOTIFICATION-GROUP,
>             OBJECT-GROUP
>                 FROM SNMPv2-CONF
>             TEXTUAL-CONVENTION
>                 FROM SNMPv2-TC
>             SnmpAdminString
>                 FROM SNMP-FRAMEWORK-MIB
>             RowStatus, TimeInterval
>                 FROM SNMPv2-TC
>             PhysicalIndexOrZero
>                 FROM ENTITY-MIB;
>          
>         energyMonitorMIB MODULE-IDENTITY
>             LAST-UPDATED    "201001130000Z"
>             ORGANIZATION    "Cisco Systems, Inc."
>             CONTACT-INFO
>                     "Cisco Systems
>                     Customer Service
>          
>                     Postal: 170 W Tasman Drive
>                     San Jose, CA  95134
>                     USA
>          
>                     Tel: +1 800 553-NETS
>          
>                     E-mail: [email-masked]"
>              
>           DESCRIPTION
>                "This MIB is used to monitor power usage in network

"power usage" -> "power" or "energy usage"
 
>                 Devices."
>            REVISION
>                 "201001130000Z"
>           DESCRIPTION
>                "This Latest draft of this MIB module. "

" ... " -> "Initial version, published as RFC XXXX."
      
>      <Claise, et. Al>        Expires August 5, 2011           [Page 12]
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010
>          
>            ::= { mib-2 xxxxx }
>          
>         energyMonitorMIBNotifs OBJECT IDENTIFIER
>             ::= { energyMonitorMIB 0 }
>          
>         energyMonitorMIBObjects OBJECT IDENTIFIER
>             ::= { energyMonitorMIB 1 }
>       
>         energyMonitorMIBConform  OBJECT IDENTIFIER
>             ::= { energyMonitorMIB 2 }
>          
>                  
>         -- Textual Conventions
>       
>          
>         EnergyMonitorLevel ::= TEXTUAL-CONVENTION
>             STATUS          current
>             DESCRIPTION
>                 "An enumerated integer value that represents the value
>                 of EnergyMonitor Level, a power setting at which a
>                 EnergyMonitor Entity uses power.
>                  
>                 The EnergyMonitor Levels are divided into six
>                 operational states, and six non-operational states.
>                 Each non-operational state corresponds to an ACPI
>                 (Advanced Configuration and Power Interface
>                 Specification, http://www.acpi.info/spec30b.htm)
>                 Global and System level state between G3 (hard-off) and
>                 G1 (sleeping).  The operational levels represent a
>                 performance state, and correspond to ACPI states P0
>                 (maximum performance & power) through P5 (minimum
>                 performance and minimum power).
>                  
>                 EnergyMonitor Entities need not support all levels, but
>                 a subset of the levels that can be mapped to their
>                 system state.
>          
>                  mechoff(1)  : An off state.  No entity features are
>                                available.  The entity is unavailable.
>                                No power is being consumed and the power

"power" -> "energy"

>                                Connector can be removed.  This maps to

"Connector" -> "connector"
>                                the level G3 in ACPI.

This can hardly be reported by the entity itself, because it is unavailable.
It should be elaborated in the DESCRIPTION clause how this state (and
several of the following states) can be reported.
         
>                  softoff(2)  : Similar to off, but some components

"off" -> "mechoff(1)"
>                                remain powered so the device can be woken
>                                from its off state.  In soft-off, no

"soft-off" -> "state softoff(2)"

>                                context is saved and the device requires
>                                a complete boot when awakened.  This maps

"maps" -> "corresponds" ?

> 
>      <Claise, et. Al>        Expires August 5, 2011           [Page 13]
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010
>                                to level G2 in ACPI.
>          
>                  hibernate(3): No entity features are available.  The
>                                entity may be awoken without requiring a

"awoken" -> "woken up" ?
 
>                                complete boot, but the time for
>                                availability is longer than sleep.
>                                This is generally the same as save-to-
>                                disk where DRAM context is not
>                                maintained. Minimal, nearly zero, or zero

"This is generally the same as save-to-disk"
-> "An example for state sleep(4) is a save-to-disk state"

>                                power is consumed.  This maps to level

What would "minimal" mean? Minimal among all states?
Then minimal would be zero.
"Minimal, nearly zero, or zero power is consumed"
-> "Typically, energy consumption is zero or close to zero."
"maps" -> "corresponds" (also for the following states) ?

>                                G1, S4 in ACPI.
>
>                  sleep(4)    : No entity features are available.  The

"available" -> "available except for wake-up mechanisms"

>                                entity may be available but the time
>                                for availability is longer than

This is contradicting. If the entity is available already,
why would there be a delay until it becomes available?

It looks like you use three times the concept of "available" in two
consecutive sentences and each time you refer to a different concept
of availability.

>                                standby. This is generally the same as
>                                save-to-RAM, where DRAM context is

"This is generally the same as save-to-RAM"
-> "An example for state sleep(4) is a save-to-RAM state"

>                                maintained.  Minimal power is consumed.
>                                This maps to level G1, S3 in ACPI.

"Minimal power is consumed"
-> "Typically, energy consumption is close to zero."

>          
>                  standby(5)  : Indicates some entity features may not be
>                                available.  The entity may be available
>                                but the time for availability is longer
>                                than ready.  Processor context is not

What is a "processor context"? What does it include? Program counter?
Registers? Cashes? Queued operations?

>                                maintained.  Minimal power is consumed.

Power consumption may be more than zero. Thus it is not minimal.
"Minimal power is consumed"
-> "Typically, energy consumption is close to zero."

>                                This maps to level G1, S2 in ACPI.
>          
>                  ready(6)    : Indicates some entity features may not
>                                be available.  The entity itself may be
>                                available but there may be a time delay
>                                for availability.  Processors are not

Again, either a contradiction or the word "available" has two different
Meanings within the same sentence. This needs more explanation.

>                                executing, but their context is

Is this mandatory? I would not require this. It implies that if 
processors are executing anything, the device cannot be in state 
ready(6).

>                                maintained. Low or less power is 
>                                consumed.  This maps to level G1, S1 in  

"Low or less power is consumed."
Less than what? Less energy than in state low(7)?

>                                ACPI. 
>          
>                  low(7)      : Indicates some features may not be     

"features" -> "entity features"

>                                available and the entity has taken  
>                                measures/options to provide less than  
>                                frugal usage.  This maps to ACPI State 
>                                G0; which includes operational levels  
>                                low to full. 

"low to full" -> "low(7) to full(12)"

>                  frugal(8)   : Indicates some features may not be  
>                                available and the entity has take  

"take" -> "taken"

>                                measures/options to provide less than  

"measures/options" -> "measures or selected options"

>                                medium usage. 

Can the entity provide usage? 
It can provide service and may be able to limit usage.
"usage" -> service" (also for the following states)
          
>                  medium(9)   : Indicates all entity features are  
>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 14] 
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010 
>                                available but the entity has taken  
>                                measures/options to provide less than  
>                                reduced usage. 
>          
>                  reduced(10)  : Indicates all entity features are  
>                                available but the entity has taken  
>                                measures/options to provide less than  
>                                high usage. 
>          
>                  high(11)    : Indicates all entity features are  
>                                available and power consumption is less  
>                                than full. 
>          
>                  full(12)    : Indicates all entity features are  
>                                available and the entity is consuming the  
>                                highest power."  

States frugal(8), medium(9), reduced(10), and high(11) are only 
distinguished by energy consumption which is defined relative to 
each other or to state full(12). How would an implementer choose them?
If the device has less states, how would an implementer select the ones
to be supported?
         
>             SYNTAX          INTEGER  { 
>                                 mechoff(1), 
>                                 softoff(2), 
>                                 hibernate(3), 
>                                 sleep(4), 
>                                 standby(5), 
>                                 ready(6), 
>                                 low(7), 
>                                 frugal(8), 
>                                 medium(9), 
>                                 reduced(10), 
>                                 high(11), 
>                                 full(12) 
>                             } 
>          
>         EnergyMonitorId ::= TEXTUAL-CONVENTION 
>             STATUS          current 
>             DESCRIPTION 
>              "A unique identifier for the EnergyMonitor Entity in the 
>              EnergyMonitor Domain. Implementation must ensure that the 

"must" -> "MUST" ?

>              ID for each EnergyMonitor Entity is unique among all 
>              entities within the EnergyMonitor Domain. A Universally 

How would an implementation of the MIB module know about the domain
(except may be the name of the domain)? I see no generic way to do
so for an implementer than using globally unique IDs.

>              Unique Identifier (UUID) is typically used." 

I would suggest to RECOMMEND that if there is an entry in the
entPhysicalTable available that represents this EnergyMonitor, 
then a pointer to the corresponding entPhysicalEntry is used 
as ID.         
This may require changing the SYNTAX clause to a longer OCTET STRING.     

>             REFERENCE 
>                    "IETF RFC 4122" 
>             SYNTAX          OCTET STRING (SIZE (16)) 
>          
>         EnergyMonitorPowerScale ::= TEXTUAL-CONVENTION 

This duplicates EntitySensorDataScale with only slight variations.
 
>             STATUS          current 
>             DESCRIPTION 
>                  
>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 15] 
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010 
>                "The EnergyMonitor Scale: an integer value that 
>                represents the units used to measure the power.   
>                The units are expressed in watts. 
>                I.e., -3 represents 10^-3 or milliwatts" 
>             REFERENCE 
>                     "The International System of Units (SI), 
>                     National Institute of Standards and Technology, 
>                     Spec. Publ. 330, August 1991." 
>             SYNTAX INTEGER { 
>                 yocto(-24),   -- 10^-24 
>                 zepto(-21),   -- 10^-21 
>                 atto(-18),    -- 10^-18 
>                 femto(-15),   -- 10^-15 
>                 pico(-12),    -- 10^-12 
>                 nano(-9),     -- 10^-9 
>                 micro(-6),    -- 10^-6 
>                 milli(-3),    -- 10^-3 
>                 units(0),     -- 10^0 
>                 kilo(3),      -- 10^3 
>                 mega(6),      -- 10^6 
>                 giga(9),      -- 10^9 
>                 tera(12),     -- 10^12 
>                 peta(15),     -- 10^15 
>                 exa(18),      -- 10^18 
>                 zetta(21),    -- 10^21 
>                 yotta(24)     -- 10^24 
>             } 
>          
>         -- Objects 
>          
>          
>         emTable OBJECT-TYPE 
>             SYNTAX          SEQUENCE OF EmEntry  
>             MAX-ACCESS      not-accessible 
>             STATUS          current 
>             DESCRIPTION 
>                "This table lists EnergyMonitor Entities." 
>             ::= { energyMonitorMIBObjects 1 } 
>          
>          
>         emEntry OBJECT-TYPE 
>             SYNTAX          EmEntry 
>             MAX-ACCESS      not-accessible 
>             STATUS          current 
>             DESCRIPTION 
>                 "An entry describes attributes of a EnergyMonitor 
>                 Entity.  Whenever the device creates/destroys a  
> 
>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 16] 
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010 
>                 EnergyMonitor Entity, the device creates/destroys  

I have not yet seen any network device that was capable of creating
or destroying physical entities :-) 

>                 a row in the emTable." 
>             INDEX           { emIndex }  
>             ::= { emTable 1 } 
>          
>          
>         EmEntry ::= SEQUENCE { 
>                 emIndex                  Integer32, 
>                 emEnergyMonitorId        EnergyMonitorId, 
>                 emPhysicalEntity         PhysicalIndexOrZero, 

If you use entPhysicalEntry as index, you can replace the three objects
above plus emName by just a single object.

>                 emDomainName             SnmpAdminString, 
>                 emName                   SnmpAdminString, 
>                 emRoleDescription        SnmpAdminString, 
>                 emEnergyUnits            EnergyMonitorPowerScale, 
>                 emEnergyUsage            Integer32, 

emPower would be a good alternative name.

>                 emEnergyUsageNameplate   Integer32, 

same here: This reports the "power" entry of the nameplate:
"emEnergyUsageNameplate" -> "emPowerNameplate"
Particularly, since name plate power is not
necessarily entirely consumed, see below.

The next two objects could be rename to 
emPowerAccuracy and emPowerCaliber

>                 emEnergyUsageAccuracy    Integer32, 
>                 emEnergyUsageCaliber     INTEGER, 
>                 emEnergyLevel            EnergyMonitorLevel, 
>                 emEnergyUsageCategory    BITS 
>         } 
>          
>         emIndex OBJECT-TYPE 
>             SYNTAX          Integer32 (1..2147483647) 
>             MAX-ACCESS      not-accessible 
>             STATUS          current 
>             DESCRIPTION 
>                "A unique value, greater than zero, for each 
>                EnergyMonitor Entity. It is recommended that values are 
>                assigned contiguously starting from 1.  The value for 
>                each emIndex must remain constant at least from one re-
>                initialization of the entity's network management system 
>                to the next re-initialization." 
>              ::= { emEntry 1 } 
>          
>         emEnergyMonitorId OBJECT-TYPE 
>             SYNTAX          EnergyMonitorId 
>             MAX-ACCESS      read-only 
>             STATUS          current 
>             DESCRIPTION 
>                "This object indicates the EnergyMonitor UUID identifier.  
>                This object value must be unique within the EnergyMonitor 
>                Domain."  

The second sentence can be removed. If the identifier is a UUID, as stated
in the fist sentence, then it is unique in any domain.

>             ::= { emEntry 2 } 
>          
>         emPhysicalEntity OBJECT-TYPE 
>             SYNTAX          PhysicalIndexOrZero                         
>             MAX-ACCESS      read-only 
>             STATUS          current 
>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 17] 
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010 
>             DESCRIPTION 
>                "This object contains the index of a physical entity in 
>                the ENTITY MIB.  This physical entity is the given 
>                Observation Point. If such a physical entity cannot be 

"Observation Point" -> "observation point"
(No terminology definition for a special capitalized term Observation 
Point.)

>                specified or is not known then the object is zero."  
>             ::= { emEntry 3 } 
>          
>         emDomainName OBJECT-TYPE 
>             SYNTAX          SnmpAdminString 
>             MAX-ACCESS      read-write 
>             STATUS          current 
>             DESCRIPTION 
>                "This object specifies the name of a EnergyMonitor Domain 
>                for the EnergyMonitor Entity.  This object specifies a 
>                null string if no EnergyMonitor Domain name is 
>                configured. The value of emDomainName must remain 
>                constant at least from one re-initialization of the 
>                entity's network management system to the next re-
>                initialization." 
>             ::= { emEntry 4 } 

I doubt, this object is sufficiently useful to include it in the standard.

I assume that typically, it would need to be set by the network management
system. But if the NMS can assign it, there is not need for reading it ever
again except we wnat to signal the domain membership of the device
from one NMS to another one.

Also this single name is only usefu for a single membership.
Overlapping domains or multiple parallel domain hierarchies are nit 
supported.

>         emName OBJECT-TYPE 
>             SYNTAX          SnmpAdminString 
>             MAX-ACCESS      read-write    STATUS          current 
>             DESCRIPTION 
>                "This object specifies a printable name, a text string, 
>                for the EnergyMonitor Entity.  It is preferred, but not 
>                required that emName be unique. 
>                The process to assign the emName is implementation 
>                specific. Example: DNS Name, MAC address in canonical 
>                form, ifName, etc..." 

This object should be empty, if emPhysicalEntity has a value different
from zero.

>             ::= { emEntry 5 } 
>          
>         emRoleDescription OBJECT-TYPE 
>             SYNTAX          SnmpAdminString 
>             MAX-ACCESS      read-write 
>             STATUS          current 
>             DESCRIPTION 
>                "This object specifies an administratively assigned name 
>                to indicate the purpose an EnergyMonitor Entity serves in 
>                the network. 
>                    
>                For example, we can have switches deployed to a lobby 
>                with emName as 'Lobby Switch' and emRoleDescription as 
>                'IP Phones'. 
>                    
>                This object specifies a null string if no role 
>                description is configured."  
>             ::= { emEntry 6 } 

I wonder why we don't have a column like this in the entPhysicalTable.
Was there a good reason for not having it?  

>      <Claise, et. Al>        Expires August 5, 2011           [Page 18] 
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010 
>          
>         emEnergyUnits OBJECT-TYPE 
>             SYNTAX         EnergyMonitorPowerScale  
>             MAX-ACCESS      read-only 
>             STATUS          current 
>             DESCRIPTION 
>                "The magnitude of Watts for the usage value in 

"Watts" -> "watts"

>                emEnergyUsage and emEnergyUsageNameplate."  
>             ::= { emEntry 7 } 
>          
>         emEnergyUsage OBJECT-TYPE 
>             SYNTAX          Integer32 
>             MAX-ACCESS      read-only 
>             STATUS          current 
>             DESCRIPTION 
>                "This object indicates the instantaneous consumption for 
>                the EnergyMonitor Entity.  This value is specified in SI 
>                units of watts with the magnitude of watts (milliwatts, 
>                kilowatts, etc.) indicated separately in emEnergyUnits.  

After the scale, also the accuracy (emEnergyUsageAccuracy) should 
be mentioned here.
                
>                If the EnergyMonitor Entity is a consumer (bit value 1 in 
>                emEnergyUsageCategory, the usage value will be positive. 

"positive" -> "positive or zero"

>                If the EnergyMonitor Entity is a producer (bit value 2 in 
>                emEnergyUsageCategory, the usage value will be negative.               

"negative" -> "negaive or zero"

>                This should be less than or equal to the power that can 
>                be consumed at that specified level.

"that specified level" -> "the power level specified by emEnergyLevel"

>                "  

Since the term "consumption" is used in the description, I assume that
the value indicates real power and not apparent power (as the name plate
does). This should be mentioned explicitly.
 
>             ::= { emEntry 8 } 
>          
>         emEnergyUsageNameplate OBJECT-TYPE 
>             SYNTAX          Integer32 
>             MAX-ACCESS      read-only 
>             STATUS          current 
>             DESCRIPTION 
>                "This object indicates the rated maximum consumption for 

Nameplate power is apparent power. Apparent power is not necessarily
fully consumed. The consumed component of apparent power is the real 
power. 

Therefore, it would also be a good idea to rename the object to
emPowerNameplate.

"consumption" -> "power"

>                the fully populated EnergyMonitor Entity.  The nameplate 
>                power requirements are the worst-case power consumption 

"worst-case" -> "maximum"
"consumption" -> ""

>                numbers and in almost all cases, are well above the 
>                expected operating level.  Nameplate power is widely used

The term level is already in use:
"operating level"  -> "operational consumption"

>                for power provisioning.  This value is specified in SI 
>                units of watts with the magnitude of watts (milliwatts, 
>                kilowatts, etc.) indicated separately in emEnergyUnits.  

It should be discussed that name plate power is a value for apparent
power while the value provided by emEnergyLevel is (assumed to be) 
real power.

>                Nameplate power is widely used for capacity and 
>                provisioning planning. It is typically a value provided 
>                via experimentation and prediction from the manufacturer 
>                of the entity."  

Other manufacturers design devices for a certain power.
Typically, this engineering process does not require experimentation
or prediction for determining nameplate power.

>             ::= { emEntry 9 } 
>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 19] 
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010 
>          
>         emEnergyUsageAccuracy OBJECT-TYPE 
>             SYNTAX          Integer32 (0..10000) 
>             MAX-ACCESS      read-only 
>             STATUS          current 
>             DESCRIPTION 
>                "This object indicates a percentage value in 100ths of a 
>                percent representing the accuracy to which the usage, 
>                reported by the emEnergyUsage can be assumed. Example 
>                1010 means the reported usage is accurate to +/- 10.1 
>                percent.  This value is zero if the accuracy is unknown. 
>                 
>                ANSI and IEC define the following accuracy classes for 
>                power measurement: 
>                     IEC 62053-22 & 60044-1 class 0.1, 0.2, 0.5, 1 & 3. 
>                     ANSI C12.20 class 0.2 & 0.5" 
>             ::= { emEntry 10 } 
>          
>         emEnergyUsageCaliber OBJECT-TYPE 
>             SYNTAX          INTEGER  { 
>                                 unknown(1),  
>                                 actual(2) , 
>                                 trusted(3),  
>                                 predicted(4),   
>                                 presumed(5) 
>                             } 
>             MAX-ACCESS      read-only 
>             STATUS          current 
>             DESCRIPTION 
>                "This object specifies how the usage value, reported by 
>                emEnergyUsage, is obtained. 
>                  
>                 
>                - unknown: This indicates that the way the usage is 
>                determined is unknown. In some cases, entities report 
>                aggregate power like what a lighting controller or 
>                aggregate controller does. In such cases it is not known 
>                whether the usage reported is actual or presumed.  

"actual or presumed" -> "actual(") or presumed(5)"

>                - actual: This indicates that the usage data reported is 
>                not presumed or predicted but the real power drawn.  A 

to "draw power" is not a precise technical term.
"real power drawn" -> "real current power value" or
-> "real current energy consumption rate"

>                PoE phone drawing X amount of power can be determined by 
>                reading from the port. For example, a PoE phone can 
>                report the actual usage as X W.  
>        
>                - trusted: This indicates that the usage data reported 
>                was reported from another source.  Trusted is higher 
>                caliber than predicted.  

"predicted" -> "predicted(4)"

What if at the other trusted source, the value was generated based on 
estimation? Then the caliber of trusted(3) would not be higher than
predicted(5).

I see trusted being orthogonal to actual, predicted, and presumed.
It does not necessarily belong to the same list as the other 
values.
      
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 20] 
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010 
>                - predicted: This indicates that the actual power drawn 

Why is this called "predicted" and not "estimated"? For me as a
non-native speaker, "predicted" points to the future. But according 
to the description this is an estimation based on usage. I understand
that this can be current usage and is not necessarily predicted usage.
But if it is current usage then it is a current estimation and not an 
estimation of power values in the future.

>                cannot be determined. The value is an estimate based upon 
>                the device type, state, and/or utilization.  Predicted is 
>                a higher caliber than presumed. For example, a switch is 

"presumed" -> "presumed(5)"

>                known to draw 200w when POE on all interfaces is disable, 
>                and  600w when POE is fully enabled. 
>       
>                - presumed: This indicates that the actual power drawn 
>                cannot be determined but can be presumed from the model.

For predicted(4) estimation was based on device type, state and load,
but not on model. Here estimation is based on model. Does "model" include
"device type"? Please clarify.

>                Presumed is the lowest caliber.  For example, a PC Model 
>                X draws 200W, while a PC Model Y draws 210W." 
>                 
>             ::= { emEntry 11 } 
>          
>         emEnergyLevel OBJECT-TYPE 
>             SYNTAX          EnergyMonitorLevel 
>             MAX-ACCESS      read-write 
>             STATUS          current 
>             DESCRIPTION 
>                 "This object specifies the current power level (1..12) 
>                 for the EnergyMonitor Entity."  
>             ::= { emEntry 12 } 
>       
>         emEnergyUsageCategory OBJECT-TYPE 
>             SYNTAX          BITS  { 
>                                 consumer(1), 
>                                 producer(2), 

I would suggest replacing "producer" with "provider",
see corresponding comment on section 4.

>                                 meter(3) 
>                             } 
>             MAX-ACCESS      read-only 
>             STATUS          current 
>             DESCRIPTION 
>                "This object specifies the energy usage type of the 

Maybe "usage" is not the right term here.
Or is metering energy consumption a kind of energy usage?

>                entity. An entity could be producing power when 
>                emEnergyUsageCategory is producer(2) or a consumer of 
>                power consumer (1) or a hybrid - consumer and 
>                producer(3). Negative values of energy usage are 
>                permissible to indicate the entities as energy sources. 

"permissible" -> "used"
 
>                 
>                Consumer:   This indicates that the entity is 
>                            consumes energy. 
>                Producer:   This indicates that the entity  
>                            generates energy. 
>                Meter:  This indicates that the entity is a  
>                            meter which reads the energy consumed  
>                            or produced." 

"produced" -> "provided or consumed by other devices".
 
>             ::= { emEntry 13 } 
>          
>          
>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 21] 
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010 
>         emLevelTable OBJECT-TYPE 
>             SYNTAX          SEQUENCE OF EmLevelEntry  
>             MAX-ACCESS      not-accessible 
>             STATUS          current 
>             DESCRIPTION 
>                "This table enumerates the maximum power usage in watts 
>                at each EnergyMonitor Level for each EnergyMonitor 
>                Entity.  
>                 
>                This table has an expansion dependent relationship on the 
>                emTable, containing rows describing each EnergyMonitor 
>                Level for the corresponding EnergyMonitor Entity." 

It should be clearly stated if there must be an entry in this table 
for every entry in the emTable. The current phrasing is not clear to me.

>             ::= { energyMonitorMIBObjects 2 } 
>          
>          
>         emLevelEntry OBJECT-TYPE 
>             SYNTAX          EmLevelEntry 
>             MAX-ACCESS      not-accessible 
>             STATUS          current 
>             DESCRIPTION 
>                "A emLevelEntry extends a corresponding emEntry.  This 
>                entry displays max usage and delta values at each level. 
>                For example, the given the values of a EnergyMonitor 
>                Entity corresponds to a maximum usage of 11W at the  
>                level 2: 
>                 
>                     Level  MaxUsage  Units   
>                     2      11        1" 

The description of the table or entry should comment on if it is
mandatory or not to create entries for each power level (even if 
the power level is not supported by the device).

>                 
>                         INDEX   { 
>                                   emIndex, 
>                                   emLevelIndex 
>                                 }  
>             ::= { emLevelTable 1 } 
>          
>         EmLevelEntry ::= SEQUENCE { 
>                 emLevelIndex       EnergyMonitorLevel, 
>                 emLevelMaxUsage    Integer32, 

emLevelMaxPower would probably be a more obvious term.

>                 emLevelEnergyUnits EnergyMonitorPowerScale 

This should be called emLevelPowerScale.

>         } 
>          
>         emLevelIndex OBJECT-TYPE 
>             SYNTAX          EnergyMonitorLevel 
>             MAX-ACCESS      not-accessible 
>             STATUS          current 
>             DESCRIPTION 
>                "This object indicates the level for which this entry 
>                describes the power usage."  
>             ::= { emLevelEntry 1 } 
>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 22] 
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010 
>          
>          
>         emLevelMaxUsage OBJECT-TYPE 
>             SYNTAX          Integer32 
>             MAX-ACCESS      read-only 
>             STATUS          current 
>             DESCRIPTION 
>                "This object indicates the maximum power usage for the 

"usage" -> ""
>                EnergyMonitor Entity at the particular EnergyMonitor 
>                Level. This value is specified in SI units of watts with 
>                the magnitude of watts (milliwatts, kilowatts, etc.) 
>                indicated separately in emLevelEnergyUnits."  

How to indicate that the maximum power is not known for a certain
power level? Value zero cannot be used for this purpose, because 
it may be a valid value for some power levels. 

>             ::= { emLevelEntry 2 } 
>          
>          
>         emLevelEnergyUnits OBJECT-TYPE 

"emLevelEnergyUnits" -> "emLevelPowerScale"

>             SYNTAX          EnergyMonitorPowerScale  
>             MAX-ACCESS      read-only 
>             STATUS          current 
>             DESCRIPTION 
>                "The magnitude of the watts for the usage value in 
>                emLevelMaxUsage."  
>             ::= { emLevelEntry 3 } 
>          
>          
>         emDemandControlTable OBJECT-TYPE 
>             SYNTAX          SEQUENCE OF EmDemandControlEntry  
>             MAX-ACCESS      not-accessible 
>             STATUS          current 
>             DESCRIPTION 
>               "Controls the setup of the demand table emDemandTable."    
>         ::= { energyMonitorMIBObjects 3 } 
> 
>       
>         emDemandControlEntry OBJECT-TYPE

Why is this called "demand control" although it is about 
measurement control?
 
>             SYNTAX          EmDemandControlEntry 
>             MAX-ACCESS      not-accessible 
>             STATUS          current 
>             DESCRIPTION 
>                 "An entry controls energy usage measurements." 
>             INDEX  { emIndex }  
>             ::= { emDemandControlTable 1 } 
>       
>         EmDemandControlEntry ::= SEQUENCE { 
>                 emDemandControlIntervalLength        TimeInterval, 
>                 emDemandControlIntervalNumber        Integer32, 
>                 emDemandControlSampleRate            Integer32, 
>                 emDemandControlStatus                RowStatus 
> 
>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 23] 
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010 
>         } 
>       
>          
>         emDemandControlIntervalLength OBJECT-TYPE 
>             SYNTAX          TimeInterval 
>             MAX-ACCESS      read-write 
>             STATUS          current 
>             DESCRIPTION 
>                " This object indicates the length of time in seconds 
>                over which the average demand is computed. The 
>                computation is based on EnergyMonitor Entity internal 
>                sampling rate of power consumption of the entity. The 
>                sampling rate may differ based on device capabilities. 
>                The average power consumption is computed over the length 
>                of the demand interval."  

It should be stated which objects are affected by this setting.
I guess it also affects emEnergyUsage?

>             DEFVAL { 900 } 
>             ::= { emDemandControlEntry 1 } 
>       
> 
>         emDemandControlIntervalNumber OBJECT-TYPE 
>             SYNTAX          Integer32 
>             MAX-ACCESS      read-write 
>             STATUS          current 
>             DESCRIPTION 
>                "The number of demand intervals over which the maximum 
>                demand is computed. Whenever the maximum number of entry 

"demand" -> "power per level"?

Same point as for the previous object: It should be clearly stated
which objects are affected.

>                is reached, the new demand interval replaces the oldest 
>                one, except if the oldest one is the 
>                emDemandIntervalMax." 
>              DEFVAL { 10 }  
>             ::= { emDemandControlEntry 2 } 
>          
>         emDemandControlSampleRate OBJECT-TYPE 
>             SYNTAX          Integer32 
>             MAX-ACCESS      read-write 
>             STATUS          current 
>             DESCRIPTION 
>                "The sampling rate in milliseconds at which the 
>                EnergyMonitor Entity would poll the instantaneous value 
>                power value in order to compute the energy usage 
>                measurements in the emDemandTable.  The EnergyMonitor 
>                should initially set up this sample rate to a reasonable 
>                value, i.e. a compromise between a low value that will 
>                give a good accuracy, and a too low value that will 
>                impact the EnergyMonitor Entity performance by requesting 
>                continuous polling." 

What value should be reported if the sample rate is unknown? Zero?

>              DEFVAL { 1000 }  
>             ::= { emDemandControlEntry 3 } 
>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 24] 
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010 
>          
>       
>         emDemandControlStatus OBJECT-TYPE 
>             SYNTAX          RowStatus 
>             MAX-ACCESS      read-create 
>             STATUS          current 
>             DESCRIPTION 
>               "The status of this row. An entry may not exist in the 
>               active state unless all objects in the entry have an 
>               appropriate value.  If this object is not equal to 
>               active(1), all associated entries in the emDemandTable 
>               shall be deleted." 

Is it mandatory to support writing all values defined by TC RowStatus?
What is the behavior for other values than active(1)
Can rows be destroyed?

>             ::= {emDemandControlEntry 4 } 
>          
>       
>         emDemandTable OBJECT-TYPE 
>             SYNTAX          SEQUENCE OF EmDemandEntry  
>             MAX-ACCESS      not-accessible 
>             STATUS          current 
>             DESCRIPTION 
>                "This table lists EnergyMonitor energy usage 
>                measurements.  Only when the Energy Monitor Entity has 
>                the emEnergyUsageCaliber value set to actual(2), this 

Why not for trusted(3) and predicted(4)?

>                table will be populated." 

There may be many entities in the emTable. The table will be 
populated as soon as there is only one entry with caliber actual(2).
Probably you rather want to say: Entries in this table are only created
if the corresponding value of object emEnergyUsageCaliber is active(2).

>             ::= { energyMonitorMIBObjects 4 } 
>          
>          
>         emDemandEntry OBJECT-TYPE 
>             SYNTAX          EmDemandEntry 
>             MAX-ACCESS      not-accessible 
>             STATUS          current 
>             DESCRIPTION 
>                 "An entry describes energy usage measurements." 

"desribes" -> "describing"

>             INDEX  { emIndex, emDemandIntervalStartTime }  
>             ::= { emDemandTable 1 } 
>       
>          
>         EmDemandEntry ::= SEQUENCE { 
>                 emDemandIntervalStartTime     TimeTicks, 
>                 emDemandIntervalEnergyUsed    Integer32, 
>                 emDemandIntervalEnergyScale   EnergyMonitorPowerScale, 
>                 emDemandIntervalMax           Integer32 
>         } 
>          
>         emDemandIntervalStartTime OBJECT-TYPE 
>             SYNTAX          TimeTicks 
>             MAX-ACCESS      not-accessible 
>             STATUS          current 
>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 25] 
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010 
>             DESCRIPTION 
>                "The time (in hundredths of a second) since the 
>                network management portion of the system was last 
>                re-initialized, as specified in the sysUpTime [RFC3418]. 
>                This object is useful for reference of interval period 
>                for which the demand is measured. "  
>             ::= { emDemandEntry 1 } 
>          
>          
>         emDemandIntervalEnergyUsed OBJECT-TYPE 
>             SYNTAX          Integer32 
>             MAX-ACCESS      read-only 
>             STATUS          current 
>             DESCRIPTION 
>                "This object indicates the energy used in units of watt-
>                hours for the EnergyMonitor Entity over the defined 
>                interval. This value is specified in the common billing 
>                units of watts-hours with the magnitude of watt-hours 
>                (kW-Hr, MW-Hr, etc.) indicated separately in 
>                emDemandIntervalEnergyScale."  
>             ::= { emDemandEntry 2 } 
>          
>         emDemandIntervalEnergyScale OBJECT-TYPE 
>             SYNTAX          EnergyMonitorPowerScale 
>             MAX-ACCESS      read-only 
>             STATUS          current 
>             DESCRIPTION 
>                "This magnitude of watt-hours for the energy field in 
>                emDemandIntervalEnergyUsed."  
>             ::= { emDemandEntry 3 } 
>       
> 
>         emDemandIntervalMax OBJECT-TYPE 
>             SYNTAX          Integer32 
>             MAX-ACCESS      read-only 
>             STATUS          current 
>             DESCRIPTION 
>                "This object is the maximum demand ever observed in 
>                emDemandIntervalEnergyUsed since the monitoring started. 
>                This value is specified in the common billing units of 
>                watts-hours with the magnitude of watt-hours (kW-Hr, MW-
>                Hr, etc.) indicated separately in 
>                emDemandIntervalEnergyScale."  

There needs to be a specification of what to do if this number has been
reached. Probably you want the oldest interval to be deleted before a 
new one is added. Alternatively you could stop measuring.

>             ::= { emDemandEntry 4 } 
>       
>         emEnable OBJECT-TYPE 
>             SYNTAX          INTEGER  { 
>                                 enable(1), 
>                                 disable(2) 
>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 26] 
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010 
>                             } 
>             MAX-ACCESS      read-write 
>             STATUS          current 
>             DESCRIPTION 
>                "A control object to activate/de-activate all 
>                EnergyMonitor Entities on the SNMP agent (e.g. Switch).

According to section 3, "An EnergyMonitor Entity is a system of one or 
more components". Why would anyone seriously use the Energy MIB module 
to (de)activate them ???

There is no entity on an SNMP agent. It's the other way around.
An SNMP command responder may be located at an entity.
         
>                     enable:  enables all EnergyMonitor Entities. 
>          
>                     disable: disables all EnergyMonitor Entities"  
>          
>             ::= { energyMonitorMIBObjects 5 } 
>          
>         emVersion OBJECT-TYPE 
>             SYNTAX          SnmpAdminString 
>             MAX-ACCESS      read-only 
>             STATUS          current 
>             DESCRIPTION 
>                 "This object specifies the current version of the  
>                 EnergyMonitor software running on a EnergyMonitor  
>                 Entity."

This is a very uncommon object in MIB modules.
I have seen very few MIB modules that report the version 
numbers of their implementations.

If this object refers to energy monitoring software outside
of the MIB module implementation then it should be considered
that each entity may run ist own energy monitoring software
and a variety of version numbers might have to be supported
instead of just a single one.

I would suggest removing this object.

>             ::= { energyMonitorMIBObjects 6 } 
>          
>         -- Notifications 
>          
>         emLevelChange NOTIFICATION-TYPE 
>             OBJECTS         { emIndex, emEnergyLevel } 

When you report emEnergyLevel, then the notification includes
the OID and the value of this object. Since emIndex is part
of the OID of emEnergyLevel, I do not understand why you 
suggest reporting this redundant object.

>             STATUS          current 
>             DESCRIPTION 
>                 "The SNMP entity generates the EmLevelChange when 
>                 the value of emEnergyLevel has changed for the 
>                EnergyMonitor Entity represented by the emIndex" 
>            ::= { energyMonitorMIBNotifs 1 } 
>          
>         -- Conformance 
>          
>         energyMonitorMIBCompliances  OBJECT IDENTIFIER 
>             ::= { energyMonitorMIB 3 } 
>          
>         energyMonitorMIBGroups  OBJECT IDENTIFIER 
>             ::= { energyMonitorMIB 4 } 
>          
>          
>         energyMonitorMIBFullCompliance MODULE-COMPLIANCE 
>             STATUS          current 
>             DESCRIPTION 
>                 "When this MIB is implemented with support for 
>                 read-create, then such an implementation can  
>                 claim full compliance. Such devices can then  
>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 27] 
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010 
>                 be both monitored and configured with this MIB." 
>             MODULE          -- this module 
>             MANDATORY-GROUPS { 
>                                 energyMonitorMIBTableGroup, 
>                                 energyMonitorMIBLevelTableGroup, 
>                                 energyMonitorMIBNotifGroup 
>                             } 
>          
>             ::= { energyMonitorMIBCompliances 1 } 
>          
>         energyMonitorMIBReadOnlyCompliance MODULE-COMPLIANCE 
>             STATUS          current 
>             DESCRIPTION 
>                 "When this MIB is implemented without support for 
>                 read-create (i.e. in read-only mode), then such an  
>                 implementation can claim read-only compliance.  Such a  
>                 device can then be monitored but can not be configured  
>                 with this MIB." 
>             MODULE          -- this module 
>             MANDATORY-GROUPS { 
>                                 energyMonitorMIBTableGroup, 
>                                 energyMonitorMIBLevelTableGroup, 
>                                 energyMonitorMIBNotifGroup 
>                             } 
>          
>          
>             OBJECT          emName 
>             MIN-ACCESS      read-only 
>             DESCRIPTION 
>                 "Write access is not required." 
>          
>             OBJECT          emRoleDescription 
>             MIN-ACCESS      read-only 
>             DESCRIPTION 
>                 "Write access is not required." 
>          
>             OBJECT          emDomainName 
>             MIN-ACCESS      read-only 
>             DESCRIPTION 
>                 "Write access is not required." 
>          
>             OBJECT          emEnable 
>             MIN-ACCESS      read-only 
>             DESCRIPTION 
>                 "Write access is not required." 
>          
>             ::= { energyMonitorMIBCompliances 2 } 
>          
>         -- Units of Conformance 
>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 28] 
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010 
>          
>         energyMonitorMIBTableGroup OBJECT-GROUP 
>             OBJECTS         { 
>                                 -- Note that object emIndex is NOT  
>                                 -- included since it is not-accessible 
>                                 emEnergyMonitorId, 
>                                 emPhysicalEntity, 
>                                 emDomainName, 
>                                 emName, 
>                                 emRoleDescription, 
>                                 emEnergyUnits, 
>                                 emEnergyUsage, 
>                                 emEnergyUsageNameplate, 
>                                 emEnergyUsageAccuracy, 
>                                 emEnergyUsageCaliber, 
>                                 emEnergyLevel, 
>                                 emEnergyUsageCategory, 
>                                 emEnable, 
>                                 emVersion 
>          
>          
>                             } 
>             STATUS          current 
>             DESCRIPTION 
>                 "This group contains the collection of all the objects 
>                 related to the Energy Monitor Entity." 
>             ::= { energyMonitorMIBGroups 1 } 
>          
>          
>         energyMonitorMIBLevelTableGroup OBJECT-GROUP 
>             OBJECTS         { 
>                                 -- emLevelIndex, 
>                                 emLevelMaxUsage, 
>                                 emLevelEnergyUnits 
>                             } 
>             STATUS          current 
>             DESCRIPTION 
>                 "This group contains the collection of all the objects 
>                 related to the Energy Monitor level." 
>             ::= { energyMonitorMIBGroups 2 } 
>          
>          
>         energyMonitorMIBNotifGroup NOTIFICATION-GROUP 
>            NOTIFICATIONS    { 
>                                 emLevelChange 
>                                 -- emLevelIndex 
>                             } 
>             STATUS          current 
>             DESCRIPTION 
>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 29] 
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010 
>                 "This group contains the notifications for the energy 
>                 monitoring MIB Module." 
>             ::= { energyMonitorMIBGroups 3 } 
>          
>         END 
>          
>          
>      7. Security Considerations 

This section only discusses read-only objects.
However, the MIB module defined above contains several
writeable objects. Definitely, these objects needs explicit
discussion in this section.

>         Some of the readable objects in these 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 
>         thus important to control even GET and/or NOTIFY access to these 
>         objects and possibly to even encrypt the values of these objects 
>         when sending them over the network via SNMP.  These are the 
>         tables and objects and their sensitivity/vulnerability: 
>          
>         All other objects and tables contain no data that is considered 
>         sensitive. 
>          
>         SNMP versions prior to SNMPv3 did not include adequate security. 
>         Even if the network itself is secure (for example by using 
>         IPsec), even then, there is no control as to 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), 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 indeed GET or SET (change/create/delete) 
>         them. 
>          
> 
>      8. IANA Considerations 
> 
>         The MIB module in this document uses the following IANA-assigned 
>         OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 
>          
>                Descriptor            OBJECT IDENTIFIER value 
>                ----------            ----------------------- 
>                EnergyMonitorMIB         { mib-2 xxxxx } 
>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 30] 
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010 
>          
>         Additions to this MIB module are subject to Expert Review 
>         [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 MIB objects for completeness and accuracy of the 
>         description.  Requests for MIB objects that duplicate the 
>         functionality of existing objects SHOULD be declined.  The 
>         smallest available OID SHOULD be assigned to a new MIB objects.  
>         The specification of new MIB objects SHOULD follow the structure 
>         specified in Section 6 and MUST be published using a well-
>         established and persistent publication medium.   
>          
>       
>      9. References 
> 
>      9.1. Normative References 
> 
>          
>         [RFC4133]  Bierman, A. and K. McCloghrie, "Entity MIB (Version 
>                 3)", RFC 4133, August 2005. 
>          
>          
>         [RFC-3621] Berger, A., and D. Romascanu, "Power Ethernet MIB", 
>                 RFC3621, December 2003. 

You are not using any objects or TCs of this MIB module
I think this can be an informative reference.

>          
>         [RFC3433]  Bierman, A., Romascanu, D., and K. Norseth, "Entity 
>                 Sensor Management Information Base", RFC 3433, December 
>                 2002. 

You are not using any objects or TCs of this MIB module
I think this can be an informative reference.

>         [RFC4268]  Chisholm, S. and D. Perkins, "Entity State MIB", RFC 
>                 4268,November 2005. 

You are not using any objects or TCs of this MIB module
I think this can be an informative reference.

>         [POWER-MON-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., 
>                 and M. Chandramouli, "Requirements for Power 
>                 Monitoring", draft-quittek-power-monitoring-
>                 requirements-00 (work in progress), October 2009. 

This draft has an intended status of "Informational".
This should be an informative reference.

>         [ACPI] "Advanced Configuration and Power Interface 
>                 Specification", http://www.acpi.info/spec30b.htm 
>       
>          
>      9.2. Informative References 
> 
>          
>         [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 
>                 Requirement Levels, BCP 14, RFC 2119, March 1997. 

No need for this reference.
You do not use these terms so far. 

>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 31] 
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010 
>          
>         [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J. 
>                 Schoenwaelder, Ed., "Structure of Management 
>                 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 
>                 1999. 
>          
>         [RFC2579]  McCloghrie, K., Ed., Perkins, D., Ed., and J. 
>                 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 
>                 STD 58, RFC 2579, April 1999. 
>          
>         [RFC2580]  McCloghrie, K., Perkins, D., and J. Schoenwaelder, 
>                 "Conformance Statements for SMIv2", STD 58, RFC 2580, 
>                 April 1999. 
>          
>         [RFC5226]  Narten, T. Alverstrand, H., A. and K. McCloghrie, 
>                 "Guidelines for Writing an IANA Considerations Section 
>                 in RFCs ", BCP 26, RFC 5226, May 2008. 
>          
>         [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart, 
>                 "Introduction and Applicability Statements for Internet 
>                 Standard Management Framework ", RFC 3410, December 
>                 2002. 
>          
>         [RFC2863]  McCloghrie, K., Kastenholz, F., "The Interfaces Group 
>                 MIB", RFC 2863, June 2000. 
>          
>         [RFC3418]  Presun, R., Case, J., McCloghrie, K., Rose, M, and S. 
>                 Waldbusser, " Management Information Base (MIB) for the 
>                 Simple Network Management Protocol (SNMP)", RFC3418, 
>                 December 2002. 
>       
> 
>          
>      10. Authors' Addresses 
> 
>       Benoit Claise 
>       Cisco Systems Inc. 
>       De Kleetlaan 6a b1 
>       Diegem 1813 
>       BE 
>           
>       Phone: +32 2 704 5622 
>       Email: [email-masked] 
>        
>        
>        
>       Mouli Chandramouli 
>       Cisco Systems, Inc. 
>       Sarjapur Outer Ring Road 
>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 32] 
>          
>      Internet-Draft        <Energy Monitoring MIB>           Feb 2010 
>       Bangalore, 
>       IN 
>        
>       Phone: +91 80 4426 3947 
>       Email: [email-masked] 
>        
>        
>       John Parello 
>       Cisco Systems Inc. 
>       3550 Cisco Way  
>       San Jose, California 95134  
>       US 
>           
>       Phone: +1 408 525 2339 
>       Email: [email-masked] 
>        
>        
>       Brad Schoening 
>       Cisco Systems Inc. 
>       3550 Cisco Way  
>       San Jose, California 95134  
>       US 
>           
>       Phone: +1 408 525 2339 
>       Email: [email-masked] 
>        
>        
>        
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>       
>       
>      <Claise, et. Al>        Expires August 5, 2011           [Page 33] 
>          
>

---

From: "Brad Schoening" <[email-masked]>
Date: Tue, 9 Mar 2010 12:18:09 -0500

Brad's Todos:
* map in the comments hot-standby -> ready(6) and cold-standby -> standby(5)
* explain data scale multiplier is consistent with 61850 Annex A

I liked several nomenclature suggestions of Jurgen
* change EnergyUsage -> Power; EnergyUsageCaliber -> PowerCaliber, etc

On some items Jurgen misunderstands:
* nameplate power he confuses with apparent power

Should we set up a Webex to go through Jurgen's issues one-by-one?

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]] 
Sent: Tuesday, March 09, 2010 11:09 AM
To: Benoit Claise; John Parello (jparello); Brad Schoening;
[email-masked]; [email-masked]
Subject: Review of draft-claise-energy-monitoring-mib-01

Dear all,

    Juergen

 [snip]

 [snip]

 

         EnergyMonitor Scale
>            EnergyMontor usage.  It conforms to the standard prefixe>
for the SI (System Interntional) units of measure.  Measured

 
                     5               G2, S2           Stadby

 

>        uniquely identifying the entty.  The emName should ideally be>
unique.  As an example, in the case of phones, emNamecan be

"shall" o "SHALL"?

>         emEnergyUsageCaliber indicates that the energy measurement is>
"actual".  The power state of that EnergyMonitor Entity

"of power" -> "f energy"

"should" -> "SHULD" ?

Two questions: 

"not" -> "note"

 

 

"power" -> "energy"

         

"off" -> "mechoff(1)"

"awoken" -> "woken up" ?

"take" -> "taken"

          

"must" -> "MUST" ?

 

"Watts" -> "watts"

                

 

"consumption" -> "power"

      

"permissible" -> "used"

 

"usage" -> ""

---

From: "Juergen Quittek" <[email-masked]>
Date: Thu, 11 Mar 2010 11:43:12 +0100

Hi Brad,

On 09.03.10 18:18  "Bra Schoening" <[email-masked]> wrote:

> ad's Todos:
> * explain data scale multiplier is consistent with61850 Annex A
> 
> I liked several nomenclatur suggestions of Jurgen
> * change EnergyUsage -> Power; EnergyUsagealiber -> PowerCaliber, etc
> 
> On some tems Jurgen misunderstands:
> * nameplate ower he confuses with apparent power

I general power stated on th nameplate of a device is the apparent power.
That is why often you find here units of VA (VoltAmpere) instead of
W (watts). As you correctly statedin your draft, the nameplate power
is the maximum power potentially drawn by a device. Since the apparent
power is always larger than or equal to the real power it is the apparent
power that needs to be stated there In cases where the manufacturer
designs a device such hat apparent power is always more or les equal
to the real power, it iOK to state the real power on the nameplate.

est regards,

    Juergen

> Should we set up a Webex to go though Jurgen's issues one-by-one?
> 
> ----Original Message-----
> From: Juergen Quitek [mailto:[email-masked]]
> Sen: Tuesday, March 09, 2010 1:09 AM
> To: Benoit Claise; John Parello (jparello); Brad Schoenin;
> Subject: Review of draft-claise-nergy-monitoring-mib-01
> 
> Dear all,
> 
> Plea find my review of raft-claise-energy-monitoing-mib-01 inline below.
> 
> After reviewng tw short related draft rahter quickly,
> it took me significantly more time t review his one,
> I look forwar to the discssions we will have in Anaheim.
> 
>     Juergen
> 
> 
>>      nternet-Draft                                 M. Chandramouli
>>      Expis: August 5, 2010                             . Schoening
>>                                                   Cisco Systems, Inc.
>>                
>>                                                      Feruary 5, 2010
>>      
>>                              EnergyMonitoring MIB
>>                     draft-laise-energy-monitoring-mi-01
> 
>  [snip]
> 
>>     Abstract 
>> 
>>        This documentdefines the Manageent Infrmation Base (MIB)
>
>>         for theenergy monitoring ofnetwork elements.
> 
>  [snip]
> 
>>      3. Terminology
>> 
>>        Energonitor Entity
>>       
>>       
>      Intenet-Draft        <Energy Montoring MB>           Feb 2010
>>          
> you call is mst times "EnergMonitor Entity", but several times just
> "EnergyMonitor".  hink the latter is sufficient.
> 
> Why is"EnergyMonitor"ne word and not two like "Enrgy Monitor"?
>  
>            component, that provides pwer or draws power.  It canbe
>>            independently managed from a pwer monitoring ad power state
>>            configuration point of view.  This entitymay e represented
>>           by a physical component referenced using the ntPhysicalTabl
>>           Exampes of EnergyMonitor Entities are a router line card, a
>>           A uniform way to clasify power setings on an EnergyMonitor
>>            Etity.  Levls are guidelines for the mnufacturers of
> 
 I don't thnk that levels by themselves can beguidelines.
> But level specifications an be guidelines:
> "Levels -> "Level specifications"?
> 
>>            etity (e.g., shut, hibrnate, sleep, standby).
>>             
>>          
>          EnergyMonitor Scale
>>          >            A scale used to rpresent saller or larger quantities of
> for the SI (System Iterntional) units of measure.  Measured
>>            valuesare reresented in SI units obtained by BaseValue * 10
>>           raised o the power of Scale.
>>            
>>            For examle, ifcurrent usage of an Energyonitor Entity is
>>            3, it could b 3 W, 3 mW, 3 KW, 3 MW depeding on the vaue
>>            of EnergyMonitoScale.
>>            
>>             
>>        EnergMonitor Domain
>>          
>>          comprises a uni o manageable power consumpion.  For
>>           example, all phones i a floor, all EnergyMoitor Entities
>>           from a specific building,or all EnergyMontor Entities of a
>>           specific device type for hich a common profie is deployed.
> 
> Grouping of devices that contain each other can be moeled in a better
> Way by the entity ontainment tree othe Entity MIB module.
> 
> For vices tat are physically separate, such as all phones on a floor,
> I don't think tat this information should be stored in te MIB module.
> Grouing of separate devics is the job of the management system mnitoring
> Them. The manageent syste can do much more than the vague and fla
> according to veral spects and use hierarchical or otherwie structured
> Groupings. Also they an (and actually do) apply different grouping schemes
> to he same set o devices for different purposes, for example an energy
> Consumr group ad a provider group in parallel t one grp per building
> level.
> For none o thse schemes it is required to storethe group name(s) on the
> dvie itself. Also, a relocation of a device from one floorto aother one
> would require a re-configration if the floor domain is stored onthe
> device.
> 
> Poweris an energy rate. Energy can be consumed. I do say that power
> cannot be consumed. Bt the consumption of a rate sounds like a non-trivial
> cncept that deserves further explanation. robably, the all instances of
> "power cosumption" in this draft refer to "energ consmption" and can
> be rplaced accordingly.
>  
>>           to report the total energconsumedas the sum of energy
>>           consumed by all th EnergyMonitor Entitiesof the
>>           EergyMonitor Domain.
>>       
>>       
>> 
>> 
>>>      
>>       
>>      Internet-Draft       <Energy Monitoring MIB>           Feb 201>
>. Concepts 
>> 
>>                   Level        ACPIGlobal/System      Name
>>                                    State
>>          
>>        Non-operational states:
>>          
>>                    1               G3, S5           Mech Off
>>                     2              G2, S5           Soft Off
>>                     3               G1, S4          Hibernae
                      5               G, S2           Stadby
>>                    6               G2, S1           Ready
>>         
>>         Operational states:
>>                     7               G0, S0, P5       Low
>>                    8               G0, S0, P4       rugal
>>                     9              G0, S0, P3       Mediu
>>                   10               G0, S0, P2       Reduced
>>                   11               G0, S0, P1       High
>>                   12               G0, S0, P0       Full
> 
> The non-operatioal states seem to be clear, but theoperationa states
> may be hard to apply in an ineroperable way to a router, a lincard,
> Etc. 
> 
>>         For example the energy state of th EnergyMonitor Enity is 9,
>>         to indicte the entity is medium power consuption operatonal
> 
>>       The emEnergyUsageCatgory MIB obect, specified as a read-only
>>       object, specifies t enery usage type of the EnergyMonitor
>>        Entity: energy consu, energy producer, or meter.  The
> 
> A battery, for example can wod act a consumer when charging
>>        ntity consumes or produces power in cae o "consumer" and
>>        "producer".
>> 
>>        An Eerg Monitor Entity should have an eName, and a unique
>>        entityPhysicalIndex fom the ENTITY-MIB [RFC4133,if supported
> I am missing a statemet like
>   "If entPhysicalName iset for the entity, then emName shuld be empty".
> 
>>        address of thdevice, interface ifName, r a tex string
>>        uniquely identifying te entty.  The emName should ideally be>> unique.  As an example, in the case of phones, emNamecan be
>>       discovered by DNS and can be the IP addres or MAC-ddress.  In
>>        the case of router/switch line cards th emName shall be text
> 
> "shall" o "SALL"?
> 
>>        EnrgyMonitor Domin.  The EnergyMonitor Doin could map 1-1
>>        ith a metered or sub-meered portion of the customers site.  It
>>       can be usedto further sub divide the deployment dow to fin
>>        EnergyMnitor Domains such as a lab, data center, racket.
>> 
>>         document thenotion of EnergyMonitor Doain shall be useful.
>>          
>>         For an nergyMoitor Entity, instantaneous energy usage is
>          reported usingemEnergyUsage an the unit magnitude of
>>       measurement is specified in emEnrgyUnits whch is based on
>>         EnergyMonitorPowerScale.
>          
>>        Nameplate power consumption of an EnergMonitor ntity is
>>         specified by the vendor as the maximum capcity required to
>>        safelypower the device.  Often this label is a conservative
>>         nmber an is the worst case power draw of all elements in a
>>         flly conigured system.  While th actual utilizaion of an
>>         entitycan be lower, Nameplate por consumption is important
>>         for pwer provisioning, capacity planing and billing.
>>         In additionto measuremet of power consumption, an approach to
>>         chaacterize e power demand is also presented in te MIB.  It
>>         is well-known,  theelectrical utility perspective,the demand
>>         harges can weigh on par ith actual energy charge.  So, in
>         addition to measuring power cnsumption, it is useful o
>>         characterize the demad.  The demand can be described asaverage
>>         powe usage of an entity over a time window,called demand
>>        interval,typically 15 minutes.  The highet peak demand
>>         measure over a time horizon, say1 month or 1 yea is often the
>>         bas for usage charge.  For example, a single wndow oftime of
>>         high usage can penalize the poer consumptio charges.  It is
>>        relevant to mesure the emand, only when tere are actual power
>>         measurements from a EnrgyMonitor Entity.  There are cases,
>>         wherei th power measurement of an EnergyMonitorEntity i
>>         assumed or predicted as pointed in the MIB OID
>>         nergyUsagCaliber.
> 
> Object EnergyUsageCalier is no of type OID.
> "in the MIB OID" -> "in te ESRIPTION clause of objec"
> 
>>         Two tables ae introduced to charactrize the energy demand -
>>        emDemandTable and emDemandCntroTable.  emDemandControl Table
>>        consistsof parametes of the duration of the demand interval
>>         specified in seconds, mDemandConrolIntervalLength, (for e.g.
>>       
>>      
>>      <Claise, et. Al>        Expires Agust , 2011            [Page 7]
>>          
>> 
>      InternetDraft        <Energy Montoring MI>           Feb 2010
>>        15 minutes); The number of demand inters kept in the
>>        mDemandControlSampleRate which is intenal to te device to
>>        calculate energy usage.  Judicius choice of SamplingRate would
>>         help i accurae measurement of energy and ensure tat it does
>>         useful to pecify the powermeasurement is actual and thus to
>        indicate if the emDemandTable entries exist ornot.>>       
>>         emDemand Table consists of measuremens of energy
>>         DmandIntervalEnergyUsed, the scaleof energy measurement -
>>         DemandIntervalEergyScale and the maximum observed demand in a
>>         indow - emDemandIntervalMaxf
>>          
>>        Various efficiency metrics can be deried and tracked with the
>>         uage data present in thi MIB module.  For example,
>>          >>          Per-packet enery costs for a networking device (router or
>>          switch) can be calclated by an network management system.
>>           The acets count can be determined from the traffic usae in
>>          fro the platform specifiations
>>         - Watt-hour energy use fromthis MI can be combined with
>>           utility energy sorces to estimate carbon fotprint and other
>>         emission statistics.
>>          >>         An example is provided to ilustrate he concepts.  For eample,
>>         a given EnergyMonitor Entity as escribed by the emIndex 7"
>>         emPhysicalEntity "5" and emName  "sitch2.fo.com".  For that
>>         EnergyMonitor Etity,the energy measurement and power state is
>>         reported as folows: the units f measurement emEnergyUnits is
>>        "watts" (value 1), theinstantaneous powerusage enEnergyUsage
> 
> Watts is a unit of power, ot  unit of energy.
> "power usag" -> "energy usage"
> 
>>         is 10 watts, hile the maximum poer consumption as prescribed
> 
>>         by the vendor emEergyNamePlate is 300 watts. The
>>         emEnergyUsageCaliber indicates that the energymeasurement is>
> "actual".  The power state of that EnergyMonitor Entity>>        EmEnergyLevel is "9" to indicate edium power usage and
>>         emEnegyUsageCatgory indicates the type of EnergyMonitor Entity
>>         consuer or producer of power orboth.  In addition, the maximum
> 
> "of power" -> "f energy"
> 
>>         following the same exmple.  Fistly, in order to estimate
>>         demand, an interval to samle power uage should be specified,
>>         i.e.  emDemandControlIntervalength cn be "900 seconds" and the
>>         number of consecutve intervals over whch the maximum demand is
>>         caculated emDemandControlIntervalNumber s "10".  The sampling
>>         rate internal to the nergyMonitor Entiy for measurement of
>>       
>>       
>      Internet-Draft      <Energy Monitoring IB>           Feb 2010
>>         ative (value 1) to indicatethat the EnergyMonitor Entty
> "idenstiufies" -> identify"
> 
>>         emDemandIntervalStartTime, which denotes the start ime of the
>>         dnd measurement interval based on he sysUpime.
>>         (emDemandConrolIntervalLength) ased on the EnergyMonitor
>>         Entity internal sapling rate (emDemandControlSampleRate).  Te
>>         units are derived fom emDemanIntervalEnergyScale is based
>>         EnergyMonitorScale.  For xample, emDemandIntervalEnergyUsed can
>>         be "100" with emDemandIntevalEnergyScale equal to 0, the demand
>>         s 100 watt-hours.  emDemndIntervalMax is the maximum demand
>>         obsrved can be "150watt-hors".
>>          
>>         The emDemandTable has a buffer to retain a crtain number of
>>         intervals, as defined by emDemandControlIntervaNumber.  If the
>>         defaul value of "10" is kept, then the emDemndTabl contains
>>         10 demand measurements including the maximu.  A brief
>>         explanation on how the maximum demandis calculated.  The first
> 
>>         With each easurement, based on numerical comparison, maximum
>>         demnd may be updated  The maximum value is retained as long as
>>         the measurement is taing place.  Based on periodic polling, the
>>         Network Manaement Sytem can compute the maximum over a longer
>>         period i.e. a monh, 3 months, or a year.
>>          
>>        [POWER-MON-REQ] specifes some requirements about power states
>>         such as "th currentstate - the time of the last change", "the
>>         total ime spent in ea state", "the number of transitions to
>>        each state", etc...  Such rquirements are fulfilled thanks to
>>         the emEnyLevel, which is genrated when the value of
>         emEnergyLevel has changed forthe EnergyMonitr Entity
>>         represented by the emIndex.  Indeed, assumin that the SNP
>>         notifications arrives to Network Mnagement Statin (NMS), the
>>         The pimary MIB object in this MIB module is
>>         nergyMonitorMIBObjects.
>>       
>>       
>>      
>>        The emTable tabledefines he EnergyMonitor Entities, with a
>>        the entities that re possible candidats for power management.
>>         TheemLevelTable table lists the maximum power usageat each
>>         EnegyMonitor Level for eachEnergyMonitor Entiy.
>>          
>>         SNMP agent canbe turned on/off ith the emEnable MIB object.
>>          
>>                 
>>      5.1.1. Link with the ENTITY-MIBand the ENTITY-SENSO-MIB
>> 
>>         RFC 4133 [RFC4133] defines the Etity MIB module hat lists the
>>        physical entities of a networking dvice (route, switch) and
>>         tose physical entities liste indexed by entPhysicalIde.
>>         From an nergy management point of view, of interest ar the
>>         provies a sandardized way of obtaining information (current
>>         value of the sensor, operaionl status of the sensor, and the
>>         data units precision) from sensors embded in networking
>>         devices.  Sensors are associated wih each indx of
>>         entPhysicalIndex ofthe Entity MIB [RFC4133].  Whie the focu
>>         of he Energy Moitoring MIB, is on measement of energy
>>         consumpti by networing equipment indexed by the entity MIB,
>>        this MIB proposes a cstomize power scale for power measurement
>>        When this MIB mdule is used to moitor the enery consumption
 "should" -> "SHULD" ?
> 
>>         EnergyMonitor Entitie are modeled by the entPhysicalIndex
>>         through the emPhysicalEntity MIB objet specified in the
>>         emTable.
>> 
>>         However, the ENTITY-SNSOR-MIB doesn't have the ANSI C12.x
>>         accuracy classes requird for electricity, i.e., %, 2%, 0.5%
>>        use an accuracy class, and not the preision model in RFC3433.
> 
> Two questions: 
> Why are we required to use ANSI accuracy casses?
> Why can't ANSI accuracy classes be represented by entPhysicalTable
> 
> So far ut I cannot see from the text why hey would be correct.
> 
>>         The emEnergyUsageAccurcy MIB object models this acuracy. Note
>>         thatthe emEntEnergyScale represets the scale is a mor logical
>>       
>>       
>      Internet-Draft        <Enery Monitoring MIB>           Fb 2010
>>         representation (ompared to entPhySensorScale), with the
>>         mantissa and the exponent values X * 10 ^ Y.>> 
>>         SENSR-MIB are implemente for all EnergyMonitor Entity that
>>         needs to bemonitored.  A typical example is a onverged
> 
> Why? You cold just mandate tha when you implement the Enery MIB
> module, this impmentation MUST include the Entity MIit is not
> available already.
> 
>>         building gatewy, monitoring several other devicesin the
>>         building, doing the proxy beween SNMP and a protocol suc as
>>         BACNET.  other example is the home energy conoller.
> 
> Why do these examples imply that if the Energy IB is implemented, the
> Entity MIBcannot be implemented as well? I don not see any reason for this.
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Benoit Claise <[email-masked]>
Date: Tue, 16 Mar 2010 12:18:33 +0100

Juergen,

Thanks for your detailed feedback. I can see that you spent quite some 
time on this draft.
See inline.
>>      Internet-Draft<Energy Montoring MIB>            Feb 2010
>>
In the version 2, we called that "PowerMonitor Entity".
We're fine with PowerMonitor
> included the EnergyMotor Entity is a meter. This should be overed here.
In the version 2, we added some more examples: connected building, data 
center, etc..
We'll extend the definition.
> "Levels" ->  "Level specifications"?

So basically, we believe that these should be guidelines. Maybe a better 
name is power policy
It's up to each device to document what it can do at each level.

Mapping levels to a device state begins with looking at the number of 
operational power states the device supports, and evenly as possible 
mapping these to levels.   Levels can be either scaled (i.e., an 
incandescent light dimmer) or discrete operational states (i.e, a 
florescent light bank).

Ex 1:   an IP phone with a single operational power mode (12w);

levels Low...Full : 12w

Ex 2:  an IP phone with an external dial pad and power savings (LCD off) 
having three power modes (i.e., 9w, 12w, 14w);

levels Low & Frugal :  9 w -- power savings mode (also corresponds to 
'aLldpXdot3LocReducedOperationPowerValue')

levels Medium & Reduced :  12w -- phone powered, but not external dial pad

levels High & Full :  14w -- phone and external dial pad powered

Ex 3: a Laptop PC with Windows 7 default power management has three 
levels:  High Performance, Balanced, and Power Saver.

                                 Levels low & Frugal : Power Saver

                                 Levels Medium & Reduced : Balanced

                                 Levels High & Full : High Performance

> Way by the entity ontainment tree of the Entity MIB module.
Sure, if you speak about the entPhysicalContainsTable table, which is 
good for containment information within a device/SNMP agent.
> would require a re-configuration if the floor domain is stored on the

Let's take the simple example of an IP phone or access point, I agree 
that the domain should not be stored on the IP phone or access point.
For the simple reason that if you move the device, you'll have to 
reconfigure it, which is not practical.
However, I believe that it makes sense to store the domain in the 
switch, because:
     - for example, a specific switch port is associated to a specific 
domain
     - for example, based on the device type (potentially received from 
LLDP, if enable), the domain can be set according to the policy stored 
in the switch

Btw, we propose to rename the domain to meterDomain, if it makes more sense
The meterDomain is the command/control of the device, not for accounting 
or policies or arbitrary grouping.
     A device can be part of multiple groups, administered by the NMS
     A device can be part of only one meterDomain

> "power consumption" in this draft refer to "energy consmption" and can
We corrected this one in the version 2 of the draft. Hopefully all 
instances.
>>       Internet-Draft<Energy Monitoring MIB>            Feb 201>       4. Concepts
>>

Considering that these are policies, you have a good point.
Do you have an alternative?

> Pors, but not as "producer".
Agreed.
> enMane ans emIndex should be introduced to the reader before usng it.
Agreed
>    "If entPhysicalName iset for the entity, then emName should be empty".
Can we simply say that, in this case, emName = entPhysicalName?
>>         the case of router/switch line cards, th emName shall be text
Yes.
> "in the MIB OID" ->  "in the ESRIPTION clause of object"
yep.
>>      Internet-Draft<Energy Monitoring MIB>            Feb 210
Ok. However, we tried to justify that these are not good enough.
> So far but I cannot see from the text why they would be correct.
This is how people measures power usage accuracy. See the scale 
multiplier in IEC 61850 Annex A

The ENTITY-SENSOR-MIB doesn't offer the relative accuracy, only the scientific precision.

entPhySensorPrecision OBJECT-TYPE
     SYNTAX        EntitySensorPrecision
     MAX-ACCESS    read-only
     STATUS        current
     DESCRIPTION
             "The number of decimal places of precision in fixed-point
             sensor values returned by the associated entPhySensorValue
             object.

Note: the PoE MIB doesn't use the ENTITY-SENSOR-MIB

>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
The version 2 of the draft, we have introduced the notion of 
parent/child, for the case where the parent reports the power used by 
children.
For example:
     * PoE IP Phone
     * PoE IP Phone PC connected to the IP Phone
     * PoE Access Point + PCs connected
     * A building Mediator + Power meters associated with power 
consuming entities (HVAC, lighting, electrical, fire control, elevators, 
etc...
     * Data centers + several servers
My point is that we can't expect the ENTITY MIB to present on every 
children. Specifically, when we speak about power meters, a PC, a 
server, etc...

> Entity MIB cannot be implemented as well? I don not see any reason for this.
See my previous comment
> Certainly, they are more clear than the operational states defined above.

      EntityStandbyStatus  ::=  TEXTUAL-CONVENTION
        STATUS         current
        DESCRIPTION
             " Represents the possible values of standby status.
               A value of 'hotStandby' means the resource is not
               providing service, but it will be immediately able to
               take over the role of the resource to be backed up,
               without the need for initialization activity, and will
               contain the same information as the resource to be
               backed up.  A value of 'coldStandy' means that the
               resource is to back up another resource, but will not
               be immediately able to take over the role of a resource
               to be backed up, and will require some initialization
               activity.  A value of 'providingService' means the
               resource is providing service.  A value of
               'unknown' means that this resource is unable to
               report standby state."
              SYNTAX         INTEGER
                {
                unknown (1),
                hotStandby (2),
                coldStandby (3),
                providingService (4)
                }

  These are not ignored, but have direct correspondence.

                                 unknown -> pmEnable == Disable

                                 hotStandby -> Ready in our MIB

                                 coldStandby -> Standby in our MIB

                                 providingService -> all operational 
levels Low..Full in our MIB

Our power policy model is an abstraction that is designed to allow 
interoperability among ACPI, Windows power states, and  other power models.
> The PoE MIB module with an index of an entry in the physical entity table?
I found the missing link in the RFC3621 Power Ethernet MIB wrt the 
entPhysicalIndex and/or ifIndex link .. in a Cisco private MIB 
ftp://ftp.cisco.com/pub/mibs/v2/CISCO-POWER-ETHERNET-EXT-MIB.my

cpeExtPsePortEntry OBJECT-TYPE
     SYNTAX          CpeExtPsePortEntry
     MAX-ACCESS      not-accessible
     STATUS          current
     DESCRIPTION
         "A cpeExtPsePortEntry extends a corresponding
         pethPsePortTable entry. This entry displays and
         controls more characteristics of a power Ethernet
         port on a PSE device."
     AUGMENTS           { pethPsePortEntry  }

     ::= { cpeExtPsePortTable 1 }

...

cpeExtPsePortEntPhyIndex OBJECT-TYPE
     SYNTAX          EntPhysicalIndexOrZero
     MAX-ACCESS      read-only
     STATUS          current
     DESCRIPTION
         "The entPhysicalIndex value that uniquely identifies the
         PSE port. If the PSE port does not have a corresponding
         physical entry in entPhysicalTable or if the
         entPhysicalTable is not supported by the management
         system, this object has the value of zero."
     REFERENCE       "RFC 2737, entPhysicalIndex."
     ::= { cpeExtPsePortEntry 11 }

In the version 2 of the draft, we have added two new objects in the 
monitoring table: pmethPortIndex  (PethPsePortIndexOrZero TC) and 
pmethPortGrpIndex ( PethPsePortGroupIndexOrZero TC).
This makes the link with Power Over Ethernet MIB (RFC3621) if implemented.
>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
>>          --
>>                      E-mail:[email-masked]"
>>
>>            DESCRIPTION
Ok.

>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
>>
>>             ::= { mib-2 xxxxx }
>>
>>                  Specification,http://www.acpi.info/spec30b.htm)
>>                  (maximum performance&  power) through P5 (minimum
Correct. However, this can be represented by its parent.
> several of the following states) can be reported.
We will elaborate on this one.

>>                   softoff(2)  : Similar to off, but some components
good catch
> "soft-off" ->  "state softoff(2)"
and again.
>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
>>                                 to level G2 in ACPI.
>>
ok.
> "maps" ->  "corresponds" (also for the following states) ?
ok.
> "available" ->  "available except for wake-up mechanisms"
yes.
> consecutive sentences and each time you refer to a different concept
We will clarify.
> Registers? Cashes? Queued operations?
To be expanded
> Meanings within the same sentence. This needs more explanation.
To be clarified.
> processors are executing anything, the device cannot be in state
To be clarified.
> Less than what? Less energy than in state low(7)?
To be clarified.
> "usage" ->  service" (also for the following states)

To be clarified.
>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
Power levels can be either scaled (i.e., an incandescent light dimmer) 
or discrete operational states (i.e, a florescent light bank).
Note that, even if not clearly expressed in the draft, the pmLevelTable 
should implement all levels, even if not supported.

             pmLevelTable OBJECT-TYPE
             SYNTAX          SEQUENCE OF PmLevelEntry
             MAX-ACCESS      not-accessible
             STATUS          current
             DESCRIPTION
                "This table enumerates the maximum power usage in watts
                at each PowerState Level for each PowerMonitor Entity.

                This table has an expansion dependent relationship on the
                pmTable, containing rows describing each PowerState Level
                for the corresponding PowerMonitor Entity."
             ::= { powerMonitorMIBObjects 2 }

This might look an overkill, but it's easier to quickly see gain we 
could get from going level to another.

> so for an implementer than using globally unique IDs.
Agreed. We'll correct.
> This may require changing the SYNTAX clause to a longer OCTET STRING.
if we work with UUID, we don't need this, right?

> This duplicates EntitySensorDataScale with only slight variations.
its consistent with IEC 61850 Annex A unit multiplier which is common 
convention in the power management domain

>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
Will correct ;-)
> above plus emName by just a single object.
As discussed above
> emPower would be a good alternative name.
Ok. Actually we renamed that to pmPowerUsage in the version 2, but we 
agree with pmPower, which is a better name

> emPowerAccuracy and emPowerCaliber
In version 2, we renamed that to

  pmPowerUsageNameplate    Integer32,
  pmPowerUsageAccuracy     Integer32,

But we'll change them to emPowerAccuracy and emPowerMeasurementCaliber

> in the fist sentence, then it is unique in any domain.
Agreed.

>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
>>              DESCRIPTION
ok
> from one NMS to another one.
However, from a switch point of view, it's interesting to have show 
commands that contains power consumption for all children in the domain
> Overlapping domains or multiple parallel domain hierarchies are nit
A single membership of the meterDomain, which meter and control the device
> This object should be empty, if emPhysicalEntity has a value different
What about copying the emPhysicalEntity name into this emName?

> Was there a good reason for not having it?
I don't know!
>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
>>
ok.
> "positive" ->  "positive or zero"
ok.
> "negative" ->  "negaive or zero"
ok.
> does). This should be mentioned explicitly.

We intentionally don't distinguish between real and apparent power in 
this MIB.  Power quality attributes such as these are Important and 
would be good to include in a companion power-quality-MIB
> Therefore, it would also be a good idea to rename the object to
Ok
> "worst-case" ->  "maximum"
We like the "worst case" better here. It really is worst case, not a 
useful maximum
> "operating level"  ->  "operational consumption"
ok.
> power while the value provided by emEnergyLevel is (assumed to be)
I'd like to punt on real vs. apparent power to a companion 
power-quality-mib.  Since the majority of consumer equipment real == 
apparent, its confusing to introduce the distinction in this context.  
We can run this idea by Schneider and see what there take on it is.  I 
don't believe nameplate volts * current is called 'apparent' even though 
it shares units with reactive power.

>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
>>
>>                      IEC 62053-22&  60044-1 class 0.1, 0.2, 0.5, 1&  3.
>>                      ANSI C12.20 class 0.2&  0.5"
>>              ::= { emEntry 10 }
>>
good catch
> ->  "real current energy consumption rate"
ok.

>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
As a non-native English speaker, I agree with you.
I'll let the native English speakers decide.
> "device type"? Please clarify.
We will.
> see corresponding comment on section 4.
  If you're a solar-panel or windmill, you are a "producer".  PoE ports 
"provide" power, but the switch itself is being classified as a "consumer"
> Or is metering energy consumption a kind of energy usage?
We'll change the instances of "energy usage" by "energy"
> "produced" ->  "provided or consumed by other devices".
Fine.
>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
>>          emLevelTable OBJECT-TYPE
Yes, there should be.
We will improve for the next version.
> the power level is not supported by the device).
Yes, it is mandatory to create entries for each power level (even if
the power level is not supported by the device).
The reason is that the processing for the NMS would be easier.
We'll clarify.
> This should be called emLevelPowerScale.
Let's call it "unitMultiplier" using the same nomenclature as IEC 61850 
Annex A
>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
>>
>>
potentially 0xFFFF?
> Why is this called "demand control" although it is about

I was under the impression that the convention was to call the control 
table with the same root as the data table, like it was done in RMON2

emDemandControlTable<- emDemandTable

Checking this, RFC4181 doesn't cover it.

>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
>>          }
>>
>>
ok.
> I guess it also affects emEnergyUsage?
Actually, no. It's for the emDemandTable.
> which objects are affected.
ok.
> What value should be reported if the sample rate is unknown? Zero?
yes, zero is fine.
>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
>>
>>
Will clarify.
> Why not for trusted(3) and predicted(4)?
for trusted(3) and predicted(4) usage is either not of sufficient 
caliber to trend, or not usage we're measuring.  We would just be 
extrapolating predicted or reported-elsewhere values.  Thus, we only 
will sample and trend usage we actual(2)-ly measure.
> if the corresponding value of object emEnergyUsageCaliber is active(2).
ok.
>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
>>              DESCRIPTION
Good point, we could look at the RMON table or something else that 
trends to see how to reset.  It's a corner case that probably would not 
happen in real life.
>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
>>                              }
>>              MAX-ACCESS      read-write
>>              STATUS          current
>>              DESCRIPTION
Will clarify.
> I would suggest removing this object.
Ok.
> suggest reporting this redundant object.
Good catch.
We'll correct that!
>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
>>
>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
Yes, we'll improve this one.
>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
>>
Ok.
> I think this can be an informative reference.
ok.
> I think this can be an informative reference.
ok.
> This should be an informative reference.
ok.
>>                  Specification",http://www.acpi.info/spec30b.htm
>>
>>
>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
>>
>>        Email:[email-masked]
>>      Internet-Draft<Energy Monitoring MIB>            Feb 2010
>>        Bangalore,
>>        IN
>>
>>        Phone: +91 80 4426 3947
>>        Email:[email-masked]
>>
>>
>>        John Parello
>>        Cisco Systems Inc.
>>        3550 Cisco Way
>>        Email:[email-masked]
>>        Email:[email-masked]