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

[Juergen Quittek <[e-mail]>]

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