Re: Proposed text for xyzValidIntervals/xyzInvalidIntervals

"C. M. Heard/VVNET, Inc." <heard@vvnet.com> Fri, 12 June 1998 19:20 UTC

Delivery-Date: Fri, 12 Jun 1998 15:20:47 -0400
Return-Path: heard@vvnet.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 PAA23569 for <ietf-archive@ietf.org>; Fri, 12 Jun 1998 15:20:47 -0400 (EDT)
Received: from jindo.cisco.com (jindo.cisco.com [171.69.43.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA26107 for <ietf-archive@cnri.reston.va.us>; Fri, 12 Jun 1998 15:23:09 -0400 (EDT)
Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by jindo.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id MAA24328 for <extdom.trunk-mib@aliashost.cisco.com>; Fri, 12 Jun 1998 12:13:10 -0700 (PDT)
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id MAA13449 for <trunk-mib@external.cisco.com>; Fri, 12 Jun 1998 12:13:09 -0700 (PDT)
Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id MAA18245 for <trunk-mib@external.cisco.com>; Fri, 12 Jun 1998 12:13:08 -0700 (PDT)
Received: from shell16.ba.best.com(206.184.139.148) by proxy1.cisco.com via smap (V2.0) id xma018233; Fri, 12 Jun 98 19:13:06 GMT
X-SMAP-Received-From: outside
Received: from localhost (heard@localhost) by shell16.ba.best.com (8.8.8/8.8.BEST) with SMTP id MAA02899; Fri, 12 Jun 1998 12:09:15 -0700 (PDT)
X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs
Date: Fri, 12 Jun 1998 12:09:15 -0700
From: "C. M. Heard/VVNET, Inc." <heard@vvnet.com>
X-Sender: heard@shell16.ba.best.com
To: atommib@thumper.bellcore.com, trunk-mib@external.cisco.com
Subject: Re: Proposed text for xyzValidIntervals/xyzInvalidIntervals
In-Reply-To: <35813AF7.4D600B3B@aur.alcatel.com>
Message-ID: <Pine.BSF.3.96.980612105306.11307D-100000@shell16.ba.best.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"

On Fri, 12 Jun 1998, Rajesh Abbi wrote:

> I have following comments on your proposal ...
[ ... ]
> I believe that this object [xyzValidIntervals] is 'mis-named' - perhaps it
> should be named'xyzMaxAvailableInterval'.  I do NOT see any meaning of
> 'validity' here.  I would describe it as:
> "The oldest interval for which an entry is available in this table."
>
> Note that the above item includes the number of 'InvalidIntervals' as well.

That's all true, and has been covered by previous discussions, e.g.,
Jeff Johnson's comments of 03 June 1998:

% xyzValidIntervals + xyzInvalidIntervals may not equal the number of
% intervals, mainly because xyzValidIntervals is a misnomer.  It is really
% the index of the oldest valid interval.

In a subsequent message on 03 Jun 1998 Jeff Johnson also wrote:

% Keep in mind that the origin of the Perf Hist TC MIB is the three trunk
% mibs (SONET, DS1, and DS3).  These definitions were factored out since they
% were common to all three mibs, and so that others could use them as well.
% I would love to make changes to the valid/invalid stuff, but it is
% impossible to do so without affecting implementations of the trunk mibs.

In other words, we cannot change the definitions of the various
xyzValidIntervals and xyzInvalidIntervals without breaking
fielded implementations.  Actually, SMI rules wouldn't let us
change the definitions anyway -- we'd need to deprecate these
objects and replace them with new objects.  We are, however,
allowed to make editorial changes to the description clauses
to clarify the definitions.  That's what I have tried to do,
and corrections are invited if someone feels that I have
done something else.

> > proposed>      -- xyzInvalidIntervals OBJECT-TYPE
> > proposed>      --     SYNTAX  INTEGER (0..<n>)
> > proposed>      --     MAX-ACCESS  read-only
> > proposed>      --     STATUS  current
> > proposed>      --     DESCRIPTION
> > proposed>      --       "The number of intervals in the range from
> > proposed>      --       1 to xyzValidIntervals for which no valid
> > proposed>      --       is available.  This object will typically
> > proposed>      --       be zero except in proxy situations."
> > proposed>      --       ::= { xxx }
> >
>
> If an interval is termed 'Invalid' if NO valid data is collected, how is
> this interval treated ?  I believe two options exist:
> A) The corresponding entry is NOT PRESENT in the table (ie: noSuch)

I believe that is the intent.  David Fowler -- please comment.

> B) The entry is present, but all counters are set to '0' AND the
>      'xyzIntervalValidData' flag is set to 'false'.

No.  That is NOT what the proposed description clause says!

[ ... ]
> Also, I would like to add that it is possible to have 'Invalid' intervals
> even in a 'non-proxy' situation (see my earlier response
> ' Re: Proposals to clarify xyzIntervalValidData description'.

I think that the problem here is that xyzInvalidIntervals is
a misnomer, just as xyzValidIntervals is.

It is really the number of intervals in the range from 1 to
xyzValidIntervals which are missing [David Fowler -- please
jump in and correct me if this is wrong].

The xyzIntervalValidData objects exist to allow an interval for
which data is present to be marked as "valid" or "invalid" in
the sense of ANSI T1.231-1993 ot T1.231-1997 Section 9.1.2.2,
which [I think] is how you are using the term.  Most certainly
it is possible in non-proxy situations to have intervals for
which this flag should be false(2) (i.e., "invalid" in the sense
of ANSI T1.231 Section 9.1.2.2).  But despite its name, that't
NOT what xyzInvalidIntervals is supposed to be used for.


Here is a summary:

    Object                  Meaning
    ------                  -------

xyzValidIntervals     Index of the oldest interval for which at least
                      some data exists

xyzInvalidIntervals   Number of intervals between 1 and xyzValidIntervals
                      which are missing (i.e., for which _no_ data exists)


xysIntervalValidData  A flag that says if the interval data is valid in
                      the sense of ANSI T1.231 Section 9.1.2.2.


If you ignore the names -- which I agree can be misleading -- and
concentrate on the what the definitions say -- can you live with
these objects?  Or do you feel that they are fatally flawed in some way?

>
> Rajesh
>

Mike
--
C. M. Heard/VVNET, Inc.
heard@vvnet.com