Subject: [eman] Review of draft-quittek-eman-battery-mib-00.txt

From: Benoit Claise <[email-masked]>
Date: Sat, 26 Mar 2011 15:36:40 +0100

Dear authors,

Here is my review of the draft-quittek-eman-battery-mib-00.txt draft.
This draft is good start. However, I have some feedback:

1. I believe that the connection with the Energy Management Framework 
draft-ietf-eman-framework-0 should be clarified, as it's not even mentioned.

2. What is the link with the "Energy-aware Networks and Devices MIB" 
draft-ietf-eman-energy-aware-mib-01

3.  I have a concern with this index.

    batteryIndex OBJECT-TYPE
        SYNTAX      Unsigned32
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
            "This object identifies a battery for which status is
            reported. Index values MUST be locally unique.

            If there is an instance of the entPhysicalTable (defined in
            the ENTITY-MIB module, see RFC 4133) with individual entries
            for each battery, then it is RECOMMENDED that values of
            batteryIndex match the corresponding values of
            entPhysicalIndex for the batteries. Otherwise, index values
            may be chosen arbitrarily."
        ::= { batteryEntry 1 }

In draft-claise-energy-monitoring-mib-07, you asked to change the index, 
because we can't impose that the "Energy-aware Networks and Devices MIB" 
is present. Fine. I believe that those indexes should be inline. One 
side, there is a RECOMMENDED, on the other side a MUST

        pmPowerIndex OBJECT-TYPE
             SYNTAX          Integer32 (0..2147483647)
             MAX-ACCESS      not-accessible
             STATUS          current
             DESCRIPTION

               "A unique value, for each Power Monitor.
               If an implementation of the ENERGY AWARE MIB module is
               available in the local SNMP context, then the same index
               as the one in the ENERGY AWARE MIB MUST be assigned for
               the identical Power Monitor. In this case, entities
               without an assigned value for pmIndex cannot be indexed
               by the pmPowerStateTable.

               If there is no implementation of the ENERGY AWARE MIB
               module but one of the ENTITY MIB module is available in
               the local SNMP context, then the same index of an entity
               MUST be chosen as assigned to the entity by object
               entPhysicalIndex in the ENTITY MIB module. In this case,
               entities without an assigned value for entPhysicalIndex
               cannot be indexed by the pmPowerStateTable.

               If neither the ENERGY AWARE MIB module nor of the ENTITY
               MIB module are available in the local SNMP context, then
               this MIB module may choose identity values from a further
               MIB module providing entity identities. In this case the
               value for each pmPowerIndex must remain constant at least
               from one re-initialization of the entity's network
               management system to the next re-initialization.

               In case that no other MIB modules have been chosen for
               providing entity identities, Power States can be reported
               exclusively for the local device on which this table is
               instantiated.  Then this table will have a single entry
               only and an index value of 0 MUST be used."

             ::= { pmPowerEntry 1 }

4.  The previous points 1, 2, and 3, come from the fact that the 
requirements draft is not too clear about batteries. What about 
batteries in a PC? How should we monitor it/them? Independently of the 
PC? From the requirements and the framework, we will then know if those 
batteries are Power Monitor Children or not? Final question: what if 
there is a battery in a Power Monitor Child?

5. I'm not too sure regarding the connection with the UPS-MIB. I see the 
following paragraph:

    A traditional type of managed device containing batteries is an
    uninterruptible power supply (UPS) system; these supply other devices
    with electrical energy when the main power supply fails.  There is
    already a MIB module for managing UPS systems defined in RFC 1628
    [RFC1628].  This module includes managed objects for monitoring the
    batteries contained in an UPS system.  However, the information
    provided by these objects is limited and tailored the particular
    needs of UPS systems.

Do you mean that UPS will _only _implement the UPS MIB, and the 
batteries will _only_ implement draft-quittek-eman-battery-mib-00.txt? 
So basically, there is no connection?

