[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: guidelines sec. 4.6.1.2 and discontinuity indicator
Inline
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: donderdag 6 februari 2003 0:56
> To: Mreview (E-mail)
> Subject: Re: guidelines sec. 4.6.1.2 and discontinuity indicator
>
>
> 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.
>
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.
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.
> 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.
> 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.
>
We need the reset to zero too. That is that one cannot mandate/require
that when a counter resets that it resets to zero. Or that a counter
should reset to zero at any specific time or at any timeinterval
or such. For that we have thother TCs.
> 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.
Bert
> //cmh
>
>