Re: guidelines sec. 4.6.1.2 and discontinuity indicator

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

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.