Subject: [eman] Comments on draft-ietf-eman-energy-monitoring-mib-04.txt

From: Alan Luchuk <[email-masked]>
Date: Wed, 13 Mar 2013 15:12:05 -0400 (EDT)

Hello,

Based upon review and prototyping the ENERGY-OBJECT-MIB, and the
POWER-CHARACTERISTICS-MIB from draft-ietf-eman-energy-monitoring-mib-04.txt,
here are a comments about the ENERGY-OBJECT-MIB.  I hope these are helpful 
to the IETF EMAN WG.

Sincerely,
--Alan

Page 6, Last Sentence, and Page 7, First Sentence:
--------------------------------------------------

This text currently reads:

        The energyObjectMib MIB module consists of four tables.  The
        first table eoPowerTable is indexed by entPhysicalIndex. The
        second table eoPowerStateTable indexed by entPhysicalIndex,
        and eoPowerStateIndex. The eoEnergyParametersTable is indexed
        by eoEnergyParametersIndex. The eoEnergyTable is indexed by
        eoEnergyParametersIndex and eoEnergyCollectionStartTime.

I suggest the following replacement:

        The energyObjectMib MIB module consists of five tables.  

        The first table is the eoMeterCapabilitiesTable.  It indicates 
        the instrumentation available for each energy object.  Thus,
        the entries in this table indicate to the EnMS which other 
        tables from the ENERGY-OBJECT-MIB and POWER-CHARACTERISTICS-MIB 
        are available for each energy object.  The eoMeterCapabilitiesTable 
        is indexed by entPhysicalIndex.

        The second table is the eoPowerTable.  It returns the power
        consumption of each energy object, as well as the units, sign,
        measurement accuracy, and related objects. The eoPowerTable is
        is indexed by entPhysicalIndex.

        The third table is the eoPowerStateTable.  For each energy
        object, it provides information and statistics about the
        supported power states.  The eoPowerStateTable is indexed by
        entPhysicalIndex and eoPowerStateIndex.

        The fourth table is the eoEnergyParametersTable.  The entries
        in this table configure the logging of energy and demand 
        information.  This table is indexed by eoEnergyParametersIndex.

        The fifth table is the eoEnergyTable.  The entries in this table
        provide the log the energy and demand information.  This table
        is indexed by eoEnergyParametersIndex.

Page 14, Section 5.1, Last Paragraph:
-------------------------------------

The text reads:

        The Energy Object identity information is specified in the MIB
        ENERGY-AWARE-MIB module [EMAN-AWARE-MIB] primary table, i.e. the
        eoTable. In this table, every Energy Object SHOULD have a
        printable name eoName, and MUST HAVE a unique Energy Object
        index entPhysicalUUID and entPhysicalIndex. 

I could not find an object called eoName.

Page 21, Section 5.5, Second Paragraph:
---------------------------------------

The text reads:

        It is relevant to measure energy when there are actual power
        measurements from an Energy Object, and not when the power
        measurement is assumed or predicted as specified in the
        description clause of the object eoPowerMeasurementCaliber.

I had to study and think about this section of the document; it's meaning 
was not immediately obvious to me.  I _think_ what this is trying to say 
is that unless eoPower is actually measured by some kind of hardware, the
energy and demand values are not useful or meaningless.  I suggest:

I suggest replacing the text above with:

        It is relevant to measure energy and demand only when there are 
        actual power measurements obtained from measurement hardware.
        If the eoPowerMeasurementCaliber MIB object has values of 
        unavailable, unknown, estimated, or presumed, then the energy
        and demand values are not useful.

Page 37, the DESCRIPTION for IANAPowerStateSet:
-----------------------------------------------

Extra enumerations can cause the eoPowerStateTable to greatly increase
in size.  Is the eoPowerStateTable required to have entries for all 
enumerated values of a power state, even if the hardware cannot support
them?

Should there be a power state set consisting of only "off" and "on"?
I would think that PoE ports, or PDU interfaces, might only have these
two power states.

I suggest adding clarifying text for the questions above to the 
DESCRIPTION clause.  Also, I suggest adding the following text to the
DESCRIPTION clause:

        An energy object can support zero, one, or more power state 
        sets.  If an energy object can report power states, it is 
        not required to implement more than one power state set.
        The preferred power state set is the EMAN power state set.

Page 40, the eoPowerTable:
--------------------------

The eoPowerTable contains the eoPower object for returning the power
consumed by the energy object.  The eoEnergyTable can maintain a
running log of eoPower samples, and from this energy demand obtained.
The  eoACPwrCharacteristicsTable  includes the MIB objects:

    eoACPwrCharacteristicsTotalActivePower
    eoACPwrCharacteristicsTotalReactivePower
    eoACPwrCharacteristicsTotalApparentPower
    eoACPwrCharacteristicsTotalPowerFactor

Would it make sense to add MIB objects to the eoPowerTable for the
reactive power, apparent power, and power factor, similar to the
eoPower value?  Would it then make sense to add MIB objects to the 
eoEnergyTable to contain the maximum values for the reactive power, 
apparent power, and power factor?  This would allow obtaining demand
values for reactive power, apparent power, and power factor.
Do electrical utility companies include demand values for reactive
or apparent power in their billing computations?

