Subject: Re: snmpconf PM MIB issue #6 CLOSED - counter32Delta and counterRate

From: "Robert Moore" <[email-masked]>
Date: Wed, 16 May 2001 15:31:32 -0400

I'm still uneasy about counter discontinuity indicators
and how they figure into this topic.  The purpose of a
discontinuity indicator is to raise a flag that says
"Don't do a delta calculation for this counter - the
result will be invalid!"  Since these accessor functions
don't themselves do anything with discontinuity indicators
(and it's hard to see how they could, since that would
require MIB knowledge), it must be up to the script writer
to check them before invoking these functions.  If this is
how it's supposed to work, then the document should have
examples where the calls to these functions are preceded
by statements that check (and save) the appropriate
discontinuity indicator.

I know this moves the scripts in the direction of larger
and uglier, but given the way counters are defined in SMI,
I don't see any other way to do it.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
[email-masked]

David Partain <[email-masked]>@snmp.com on 05/16/2001 12:04:02
PM

Please respond to [email-masked]

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  snmpconf PM MIB issue #6 CLOSED - counter32Delta and counterRate

Hi,

Issue:  When Steve presented counter32Delta and counterRate,
there was a fair bit of discussion on whether they were right
as they are. More thought and discussion is required.

There have been no discussion and no questions.  As such,
I assume that everyone understands how these two accessor
functions work and that the description is clear.

If you have questions, please bring them up quickly.

With kind regards,

--
David Partain                  [email-masked]
Ericsson Radio Systems AB      Tel:    +46 13 28 41 44
Research and Innovation        Fax:    +46 13 28 75 67
P.O. Box 1248
SE-581 12  Linköping, Sweden

---

From: David Partain <[email-masked]>
Date: Thu, 17 May 2001 14:24:07 +0200

Hi Bob,

I wrote:

dp> Issue:  When Steve presented counter32Delta and counterRate,
dp> there was a fair bit of discussion on whether they were right
dp> as they are. More thought and discussion is required.
dp> 
dp> There have been no discussion and no questions.  As such,
dp> I assume that everyone understands how these two accessor
dp> functions work and that the description is clear.
dp> 
dp> If you have questions, please bring them up quickly.

and Bob Moore did:

bm> I'm still uneasy about counter discontinuity indicators
bm> and how they figure into this topic.  The purpose of a
bm> discontinuity indicator is to raise a flag that says
bm> "Don't do a delta calculation for this counter - the
bm> result will be invalid!"  Since these accessor functions
bm> don't themselves do anything with discontinuity indicators
bm> (and it's hard to see how they could, since that would
bm> require MIB knowledge), it must be up to the script writer
bm> to check them before invoking these functions.

I'm not sure what I'm missing... In the definition of
counterRate, there is the following text:

        The delta calculation will allow for 32-bit counter semantics
        if it encounters rollover between the two retrievals unless
        the optional argument '64bit' is present and equal to 1,
        in which case it will allow for 64-bit counter semantics.

That looks to me like the policy engine _will_ keep track of
the rollover and provide a correct delta.  Furthermore,
counter32Delta is specifically to retrieve the delta of
two numbers while taking 32-bit rollover into account.

bm> If this is
bm> how it's supposed to work, then the document should have
bm> examples where the calls to these functions are preceded
bm> by statements that check (and save) the appropriate
bm> discontinuity indicator.

There is only one example, under counter32Delta().  It
doesn't look at a discontinuity indicator, since this 
doesn't exist as I see it.

Can you help me understand the scenarios that you think
something more might be needed?

bm> I know this moves the scripts in the direction of larger
bm> and uglier, but given the way counters are defined in SMI,
bm> I don't see any other way to do it.

With kind regards,