Subject: [eman] updated version of the battery MIB

From: Rolf Winter <[email-masked]>
Date: Thu, 7 Jul 2011 11:55:23 +0000

Hi,

we just posted a new version of the battery MIB. It contains the following changes:

- we added objects for the maximum charging current, the recommended current to be used for trickle charging and a notification for battery
- we adopted the cycle definition of the Smart Battery Data Specification
- the former takes care of two open issues, we removed the one on battery health as we e.g. have the cycle count as an approximate metric for this and some other information in the MIB
- We added a new open issue asking how close we should align in general to the Smart Battery Data Specification

These are the main changes in this version. I think we make very good progress on this document. Thanks a lot for all the input received so far. We would appreciate any further comments, so please keep them coming.

Best,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Thu, 14 Jul 2011 06:25:02 -0500

Hi,

I had a quick look at the new battery MIB module 
The first comment deals with the index and others are nits. 

1.     Firstly,  given that the battery  provides backup power for a
device and there should be a reference (index)  
       to the device  for which the battery is providing back-up power.
Otherwise, the MIB module seems as a standalone ? 

       There is a link of the batteryIndex to the entPhysicalIndex ;
Where do you assume that the entityMIB is implemented ?   
       What is the device ? How is that device identified ? What if
entityMIB is not implemented ? 

2.     is battery temperature - is this relevant for EMAN ?   +-- r-n
Integer32   batteryTemperature(14) 

3.     the name of the object can be renamed - batteryCurrentCurrent  ?

4.     the notion of batteryType - primary (not  being rechargeable) is
confusing - and the secondary Is  only rechargeable ?  

5.     The reference to be updated.   [I-D.ietf-eman-framework]
"Claise, B., Parello, J., and L. Silver, "Energy Management  Framework",
draft-ietf-eman-framework-01 (work in  progress), March 2011."

Thanks
Mouli

PS: I had posted a review of the MIB module long back and most of my
comments still apply. 

http://www.ietf.org/mail-archive/web/eman/current/msg00494.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rolf Winter
Sent: Thursday, July 07, 2011 5:25 PM
To: [email-masked]
Subject: [eman] updated version of the battery MIB

Hi,

we just posted a new version of the battery MIB. It contains the
following changes:

- we added objects for the maximum charging current, the recommended
current to be used for trickle charging and a notification for battery
- we adopted the cycle definition of the Smart Battery Data
Specification
- the former takes care of two open issues, we removed the one on
battery health as we e.g. have the cycle count as an approximate metric
for this and some other information in the MIB
- We added a new open issue asking how close we should align in general
to the Smart Battery Data Specification

These are the main changes in this version. I think we make very good
progress on this document. Thanks a lot for all the input received so
far. We would appreciate any further comments, so please keep them
coming.

Best,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
London W3 6BL | Registered in England 2832014 

_______________________________________________
eman mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/eman

---

From: Rolf Winter <[email-masked]>
Date: Thu, 14 Jul 2011 11:52:25 +0000

Hi Mouli, 

thanks for your feedback. I was under the impression that many of the issues that you raised were commented on and solved. See some comments inline. I'll dig through the other ones later.

> Integer32   batteryTemperature(14)

We think yes. The battery temperature is also part of UPS MIB e.g. Even on Android devices you can extract the battery temperature via Python e.g. So it seems implemented and relevant. Bill mentioned some time ago that he thinks it is important for safety and battery lifetime. If you disagree please justify.

> 3.     the name of the object can be renamed - batteryCurrentCurrent  ?

What do you have in mind?

> confusing - and the secondary Is  only rechargeable ?

Wikipedia: " There are two types of batteries: primary batteries (disposable batteries), which are designed to be used once and discarded, and secondary batteries (rechargeable batteries),". Could you please be more concrete about what causes the confusion. Is it the terms? Our text? 

> draft-ietf-eman-framework-01 (work in  progress), March 2011."

Easy one.

> <http://www.ietf.org/mail-archive/web/eman/current/msg00494.html>
>

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 14 Jul 2011 17:41:33 +0200

Hi Mouli,

Thank you for your comments.

Am 14.07.2011 um 13:25 schrieb Mouli Chandramouli (moulchan):
> 1.     Firstly,  given that the battery  provides backup power for a device and there should be a reference (index) 
> 
>        to the device  for which the battery is providing back-up power. Otherwise, the MIB module seems as a standalone ?
> 
>        There is a link of the batteryIndex to the entPhysicalIndex ; Where do you assume that the entityMIB is implemented ?  
> 
>        What is the device ? How is that device identified ? What if entityMIB is not implemented ?
> 
I think the most common case is that the battery is contained in a device and the device reports about its battery.

