Re: Proposals to clarify xyzIntervalValidData description
Rajesh Abbi <abbira@aur.alcatel.com> Fri, 12 June 1998 14:17 UTC
Delivery-Date: Fri, 12 Jun 1998 10:17:44 -0400
Return-Path: abbira@aur.alcatel.com
Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA15736 for <ietf-archive@ietf.org>; Fri, 12 Jun 1998 10:17:43 -0400 (EDT)
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA24243 for <ietf-archive@cnri.reston.va.us>; Fri, 12 Jun 1998 10:20:05 -0400 (EDT)
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by kickme.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id HAA24764 for <trunk-mib@external.cisco.com>; Fri, 12 Jun 1998 07:11:45 -0700 (PDT)
Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id HAA17979 for <trunk-mib@external.cisco.com>; Fri, 12 Jun 1998 07:11:44 -0700 (PDT)
Received: from aurms0.aur.alcatel.com(143.209.4.1) by proxy1.cisco.com via smap (V2.0) id xma017962; Fri, 12 Jun 98 14:11:40 GMT
X-SMAP-Received-From: outside
Received: from aur.alcatel.com (aursf1 [198.151.197.39]) by aurms0.aur.alcatel.com (8.8.8/8.8.7) with ESMTP id KAA13429; Fri, 12 Jun 1998 10:01:33 -0400 (EDT)
Sender: abbira@aur.alcatel.com
Message-ID: <35813441.BE1C3189@aur.alcatel.com>
Date: Fri, 12 Jun 1998 09:59:29 -0400
From: Rajesh Abbi <abbira@aur.alcatel.com>
Organization: Alcatel Network Systems, Inc Raleigh, NC
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
To: "C. M. Heard/VVNET, Inc." <heard@vvnet.com>
CC: atommib@thumper.bellcore.com, trunk-mib@external.cisco.com
Subject: Re: Proposals to clarify xyzIntervalValidData description
References: <Pine.BSF.3.96.980611233012.6523C-100000@shell16.ba.best.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Mike, I'm glad to see the addition of the 'IntervalValidData' flags to the interval tables. I would also mention other cases where data may not be collected for an interval by the agent: - Agent unable to keep up with data collection due to equipment performance problems. - Equipment may be in a state where data collection is interrupted. An important case needs to be addressed explicitly in the MIBs - what happens when an interface's ifAdminStatus is set to 'down' by a manager. In my opinion the data collection must be stopped while the ifAdminStatus is 'down'. This will be another case when data in an interval may be incomplete. What's the opinion of others ? Rajesh C. M. Heard/VVNET, Inc. wrote: > When the final edits to <draft-ietf-atommib-sonetng-02.txt> were made > in July 1996, seven IntervalValidData flags were added, largely at my > urging, so that it would be possible to indicate whether or not the > data for a given interval is valid or invalid in the sense defined > in ANSI T1.231-1993 Sec. 9.1.2.2. The intent -- as I understood > it at the time -- was that one of these these flags would be set to > false(2) if the data stored for the corresponding interval interval > is incomplete or otherwise invalid because: > > - the data stored for this interval is for a period greater > or less than 15 minutes; or > > - some data is missing (e.g., when a near-end defect prevents > some far-end data from being collected). > > Similar objects also exist in the DS1 and DS3 MIBs.
- Proposals to clarify xyzIntervalValidData descrip… C. M. Heard/VVNET, Inc.
- Re: Proposals to clarify xyzIntervalValidData des… Rajesh Abbi
- Re: Proposals to clarify xyzIntervalValidData des… C. M. Heard/VVNET, Inc.