Re: guidelines sec. 4.6.1.2 and discontinuity indicator

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

On Wed, 5 Feb 2003, Wijnen, Bert (Bert) wrote:
> Now on to the comments on how you handled discussions
> Only those where I have still concerns...
> 
> > On Fri, 6 Dec 2002, Wijnen, Bert (Bert) wrote:
> > > - Say something about discontinuity timers
> > 
> > Section 4.6.1.2 already says "if it is possible for such
> > resets to occur, then a discontinuity indicator object
> > SHOULD be provided to indicate when the last such reset
> > occurred."  Is more required?  I didn't think so because
> > there is already a discussion of this in RFC 2578.  So,
> > the resolution here was "no change".
> > 
> The current text seems to focus on the RESET (to zero?)...
> In general, one of the most encountered problems with counters
> is that it is not clear which discontinuity timer is used.
> By default that then means sysUpTime, and if the system were
> to indeed reset sysUpTime for some random counter discontinuity,
> then a lot of counters are to be considered to have experienced
> a discontinuity (since tso many default to sysUpTime).
> So I feel that a bit more of a warning/focus/ and a 
> check-by-mib-doctors is justified

Let's go back and recall what RFC 2578 Section 7.6.1 actually says:

   Counters have no defined "initial" value, and thus, a single value of
   a Counter has (in general) no information content.  Discontinuities
   in the monotonically increasing value normally occur at re-
   initialization of the management system, and at other times as
   specified in the description of an object-type using this ASN.1 type.
   If such other times can occur, for example, the creation of an object
   instance at times other than re-initialization, then a corresponding
   object should be defined, with an appropriate SYNTAX clause, to
   indicate the last discontinuity.  Examples of appropriate SYNTAX
   clause include:  TimeStamp (a textual convention defined in [3]),
   DateAndTime (another textual convention from [3]) or TimeTicks.

I didn't even think of sysUpTime as a discontinuity indicator, since
it all it tells you is if the management system is re-initialized.
A discontinuity indicator is supposed to tell you about those "other"
times that such things can happen.  The object that immediately
comes into my mind when this is is mentioned is IF-MIB's
ifCounterDiscontinuityTime.  Would it suffice to cite it
as an example, like this:

   - 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 may be 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.  However, if it
     is possible for such resets to occur, then a discontinuity
     indicator object like IF-MIB's ifCounterDiscontinuityTime [RFC2863]
     SHOULD be provided to indicate when the last such reset occurred.

This is a good exemple to cite since it is often imported into other
MIBs (see, e.g., RFC 3289).

As for the focus on "reset to zero" instead of just discontinuities,
that was inherited from the review guidelines text you gave me on
this subject.  I don't think it's overdone;  mostly what it's saying
that you CAN'T specify "reset to zero" in object definitions that
use Counter32 or Counter64.

I don't mind re-working this some more, but I we're spending a lot of
text on a fairly small part of the subject, and (like everyone else
here) I don't want the document to get bloated.

So, is this proposal OK, or do I need to do more work on it?

//cmh