[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: guidelines sec. 4.6.1.2 and discontinuity indicator
This proposed new text sounds as good text to me.
Thanks Mike.
Bert
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: zondag 9 februari 2003 22:25
> To: Mreview (E-mail)
> Subject: Re: guidelines sec. 4.6.1.2 and discontinuity indicator
>
>
> On Fri, 7 Feb 2003, C. M. Heard wrote:
> > On Thu, 6 Feb 2003, Randy Presuhn wrote:
> > > 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.
>
> After sleeping on this (which is always a good idea for contentious
> issues) I have redrafted the text of Section 4.6.1.2 in a manner that
> I hope will address all the concerns. After some more hard thinking,
> it seems that there is a good reason why 2578 does not
> require outright
> that a discontinuity counter be defined: it _does_ require that the
> description clause state when such discontinuities can occur, and it
> is possible to imagine ways other than discontinuity indicator objects
> to do it. So I re-drafted the text on that basis. The entire section
> follows below. As Bert requested, the issue of discontinuity
> indicators
> has been decoupled from the issue of it not allowing a
> DESCRIPTION clause
> to prescribe a value of zero (or anything else) after a reset. I have
> taken editorial license to remove what _I_ felt was redundant
> "reset to
> zero" stuff (covering that once is enough, IMnsHO). Finally, the text
> rescinding the one-hour rule is also included, for
> completeness. Changes
> relative to the -00 draft are marked in the left-hand margin.
>
> If anyone wished to complain, I ask that a proposed remedy accompany
> the complaint.
>
> Thank you.
>
> Mike
>
> 4.6.1.2. Counter32 and Counter64
>
> Counter32 and Counter64 have special semantics as described in RFC
> 2578 Sections 7.1.6 and 7.1.10 respectively. Object
> definitions MUST
> (and textual conventions SHOULD) respect these semantics. That
> means:
>
> | - It is OK to use Counter32/64 for counters that may/will be reset
> | when the management subsystem is re-initialized or when other
> | unusual/irregular events occur (e.g., counters maintained on a
> | line card may be reset when the line card is reset). However, if
> | it is possible for such other unusual/irregular events to occur,
> | the the DESCRIPTION clause MUST state that this is so and MUST
> | describe those other unusual/irregular events in
> sufficient detail
> | that it is possible for a management application to determine
> | whether a reset has occurred since the last time the counter was
> | polled. The RECOMMENDED way to do this is to provide a
> | discontinuity indicator as described in RFC 2578
> Sections 7.1.6 and
> | 7.1.10. For an example of such a discontinuity indicator see the
> | ifCounterDisconuityTime object in the IF-MIB [RFC2863].
>
> | - It is NOT OK to put in the DESCRIPTION clause of a Counter32/64
> | that there is a requirement that on a discontinuity the counter
> | MUST reset to zero or to any other specific value.
>
> - It is NOT OK to put in the DESCRIPTION clause of a Counter32/64
> that there is a requirement that it MUST reset at any specific
> time/event (e.g., midnight).
>
> - It is NOT OK for one manager to request the agent to reset the
> value of counter(s) to zero, and Counter32/64 is the wrong syntax
> for "counters" which regularly reset themselves to zero. For the
> latter it is better to define or use textual conventions such as
> those in RFC 2493 [RFC2493].
>
> + RFC 2578 Section 7.1.10 places a requirement on "standard" MIB
> + modules that the Counter64 type may be used only if the information
> + being modeled would wrap in less than one hour if the
> Counter32 type
> + was used instead. Now that SNMPv3 is an Internet Standard
> and SNMPv1
> + is Historic (see http://www.rfc-editor.org/rfcxx00.html for status
> + and [RFC3410] for rationale) there is no reason to
> continue enforcing
> + this restriction. Henceforth "standard" MIB modules MAY use the
> + Counter64 type when it makes sense to do so, and MUST use Counter64
> + if the information being modeled would wrap in less than
> one hour if
> + the Counter32 type was used instead.
>
> There also exist closely-related textual conventions
> ZeroBasedCounter32 and ZeroBasedCounter64 defined in RMON2-MIB
> [RFC2021] and HCNUM-TC [RFC2856], respectively.
>
> The only difference between ZeroBasedCounter32/64 TCs and
> Counter32/64 is their starting value; at time=X, where X is their
> minimum-wrap-time after they were created, the behaviour of
> ZeroBasedCounter32/64 becomes exactly the same as Counter32/64.
> Thus, the preceeding paragraphs/rules apply not only to
> Counter32/64,
> but also to ZeroBasedCounter32/64 TCs.
>
>