RE: discontinuity timers for Counters

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

> > > Looking at the MIB, the question that I have is the interaction of
> > > discontinuities with these ZeroBasedCounter32 objects. Does a
> > > discontinuity couse these counters to be reset to zero? 
> > 
> > I believe that we (MIB doctors) agree that they cannot state that a 
> > ZeroBasedCounter32 MUST be re-initialized to zero at some point
> > in time (they are only required to be zero at creation time). 
> > So I had them remove that sort of text from an earlier revision.
> > So current text is silent about it, meaning that an implementation
> > could do anything, right? There is a discontinuity, so we need to
> > start with new values and then check at least 2 queries.
> 
> If I have to compute deltas after the first discontinuity anyway, why
> use ZeroBasedCounter32? If my application can't be sure to track all
> discontinuities, then it has to compute deltas to produce meaningful
> results. I tend to believe that Counter32 is actually the more
> appropriate type in this scenario.
> 
Yeah... we've seen that a number of times before.
Not sure we can forbid what they do.
I will bring it up (as part of my MIB Doctor review)
And you probably ought to bring it up as IETF Last Call comments
(if it bothers you enuf and if it is still there when the IETF
Last Call happens).

I suspect they just assume (in practice) in their mgmt apps that the
counter is just the total number since the row was created.

They first had nothing about discontinuity.
But even for zero-based counters I think such text is needed,
and so they added what they now show. That indeed makes it
clearer that Counter32 is probably more appropriate.

> > Nope, I do not think the index is constantly changing. But that is a 
> > typical use case, not the only use case is it? At least I never 
> > considered that to be a pre-requisite for the use of ZeroBasedCounter32.
> 
> A ZeroBasedCounter32 in a conceptual row which can experience
> discontinuities as part of its normal operational behaviour
> just seems a bit odd to me. I fail to see what the advantage of
> a ZeroBasedCounter32 in such a situation is.
> 
We'll (I will) pose that question  to their ml.

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