[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FW: SMIv2: use of Counter32 and Counter64



Here is what I agreed to with Juergen, David Perkins, Keith
a few years back when this issue cam up initially and when 
I wanted to have a coinsistent stroy from all MIB doctors.

I do not longer have the original emails... possibly Juergen
has them.

I did that discussion with Juergen/Keith/David since they are
the editors of RFC2578.

I then fed that into the mib-review -guidelines discussion, so that
we did (and still do) have the opportunity to try and get one
common view with all the MIB doctors, so that (very important)
we DO use the same criteria when doing MIB Doctor review.

Thanks,
Bert 

-----Original Message-----
From: Wijnen, Bert (Bert) 
Sent: woensdag 4 september 2002 00:46
To: Bert Wijnen (E-mail)
Subject: SMIv2: use of Counter32 and Counter64


These are the rules/guidelines we use when doing 
MIB reviews. These guidelines have the agreement
of the Editors of the SMIv2 document (RFC2578).

Counter32 and Counter64 have special semantics as defined in
RFC 2578, sections 7.1.6 and 7.1.10 respectively.

This means:
- It is OK to use Counter32/64 for counters that can reset 
  themselves on unusual/irregular events (e.g., counters 
  maintained on a line card are reset when the line card 
  is reset), and it is not illegal if their value after 
  the reset happens to be zero (i.e., it does not have to
  be non-zero). So, "counters that can reset to zero" is 
  not automatically wrong for Counter32/64.
- It is NOT OK to put in the DESCRIPTION clause of a
  Counter32/64 that there is a requirement that on a
  discontinuity, the counter MUST reset to zero. 
- It is NOT OK to put in the DESCRIPTION clause of a
  Counter32/64 that there is a requirement MUST reset
  at any specific time/event (e.g. midnight).
- It is NOT OK for one manager to request the  agent to
  reset the value of counter(s) to zero, and Counter32/64
  is the wrong syntax for "counters" which regularly reset
  themselves to zero (For such cases it is better to define
  or use the TCs as defined in RFC 2493).

We also have defined a ZeroBasedCounter32/64 (in RMON2 MIB
and in HCNUM-TC respectively).

The only difference between ZeroBasedCounter32/64 TCs and 
Counter32/64 is their starting value; at time=X, where X is
their minimum-wrap-time after they were created, the behaviour
of ZeroBasedCounter32/64 becomes exactly the same as 
Counter32/64. Thus, the preceeding paragraphs/rules apply not
only to Counter32/64, but also to ZeroBasedCounter32/64 TCs.

Bert