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

["John Parello (jparello)" <[e-mail]>]

+1 Sounds reasonable

Jp


On 11/5/14 2:18 AM, "Juergen Quittek" <[e-mail]> 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:[e-mail]] On Behalf Of Juergen Quittek
>> Sent: Dienstag, 9. September 2014 16:39
>> To: Alan Luchuk; [e-mail]
>> 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:[e-mail]] On Behalf Of Alan Luchuk
>> > Sent: Mittwoch, 12. März 2014 18:57
>> > To: [e-mail]
>> > 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/eman
>> 
>> _______________________________________________
>> eman mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/eman
>
>_______________________________________________
>eman mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/eman