Page 41, the eoPowerNameplate object:
-------------------------------------

The current syntax is Integer32.  Should this be an Unsigned32?   Are
there energy objects that would really have a negative nameplate power?

Page 43, the DESCRIPTION for eoPowerMeasurementCaliber value actual(3):
-----------------------------------------------------------------------

The text reads:

               - actual(3):  Indicates that the reported usage was
               measured by the entity through some hardware or direct
               physical means. The usage data reported is not presumed
               (4) or estimated (3) but the real apparent current energy
               consumption rate.

I suggest changing the text to:

               - actual(3):  Indicates that the reported usage was
               measured by the entity through some hardware or direct
               physical means. The usage data reported is not presumed
               (4) or estimated (3) but is the measured energy
               consumption rate.

The phrase "real apparent current" is confusing with "real power" and 
"apparent power" due to non-resistive loads.

Page 43, the DESCRIPTION for eoPowerCurrentType:
------------------------------------------------

The text reads:

              "This object indicates whether the eoUsage for the
               Energy Object reports alternative current AC(1), direct
               current DC(2), or that the current type is unknown(3)."

I suggest the text:

              "This object indicates whether the eoPower for the
                                                 ^^^^^^^
               Energy Object reports alternating current AC(1), direct
                                     ^^^^^^^^^^^
               current DC(2), or that the current type is unknown(3)."

Page 43, the DESCRIPTION for eoPowerStateEntry:
-----------------------------------------------

