RE: guidelines sec. 4.6.1.2 and discontinuity indicator

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

On Fri, 7 Feb 2003, Wijnen, Bert (Bert) wrote:
> > [ C. M. Heard wrote: ]
> > On Wed, 5 Feb 2003, Wijnen, Bert (Bert) wrote:
> > 
> > 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.
> >
> 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.
------^^^^

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

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.

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

> > 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.
>  
> Correct. That was specifcally added based on the reasoning above (or
> at least so is my recollection/understanding).
> 
> > 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).
> 
> I suppose (but I do not know for sure) that most (if not all) counters
> can actually reset or get discontinuities at times. If it is a
> subagent, the subagent may crash/restart. If it is on a card or
> in a device driver, some hickup may occur there... you never know.
> 
> So that is why I think that all counters need a ptr to an object
> that indicates the time at wich (a possible) discontinuitty 
> occured. 

Agreed.  And that's what it says to do.

> > 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?
> > 
> I think I would make the issue on a ptr to a discontinuity timer
> a separate topic. And decouple it from the reset to zero topic.
> Using IFMIB as an example is fine.

Ok, I will give it another try tomorrow.

//cmh