6.

    batteryType OBJECT-TYPE
        SYNTAX      INTEGER {
                        primary(1),
                        rechargeable(2),
                        capacitor(3),
                        other(4),
                        unknown(5)
                    }
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "This object indicates the type of battery.  It distinguishes
            between one-way primary batteries, rechargeable secondary
            batteries and capacitors which are not really batteries but
            often used in the same way as a battery.

            The value other(4) can be used if the battery type is known
            but none of the ones above.  Value unknown(5) is to be used
            if the type of battery cannot be determined."
        ::= { batteryEntry 2 }

You might want to expand on primary/secondary. A sentence such as " 
primary batteries (disposable batteries), which are designed to be used 
once and discarded, and secondary batteries (rechargeable batteries)" 
would help already.
I'm not an expert in batteries, but are we covering all types? In other 
words, do we need an IANA registry?
Same question regarding the batteryTechnology.
I googled battery type and found 
http://en.wikipedia.org/wiki/List_of_battery_types, way more than the 17 
defined.
Is there such a registry somewhere in the industry?

- 7 rechargeable battery

    batteryTechnology OBJECT-TYPE
        SYNTAX      INTEGER {
			...
                    }
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "This object indicates the technology used by the battery.
            Values 1-8 are primary battery technologies, values 10-16
            are rechargeable battery technologies and value alkaline(9)
            is used for primary batteries as well as for rechargeable
            batteries.

            The value other(18) can be used if the battery type is known
            but none of the ones above.  Value unknown(19) is to be used
            if the type of battery cannot be determined."
        ::= { batteryEntry 3 }

We have to deduce if a battery is rechargeable from the value range of 
batteryTechnology. I believe that an boolean object would be more 
interesting, specifically if this registry grows.

- 8

  batteryState OBJECT-TYPE
        SYNTAX      INTEGER {
                        full(1),
                        partiallyCharged(2),
                        empty(3),
                        charging(4),
                        discharging(5),
                        unknown(6)
                    }
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "This object indicates the current state of the battery.
            Value full(1) indicates a full battery with a capacity
            given by onject batteryRemainingCapacity.

So batteryRemainingCapacity is not relevant for 2, 4, 5, 6?

- 9.  Can you elaborate on the relationship between 
batteryRemainingCapacity and batteryCurrentCharge

- 10. Why are batteryLowAlarmPercentage and batteryLowAlarmVoltage 
read-only?
Same question for batteryReplacementAlarmCapacity and 
batteryReplacementAlarmCycles: do you expect those to be hardcoded by 
the vendor?

- 11. How do we re-arm the batteryLowNotification? Only when a full 
charge happen?

- 12.

   batteryCompliance MODULE-COMPLIANCE
        STATUS      current
        DESCRIPTION
            "The compliance statement for implementations of the
            POWER-STATE-MIB module.

            A compliant implementation MUST implement the objects
            defined in the mandatory group psmRequiredGroup."
        MODULE  -- this module
        MANDATORY-GROUPS {
            batteryDescriptionGroup,
            batteryStatusGroup,
            batteryAlarmThresholdsGroup
        }
        GROUP   batteryNotificationsGroup
        DESCRIPTION
           "A compliant implementation does not have to implement
            the psmNotificationsGroup."

psmNotificationsGroup doesn't exist

Regards, Benoit (as a contributor)

---

From: Bruce Nordman <[email-masked]>
Date: Sat, 26 Mar 2011 22:36:10 +0100

