Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13

Brad Schoening <brads@coraid.com> Wed, 19 February 2014 04:29 UTC

Return-Path: <brads@coraid.com>
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FCB1A0325 for <eman@ietfa.amsl.com>; Tue, 18 Feb 2014 20:29:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEKAUZ7uuJxp for <eman@ietfa.amsl.com>; Tue, 18 Feb 2014 20:29:19 -0800 (PST)
Received: from server506.appriver.com (server506k.appriver.com [50.56.144.157]) by ietfa.amsl.com (Postfix) with ESMTP id 525491A0129 for <eman@ietf.org>; Tue, 18 Feb 2014 20:29:19 -0800 (PST)
X-Note-AR-ScanTimeLocal: 2/18/2014 10:29:14 PM
X-Policy: GLOBAL - coraid.com
X-Policy: GLOBAL - coraid.com
X-Primary: brads@coraid.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-14/SG:2 2/18/2014 10:28:16 PM
X-GBUdb-Analysis: 0, 10.242.229.139, Ugly c=1 p=-0.972283 Source White
X-Signature-Violations: 0-0-0-23357-c
X-Note-419: 62.4016 ms. Fail:0 Chk:1345 of 1345 total
X-Note: SCH-CT/SI:0-1345/SG:1 2/18/2014 10:29:07 PM
X-Note: Spam Tests Failed:
X-Country-Path: UNKNOWN->PRIVATE->UNITED STATES
X-Note-Sending-IP: 10.242.229.139
X-Note-Reverse-DNS: smtp.exg6.exghost.com
X-Note-Return-Path: brads@coraid.com
X-Note: User Rule Hits:
X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445
X-Note: Encrypt Rule Hits:
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [10.242.229.139] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 46313026; Tue, 18 Feb 2014 22:29:14 -0600
Received: from DAGN05C-E6.exg6.exghost.com ([169.254.3.11]) by HT04-E6.exg6.exghost.com ([50.56.144.22]) with mapi id 14.03.0174.001; Tue, 18 Feb 2014 22:29:14 -0600
From: Brad Schoening <brads@coraid.com>
To: Alan Luchuk <luchuk@snmp.com>, "eman@ietf.org" <eman@ietf.org>
Thread-Topic: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13
Thread-Index: AQHPLSsk3UblO5lWEECy3YcSkC9tzw==
Date: Wed, 19 Feb 2014 04:29:13 +0000
Message-ID: <CF2995D3.11CC99%brads@coraid.com>
In-Reply-To: <201312301853.NAA03279@adminfs.snmp.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [50.56.144.245]
x-rerouted-by-exchange:
Content-Type: text/plain; charset="us-ascii"
Content-ID: <ADDE76D63680AE4D8983C62BE2058DBD@fwd6.exghost.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/eman/J3yi_g6MNEsr_7d-I0Mt-rPyMPQ
Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions about the Energy Management Working Group <eman.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eman>, <mailto:eman-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/eman/>
List-Post: <mailto:eman@ietf.org>
List-Help: <mailto:eman-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eman>, <mailto:eman-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Feb 2014 04:29:22 -0000

Hi Alan,

Thanks for your review of the EnergyMonitoringMib v8 and the many helpful
comments.  I have fixed or resolved  all of the 26+ issues you mention in
the latest published draft, v9.  Of the two remaining, please see my
comments below:

#1) In the MIBs, adding eye-catching comments between the tables would ease
visually identifying where each MIB table begins.


I wasn't sure how to address this.


#2) Would it be useful or helpful to have UnitsMultiplier companion
objects for
the following objects?

My feeling is generally, no, because voltage and THD values are not
additive and don't have a large range.  AC voltage is commonly 120, 240 or
480.  THD is a percentage value and also has a fixed range.  However,
perhaps amperes should be in 0.01 amperes units.  I'm not certain, but
perhaps this could have a unit multiplier.

Finally, when reviewing your comments on eoACPwrAttributesPhaseEntry
together with the latest IEC 61850, I realized this could be simplified
and have elided the common PhaseEntry table in favor of only Del and Wye
subtables.

Best Regards,

Brad

On 12/30/13 1:53 PM, "Alan Luchuk" <luchuk@snmp.com> wrote:

