Subject: RE: [Disman] zero-based counters in draft-ietf-disman-alarm-mib-1 5.txt?

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 8 Oct 2003 16:26:18 -0400

Hi

Do we really feel that the current description and data type will result in
non-interoperable implementations? Other than the fact there was a neater
data type that we could have used instead, I don't really see a problem
here. I think the text is sufficient for people to know to start the thing
at 0 if nothing has happened.

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Thursday, October 02, 2003 10:54 PM
To: Disman (E-mail)
Subject: [Disman] zero-based counters in draft-ietf-disman-alarm-mib-15.txt?

Hi -

> From: "Sharon Chisholm" <[email-masked]>
> To: "Disman (E-mail)" <[email-masked]>
> Cc: <[email-masked]>; "Randy Presuhn" 
> <[email-masked]>; "Romascanu, Dan (Dan)"
<[email-masked]>
> Sent: Monday, September 29, 2003 7:34 AM
> Subject: [Disman] RE: Comments on draft-ietf-disman-alarm-mib-14.txt
...
> 62) alarmActiveStatsActives, the SYNTAX says this is a Counter32,
>     but the DESCRIPTION sure makes it sound like it's supposed to
>     be zero-based.
>
> 71) ituAlarmActiveStatsIndeterminates,
>     ituAlarmActiveStatsCriticals,
>     ituAlarmActiveStatsMajors,
>     ituAlarmActiveStatsMinors, and
>     ituAlarmActiveStatsWarnings are all Counter32, but their
>     DESCRIPTIONs sound like they're assumed to be zero-based.
>
> Sharon-> Counter32 can have a value of 0.
...

Let me put it another way:
  if none of these events have occured since system restart,
  what will the value of these objects be?

  a) zero, since the descriptions say they are counts "since system restart"
     if this is the case, they should use the ZeroBasedCounter32 TC
  b) not predictable, given the defnition of Counter32 in RFC 2578 clause
7.1.6
     if this is the case, then the "since system restart" words are
misleading

Randy (technical contributor)

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Oct 2003 13:50:15 -0700

Hi -

> Sent: Wednesday, October 08, 2003 1:26 PM
> Subject: RE: [Disman] zero-based counters in draft-ietf-disman-alarm-mib-15.txt?
...
...

If this is the intended semantic, then we really really should use the
ZeroBasedCounter32 TC.  Section 4.6.1.2 of the MIB review guidelines
seems to be saying that if a counter is required to start at zero,
then the TC is the appropriate type to use.  If you disagree, then we
should move that discussion to the mib review list to find out what
the reviewer consensus is, and to perhaps follow up with a clarification
to  draft-ietf-ops-mib-review-guidelines-02.txt to make it clear
what the strength of the recommendation there is.

(From the perspective of a former tool vendor, I can say that using
the ZeroBasedCounter32 TC is preferable, since would enable automatic
generation of initialization code for the counter.  Just saying "Counter32"
would mean that some human would need to put in the initialization code.)

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Oct 2003 13:50:15 -0700

Hi -

...
...

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Oct 2003 10:49:48 +0200

>>>>> Randy Presuhn writes:

Randy> (From the perspective of a former tool vendor, I can say that
Randy> using the ZeroBasedCounter32 TC is preferable, since would
Randy> enable automatic generation of initialization code for the
Randy> counter.  Just saying "Counter32" would mean that some human
Randy> would need to put in the initialization code.)

Same on the manager side. A Counter32 translates into "a single sample
has absolutely no meaning" while ZeroBasedCounter32 translates into "a
single sample has some meaning if we assume no wrap-around has
occured". And this distinction has implications how you deal with such
counters. So if you use zero-based counters, just put in the right TC
and move on.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Oct 2003 10:49:48 +0200

/js