(Benoit's comments excerpted below).

> This draft is good start. However, I have some feedback:
I agree.  Much appreciated since I don't think anyone else wanted to take
this on.

> draft-ietf-eman-framework-0 should be clarified, as it's not even mentioned.
Yes.  In particular, I think a key feature of this draft is that the MIB
content
does not overlap with the information that could be reported by the rest of
the EMAN MIBs if the battery was reported on as a separate component.
That is, figures such as power in or total energy consumed are not included
here.
This fact should be mentioned.

Add a note that very small batteries in systems (e.g. to enable reliable
time-keeping)
are not in scope.

Say something about readily removable batteries, e.g. as in notebooks, that
can
easily be replaced.  I realize this is a huge can of worms, and am not
suggesting
adding content to the document.  Safest would be to say that the effect of
battery
replacement on the values reported is not defined.

Worth noting that only the alarm levels are writeable (actually, they now
say read-only
but I think should be changed).

For number of charging cycles, I am not sure that "age" is the right term,
since
someone later might actually want to report age.  Activity?

For the UPS reference, clarify if a UPS should use the battery MIB also, or
only
the UPS MIB.

> draft-ietf-eman-energy-aware-mib-01
I assume no link, which is fine.  A device can implement one MIB, the other,
or both.
Worth stating this.

> requirements draft is not too clear about batteries. What about batteries in
> a PC? How should we monitor it/them? Independently of the PC? From the
> requirements and the framework, we will then know if those batteries are
> Power Monitor Children or not? Final question: what if there is a battery in
> a Power Monitor Child?
>
This MIB is about battery status, not energy management of batteries.
A device could report on the power level and energy consumption of an
integral battery,
or only do so for the entire device.  Whether the battery MIB is implemented
is independent
of this.  This point should be made in the requirements - that there is no
linkage.
I think this deals with these questions.  Primary energy reporting for ANY
device is the mains
power consumption - the effect of any internal batteries is invisible to
this reporting.
This does raise the point that if components of a device are reported on,
then a battery
may have negative power consumption.

> Do you mean that UPS will *only *implement the UPS MIB, and the batteries
> will *only* implement draft-quittek-eman-battery-mib-00.txt? So basically,
> there is no connection?
>
I think the answer is the same as the above.  A device that is a UPS can
report the
UPS MIB (or not).  It also can report only its total energy/power input (and
not battery details),
or can report on individual components, including the battery in the UPS.

> interesting, specifically if this registry grows.
The type tells us if rechargeable or not.

> batteryRemainingCapacity and batteryCurrentCharge
I would replace "Remaining" with "Actual" since I first interpreted
"Remaining" as
being the Current Charge (and I think Benoit may have as well).

In all places where "needs to be measured" appears I would delete the
phrase.

> batteryReplacementAlarmCycles: do you expect those to be hardcoded by the
> vendor?
>
I had the same question.  Also, there seem to be four thresholds where
something bad
could happen but only two notifications.  Shouldn't there be four
notifications?
Also, I am not knowledgeable about batteries, but I would think there are
other
errors, e.g. not taking a charge (my power drill charger tells me that
sometimes)
and an overcharged condition.  We definitely need outside help here.

For Voltage, does this change when charging or discharging?  I thought that
there
was a higher voltage applied to charge a battery.  Perhaps we need to be
more
specific than 'the voltage'?

For Replacement, units should be "Cycles".

For the questions, I would say that percentage should always be for actual
and
not nominal.  Also, I would punt and say that definitions of "full" and
"empty" are
up to the implementor.

Since the % remaining charge can be computed from the other variables, is it
necessary to report it?  Is the fact that a threshold is dependent on this
mean
that it should definitely be reported?

For very low power devices with no mains power - only battery - is this an
appropriate mechanism to signal a low battery condition?  I don't know the
answer, but whatever it is should probably be mentioned.

--Bruce (as a contributor)

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

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
[email-masked]
510-486-7089
m: 510-501-7943

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 28 Mar 2011 15:40:57 +0200

Hi Benoit,

Thank you for the review.
Please find comment inline,

    Juergen

Am 26.03.2011 um 15:36 schrieb Benoit Claise:

> 1. I believe that the connection with the Energy Management Framework draft-ietf-eman-framework-0 should be clarified, as it's not even mentioned.

'We will do so in the next update.
However, the main message will be that it is not connected.

> 2. What is the link with the "Energy-aware Networks and Devices MIB" draft-ietf-eman-energy-aware-mib-01

We need to find out if we need one.

> In draft-claise-energy-monitoring-mib-07, you asked to change the index, because we can't impose that the "Energy-aware Networks and Devices MIB" is present. Fine. I believe that those indexes should be inline. One side, there is a RECOMMENDED, on the other side a MUST

This is an open issue. Let's wait for the outcome of the Entity MIb discussion.
For the Power monitoring MIB I think it should be a MUST to use the POWER-AWARE or ENTITY MIB indexing when available.
For the BATTERY MIB the story is a bit different. But I will have no problem with changing RECOMMENDED to MUST, if the WG has consensus on this. 
> 4.  The previous points 1, 2, and 3, come from the fact that the requirements draft is not too clear about batteries. What about batteries in a PC? How should we monitor it/them? Independently of the PC? From the requirements and the framework, we will then know if those batteries are Power Monitor Children or not? Final question: what if there is a battery in a Power Monitor Child?

The battery MIB is not a power consumption monitor or a power state monitor. It is just a MIB module reporting states of batteries in a device. I don't see this much different to reporting on the processor status (load) in a PC. And I would like to not treat it much differently. A MIB module on processor load would also not relate to the energy management framework or discuss parent child relationships.

However, if we model a battery as a component of a PC which we see as separate entity on which we report power independently, then we can do so with the power MIB and with the power state MIB. I volunteer to write a section on dealing with batteries for the framework document.

> 5. I'm not too sure regarding the connection with the UPS-MIB. I see the following paragraph:
> 
> Do you mean that UPS will only implement the UPS MIB, and the batteries will only implement draft-quittek-eman-battery-mib-00.txt? So basically, there is no connection?

There is a limited overlap between the two.
The UPS MIB just deals with the UPS functionality.
I could imagine an UPS implementing the UPS MIB for this purpose 
and in addition reporting on battery status (e.g. age of the battery) 
with the Battery MIB. But this story is subject to further discussion.

> You might want to expand on primary/secondary. A sentence such as " primary batteries (disposable batteries), which are designed to be used once and discarded, and secondary batteries (rechargeable batteries)" would help already.

Right. Will do.

> I'm not an expert in batteries, but are we covering all types? In other words, do we need an IANA registry? 

> Same question regarding the batteryTechnology.

Good questions. I do not have an answer at this point in time.
I don't think we need it for the types. But probably for the technologies.

> 
>      I googled battery type and found http://en.wikipedia.org/wiki/List_of_battery_types, way more than the 17 defined.

It's not what we here call type, but it's technologies. 
Yes, I have seen a similar list when writing the draft.
There is a plenty of battery types, But most of them are of academic nature. iYou can build them, but there are economic or practical reasons why you would not commercially use them. I removed all baterries from the long list for which I could find that they are not in commercial use.

> Is there such a registry somewhere in the industry?

I have not seen anything like this.
Does anyone else know?

> We have to deduce if a battery is rechargeable from the value range of batteryTechnology. I believe that an boolean object would be more interesting, specifically if this registry grows.

This was just for explanation. Shall I remove the text on which technologies belong to which type.
Maybe I should just add a sentence as you say: "Whether it is rechargeable can be retrieved from object batteryType".

> So batteryRemainingCapacity is not relevant for 2, 4, 5, 6?

It is valid in all states. I just wanted to clearly define what "full" means.
"Ful" may mean: 100% original capacity or 100% remaining capacity.
I am still not sure which alternative is the best one.

> - 9.  Can you elaborate on the relationship between batteryRemainingCapacity and batteryCurrentCharge

While in use, the capacity of a battery (the maximum energy that you can store in it) decreases.
An old battery typically has a lower capacity than a new one. 
The current charge relates to the energy currently stored in the battery.
The currentCharge is always less than or equal to the currentCapacity.

> - 10. Why are batteryLowAlarmPercentage and batteryLowAlarmVoltage read-only?
> Same question for batteryReplacementAlarmCapacity and batteryReplacementAlarmCycles: do you expect those to be hardcoded by the vendor?

Good point.
I expect that manufacturers will install a reasonable default value for these objects 
and that they will allow you to change them via CLI or a GUI,
So far, it is a read-only MIb module for monitoring. 
If we want to open it for configuration, we can discuss doing so.

> - 11. How do we re-arm the batteryLowNotification? Only when a full charge happen?

Good question, I have no good answer to this right now. But we need to give one in the draft.

> psmNotificationsGroup doesn't exist

Thanks for catching this.
It's a copy/paste mistake. 
Will fix it in the next revision.

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 28 Mar 2011 16:02:04 +0200

Hi Bruce,

Thanks for the second review on this draft.
Now we have a lot of input for the next revision 
and for starting discussions.

    Juergen

Am 26.03.2011 um 22:36 schrieb Bruce Nordman:

> Yes.  In particular, I think a key feature of this draft is that the MIB content
> That is, figures such as power in or total energy consumed are not included here.
> Add a note that very small batteries in systems (e.g. to enable reliable time-keeping)
> are not in scope.

Yes. I thought often about it but did not write anything.
Will add a clarification in the next revision.

> Say something about readily removable batteries, e.g. as in notebooks, that can
> easily be replaced.  I realize this is a huge can of worms, and am not suggesting
> adding content to the document.  Safest would be to say that the effect of battery

OK. I will try to carefully phrase some text.
I would not like to add an object indicating the "replaceability".

> Worth noting that only the alarm levels are writeable (actually, they now say read-only

Looks like we are getting closer to consensus on this :-)

> For number of charging cycles, I am not sure that "age" is the right term, since

Then rather boringly: numberOfChargingCycles.

> For the UPS reference, clarify if a UPS should use the battery MIB also, or only
> the UPS MIB.

Will do so, But it will rather be a MAY than a SHOULD.
> I assume no link, which is fine.  A device can implement one MIB, the other, or both.
> Worth stating this.

Wil do it anyway.

> A device could report on the power level and energy consumption of an integral battery,
> or only do so for the entire device.  Whether the battery MIB is implemented is independent
> of this.  This point should be made in the requirements - that there is no linkage.
> I think this deals with these questions.  Primary energy reporting for ANY device is the mains
> power consumption - the effect of any internal batteries is invisible to this reporting.
> This does raise the point that if components of a device are reported on, then a battery
> I think the answer is the same as the above.  A device that is a UPS can report the
> UPS MIB (or not).  It also can report only its total energy/power input (and not battery details),
> I would replace "Remaining" with "Actual" since I first interpreted "Remaining" as

Fine.

> In all places where "needs to be measured" appears I would delete the phrase.

I will check all these places.

> I had the same question.  Also, there seem to be four thresholds where something bad
> could happen but only two notifications.  Shouldn't there be four notifications?
> Also, I am not knowledgeable about batteries, but I would think there are other
> errors, e.g. not taking a charge (my power drill charger tells me that sometimes)
> For Voltage, does this change when charging or discharging?  I thought that there
> was a higher voltage applied to charge a battery.  Perhaps we need to be more

Well, I can add a sentence that voltage of batteries changes. Voltage drops over time when discharging, it increase over time when charging, and yes, it is different in charging and discharging modes,

> For Replacement, units should be "Cycles".

Will add.

> For the questions, I would say that percentage should always be for actual and
> not nominal.  Also, I would punt and say that definitions of "full" and "empty" are
> up to the implementor.

But the choice if full related to original capacity or actual capacity should not be up to the implementor,
Otherwise we get ambiguous monitoring results.

> necessary to report it?  Is the fact that a threshold is dependent on this mean

Yes, we can omit it. This would also avoid the ambiguities.
The only problem we create then is that it is convenient to calculate 
with percentage values or to create policies with percentage value.

> answer, but whatever it is should probably be mentioned.

I need to understand the issue here. Can you elaborate?

> Bruce Nordman