>Hello,
>
>Here are comments about  draft-ietf-eman-energy-monitoring-mib-08 and
>draft-ietf-eman-energy-aware-mib-13.  Due to the holidays, I was unable
>to get these sent to the WG E-mail list sooner.
>
>
>Regarding draft-ietf-eman-energy-aware-mib-13:
>----------------------------------------------
>
>Section 5, Page 6:
>
>   The UML on Page 6 _looks_ incorrect.  It _looks_ like the
>eoRelationTable
>   is subordinate to, or a child of, the eoEntry.  I'm not sure how the
>   actual relationship specified in the MIB is _supposed_ to be
>represented
>   in UML.
>
>
>Page 22:
>
>   The eoRelationID in the eoRelationTable is "read-only".  In many cases,
>   I do not see how an energy object can determine the eoRelationID to the
>   Energy Objects to which it is connected, so I _think_ the eoRelationID
>   must be configured by the EnMS.  I _think_ the eoRelationID should be
>   a read-write object like the eoRelationship object.
>
>   As an example, consider a manageable, metering power distribution
>   unit (PDU), I don't see how it can autodiscover and populate the
>   eoRelationID of the energy objects to which it is connected.  The
>useful-
>   ness of the eoRelationID MIB object is reduced if it is only populated
>   in devices where it can be autodiscovered.
>
>
>
>Regarding draft-ietf-eman-energy-monitoring-mib-08:
>---------------------------------------------------
>
>Section 5, 3rd paragraph, Page 6:
>
>       "entity4CRCompliance.  This compliance requires that the
>        following 3 MIB objects from ENTITY-MIB [RFC6933]
>        (entPhysicalIndex, entPhysicalName and entPhysicalUUID) MUST be
>        implemented."
>
>   I think entPhysicalClass should be included in this list.  There are
>   other references to the entity4CRCompliance in this draft that need the
>   same update.
>
>
>Section 5, Page 7:
>
>          |   +-- r-n INTEGER           eoMeasurementCaliber(5)
>
>   I think the above should be eoPowerMeasurementCaliber(5).
>
>          |      +-- r-n Interger32        eoPowerStateMaxPower(2)
>
>   Change "Interger32" to Integer.
>
>          |   +-- r-n Integer32    eoEnergyParametersIntervalMode(5)
>
>   I think the type of "eoEnergyParametersIntervalMode" should be INTEGER.
>
>
>Section 5, Page 8:
>
>   I suggest changing "powerAttributesMIB" to "POWER-ATTRIBUTES-MIB" for
>   for consistency with previous text that references the
>ENERGY-OBJECT-MIB
>   and POWER-ATTRIBUTES-MIB.
>
>   A quick summary of the function of each of the tables in the POWER-
>   ATTRIBUTES-MIB, similar to the quick summary of each of the tables in
>   the ENERGY-OBJECT-MIB (on Page 6) might be helpful and consisent.
>
>
>          |   +-- r-n Interger32 eoACPwrAttributesAvgVoltage(2)
>
>      |   +-- r-n Interger32
>          |                   eoACPwrAttributesTotalActivePower(7)
>
>   Change "Interger32" to Integer.
>
>   In the diagram for the eoACPwrAttributesEntry, after eoACPwrAttributes-
>   ThdAmpheres, the eoACPwrAttributesThdVoltage object is missing.
>
>   Also, here, and several places in the document, "Ampheres" is
>referenced.
>   Not sure if "Ampheres" is intentional, but "Amperes" might be
>preferable.
>   It might be good to do a case-insensitive search for "ampheres".
>
>
>Section 5, Page 9:
>
>          +-- eoACPwrAttributesDelPhaseEntry(1)
>          |     |   [entPhysicalIndex, eoPhaseIndex]
>          |     | 
>          |     +-- r-n Integer32
>          |     |    eoACPwrAttributesDelPhaseToNextPhaseVoltage(1)
>          |     +-- r-n Integer32
>          |     | eoACPwrAttributesDelThdPhaseToNextPhaseVoltage(2)
>          |     +-- r-n Integer32
>                                 eoACPwrAttributesDelThdCurrent(3)
>
>   I think the column numbers 1, 2, and 3, are incorrect.  The actual
>column 
>   numbers in the MIB are 2, 3, and 4.  Perhaps the MIB table should be
>fixed 
>   so the column numbers are 1, 2, and 3.
>   
>
>Section 5, Page 12.
>
>   At the very top, in the diagram for the eoACPwrAttributesEntry, after
>   eoACPwrAttributesThdAmpheres, the eoACPwrAttributesThdVoltage object
>   is missing.
>
>
>Section 5.4, Page 15:
>
>   I suggest changing "powerAttributesMIB" to "POWER-ATTRIBUTES-MIB" for
>   for consistency with previous text that references the
>ENERGY-OBJECT-MIB
>   and POWER-ATTRIBUTES-MIB.
>
>
>Section 6, Page 20:
>
>   This section references the EMAN-MON-MIB.  I think this should be
>   ENERGY-OBJECT-MIB.
>
>
>Section 9, Page 27:
>
>   This section references the "energyObjectMIBObject".  Not sure what
>this
>   is.
>
>
>In the MIBs, adding eye-catching comments between the tables would ease
>visually identifying where each MIB table begins.
>
>
>Page 37, "eoPowerOperState" MIB object:
>
>   The second paragraph of the DESCRIPTION clause reads:  "Possible values
>   of eoPowerAdminState...".   I think "eoPowerAdminState" should be
>changed
>   to "eoPowerOperState."
>
>
>Page 38, "eoPowerStateTable":
>
>   The text reads:
>
>       This table has an expansion-dependent relationship on the
>       eoPowerTable, containing rows describing each Power State
>       for the corresponding Energy Object. For every Energy
>       Object in the eoPowerTable, there is a corresponding
>       entry in this table."
>
>   Not sure I correctly understand this table, but should the second
>sentence
>   read something like:  "For every Energy Object in the eoPowerTable,
>there 
>   is a corresponding set of entries in this table, one entry for each
>power 
>   state supported by the Energy Object."
>  
>
>Page 38, "eoPowerStateEntry":
>
>   In the DESCRIPTION clause, the state numbers and state names do not
>match
>   any documented enumerations for the IANAPowerStateSet textual
>convention.
>   Should the existing values be replaced with:
>
>           eman(1024),       -- indicates EMAN set
>           emanmechoff(1025),
>           emansoftoff(1026),
>           emanhibernate(1027),
>           emansleep(1028),
>           emanstandby(1029),
>           emanready(1030),
>           emanlowMinus(1031),
>           emanlow(1032),
>           emanmediumMinus(1033),
>           emanmedium(1034),
>           emanhighMinus(1035),
>           emanhigh(1036)
>
>
>Page 45, "eoEnergyStored":
>
>   The first sentence of the DESCRIPTION clause reads:
>
>   "This object indicates the resultant of the energy consumed..."
>
>   Perhaps the following text would be clearer:
>
>   "This object indicates the difference of the energy consumed..."
>                              ^^^^^^^^^^
>
>
>Page 46, "eoEnergyMaxConsumed":
>
>   The DESCRIPTION text reads:
>
>       "This object is the maximum energy ever observed in
>       eoEnergyConsumed since the monitoring started. This value
>       is specified in the common billing units of watt-hours
>       with the magnitude of watt-hours (kW-Hr,   MW-Hr, etc.)
>       indicated separately in eoEnergyUnitMultiplier."
>
>   Does this mean that the eoEnergyMaxConsumed value must be retained
>   across reboots, and thus must be stored in non-volatile memory?
>
>
>Page 48/49/54, where "entity4CRCompliance" is listed:
>
>   I believe the "entPhysicalClass" object must be added to the lists of
>   MIB objects (entPhysicalIndex,  entPhysicalName and entPhysicalUUID).
>
>
>Page 56, "eoACPwrAttributesAvgCurrent":
>
>   It might be niced to expand the DESCRIPTION clause so that it more
>   precisely specifies the significance of this, perhaps similar to the
>   DESCRIPTION clause for "eoACPwrAttributesAvgVoltage".
>
>
>Page 56, "eoACPwrAttributesFrequency":
>
>   The UNITS clause does not match the comment after the SYNTAX clause.
>
>        eoACPwrAttributesFrequency OBJECT-TYPE
>            SYNTAX          Integer32 (4500..6500) -- UNITS 0.01 Hertz
>            UNITS           "hertz"
>
>
>Would it be useful or helpful to have UnitsMultiplier companion objects
>for 
>the following objects?
>
>   Page 58, "eoACPwrAttributesThdAmpheres":
>   Page 60, "eoACPwrAttributesPhaseAvgCurrent":
>   Page 62, "eoACPwrAttributesDelPhaseToNextPhaseVoltage":
>   Page 63, "eoACPwrAttributesWyePhaseToNeutralVoltage":
>   Page 64, "eoACPwrAttributesWyePhaseCurrent":
>                  
>
>Page 59, "eoACPwrAttributesPhaseEntry":
>   
>   Under the DESCRIPTION clause, it might be helpful to add a comment that
>   indicates the phase-to-phase voltages are in separate tables.
>
>   When I first encountered the "eoACPwrAttributesPhaseEntry", I wondered
>   about the voltages until I read further in the MIB and found the
>   eoACPwrAttributesDelPhaseTable and the eoACPwrAttributesWyePhaseTable.
>
>
>
>Page 60, "eoACPwrAttributesPhaseActivePower",
>         "eoACPwrAttributesPhaseReactivePower",
>         "eoACPwrAttributesPhaseApparentPower":
>
>   Expanding the DESCRIPTION clauses to note these are scaled by the
>   eoACPwrAttributesPowerUnitMultiplier might be helpful, but the
>   DESCRIPTION clause for the "eoACPwrAttributesPowerUnitMultiplier"
>   does note this scaling relationship.
>
>
>Page 61, "eoACPwrAttributesPhaseImpedance":
>
>   Are the UNITS of "volt-amperes" correct?
>
>
>
>Page 62/63, "eoACPwrAttributesDelPhaseToNextPhaseVoltage",
>            "eoACPwrAttributesDelThdPhaseToNextPhaseVoltage",
>            "eoACPwrAttributesDelThdCurrent":
>
>   The last SID values for these objects are 2, 3, and 4, which distinctly
>   does NOT match the values shown in the figure on Page 9, which shows
>   the last SID values as 1, 2, and 3.
>
>
>Page 74, Section 13:
>
>        [EMAN-AWARE-MIB] J. Parello, B. Claise and M. Chandramoili,
>                "draft-ietf-eman-energy-aware-mib-11 ", work in
>                progress, November 2013.
>
>   Does it matter, or should this reference draft 13,
>   draft-ietf-eman-energy-aware-mib-13?
>
>
>Regards,
>--Alan
>
> 
>--------------------------------------------------------------------------
>----
> 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/
> 
>--------------------------------------------------------------------------
>----
>
>_______________________________________________
>eman mailing list
>eman@ietf.org
>https://www.ietf.org/mailman/listinfo/eman