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

[Juergen Quittek <[e-mail]>]

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