Re: discontinuity timers for Counters

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> To: "'Randy Presuhn'" <randy_presuhn@mindspring.com>; "Mreview (E-mail)" <mreview@ops.ietf.org>
> Sent: Tuesday, July 27, 2004 2:54 PM
> Subject: RE: discontinuity timers for Counters
...
> > This seems contrary to the whole motivation for using a zero-based
> > counter.  I'd think that if they *really* need a zero-based counter,
> > that the appropriate semantic is for its value to represent the number
> > of events since the beginning of the epoch defined by its discontinuity
> > indicator.  If that is so, then the appropriate discontinuity
> > behaviour would indeed be a reset to zero.
>
> Sect 4.6.1.2 iof mib review guidelines towards the end:
>
>    There also exist closely-related textual conventions
>    ZeroBasedCounter32 and ZeroBasedCounter64 defined in RMON2-MIB
>    [RFC2021] and HCNUM-TC [RFC2856], 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 preceding paragraphs/rules apply not only to Counter32/64,
>    but also to ZeroBasedCounter32/64 TCs.
>
> I conclude from that that we will not allow that a ZeroBasedCounter XX
> can REQUIRE a reset to zero at any time other than at creation time?
>
> Do I not interpret that correctly?
...

I hadn't thought of considering the MIB review guidelines to be the definitive
statement of intent for those textual conventions.  If that is what we should do, then
we should perhaps go over the review guidelines more closely to ensure that
they do not over- or under- specify things like, for example, discontinuity behaviour
of ZeroBasedCounter32.  In my opinion, the reading you propose can probably
be justified by the review guidelines, if one assumes that it the intent was to include
discontinuity behaviour in with the "post wrap" behaviour.  However, I also think that
that reading doesn't fit well with the original motivations for ZeroBasedCounter32,
even if the original use of that TC did not anticipate discontinuity events, which
in any case should not be lumped together with wraps.  Two samples straddling
a wrap yield a meaningful delta.  Two samples straddling a discontinuity do not.

Randy