The test reads:

            DESCRIPTION
               "A eoPowerStateEntry extends a corresponding
               eoPowerEntry.  This entry displays max usage values at
               every single possible Power State supported by the Energy
               Object.
               For example, given the values of a Energy Object
               corresponding to a maximum usage of 11W at the
               state 1 (mechoff), 6 (ready), 8 (mediumMinus), 12 (High):

                    State         MaxUsage Units
                     1 (mechoff       0       W
                     2 (softoff)      0       W
                     3 (hibernate)    0       W
                     4 (sleep)        0       W
                     5 (standby)      0       W
                     6 (ready)        8       W
                     7 (lowMinus)     8       W
                     8 (low)         11       W
                     9 (medimMinus)  11       W
                    10 (medium)      11       W
                    11 (highMinus)   11       W
                    12 (high)        11       W

The text in the last sentence before the table does not seem to match
the table.

Regarding the eoPowerStateTable, is a row required for each enumerated
value in a power state set, even if the device does not implement the
all of the power states?

For example, suppose a vendor wanted to produce a manageable PDU, with
a different entPhysicalIndex for each power interface.  Now suppose
the vendor wanted to implement the DMTF power state set.  If the PDU
could only support the values  dmtfOn(513)   and  dmtfOffHard(516),
would the eoPowerStateTable be required to have a row for all of the
other, unsupported, enumerated values in the  DMTF power state set?

Of the documents I studied, I do not remember text that clarified this.
It would be helpful to add clarifying text, even if it already exists
somewhere else.

Page 46, eoPowerStateMaxPower:
------------------------------

In practice, how will the eoPowerStateMaxPower values be determined?

Maybe I'm missing something, but it seems like in the very vast majority
of cases these values will either be wild guesses or unknown.  Will they 
ever be measured dynamically, or just hard-coded at the factory?

Is this object truly useful?

Should there be additional objects in the table for measurement caliber
and accuracy?

Page 47, the DESCRIPTION for eoPowerStateTotalTime:
---------------------------------------------------

The description text reads:

              "This object indicates the total time in hundreds
              of seconds that the Energy Object has been in this power

Should the description text read:

              "This object indicates the total time in hundredths
                                                       ^^^^^^^^^^
              of a second that the Energy Object has been in this power
                 ^^^^^^^^

Page 47, the DESCRIPTION for eoEnergyParametersTable:
-----------------------------------------------------

I believe that expanding the DESCRIPTION to repeat the fact that
implementing this table and the eoEnergyTable only makes sense for
energy objects that an eoPowerMeasurementCaliber of actual(3).

Also if an implementor chooses to implement the eoEnergyParameters-
Table and eoEnergyTable, for an energy object that may not or 
optionally may support an eoPowerMeasurementCaliber of actual(3), 
then what is the code supposed to do?  

Should the eoEnergyParametersTable refuse to create a row for 
energy objects that do not actually measure the eoPower?  Should
the eoEnergyTable refuse to log values for non-measured values of
eoPower?

Page 48, the eoEnergyParametersEntry:
-------------------------------------

The entry is currently defined as:

        eoEnergyParametersEntry OBJECT-TYPE
            SYNTAX          EoEnergyParametersEntry
            MAX-ACCESS      not-accessible
            STATUS          current
            DESCRIPTION
               "An entry controls an energy measurement in
               eoEnergyTable."
            INDEX  {  eoEnergyParametersIndex }
            ::= { eoEnergyParametersTable 1 }

        EoEnergyParametersEntry ::= SEQUENCE {
                eoEnergyObjectIndex                PhysicalIndex,
                eoEnergyParametersIndex            Integer32,
                eoEnergyParametersIntervalLength   TimeInterval,
                eoEnergyParametersIntervalNumber   Integer32,
                eoEnergyParametersIntervalMode     Integer32,
                eoEnergyParametersIntervalWindow   TimeInterval,
                eoEnergyParametersSampleRate       Integer32,
                eoEnergyParametersStatus           RowStatus
        }

Should the entry be defined as:

        eoEnergyParametersEntry OBJECT-TYPE
            SYNTAX          EoEnergyParametersEntry
            MAX-ACCESS      not-accessible
            STATUS          current
            DESCRIPTION
               "An entry controls an energy measurement in
               eoEnergyTable."
            INDEX  {  entPhysicalIndex, eoEnergyParametersIndex }
            ::= { eoEnergyParametersTable 1 }

        EoEnergyParametersEntry ::= SEQUENCE {
                eoEnergyParametersIndex            Integer32,
                eoEnergyParametersIntervalLength   TimeInterval,
                eoEnergyParametersIntervalNumber   Integer32,
                eoEnergyParametersIntervalMode     Integer32,
                eoEnergyParametersIntervalWindow   TimeInterval,
                eoEnergyParametersSampleRate       Integer32,
                eoEnergyParametersStatus           RowStatus
        }

The fact that the EoEnergyParametersEntry is not doubly-indexed with the
first index being  entPhysicalIndex  struck me as inconsistent and odd.

Page 49, the DESCRIPTION for eoEnergyParametersIntervalNumber:
--------------------------------------------------------------

The last sentence of the text reads:

               There is one exception to
               this rule: when the eoEnergyMaxConsumed and/or
               eoEnergyMaxProduced are in (one of) the two oldest
               measurement(s), they are left untouched and the next
               oldest measurement is replaced."

This might be inefficient to implement.  Each time an entry is added
to the eoEnergyTable, then all entries in the eoEnergyTable (that result
from that eoEnergyParametersEntry) must be scanned before deciding
which is the oldest entry that can be expired.

Not sure if this is a good idea, but perhaps adding MIB objects to the
eoEnergyParametersEntry to save the eoEnergyMaxConsumed or eoEnergyMax-
Produced would be more efficient and easier to implement.

Page 50, the eoEnergyParametersSampleRate:
------------------------------------------

The units for eoEnergyParametersSampleRate is specified as milli-
seconds.  Would it make sense to change the UNITS to centi-seconds 
to match the resolution of the  eoEnergyParametersIntervalLength
and  eoEnergyParametersIntervalWindow  objects?  Also, changing 
the units to centi-seconds (arguably) might prevent the sampling 
rate from being set to values that might be burdensome to the 
implementing system.

Page 51, the DESCRIPTION for eoEnergyTable:
-------------------------------------------

It might be helpful to expand the DESCRIPTION clause to state that
the eoEnergyTable is conceptually like a log file.

Page 52, the DESCRIPTION for eoEnergyCollectionStartTime:
---------------------------------------------------------

The DESCRIPTION text reads:

               "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 periods
               for which the energy is measured."
 
How about substituting:

               "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 specifies the start time of the energy
               measurement sample."

Page 54, the eoPowerStateChange NOTIFICATION:
---------------------------------------------

Is there any way to disable the eoPowerStateChange notification?  If
not, an energy object could flood an EnMS with these notifications.

 ------------------------------------------------------------------------------
 Alan Luchuk               SNMP Research, Inc.          Voice:  +1 865 573 1434
 Senior Software Engineer  3001 Kimberlin Heights Road  FAX:    +1 865 573 9197
 luchuk at snmp.com        Knoxville, TN  37920-9716    http://www.snmp.com/
 ------------------------------------------------------------------------------

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Thu, 14 Mar 2013 06:05:21 +0000

Hi Alan,

Thanks very much for taking time to review the MIB modules.  I have read through your comments. 

We plan to submit an updated version of the draft and we shall incorporate your feedback. 

Thanks
Mouli 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan Luchuk
Sent: Thursday, March 14, 2013 12:42 AM
To: [email-masked]
Subject: [eman] Comments on draft-ietf-eman-energy-monitoring-mib-04.txt

Hello,

Sincerely,
--Alan

The text reads:

The text reads:

The text reads:

The text reads:

I suggest the text:

The test reads:

            DESCRIPTION

                    State         MaxUsage Units
                     1 (mechoff       0       W
                     2 (softoff)      0       W
                     3 (hibernate)    0       W
                     4 (sleep)        0       W
                     5 (standby)      0       W
                     6 (ready)        8       W
                     7 (lowMinus)     8       W
                     8 (low)         11       W
                     9 (medimMinus)  11       W
                    10 (medium)      11       W
                    11 (highMinus)   11       W
                    12 (high)        11       W

 
How about substituting:

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