Re: [eman] MIB-Doctor Review of draft-ietf-eman-battery-mib-11
Juergen Quittek <Quittek@neclab.eu> Thu, 27 February 2014 10:06 UTC
Return-Path: <Quittek@neclab.eu>
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 623CC1A0806; Thu, 27 Feb 2014 02:06:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.449
X-Spam-Level:
X-Spam-Status: No, score=-0.449 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, 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 dk2oNI3xcIGz; Thu, 27 Feb 2014 02:06:26 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 693341A07EF; Thu, 27 Feb 2014 02:06:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id B9B88106E5C; Thu, 27 Feb 2014 11:06:24 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjNbFzu6LezB; Thu, 27 Feb 2014 11:06:24 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 99F3F106E84; Thu, 27 Feb 2014 11:06:04 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.233]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 27 Feb 2014 11:06:04 +0100
From: Juergen Quittek <Quittek@neclab.eu>
To: Thomas Nadeau <tnadeau@lucidvision.com>, "draft-ietf-eman-battery-mib@tools.ietf.org" <draft-ietf-eman-battery-mib@tools.ietf.org>
Thread-Topic: [eman] MIB-Doctor Review of draft-ietf-eman-battery-mib-11
Thread-Index: AQHPGUrAPWHfU4CFBUe1IOKiozRfY5rHwzYA
Date: Thu, 27 Feb 2014 10:06:04 +0000
Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6D34F@PALLENE.office.hd>
References: <BE98C880-7F58-41E4-BA0D-D1E233D79ACA@lucidvision.com>
In-Reply-To: <BE98C880-7F58-41E4-BA0D-D1E233D79ACA@lucidvision.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.99.69]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/eman/vN-u3kESSD4HoK87wIp3Fn3vmcg
Cc: "MIB Doctors (E-mail)" <mib-doctors@ietf.org>, eman mailing list <eman@ietf.org>
Subject: Re: [eman] MIB-Doctor Review of draft-ietf-eman-battery-mib-11
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: Thu, 27 Feb 2014 10:06:28 -0000
Dear Tom, Thank you very much for your review. Please see replies in line. This email addresses all of your issues except for the last one which I will reply to in a separate message. Cheers, Juergen > -----Original Message----- > From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Thomas Nadeau > Sent: Freitag, 24. Januar 2014 22:24 > To: draft-ietf-eman-battery-mib@tools.ietf.org > Cc: MIB Doctors (E-mail); eman mailing list > Subject: [eman] MIB-Doctor Review of draft-ietf-eman-battery-mib-11 > > > > I reviewed this draft as part of the MIB Doctor review on Friday, > January 24, 2014. > In general the MIB is in good shape. I have some questions/comments inline > begin with TOM: > > General Comments on the draft: > > 1) My run of id-nits produced no errors and a few warnings that can be > ignored. > > 2) In general, please go through the MIB modules and verify that the > Integer32 values are indeed ok to be negative values or change them to > Unsigned. For example, there are many instances where you used Integer32 > for things like watts or amps where negative values do not make sense, to > me at least. We use Integer32 for Current and temperatures. For temperature we do not use Kelvin, but degree Celsius as units which may have negative values. For current the DESCRIPTION clause explains that positive values are for charging current and negative values are for discharging current. > [snip] > -------------------------------------------------------------------- > -- 1.1. Battery Table > -------------------------------------------------------------------- > batteryTable OBJECT-TYPE > SYNTAX SEQUENCE OF BatteryEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table provides information on batteries. It contains > one conceptual row per battery. > > TOM: Is this a set of batteries per managed device? Yes. For example, the notebook I am writing this email on has two batteries. Proposal: OLD "This table provides information on batteries. It contains one conceptual row per battery. NEW "This table provides information on batteries. It contains one conceptual row per battery in a managed entity > [snip] > > batteryTemperature OBJECT-TYPE > SYNTAX Integer32 > UNITS "deci-degrees Celsius" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The ambient temperature at or near the battery. > > TOM: Is there some spec that defines what "near" means? No, there is not. Actual implementations vary significantly. Some sensors are directly attached to or even inside the battery, some are a few centimeters away from the battery, but (hopefully) in the flow of heated air that passed the battery for cooling. Even for sensors inside the battery, there are problems. Sometimes single cells in a multi-cell battery become very hot. Then it depends on the location of the sensor (close to the particular cell or rather far away) if this is observable from outside. > [snip] > > batteryAlarmHighCycleCount OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This object provides the upper threshold value for object > batteryChargingCycleCount. If the value of object > batteryChargingCycleCount rises above this threshold, > a battery aging alarm will be raised. The alarm procedure > may include generating a batteryAgingNotification. > > A value of 0 indicates that no alarm will be raised for any > value of object batteryChargingCycleCount." > > TOM: Is there any sort of holding time period over which an alarm should be > not emitted? I can imagine a case where a battery is charged, discharged, > etc... and just goes above and below this threshold causing a lot of > notifications to be emitted. Another option would be to add variable that > defines X numebr of notifications per time period. Yes, there is. We have specified this in the DESCRIPTION clauses of Some NOTIFICATION-TYPEs but apparently not for all where this would Be desirable. Please see a separate email on this issue. For the cycle count alarm above we do not see a need for this, because The cycle count is monotonically increasing. > [snip] > > batteryTemperatureNotification NOTIFICATION-TYPE > OBJECTS { > batteryTemperature, > batteryCellIdentifier > } > STATUS current > DESCRIPTION > "This notification can be generated when the measured > temperature (batteryTemperature) rises above the threshold > defined by object batteryAlarmHighTemperature or falls > below the threshold defined by object > batteryAlarmLowTemperature. > > If the low or high temperature has been detected for a > single cell or a set of cells of the battery and not for the > entire battery, then object batteryCellIdentifier should be > set to a value that identifies the cell or set of cells. > Otherwise, the value of object batteryCellIdentifier should > be set to the empty string when this notification is > generated." > ::= { batteryNotifications 4 } > > TOM: The same comment about rate limiting as above. I can see when a > battery is failing this value could float just about and below this value causing > numerious notifications to be issued. Have you considered such cases? Please see separate email. Thanks, Juergen
- [eman] MIB-Doctor Review of draft-ietf-eman-batte… Thomas Nadeau
- Re: [eman] MIB-Doctor Review of draft-ietf-eman-b… Juergen Quittek
- Re: [eman] MIB-Doctor Review of draft-ietf-eman-b… Thomas Nadeau
- Re: [eman] MIB-Doctor Review of draft-ietf-eman-b… Juergen Quittek