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

[Alan Luchuk <[e-mail]>]

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.



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?