Re: guidelines sec. 4.6.1.2 and discontinuity indicator

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

Hi -

> From: "C. M. Heard" <heard@pobox.com>
> To: "Mreview (E-mail)" <mreview@ops.ietf.org>
> Sent: Thursday, February 06, 2003 6:01 PM
> Subject: RE: guidelines sec. 4.6.1.2 and discontinuity indicator
...
> > So if a Counter32/64 does not specify a specific dsicontinuity timer,
> > then my interpretation (and I know we discussed this several time
> > in SNMPv3 WG several years back) is that if such a counter DOES
> > experience a discontinuity, then the only way to indicate it (and
> > one MUST indicate it I think) is to reset sysUpTime.
> ------^^^^

This has been my understanding.  As a practical matter, it means that
one should try *really* hard to avoid discontinuities for counters which
use sysUpTime as the discontinuity indicator.

There has been much discussion of this in the past, as in the
"Epochal discontinuity" and "SMI issue 18 (Epochal Discontinuity)"
threads back in 1998.

> I think that conclusion would be wrong.  First point:  an agent that
> resets sysUpTime to indicate a simple counter discontinuity, rather
> than a managament subsystem re-initialization, would be in flagrant
> violation of the well-defined semantics of that object.  Its
> description clause, which has been unchanged since RFC 1213, says:
>
>                "The time (in hundredths of a second) since the
>                network management portion of the system was last
>                re-initialized."

I think the community has come to view discontinuities of counters tied
to sysUpTime as being effectively re-initializations.  As a practical matter,
if it is at all likely that a counter will experience discontinuities, its
DESCRIPTION should specify an indicator so that the (drastic) course
of whacking sysUpTime won't be needed.

> Second point:  as you see from the text I pointed to, I don't agree
> that this is a MUST.  The language in RFC 2578 doesn't support that.
>
> It would be hard for me to justify saying in the guidelines doc that
> this is a MUST.  From a practical perspective, it probably does not
> matter, because it _is_ a SHOULD and MIB doctors (I think) will flag
> violations of such SHOULDs and get authors to correct them.

The basic guideline for using a "MUST" is "the protocol won't work
if you don't do things this way."  Without a discontinuity indicator,
counter deltas cannot be trusted at all.

> > And so if you have many of these counters in an agent, then a single
> > one can cause a manager to have to re-poll a lot of Counters and
> > consider them as having experienced a discontinuity.
>
> As I said, I hope nobody resets sysUpTime just to indicate counter
> discontinuities.  I can't see any justification for that behaviour.
...

If they don't have dedicated discontinuity indicators, then sysUpTime is
the mechanism for signaling the discontinuity.  If one doesn't signal
them at all, then counter deltas in general cannot be trusted.

Randy