Subject: [eman] Comments on draft-ietf-eman-battery-mib-02

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Thu, 28 Jul 2011 11:45:16 -0500

Provided below.  I will forward a copy of my annotated PDF file to the authors.  The PDF version also includes some minor corrections/suggestions which are not reproduced below.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: [email-masked]
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

----------------------------------------------------------------
Comments on draft-ietf-eman-battery-mib-02
----------------------------------------------------------------

General Comments:

1. I believe that the definitions for the following terms should be adjusted to clarify their intent.  I was confused after reading the current definitions in the document but after some thought I believe that the intended use of these is as follows:

batteryNominalCapacity:

This represents the manufacturer's static design capacity for the battery.  It is the rated or nameplate value advertised by the manufacturer.  It is a static number.

batteryActualCapacity:

This represents the same value as batteryNominalCapacity only it has been adjusted to account for the age and historical usage of the battery both of which degrade its capacity below its nominal rating.  It is a dynamic estimate.

batteryCurrentCharge:

This represents the amount of energy which is estimated to be remaining in the battery at any given point in time.  It is a dynamic estimate.

Are these the correct interpretations?

2. In general I think that this is in pretty good shape.

Deatiled Comments:

> The Battery MIB module serves for monitoring the battery status. It
> does not implement a Power Monitor as defined in the framework for
> energy management [I-D.ietf-eman-framework]. (Page 3)

Adjust to match the replacement terminology for "Power Monitor".

> batteryTemperature OBJECT-TYPE
> SYNTAX Integer32
> UNITS "degrees Celsius" (Page 16)

I don't know the level of precision required here, but I suspect some level of fractional degrees would be appropriate.  Should we consider deci-degrees, centi-degrees, or even milli-degrees?  I would expect deci- or centi- would be appropriate but I have no expertise to back that up.  I will inquire about this with our SMEs and get back to you.

> batteryReplacementAlarmCycles OBJECT-TYPE
> SYNTAX Unsigned32
> UNITS "milliampere hours" (Page 18)

This is simply a count, no?  So no units at all.  :)

> batteryHighAlarmTemperature OBJECT-TYPE
> SYNTAX Integer32
> UNITS "degrees Celsius" (Page 18)

Same comment as above regarding the precision.

> 8.1. Writable Notification thresholds (Page 23)

I favor allowing the thresholds to be settable by the EnMS.

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Thu, 28 Jul 2011 12:26:46 -0500

Based on the feedback I have received it seems that setting the level of precision for temperature measurements at deci-degrees would be appropriate based on experience with existing systems.

William F. Mielke
Alcatel-Lucent

    - Albert Einstein

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mielke, William F (Bill)
> Sent: Thursday, July 28, 2011 12:45 PM
> To: eman mailing list
> Subject: [eman] Comments on draft-ietf-eman-battery-mib-02
> 
> Provided below.  I will forward a copy of my annotated PDF 
> file to the authors.  The PDF version also includes some 
> minor corrections/suggestions which are not reproduced below.
> 
> William F. Mielke
> Alcatel-Lucent
> 1. I believe that the definitions for the following terms 
> should be adjusted to clarify their intent.  I was confused 
> after reading the current definitions in the document but 
> after some thought I believe that the intended use of these 
> is as follows:
> 
> batteryNominalCapacity:
> 
> This represents the manufacturer's static design capacity for 
> the battery.  It is the rated or nameplate value advertised 
> by the manufacturer.  It is a static number.
> 
> batteryActualCapacity:
> 
> This represents the same value as batteryNominalCapacity only 
> it has been adjusted to account for the age and historical 
> usage of the battery both of which degrade its capacity below 
> its nominal rating.  It is a dynamic estimate.
> 
> batteryCurrentCharge:
> 
> This represents the amount of energy which is estimated to be 
> remaining in the battery at any given point in time.  It is a 
> dynamic estimate.
> 
> I don't know the level of precision required here, but I 
> suspect some level of fractional degrees would be 
> appropriate.  Should we consider deci-degrees, centi-degrees, 
> or even milli-degrees?  I would expect deci- or centi- would 
> be appropriate but I have no expertise to back that up.  I 
> will inquire about this with our SMEs and get back to you.
> 
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman
>

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 28 Jul 2011 18:24:30 -0400

Hi Bill,

Thank you very much for this review.
Please find replies inline.

> Learn like you're going to live forever."

Yes, these are all correct.
Proposals for improved naming and explanations are very welcome.
We received proposals to rename batteryActualCapacity to batteryRemainingCapacity
BTW. This remaining capacity is often measured by the device.

> Adjust to match the replacement terminology for "Power Monitor".

Yes. We have to as soon as we have agreed on terms.

> I don't know the level of precision required here, but I suspect some level of fractional degrees would be appropriate.  Should we consider deci-degrees, centi-degrees, or even milli-degrees?  I wo…

We are about to send the draft to external reviewers for review.
We will asked them for input on this issue.

> This is simply a count, no?  So no units at all.  :)

Yes. Good catch. Thanks for pointing this out.

> Same comment as above regarding the precision.

Yes.

> I favor allowing the thresholds to be settable by the EnMS.

Thanks,

    Juergen