Subject: [eman] js review of draft-quittek-eman-battery-mib-00

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Mar 2011 12:45:51 +0200

Hi,

here are some review comments for draft-quittek-eman-battery-mib-00:

- Is there a special reason for this:

  entPhysicalIndex Integer32 (1..2147483647)
  pmIndex          Integer32 (1..2147483647)
  pmPowerIndex     Integer32 (0..2147483647) -- why very special 0 ??
  batteryIndex     Unsigned32                -- what about 0 ??

- Put other and unknown enumeration entries at the top so that in case
  additions are made, they do not end up somewhere in the middle.

- Giving a Counter32 value special semantics frankly seems stretching
  the usage of counters beyond what I think is legal. What happens if
  the counter reading 'ffffffff'H? Perhaps this is really a zero based
  counter instead of a counter? It seems to persistently stick to the
  device or is this counter reinitialized with the SNMP agent?

- psmNotificationsGroup should probably be batteryNotificationsGroup

- Why is batteryAlarmThresholdsGroup mandatory while the notifications
  are optional?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 31 Mar 2011 16:52:59 +0200

Hi Juergen,

Thank you for the review!
Please see replies inline.

>  batteryIndex     Unsigned32                -- what about 0 ??

No, there is not. This is just a mistake.
Will change batteryIndex to Integer32 (1..2147483647).

>  additions are made, they do not end up somewhere in the middle.

Will do.

>  device or is this counter reinitialized with the SNMP agent?

The problem with this object is that some devices have no provisioning 
for counting these cycles.

What would be the right solution for this?
a) have an additional object indicating whether cycles are counted?
b) if there is no counting facility, not implement the object?
c) if there is no counting facility, implement the object but return inconsistentValue(12)?
d) return a special counter value?
e) anything else?

Recommendations are highly appreciated.

> - psmNotificationsGroup should probably be batteryNotificationsGroup

Yes, that's a copy/paste mistake. Will fix it.

> - Why is batteryAlarmThresholdsGroup mandatory while the notifications

Yes, that's inconsistent.
Will fix it in the next revision.

Thanks,

    Juergen Q.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 Mar 2011 17:12:07 +0200

> Recommendations are highly appreciated.

A single Counter32 value has no meaning since a Counter32 has no
defined initial value. If you want a meaninful Counter32, you need to
use ZeroBasedCounter32. That is the simple part.

Given your options:

a) dobable, requires to pay attention of course and special case code
b) in theory the correct approach, not popular though due to some common
   implementation shortcomings, but getting slowly more accepted as far
   as I can tell (interface tables just do not report the counters that
   are not applicable/implemented for a certain interface)
c) nope, that is in conflict with RFC 3416
d) nope, does not work since counters by definition use the complete 
   number space
e) no idea what that would be

>From an SNMP point of view, you just do not implement the objects that
do not apply. Correctly written managers will cope with this just
fine.  We tend to report special "NULL" values whenever this is
possible to help not so correctly written management applications
along. In case of counters, there simply is no such "NULL" value, so I
think the correct thing to do is to not instantiate the object (and to
be explicit about this in the DESCRIPTION clause).

/js

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 31 Mar 2011 18:48:39 +0200

Thanks, I will go for option b)

    Juergen Q.

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 31 Mar 2011 18:57:04 +0200

Hi Juergen,

Sprry, I have a follow-up question on option b).

This option says "don't implement the counter object if you cannot count cycles".
What if I have two batteries where I have count values for one and but not for the
other one. Would I then implement the object in one conceptual row, but not in 
the other one? Would this be OK for management systems browsing the MIB?

Thanks,

    Juergen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 Mar 2011 20:21:00 +0200

On Thu, Mar 31, 2011 at 06:57:04PM +0200, Juergen Quittek wrote:
 
> This option says "don't implement the counter object if you cannot
> count cycles".  What if I have two batteries where I have count
> values for one and but not for the other one. Would I then implement
> the object in one conceptual row, but not in the other one? 

You "instantiate" the object for those batteries where it makes
sense.

> Would this be OK for management systems browsing the MIB?

This is what happens with the ifTable today on major routers. Here is
a typical example (showing live data retrieved via SNMP):

scli $ show interface stats

INTERFACE STATUS I-BPS O-BPS I-PPS O-PPS I-ERR O-ERR I-DIS O-DIS I-UNK  DESCRIPTION
[...]
       15  DDNN   ----  ----  ----  ----  ----  ----  ----  ----  ----  ATM0-atm layer
       16  DDNN   ----  ----  ----  ----  ----  ----  ----  ----  ----  ATM0.0-atm subif
       17  DDNN      0     0     0     0     0  ----     0     0     0  ATM0-aal5 layer
       18  DDNN      0     0     0     0     0  ----     0     0     0  ATM0.0-aal5 layer
       19  DDNN   ----  ----  ----  ----  ----  ----  ----  ----  ----  ATM0-adsl

You can see that some interface types have no counters at all, some
layers have no output error counters. And you can always create such
holes by configuring access control rules. Management systems that
can't deal with this are kind of broken. And such systems already
today have a problem to display the ifTable - so I assume that most
systems should do this correctly meanwhile.

/js