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.