You can see the battery as a component of a device such as a CPU or a line card.  If you write a MIB module for the line card or for the CPU, you woudn't have a pointer in your MIB module pointing to the device that the line card or CPU is contained in, would you? That is because the device hosting the line card or CPU is the same device hosing the implementation of the MIB module. I don't see a problem here. But maybe you envision other scenarios where this is a problem?

If the device hosting the battery implements the Entity MIB and has the battery listed as an entity, then of course can we support it.
> 2.     is battery temperature – is this relevant for EMAN ?   +-- r-n Integer32   batteryTemperature(14)
> 
It is not necessary for energy management. But it is important for battery management.
> 3.     the name of the object can be renamed - batteryCurrentCurrent  ? 
You talk about renaming the name? This sounds almost like current current :-)
But seriously, what would be your proposal?
> 4.     the notion of batteryType – primary (not  being rechargeable) is confusing – and the secondary Is  only rechargeable ? 
> 
Well, if you are dealing with batteries, the technically correct terms for the two basic kinds are 'primary battery' and 'secondary battery'.
Secondary batteries are rechargeable, primary batteries are not. 
> 5.     The reference to be updated.   [I-D.ietf-eman-framework]   “Claise, B., Parello, J., and L. Silver, "Energy Management  Framework", draft-ietf-eman-framework-01 (work in  progress), March 2011.”
> 
> 
Yes. That's really strange. In the XML we reference the draft correctly. There must be a wrong entry in the database we use for generating the references. We'll check for the next version.
> Thanks
> 
> Mouli
> 
> PS: I had posted a review of the MIB module long back and most of my comments still apply.
> 
Yes, right. But all of them seem to be answered with what I wrote in the replies above.

Thanks,

    Juergen

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Fri, 15 Jul 2011 06:09:38 -0500

Hi Juergen,

Replies inline. 

Thanks

Mouli

From: Juergen Quittek [mailto:[email-masked]] 
Sent: Thursday, July 14, 2011 9:12 PM
To: Mouli Chandramouli (moulchan)
Cc: Rolf Winter; [email-masked]
Subject: Re: [eman] updated version of the battery MIB

Hi Mouli,

	Hi,

	1.     Firstly,  given that the battery  provides backup power
for a device and there should be a reference (index)  

	       to the device  for which the battery is providing back-up
power. Otherwise, the MIB module seems as a standalone ? 

	       There is a link of the batteryIndex to the
entPhysicalIndex ; Where do you assume that the entityMIB is implemented
?   

	       What is the device ? How is that device identified ? What
if entityMIB is not implemented ? 

I think the most common case is that the battery is contained in a
device and the device reports about its battery.

You can see the battery as a component of a device such as a CPU or a
line card.  If you write a MIB module for the line card or for the CPU,
you woudn't have a pointer in your MIB module pointing to the device
that the line card or CPU is contained in, would you? That is because
the device hosting the line card or CPU is the same device hosing the
implementation of the MIB module. I don't see a problem here. But maybe
you envision other scenarios where this is a problem?

If the device hosting the battery implements the Entity MIB and has the
battery listed as an entity, then of course can we support it.

Mouli>>  Thanks for an excellent description.  

Mouli>> My point is - wouldn't you want to refer to the device that
contains the battery and such a linkage (association) would provide a
context for the battery ? - the battery is for this  device. 

	2.     is battery temperature - is this relevant for EMAN ?
+-- r-n Integer32   batteryTemperature(14) 

It is not necessary for energy management. But it is important for
battery management.

	3.     the name of the object can be renamed -
batteryCurrentCurrent  ?  

You talk about renaming the name? This sounds almost like current
current :-)

Mouli>  how about batteryPresentCharge

Well, if you are dealing with batteries, the technically correct terms
for the two basic kinds are 'primary battery' and 'secondary battery'.

Yes. That's really strange. In the XML we reference the draft correctly.
There must be a wrong entry in the database we use for generating the
references. We'll check for the next version.

	Thanks

	Mouli

	PS: I had posted a review of the MIB module long back and most
of my comments still apply. 

Yes, right. But all of them seem to be answered with what I wrote in the
replies above.

Thanks,

    Juergen

---

From: Steven Chew <[email-masked]>
Date: Fri, 15 Jul 2011 04:46:33 -0700

1) The use of the word "current" is double loaded (e.g. batteryCurrentCurrent). I suggest use "current" for electrical current and use "present" to mean instantaneous.

2) It seems more natural to give batteryTechnology(5) a SYNTAX of Integer or Enumeration. Am I right that Unsigned32 is normally given to quantitative values?

