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
- Comments on draft-kchapman-perfhist-sup-TC-00.txt C. M. Heard/VVNET, Inc.
- Re: Comments on draft-kchapman-perfhist-sup-TC-00… Ken Chapman
- Re: Comments on draft-kchapman-perfhist-sup-TC-00… C. M. Heard/VVNET, Inc.
- Re: Comments on draft-kchapman-perfhist-sup-TC-00… Ken Chapman