Re: [eman] Comments on draft-ietf-eman-battery-mib-12

"John Parello (jparello)" <jparello@cisco.com> Wed, 05 November 2014 16:00 UTC

Return-Path: <jparello@cisco.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 B344A1A89AC for <eman@ietfa.amsl.com>; Wed, 5 Nov 2014 08:00:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.095
X-Spam-Level:
X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 9eepKl_ybyb9 for <eman@ietfa.amsl.com>; Wed, 5 Nov 2014 07:59:57 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA8B11A8978 for <eman@ietf.org>; Wed, 5 Nov 2014 07:59:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11218; q=dns/txt; s=iport; t=1415203184; x=1416412784; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=TgLMyBZs0rRKdW46tZueTbSaLIBUWEEzoPAQ0pkLtK0=; b=Hg35UPa6xE5b5JlSGGAZohtXygfwfrRc0aLPD5tWL50SSwf8Py2v6eab 40Vl4vacMbtEE6iWjt66fZEj44UeDsJY1yikVHfZhurugfZsSzygpEp6b rk1uxGe7fupPCjU/gws5OgbXyPStNzscpR4xzpJpND4ISA2s/6RWdw3I/ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhsFACNIWlStJA2F/2dsb2JhbABcgw5UWQTNEAqHTQKBGBYBAQEBAX2EAgEBAQMBAQEBaxcEAgEIEQQBASgHJwsUCQgCBAESCYgvCQ3KWwEBAQEBAQEBAQEBAQEBAQEBAQEBAReORoFjEA8eMgaERQWGN4UGhC6CNocXhFiBMYNMgzJTiUqECYN4bIEGAR8igQMBAQE
X-IronPort-AV: E=Sophos;i="5.07,320,1413244800"; d="scan'208";a="93624419"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP; 05 Nov 2014 15:59:43 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sA5Fxh4u011559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Nov 2014 15:59:43 GMT
Received: from xmb-aln-x04.cisco.com ([169.254.9.81]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Wed, 5 Nov 2014 09:59:43 -0600
From: "John Parello (jparello)" <jparello@cisco.com>
To: Juergen Quittek <Quittek@neclab.eu>, "eman@ietf.org" <eman@ietf.org>
Thread-Topic: [eman] Comments on draft-ietf-eman-battery-mib-12
Thread-Index: AQHPPhyR01Pf0T/df0iAad42tJCXWZv6T0sAgFlcuAD//9k+gA==
Date: Wed, 5 Nov 2014 15:59:42 +0000
Message-ID: <D07F8954.65A5%jparello@cisco.com>
References: <201403121757.NAA24671@adminfs.snmp.com> <9AB93E4127C26F4BA7829DEFDCE5A6E894C4AADA@PALLENE.office.hd> <9AB93E4127C26F4BA7829DEFDCE5A6E894DE2DAB@PALLENE.office.hd>
In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E894DE2DAB@PALLENE.office.hd>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.5.141003
x-originating-ip: [10.21.67.117]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <A658FF1AC08B0C4DA7397E2D57FF60D9@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/eman/-EqWuGRCez8SEuTOFlPqCYGfheg
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: Wed, 05 Nov 2014 16:00:00 -0000

+1 Sounds reasonable

Jp


On 11/5/14 2:18 AM, "Juergen Quittek" <Quittek@neclab.eu> wrote:

>Dear all,
>
>Here is a proposal on the one open issues resulting from Alan's very
>helpful comments.
>
>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
>increases 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.
>
>Cheers,
>    Juergen
>
>> -----Original Message-----
>> From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Juergen Quittek
>> Sent: Dienstag, 9. September 2014 16:39
>> To: Alan Luchuk; eman@ietf.org
>> Subject: Re: [eman] Comments on draft-ietf-eman-battery-mib-12
>> 
>> Dear Alan,
>> Here comes a very late reply on your message. It got lost in our
>>records,
>> because at that time you had two sets of comments and I found a message
>> from you at that time stating "thank you for considering my comments".
>>But
>> you message was referring to another set. Fortunately, Benoit discovered
>> that your comments have not been included and I come back to them right
>> now.
>> 
>> Your comments are highly appreciated and I agree on most of them. The
>> next version -14 will include according changes.
>> 
>> There is only a comment that I am not sure how to deal with it. It
>>concerns
>> the Unsigned64TC for capacity. Please find a reply inline below.
>> 
>> Best regards,
>>     Juergen
>> 
>> 
>> > -----Original Message-----
>> > From: eman [mailto:eman-bounces@ietf.org] On Behalf Of Alan Luchuk
>> > Sent: Mittwoch, 12. März 2014 18:57
>> > To: eman@ietf.org
>> > Subject: [eman] Comments on draft-ietf-eman-battery-mib-12
>> >
>> > Hello,
>> >
>> > Here are comments on  draft-ietf-eman-battery-mib-12.txt.  I think
>> > only the last issue in the list may be a true problem; it is easily
>> > fixed.  There is one technical issue that might be worthy of further
>> > consideration.  The rest are these are typos or grammatical nits.
>> >
>> > I hope these are helpful to the EMAN WG.
>> >
>> > Regards,
>> > --Alan
>> >
>> >
>> >
>> > Page 3, Introduction  (typo)
>> > ----------------------------
>> >
>> > The second paragraph from the bottom contains the sentence:
>> >
>> >    Many battery-driven devices have existing instrumentation for
>> >    monitoring the battery status, because this is already needed for
>> >    local control of the battery by the device.
>> >
>> > I think the comma is not needed; perhaps the sentence should read:
>> >
>> >    Many battery-driven devices have existing instrumentation for
>> >    monitoring the battery status because this is already needed for
>> >    local control of the battery by the device.
>> >
>> >
>> >
>> > Page 4, Introduction (typo)
>> > ---------------------------
>> >
>> > The first paragraph from the top contains the sentence:
>> >
>> >    The former allows tracing a battery and allows continuous
>>monitoring
>> >    even if the battery is e.g. installed in another device."
>> >
>> > I think the "e.g." is not needed; perhaps the sentence should read:
>> >
>> >    The former allows tracing a battery and allows continuous
>>monitoring
>> >    even if the battery is installed in another device."
>> >
>> >
>> >
>> > Page 5, MIB Module Structure (grammer)
>> > --------------------------------------
>> >
>> > The third paragraph from the top reads:
>> >
>> >    If batteries are replaced, and the replacing battery uses the same
>> >       ^^^^^^^^^^^^^                   ^^^^^^^^^^^^^^^^^
>> >    physical connector as the replaced battery, then the replacing
>> >    battery SHOULD be indexed with the same value of object
>> >    entPhysicalIndex as the replaced battery.
>> >
>> > In the first clause the subject is plural, in the second clause, the
>> > subject is singular.  Perhaps the sentence should read:
>> >
>> >    If a battery is replaced, and the replacing battery uses the same
>> >       ^^^^^^^^^^^^                   ^^^^^^^^^^^^^^^^^
>> >    physical connector as the replaced battery, then the replacing
>> >    battery SHOULD be indexed with the same value of object
>> >    entPhysicalIndex as the replaced battery.
>> >
>> > The same text appears in the description clause for the batteryTable
>> > on page 10.
>> >
>> >
>> >
>> > Page 5, MIB Module Structure (nit)
>> > ----------------------------------
>> >
>> > The last paragraph on page 5 and the first paragraph on page 6 mention
>> > three groups of objects:  objects with OIDs ending with 1-10, objects
>> > with OIDs ending with 11-18, and objects with OIDs ending with 20-25.
>> >
>> > The  batteryCellIdentifier object ends with SID 19 and is not included
>> > in any of the three groups.
>> >
>> >
>> >
>> > Page 13, DESCRIPTION for batteryTechnology
>> > ------------------------------------------
>> >
>> > The DESCRIPTION for batteryTechnology reads:
>> >
>> >    "This object indicates the technology used by the battery.
>> >    Numbers identifying battery types are registered at IANA.
>> >    A current list of assignments can be found at
>> >    <http://www.iana.org/assignments/eman>.
>> >
>> >    Value 0 (unknown) MUST be used if the type of battery
>> >    cannot be determined.
>> >
>> >    Value 1 (other) can be used if the battery type is known
>> >    but not one of the types already registered at IANA."
>> >
>> > I tried to access the URL shown above, and could not.  I assume it has
>> > not yet been created by IANA.
>> >
>> > Also, the values and enumeration names do not match the table shown in
>> > section 3.2 on page 7.  I think this part of the DESCRIPTION should
>>read:
>> >
>> >    "Value 1 (unknown) MUST be used if the type of battery
>> >    cannot be determined.
>> >
>> >    Value 2 (other) can be used if the battery type is known
>> >    but not one of the types already registered at IANA."
>> >
>> >
>> >
>> > Page 14, batteryMaxChargingCurrent (possible technical issue)
>> > -------------------------------------------------------------
>> >
>> > Between drafts -11 and -12, the battery capacity values were increased
>> > in size from an Unsigned32 to an Unsigned64TC to accomodate very high
>> > capacity batteries.
>> >
>> > For batteries with a capacity large enough to require an Unsigned64TC
>> > is it sufficient to have a  batteryMaxChargingCurrent  limited to an
>> > Unsigned32?
>> >
>> > For example, if a battery is ever built that has a capacity that must
>> > be reported with the maximum value of the Unsigned64TC
>> > batteryDesignCapacity, the maximum allowed charging current for that
>> > battery might be too large to report with the Unsigned32
>> > batteryMaxChargingCurrent.
>> >
>> >
>> > This same issue might apply to the  batteryTrickleChargingCurrent MIB
>> > object on Page 14, as well as the  batteryActualCurrent  MIB object on
>> > Page 19.
>> >
>> >
>> > Not sure what the best course of action is here.
>> 
>> We could do so, but then we have to change further objects related to
>>The
>> current including batteryActualCurrent which is a signed integer.
>> We do not yet have a TC for Integer64.
>> 
>> >
>> > Page 16, DESCRIPTION for batteryChargingCycleCount
>> > --------------------------------------------------
>> >
>> > The second paragraph of the DESCRIPTION for batteryChargingCycleCount
>> > reads:
>> >
>> >    "For batteries of type primary(1) the value of this object is
>> >    always 0."
>> >
>> > This enumeration name/number does not match the enumerated values
>> > listed for the  batteryType  MIB object on page 12/13:
>> >
>> >    batteryType OBJECT-TYPE
>> >        SYNTAX      INTEGER {
>> >                        unknown(1),
>> >                        other(2),
>> >                        primary(3),
>> >                        rechargeable(4),
>> >                        capacitor(5)
>> >                    }
>> >
>> > Also, I think the charging cycle count only applies to a  batteryType
>> > of rechargeable(4), so would rewording this second paragraph make
>> sense?
>> >
>> >    "For batteries of any type other than rechargeable(4), the value of
>> >     this object is always 0."
>> >
>> >
>> >
>> > Page 17, DESCRIPTION for batteryChargingAdminState (nit)
>> > --------------------------------------------------------
>> >
>> > The first sentence of the first paragraph of the DESCRIPTION for
>> > batteryChargingAdminState reads:
>> >
>> >    "The value of this object indicates the desired status of
>> >    the charging state of the battery.
>> >
>> > Perhaps the following text is a little more concise:
>> >
>> >    "The value of this object indicates the desired charging
>> >    state of the battery.
>> >
>> >
>> >
>> > Page 28, batteryTemperatureNotification (problem)
>> > -------------------------------------------------
>> >
>> >    OBJECT batteryTemperatureNotification
>> >    MIN-ACCESS  read-only
>> >    DESCRIPTION
>> >        "A compliant implementation is not required
>> >        to support set operations to this object."
>> >
>> > A MIB checker squawked about  batteryTemperatureNotification  is not
>> > defined as an OBJECT-TYPE.
>> >
>> >
>> > Should this be removed from the BATTERY-MIB?
>> 
>> Good catch: This should have been an object.
>> I will replace batteryTemperatureNotification with
>> batteryAlarmHighTemperature.
>> 
>> >
>> > _______________________________________________
>> > eman mailing list
>> > eman@ietf.org
>> > https://www.ietf.org/mailman/listinfo/eman
>> 
>> _______________________________________________
>> eman mailing list
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>
>_______________________________________________
>eman mailing list
>eman@ietf.org
>https://www.ietf.org/mailman/listinfo/eman