3) I only know of the standards from sbs-forum.org that come close to the battery MIB specification. I made an attempt to match the objects from the Smart Battery Data Specification v1.10 (SBD) and those in this MIB. Please see attachment. Some of the SBD objects are only suitable as data exchanges between the battery and the battery charger (e.g. a laptop, or standalone charger). I think those are inappropriate for this MIB. For this reason, I do not think there should be a complete alignment between the two specs.

I think the current model is implementing the MIB support in a UPS, in which the battery is part of the "fixed" power source. However, I am hoping to exert sufficient influence in the MIB definition, such that we will find it useful to implement the MIB support in networked standalone battery chargers that will see different batteries from one use to another. The application I am envisioning is an asset management system that will track the usages of a pool of rechargeable batteries, and those batteries are for mobile appliances. This may not have been inside the scope originally.

Below are my thoughts and are, of course, subjective:

3.1) Objects in MIB, but not in SBD Spec:

3.1.1) batteryFirmwareVersion(3) - OK to keep in MIB, but there is no standard way to convey this from battery manufacturers
3.1.2) batteryType(7) - OK to keep in MIB
3.1.3) batteryNumberOfCells(7) - not sure of the usefulness, and not should how to get this information from a charger in general
3.1.4) batteryLastChargingCycleTime(13) - good to have in MIB
3.1.5) batteryLowAlarmVoltage(20) - OK to have, not really applicable to the charger scenario
3.1.6) batteryReplacementAlarmCapacity(21) - good to have in MIB
3.1.7) batteryReplacementAlarmCycles(22) - good to have in MIB
3.1.8) batteryHighAlarmTemperature (23) - good to have in MIB

3.2) Objects in not MIB, but in SBD Spec:
3.2.1) ManufacturerAccess() (0x00) - not applicable in MIB
3.2.2) RemainingTimeAlarm() (0x02) - important to have in MIB, seems fundamental
3.2.3) BatteryMode() (0x03) - not applicable in MIB
3.2.4) AtRate() (0x04) - this "AtRate..." group of objects is interesting - allows querying a battery performance at a projected current level
3.2.5) AtRateTimeToFull() (0x05) - see above
3.2.6) AtRateTimeToEmpty() (0x06) - see above
3.2.7) AtRateOK() (0x07) - see above
3.2.8) AverageCurrent() (0x0b) - important to have in MIB; potentially more meaningful than batteryCurrentCurrent(17), as current tend to vary greatly instantaneously
3.2.9) MaxError() (0x0c) - not important to have in MIB
3.2.10) RunTimeToEmpty() (0x11) - important to have in MIB, seems fundamental
3.2.11) AverageTimeToEmpty() (0x12) - important to have in MIB, seems fundamental
3.2.12) AverageTimeToFull() (0x13) - important to have in MIB, seems fundamental
3.2.13) SpecificationInfo() (0x1a) - not important to have in MIB
3.2.14) ManufacturerData() (0x23) - not important to have in MIB

Someone else please check me. My hats off to the authors of the Battery MIB. There are lots of details...

Regards
Steven Chew.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf Winter
Sent: Thursday, July 07, 2011 7:55 AM
To: [email-masked]
Subject: [eman] updated version of the battery MIB

Hi,

Best,

Rolf

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 15 Jul 2011 15:08:33 +0200

Hi Mouli,

Am 15.07.2011 um 13:09 schrieb Mouli Chandramouli (moulchan):

> Mouli>> My point is – wouldn’t you want to refer to the device that contains the battery and such a linkage (association) would provide a context for the battery ? – the battery is for this  device.

Yes, I got your point. But in almost all cases, the device hosting the MIB module and answering on SNMP requests IS the device that contains the battery. 
Why would it need to point to itself?
 
> Mouli>  how about batteryPresentCharge

I assume you are aware of the difference between charge and current.
Currently, we have
          batteryCurrentCharge
          batteryCurrentVoltage
          batteryCurrentCurrent
and you propose to change ist to
          batteryCurrentCharge
          batteryCurrentVoltage
          batteryCurrentCurrent
Is this a correct understanding?

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 15 Jul 2011 16:05:13 +0200

Hi Steven,

thanks for sending your very helpful comments.

> 1) The use of the word "current" is double loaded (e.g. batteryCurrentCurrent). I suggest use "current" for electrical current and use "present" to mean instantaneous.

Yes. This is what also Mouli proposed. We will find something that circumvents current current.
What about "actual" instead of "present"?

> 2) It seems more natural to give batteryTechnology(5) a SYNTAX of Integer or Enumeration. Am I right that Unsigned32 is normally given to quantitative values?

