Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13
Alan Luchuk <luchuk@snmp.com> Mon, 30 December 2013 18:54 UTC
Return-Path: <luchuk@snmp.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 DA3CA1AE293 for <eman@ietfa.amsl.com>; Mon, 30 Dec 2013 10:54:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.26
X-Spam-Level:
X-Spam-Status: No, score=0.26 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 gBe4_-6RGt0K for <eman@ietfa.amsl.com>; Mon, 30 Dec 2013 10:54:05 -0800 (PST)
Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 88BBF1AE2D7 for <eman@ietf.org>; Mon, 30 Dec 2013 10:54:04 -0800 (PST)
Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id NAA11789; Mon, 30 Dec 2013 13:53:15 -0500 (EST)
Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id NAA03279; Mon, 30 Dec 2013 13:53:14 -0500 (EST)
Date: Mon, 30 Dec 2013 13:53:14 -0500
From: Alan Luchuk <luchuk@snmp.com>
Message-Id: <201312301853.NAA03279@adminfs.snmp.com>
To: eman@ietf.org
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: Mon, 30 Dec 2013 18:54:08 -0000
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/ ------------------------------------------------------------------------------
- Re: [eman] WG Last Call for draft-ietf-eman-energ… Alan Luchuk
- Re: [eman] WG Last Call for draft-ietf-eman-energ… Benoit Claise
- Re: [eman] WG Last Call for draft-ietf-eman-energ… Brad Schoening