Subject: Counters and use of TC ZeroBasedCounter32/64 (was RE: [ipcdn] Review of: draft-ietf-ipcdn-bpiplus-mib-08.txt)

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 13 Feb 2003 15:17:37 -0700

Bert,

Thank you for all the valuable comments on bpiplus-mib-08.

2 questions for clarification on ZeroBasedCounter32/64:
Re:
>       docsBpi2CmAuthRejects    OBJECT-TYPE
>            SYNTAX         Counter32
>            MAX-ACCESS     read-only
>            STATUS         current
>            DESCRIPTION
>                 "The value of this object is the count of times the CM
>            has received an Authorization Reject message, 
> since reboot."

you wrote:
>   require that a Counter starts at zero. But those are NOT the
>   semanticws of a Counter32. If this is what you want, I think you
>   need to use the ZeroBasedCounter32 as per RFC2021.
>   Pls read draft-ietf-ops-mib-review-guidelines-00.txt sect 4.6
>   specifically 4.6.1.2
>   You have quite a few of those objetcs

Reading again through the reference above and digging the textual
conventions in rfc2021 & rfc2856, I got 2 questions:

1. the descriptions of ZeroBasedCounter32/64 both define some
applicability of those TCs:
" Typically this TC is used in tables where the INDEX space is
  constantly changing and/or the TimeFilter mechanism is in use."
Can we then assume that you're ok with us using those
ZeroBasedCounter32/64 TCs everywhere we have a counter that is set to
zero on creation and wraps up on reboot or registration.

2. Do we have to add any text in the description clause to the effect of
"minimum time to wrap"?
Most of the description text defines "reboot or registration" as the
event when counters get reset to zero. So I think we are fine.  But just
to be sure, those TCs define:
"Provided that an application discovers the new object within
the minimum time to wrap it can use the initial value as a
delta since it last polled the table of which this object is
part.  It is important for a management station to be aware
of this minimum time and the actual time between polls, and
to discard data if the actual time is too long or there is
no defined minimum time."
Can we assume we are ok there?

Jean-Francois.
_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 13 Feb 2003 23:55:30 +0100

Inline.

> >          has received an Authorization Reject message, since reboot."
> 
> you wrote:
In many cases, I (we as MIB dcotors) do not like Counters that are
supposed to start at zero at all. However, in some cases it is
acceptable. I believe in your case this is so, that is why
I made the suggestion to use those TCs.

As (I think I also said), pls take a look at
http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-00.txt
Specifically section 4.6.1.2 which says:
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 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 SHOULD be provided to indicate when the last such
     reset occurred.

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

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

   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.

Specifically that last para is important. So people who use the
ZeroBasedCounterxx have to be carefull that a wrap of the counter
makes it just a regular Counter32, and so it is not longer
usefull to do something with a single value, only with a difference
between two values.

> 2. Do we have to add any text in the description clause to 
> the effect of "minimum time to wrap"?
> event when counters get reset to zero. So I think we are fine.

So I don't think that they "reset to zero", they start at zero
the at the time they come into existence.

> But just to be sure, those TCs define:
So if you use the TC, then the DESCRIPTION clause of the TC
already explains this, and so people who use your objects that
have this TC as their SYNTAX should be able to udnerstand from
that what exactly the constraints are.
So yes, I think you are then OK.

Bert