Proposals to clarify xyzIntervalValidData description

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

Delivery-Date: Fri, 12 Jun 1998 02:42:09 -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 CAA10462 for <ietf-archive@ietf.org>; Fri, 12 Jun 1998 02:42:08 -0400 (EDT)
Received: from trix.cisco.com (trix-hme0.cisco.com [171.69.63.45]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA22959 for <ietf-archive@cnri.reston.va.us>; Fri, 12 Jun 1998 02:44:31 -0400 (EDT)
Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by trix.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id XAA24018 for <extdom.trunk-mib@aliashost.cisco.com>; Thu, 11 Jun 1998 23:36:16 -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 XAA29415 for <trunk-mib@external.cisco.com>; Thu, 11 Jun 1998 23:36:16 -0700 (PDT)
Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id XAA06744 for <trunk-mib@external.cisco.com>; Thu, 11 Jun 1998 23:36:15 -0700 (PDT)
Received: from shell16.ba.best.com(206.184.139.148) by proxy1.cisco.com via smap (V2.0) id xma006737; Fri, 12 Jun 98 06:36:09 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 XAA07984; Thu, 11 Jun 1998 23:32:23 -0700 (PDT)
X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs
Date: Thu, 11 Jun 1998 23:32:23 -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: Proposals to clarify xyzIntervalValidData description
Message-ID: <Pine.BSF.3.96.980611233012.6523C-100000@shell16.ba.best.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"

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.

The objects in question are

      sonetSectionIntervalValidData
      sonetLineIntervalValidData
      sonetFarEndLineIntervalValidData
      sonetPathIntervalValidData
      sonetFarEndPathIntervalValidData
      sonetVTIntervalValidData
      sonetFarEndVTIntervalValidData

      dsx1IntervalValidData
      dsx1FarEndIntervalValidData

      dsx3IntervalValidData
      dsx3FarEndIntervalValidData

and the all have the same description clause:

      "This variable indicates if there is valid data for this interval."

>From recent traffic on the atommib mailing list it is clear that
this description is not sufficient to convey the intent.  Here
is one of the comments:

Ken Chapman, 08 Jun 1998:
>
> I don't know if this has been rasied before, but...
> I find the wording of the DESCRIPTION clauses for all of the
> xyzIntervalValidData variable to be missleading:
> "This variable indicates if there is valid data for this interval."    XXX
> I think they should read:                                              XXX
> "This variable indicates if the data for this interval is valid."      XXX
>
> The way it is now, it sounds like it indicates if the data is
> *available* or not, rather than if the valid flag is set per
> ANSI T1.231 clause 9.1.2.2.
> Am I the only one that is confused?

I proposed the following alternative:

      "This variable assumes the value true(1) if the data stored       XXX
      for this interval is both valid and complete.  It is set to       XXX
      false(2) if the data stored for this interval is incomplete       XXX
      or otherwise invalid because:                                     XXX
                                                                        XXX
      - the data stored for this interval is for a period greater       XXX
      or less than 15 minutes;  or                                      XXX
                                                                        XXX
      - some data is missing (e.g., when a near-end defect prevents     XXX
      some far-end data from being collected)."                         XXX

I am willing to accept either proposal, but I think that _some_
change is needed.  What say the document editors, quality reviewers,
and other WG members?

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