Re: guidelines sec. 4.6.1.2 and discontinuity indicator

["C. M. Heard" <heard@pobox.com>]

On Thu, 6 Feb 2003, Randy Presuhn wrote:
> [C. M. Heard wrote:]
> > [Bert Wijnen wrote:]
> > > 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.

I agree that the only discontinuities that should occur in such
counters are those that occur when the management subsystem is
re-initialized.  But I think you are both mistaken in thinking
that an agent should set sysUpTime to zero to indicate a counter
discontinuity, unless of course that discontinuity was the result
of a management subsystem re-initialization.

> 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 don't remember any discussion on any of the mailing lists I've
subscribed to that ever suggested that an agent should reset sysUpTime
just to indicate counter discontinuities.  My understanding has always
been that sysUpTime is set to zero when (and only when) the management
portion of a system is re-initialized, and increments 100 times per
second at all other times.  It is, in effect, a special sort of
zero-based counter with a rollover time of approximately 497 days.
The only event that is ever supposed to cause non-monotonic behaviour
is a re-initialization of the management (sub)system.

Now, there _was_ a lengthy discussion in 1998 on the SNMPv3 mailing
list about what happens to TimeStamp objects when sysUpTime rolls over.
That is what the the thread "SMI issue 18 (Epochal Discontinuity)" was
all about.  I'm not relying on memory for this, I just pulled down the
archives and checked.  The result of that discussion was that TimeStamp
objects are _not_ reset when sysUpTime rolls over, although they are
reset whenever sysUpTime is reset due to a re-initialization of the
network management (sub)system.

Back again to the issue of counter discontinuitues and sysUpTime.
The rules as stated in RFC 2580 7.1.6 and 7.1.19 are:  (1) if the
management susbsystem is re-initialized, then counters may (and
normally will) suffer discontinuities;  (2) if there are other
times when discontinuities may occur, then there should be a
discontinuity indicator object.  The rules stated in RFC 3418
are that sysUpTime is the time in 1/100ths of a second (modulo
2^32) since the last management subsystem re-initialization.
None of this suggests that counter discontinuities by themselves
ever cause sysUpTime to be reset.

> I think the community has come to view discontinuities of counters
> tied to sysUpTime as being effectively re-initializations.

I think this is backwards.  The reverse is true, of course:
counter discontinuities tied to re-initializations will be
indicated by zeroing of sysUpTime (as well as all TimeStamp
objects), plus transmission of a cold start or warm start trap.

> As a practical matter, if it is at all likely that a counter will
> experience discontinuities, its DESCRIPTION should specify an indicator

so far, we agree

> so that the (drastic) course of whacking sysUpTime won't be needed.

but I don't see how whacking sysUpTime is justified.

It seems to me that there is a logical error here:  from "if sysUpTime
is reset (indicating a re-initialization) then a counter discontinuity
has occurred" one cannot not conclude "if a counter discontinuity has
occurred then sysUpTime must be reset".

All of this is something of a red herring, though ...

> > 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.

I could be convinced by this to put MUST language into the guidelines
document, because it argues pretty convincingly that the word "should"
in the phrase "a corresponding object should be defined" in RFC 2578
Sections 7.1.6 and 7.1.10 is a bug and should have been "must" (or
rather, MUST, but the SMI documents unfortunately didn't use the
conventions of RFC 2119).

I'll go sleep on it and attempt to craft some revised text for this
very contentious section tomorrow when I am fresh.

//cmh