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

Ken Chapman <KChapman@Argon.com> Tue, 21 July 1998 12:32 UTC

Delivery-Date: Tue, 21 Jul 1998 08:32:09 -0400
Return-Path: KChapman@Argon.com
Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA03747 for <ietf-archive@ietf.org>; Tue, 21 Jul 1998 08:32:07 -0400 (EDT)
Received: from beasley.cisco.com (autorespond.cisco.com [171.69.2.135]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA09142 for <ietf-archive@cnri.reston.va.us>; Tue, 21 Jul 1998 08:32:00 -0400 (EDT)
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by beasley.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id FAA18828 for <trunk-mib@external.cisco.com>; Tue, 21 Jul 1998 05:25:49 -0700 (PDT)
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by kickme.cisco.com (8.9.1-Cisco/8.9.1) with ESMTP id FAA02001 for <trunk-mib@external.cisco.com>; Tue, 21 Jul 1998 05:25:51 -0700 (PDT)
Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id FAA25226 for <trunk-mib@external.cisco.com>; Tue, 21 Jul 1998 05:25:47 -0700 (PDT)
Received: from shultz.argon.com(208.234.161.2) by proxy1.cisco.com via smap (V2.0) id xma025223; Tue, 21 Jul 98 12:25:45 GMT
X-SMAP-Received-From: outside
Received: from aruba (aruba.argon.com [208.234.161.60]) by shultz.argon.com (8.8.6/8.8.6) with SMTP id IAA04455; Tue, 21 Jul 1998 08:13:28 -0400 (EDT)
Message-Id: <3.0.32.19980721081245.009b5870@shultz.argon.com>
X-Sender: kchapman@shultz.argon.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 21 Jul 1998 08:12:45 -0400
To: "C. M. Heard/VVNET, Inc." <heard@vvnet.com>
From: Ken Chapman <KChapman@Argon.com>
Subject: Re: Comments on draft-kchapman-perfhist-sup-TC-00.txt
Cc: atommib@thumper.bellcore.com, trunk-mib@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 09:21 AM 7/20/98 -0700, C. M. Heard/VVNET, Inc. wrote:
>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.

My mistake.  :^(   I was actually responding to a later comment that didn't 
make your list:
>-- *  The agent is capable of keeping a history of n intervals of 1-day
>--    performance data.  The value of n may be limited by the media-
>--    specific MIB module but shall be 1 < n =< 32, where n = 1
>                                                  ^^^^^^^^^^^^^
>--    represents the current 1-day interval, n = 2 represents the
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>--    previous 1-day interval, n = 3 represents the newest recent 1-day
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>--    interval and n = 32 represents the oldest recent 1-day interval.
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>[ the marked text is broken and should be deleted. ]

In that light I guess I really don't take issue with the change #2.
Take a look at the SONET Supplemental MIB to see what I'm referring to.
Sorry for the confusion.
	Ken