Agreed. A type of Integer32 (1 .. 2147483647) may be the better choice. 
In the end I would leave this to the MIB doctor to decide. 

> 3) I only know of the standards from sbs-forum.org that come close to the battery MIB specification. I made an attempt to match the objects from the Smart Battery Data Specification v1.10 (SBD) and…

Thanks for the table.

We (the authors) also made this comparison.
We are tending towards aligning names better in the next version, such as replacing "NominalVoltage" with "DesignVoltage" or "ActualCapacity" with "RemainingCapacity".
But actually we started with "RemainingCapacity" and decided to change to "actualCapacity" in an earlier version. Nothing decided yet.

> I think the current model is implementing the MIB support in a UPS, in which the battery is part of the "fixed" power source. However, I am hoping to exert sufficient influence in the MIB definitio…

Indeed it has not. But please tell us what you are missing for this application.
Particularly, what would you need as identifier?
As you know, SBD has ManufacturerName() (0x20), DeviceName() (0x21), ManufactureDate() (0x1b), SerialNumber() (0x1c).
the Battery MIB just has the batteryIdentifier. What would you need? 

> 3.1.3) batteryNumberOfCells(7) - not sure of the usefulness, and not should how to get this information from a charger in general

Right, the same holds for the firmware version. However, many notebook PCs provide this information for their batteries. Then they can also make this info visible in a MIB module.

> 3.2.2) RemainingTimeAlarm() (0x02) - important to have in MIB, seems fundamental

We had many discussions about this and decided not to include it. Maybe we are too much used to get reliable numbers.
As far as I understand it, this number is a rough prediction and may be completely wrong. But maybe even such a heuristic is worth being supported in the MIB?

> 3.2.7) AtRateOK() (0x07) - see above

Seems to be complex to implement. 
Would require setting a rate.

> 3.2.8) AverageCurrent() (0x0b) - important to have in MIB; potentially more meaningful than batteryCurrentCurrent(17), as current tend to vary greatly instantaneously

What would be the interval for computing the average value?

> 3.2.10) RunTimeToEmpty() (0x11) - important to have in MIB, seems fundamental

See above. This is a rough estimate. Why not reading current and charge from the MIB and do the estimation in the management system is needed?
But I fully agree that in many cases this is exactly what a management system would like to know.
 
> 3.2.14) ManufacturerData() (0x23) - not important to have in MIB

Looks like we can easily agree. The only issue to be discussed is the support for timeToEmpty/timeToFull for the MIB module.
Let's add this to the list of open issues and discuss it further on this list and at the session in Quebec.

Thanks,

    Juergen

> <MIB-SBD Compare 02.xls>_______________________________________________
> eman mailing list
> [email-masked]

---

From: Steven Chew <[email-masked]>
Date: Fri, 15 Jul 2011 12:41:35 -0700

Hi Juergen,

Please see my comments inline below in red. Thanks for your attention.

Regards,
Steven.

From: Juergen Quittek [mailto:[email-masked]]
Sent: Friday, July 15, 2011 10:05 AM
To: Steven Chew
Cc: Rolf Winter; [email-masked]
Subject: Re: [eman] updated version of the battery MIB

Hi Steven,

Steven> I think "actual" is fine.

3) I only know of the standards from sbs-forum.org<http://sbs-forum.org> that come close to the battery MIB specification. I made an attempt to match the objects from the Smart Battery Data Specification v1.10 (SBD) and those in this MIB. Please see attachment. Some of the SBD objects are only suitable as data exchanges between the battery and the battery charger (e.g. a laptop, or standalone charger). I think those are inappropriate for this MIB. For this reason, I do not think there should be a complete alignment between the two specs.

Thanks for the table.

Steven> Yes, aligning names would be a great thing.

Steven> I think batteryIdentifier is fine. I was planning to aggregate the SBD objects you mention above to build the a unique value for batteryIdentifier for each battery.

Steven> Sure. We can keep it.

Steven> I think it's worth being supported. They are constantly improving on the battery gas gauging techniques.

Steven> I agree.

Steven> SBD specifies the interval as 1 minute.

Steven> I agree that RunTimeToEmpty() (0x11)  seems to be derivable from other values. However, the battery can estimate it better. The time is not exactly linear in relation to charge and current. For example, the battery's algorithm is highly dependent on the cell chemistry. I would vote to keep this in the MIB.

Thanks,

    Juergen

Regards
Steven Chew.

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Rolf Winter
Sent: Thursday, July 07, 2011 7:55 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [eman] updated version of the battery MIB

Hi,

Best,

Rolf

_______________________________________________
eman mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eman
<MIB-SBD Compare 02.xls>_______________________________________________
eman mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eman