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

["C. M. Heard/VVNET, Inc." <[e-mail]>]

On Mon, 20 Jul 1998, Ken Chapman wrote:

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

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.
[e-mail]