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

[Ken Chapman <[e-mail]>]

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;