Re: [eman] Comments on draft-ietf-eman-battery-mib-12
Alan Luchuk <luchuk@snmp.com> Thu, 06 November 2014 19:26 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 8E9791A8A69 for <eman@ietfa.amsl.com>; Thu, 6 Nov 2014 11:26:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.204
X-Spam-Level: *
X-Spam-Status: No, score=1.204 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MANGLED_INCRS=2.3, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
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 xik0cmu1HOX5 for <eman@ietfa.amsl.com>; Thu, 6 Nov 2014 11:26:02 -0800 (PST)
Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id ECABD1A8A68 for <eman@ietf.org>; Thu, 6 Nov 2014 11:26:01 -0800 (PST)
Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA22051; Thu, 6 Nov 2014 14:25:58 -0500 (EST)
Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id sA6JPwXg015045; Thu, 6 Nov 2014 14:25:58 -0500 (EST) (envelope-from luchuk@mainfs.snmp.com)
Received: (from luchuk@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) id sA6JPw1L015044; Thu, 6 Nov 2014 14:25:58 -0500 (EST) (envelope-from luchuk)
Date: Thu, 06 Nov 2014 14:25:58 -0500
From: Alan Luchuk <luchuk@snmp.com>
Message-Id: <201411061925.sA6JPw1L015044@mainfs.snmp.com>
To: Quittek@neclab.eu, eman@ietf.org, Alan Luchuk <luchuk@snmp.com>
In-Reply-To: Your message of Wed, 5 Nov 2014 10:18:22 +0000 <9AB93E4127C26F4BA7829DEFDCE5A6E894DE2DAB@PALLENE.office.hd>
References: <201403121757.NAA24671@adminfs.snmp.com> <9AB93E4127C26F4BA7829DEFDCE5A6E894C4AADA@PALLENE.office.hd> <9AB93E4127C26F4BA7829DEFDCE5A6E894DE2DAB@PALLENE.office.hd>
X-Mailer: mail (GNU Mailutils 2.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/eman/hltnx-4nnqbgbErGh66ZyDlAjNo
Subject: Re: [eman] Comments on draft-ietf-eman-battery-mib-12
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, 06 Nov 2014 19:26:03 -0000
Hello, >From: Juergen Quittek <Quittek@neclab.eu> >To: "eman@ietf.org" <eman@ietf.org> >CC: Alan Luchuk <luchuk@snmp.com> >Subject: RE: [eman] Comments on draft-ietf-eman-battery-mib-12 >Date: Wed, 5 Nov 2014 10:18:22 +0000 > 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header > > >The issues concerns the battery capacity for which we use an Unsigned64TC in order to be able to support batteries with more than 4MAh. The correct comment from Alan was that if we do so, we should for consistency also support corresponding 64-bit values for the objects we have concerning the electric current. For this we would need to introduce a new Signed64TC. This is all possible and no technical problem. > >However, I checked for existing battery sizes. It shows that all kinds of batteries that are used in electric vehicles or that you can by as energy storage for private households are well covered if we just use Unsigned32 for capacity values. If you go for industrial use, very large batteries are delivered in units of in 40-foot intermodal freight shipping containers. Even for the total capacity of such container, the Unsigned32 value would fit, although there would be not much headroom for further increa>ses of battery capacity per container. However, these containers are not organized as a "single" battery, but as an array of multiple batteries. And each individual one would be modeled as a separate row in the batteryTable of our MIB module. For the individual tables, I do not see a problem, with modeling them by Unsigned32 values. > >So, my proposal is removing the inconsistency addressed by Alan by reverting to Unsigned32 bit values for all objects related to battery capacity. +1 Seems like a reasonable solution to me also. 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] Comments on draft-ietf-eman-battery-mib-12 Alan Luchuk
- Re: [eman] Comments on draft-ietf-eman-battery-mi… Juergen Quittek
- Re: [eman] Comments on draft-ietf-eman-battery-mi… Juergen Quittek
- Re: [eman] Comments on draft-ietf-eman-battery-mi… John Parello (jparello)
- Re: [eman] Comments on draft-ietf-eman-battery-mi… Alan Luchuk