Subject: Re: Comments on draft-kchapman-perfhist-sup-TC-00.txt

From: Ken Chapman <[email-masked]>
Date: Mon, 20 Jul 1998 10:09:44 -0400

Mike,
Thanks for the comments.

At 10:07 AM 7/18/98 -0700, C. M. Heard/VVNET, Inc. wrote:
>Greetings,
>
>Thanks to Ken Chapman for producing <draft-kchapman-perfhist-sup-TC-00.txt>.
>My comments are listed below, in decreasing order of importance.  I have
>cross-posted them to the atommib and trunk-mib lists because the TCs in this
>draft are relevant both to the SONET supplemental MIB and to the DS1 and DS3
>supplemental MIBs.
>
>1.) PerfDayCount should have a syntax of Gauge32 (not Unsigned32),
>    and its description needs to take into account the fact that
>    its value _may decrease_ if the counts are adjusted retroactively
>    upon entering or exiting unavailable time.
>
>    Discussion:  the description clause now states that "unlike a
>    Counter32, this counter shall not wrap; it shall latch if it
>    reached its maximum value (4294967295 decimal) and it shall not
>    change until it is reset (e.g. at the beginning of a new interval)."
>    It is agreed that the a PerfDayCount must not wrap;  however, if
>    the underlying value subsequently decreases below 4294967295 owing
>    to a retroactive adjustment, then its value _should_ subsequently
>    decrease;  it should not remain latched at 4294967295.  This is
>    precisely what RFC 1902 says that a Gauge32 object will do:
>
>        The Gauge32 type represents a non-negative integer, which may
>        increase or decrease, but shall never exceed a maximum value.  The
>        maximum value can not be greater than 2^32-1 (4294967295 decimal).
>        The value of a Gauge has its maximum value whenever the information
>        being modeled is greater or equal to that maximum value; if the
>        information being modeled subsequently decreases below the maximum
>        value, the Gauge also decreases.
>
>    In conjunction with this change to the SYNTAX clause, the portion of
>    the description clause quoted above should be changed to read "unlike
>    a Counter32, this object shall not wrap;  whenever the underlying count
>    exceeds 4294967295, this object shall return the value 4294967295."
>    [Other changes are covered under (3) below.]

I agree.

>2.) The definition of xyzInvalidDays given here is not consistent with
>    the definition of xyzInvalidIntervals in PerfHist-TC-MIB.  For
>    consistency, it should be the number of recent 1-day intervals with
>    interval numbers in the range 1..xyzValidDays which are unavailable.

I disagree.  I think that the argument in favor of consistency is not 
strong enough in this case.  The table structure I'm proposing saves
complexity
and bulk in the MIB definitions for ALL 1-day interval counters.  The "old"
way requeres two OBJECT-TYPE definitions for each counter; my way only
requires
one.  The code required in my implementation of an agent will be significantly
less, since I only have one set of OIDs to deal with and just have to case
on the 
index to distinguish the current from the previous.  I just don't buy the
"consistency" argument.

>3.) There are various typos which are noted in the marked-up ID which
>    I have attached below my signature.

Thanks.

>4.) The boilerplate should be updated to the latest version agreed to
>    by the SNMPv3 WG.

Have they reached consensus?  :^)

>5.) The acknowledgments section should probably state that the document
>    has been reviewed by an IETF working group.

If we all agree...  :^)

>6.) The security section will need to be re-written, if only to state
>    that MIB objects defined using the TCs in this MIB module are
>    not likely to pose create security hazards because they are read-only
>    and the information they contain is not sensitive.

I'll go along with the group consensus.
	Ken

My goof:
>IMPORTS
>    MODULE-IDENTITY
>        FROM SNMPv2-SMI
>    mib-2, Unsigned32
>        FROM SNMPv2C-SMI
>
>[should be:
>    MODULE-IDENTITY, mib-2, Gauge32
>        FROM SNMPv2-SMI
>]
>    TEXTUAL-CONVENTION
>        FROM SNMPv2-TC;

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Mon, 20 Jul 1998 09:21:46 -0700 (PDT)

On Mon, 20 Jul 1998, Ken Chapman wrote:

> complexity and bulk in the MIB definitions for ALL 1-day interval counters.
> The "old" way requeres two OBJECT-TYPE definitions for each counter; my
> way only requires one.  The code required in my implementation of an agent
> will be significantly less, since I only have one set of OIDs to deal with
> and just have to case on the index to distinguish the current from the
> previous.  I just don't buy the "consistency" argument.

I do not follow your reasoning.  There is only one xyzInvalidDays object for
each interface in the draft supplemental MIB, just as there is only one
xyzInvalidIntervals object for each interface in each of the trunk MIBs.  It
seems to me that the agent does the same amount of work -- i.e., keeping
track of the number of intervals for which _no_ data exists -- in either
case;  the number is just reported a little differently under your approach
versus the one in the present trunk MIBs.  I see no advantage to doing this
in different ways for 1-day intervals and 15-minute intervals.

Please remember what this object was for:  it was to save the manager from
having to attempt to walk through all of the historic intervals to find out
how many would return noSuch*.  Note also that if your agent is not a proxy,
xyzInvalidWhatever is a constant, and requires no work to maintain.

Regards,

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Mon, 20 Jul 1998 09:21:46 -0700 (PDT)

Regards,

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]