Subject: history of xyzIntervalValidData objects

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Mon, 8 Jun 1998 16:07:32 -0700 (PDT)

On Mon, 8 Jun 1998, C. M. Heard/VVNET, Inc. wrote:

> My recollection was that the xyzIntervalValidData objects --
> which were not present in RFC 1595 -- were added to
> <draft-ietf-atommib-sonetng-02.txt> to allow for just this
> situation.  I will search the atommib mail archive later
> today and post my findings.

Attached below are all of the mail messages concerning
xyzIntervalValidData objects that I found in the atommib
archives.  I am not including any traffic from the last
few days.

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

Subject: Re: Specific needs from ANSI 231 -> SONET MIB
From: James Watt <[email-masked]>
To: [email-masked] (Al Plante)
Cc: [email-masked], [email-masked], [email-masked] (AToMib)
Date: Sun, 5 May 1996 20:38:20 -0400 (EDT)

Al Plante writes:
+--------
|For the work I'm doing, I'd like to see the following ANSI 
|T1.231-1993 features added to the SONET MIB.  I'd be happy
|if these were implemented as required parameters, but others
|may want them optional.
|
|1.  Thresholding and Alerting (CV, ES, SES, UAS)
+-------
I would suggest this should not be done in the MIB but rather
with a general purpose mechanism (e.g. at least one vendor uses
the mechanism specified in RFC 1451).

+---------
| ...
|4.  Current, previous, and recent 24 hour interval counts 
+--------
Certainly having the total tables would be consistent with the
Ds1 and Ds3 MIBs...

+---------
|Note that there are probably others who need much more from
|ANSI T1.231.  
+---------
And hopefullly those folk, based on their implementation experience
will be able to provide a set of extensions that cover off what they
feel is missing.

Regards,
-james
____________________________________________________________________________
James W. Watt,     [email-masked]                   Ph: +1 613 591-3600
Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680

Subject: Re: Fwd: Ds1/Ds3 MIB is not T1.231 compliant
From: James Watt <[email-masked]>
To: [email-masked] (Kaj Tesink)
Cc: [email-masked], [email-masked], [email-masked] (Dave Fowler), [email-masked] (AToMib)
Date: Sun, 5 May 1996 20:40:33 -0400 (EDT)

Kaj Tesink writes:
+----------
|>     4.  In the SONET MIB also have the IntervalValidData field.  
|
|oops, good point - that is an oversight i guess.
|can someone remind me why we had this object instead of
|relying on noSuch?
+--------
My recollection is that this tells you that your request had the right
number in it but the agent just doesn't have the data instead of
having the if# wrong or the interval or something.  It is cheap,
easy and you probably already have the bit inside so why not make
life easier for the management application.

Regards,
-james

____________________________________________________________________________
James W. Watt,     [email-masked]                   Ph: +1 613 591-3600
Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680

Subject: Re: Specific needs from ANSI 231 -> SONET MIB
From: [email-masked] (C. M. Heard/VVNET, Inc.)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Date: Sun, 5 May 1996 20:22:23 -0700

James Watt writes:
>
> Al Plante writes:
> +--------
> |For the work I'm doing, I'd like to see the following ANSI
> |T1.231-1993 features added to the SONET MIB.  I'd be happy
> |if these were implemented as required parameters, but others
> |may want them optional.
>
[ ... ]
>
> +---------
> | ...
> |4.  Current, previous, and recent 24 hour interval counts
> +--------
> Certainly having the total tables would be consistent with the
> Ds1 and Ds3 MIBs...

Note that the current and previous 24 hour interval counts cannot
be derived from a single snapshot of the counts that presently do
exist (i.e. current, previous, and recent 15-minute intervals).  A
manager would have to poll regularly in order to be able to derive
them.  This, in my view, adds some strength to the case for having them.

> +---------
> |Note that there are probably others who need much more from
> |ANSI T1.231.
> +---------

One such item required by T1.231 but not in the SONET MIB is a
suspect data flag (called an invalid data flag in T1.231) for
_every_ separate group of counters.  In order to satisfy this
particular T1.231 requirement a suspect data flag object would
need to be added to each of the following:

          SonetSectionCurrentEntry
          SonetSectionIntervalEntry
          SonetLineCurrentEntry
          SonetLineIntervalEntry
          SonetFarEndLineCurrentEntry
          SonetFarEndLineIntervalEntry
          SonetPathCurrentEntry
          SonetPathIntervalEntry
          SonetFarEndPathCurrentEntry
          SonetFarEndPathIntervalEntry
          SonetVTCurrentEntry
          SonetVTIntervalEntry
          SonetFarEndVTCurrentEntry
          SonetFarEndVTIntervalEntry

Note that such a flag is especially useful for the FarEnd groups,
since it is possible that one might be unable to collect far end
data owing to a near-end alarm condition (e.g., far end path data
cannot be collected while a near-end path LOP condition exists).
T1.231 says that in such cases the far end counts should not be
incremented but that the corresponding invalid data flag should
be raised.

I mention this item specifically because James mentioned a
related matter in an earlier message:

> Kaj Tesink writes:
> +----------
> |>     4.  In the SONET MIB also have the IntervalValidData field.
> |
> |oops, good point - that is an oversight i guess.
> |can someone remind me why we had this object instead of
> |relying on noSuch?
> +--------
> My recollection is that this tells you that your request had the right
> number in it but the agent just doesn't have the data instead of
> having the if# wrong or the interval or something.  It is cheap,
> easy and you probably already have the bit inside so why not make
> life easier for the management application.

I agree with this _but_ for the reasons I mentioned above I'd strongly
recommend that one provide as a minimum separate flags for the near end
and far end data.  It would be better still to provide a flag for each
counter group as T1.231 suggests.

Mike
--
C. M. Heard
VVNET, Inc.                           phone:  +1 408 247 9376
4040 Moorpark Ave. Suite 206          fax:    +1 408 244 3651
San Jose, CA 95117 USA                e-mail: [email-masked]

Subject: Re: Specific needs from ANSI 231 -> SONET MIB
From: James Watt <[email-masked]>
To: [email-masked] (C. M. Heard/VVNET Inc.)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Mon, 6 May 1996 01:25:58 -0400 (EDT)

C. M. Heard/VVNET, Inc. writes:
+--------
|I mention this item specifically because James mentioned a
|related matter in an earlier message:
|
|> Kaj Tesink writes:
|> +----------
|> |>     4.  In the SONET MIB also have the IntervalValidData field.
|> |
|> |oops, good point - that is an oversight i guess.
|> |can someone remind me why we had this object instead of
|> |relying on noSuch?
|> +--------
|> My recollection is that this tells you that your request had the right
|> number in it but the agent just doesn't have the data instead of
|> having the if# wrong or the interval or something.  It is cheap,
|> easy and you probably already have the bit inside so why not make
|> life easier for the management application.
|
|I agree with this _but_ for the reasons I mentioned above I'd strongly
|recommend that one provide as a minimum separate flags for the near end
|and far end data.  It would be better still to provide a flag for each
|counter group as T1.231 suggests.
+--------
I agree - I wasn't trying to suggest otherwise.  "agent doesn't have
the data" didn't want to imply a scope.

To re-iterate, if you're going to add the flag, there needs to be a 
flag for each "set" of counters which are arguably independent in 
collection.  Recall that I sit within 100 feet of someone who can rather
forcefully remind me of the issues involved in proxy agents :->

Regards,
-james

____________________________________________________________________________
James W. Watt,     [email-masked]                   Ph: +1 613 591-3600
Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680

Subject: sonetng mib
From: Kaj Tesink <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 25 Jul 96 15:49:06 EDT

howdy,

i'm revising the latest sonetng mib.
according to the list of issues identified in montreal the
following changes have been made:

- T1.231 alignment - will be addressed in a separate spec;
  no changes in sonetng mib

- 24 hout totalTable + previous 24 hour tables
  will be addressed in a separate spec;
  no changes in sonetng mib

- IntervalValidData flag
  has been added to all IntervalTables, but, conform
  to DS1/3 mibs not yet to the farEndTables. DO WE NEED THAT?

- CircuitIdentifier - keep as discussed in montreal

- ifGeneralGroup --> ifGeneralInformationGroup

- loopback issue is pending current list discussion

anything i forgot?

kaj

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/                                                                      _/
_/  Kaj Tesink                                                          _/
_/  Bellcore                                                            _/
_/  - Broadband Data Services & Consulting  vmail (908) 758-5254        _/
_/    331 Newman Springs Rd.                email [email-masked]   _/
_/    Red Bank, NJ 07701                  faxmail (908) 758-4177        _/
_/                                                                      _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Subject: Re: sonetng mib
From: [email-masked] (Charles M. Heard)
To: [email-masked]
Date: Thu, 25 Jul 1996 18:26:20 -0700

On Thu, 25 Jul 96 15:49:06 EDT Kaj Tesink <[email-masked]>
wrote:
> i'm revising the latest sonetng mib.
> according to the list of issues identified in montreal the
> following changes have been made:
> 
> - T1.231 alignment - will be addressed in a separate spec;
>   no changes in sonetng mib
>
> - 24 hout totalTable + previous 24 hour tables
>   will be addressed in a separate spec;
>   no changes in sonetng mib

Sounds good.

> - IntervalValidData flag
>   has been added to all IntervalTables, but, conform
>   to DS1/3 mibs not yet to the farEndTables. DO WE NEED THAT?

I believe that we do.  When a defect such as LOS is detected locally it
becomes impossible to accumulate far end statistics, and the far end
counts are not incremented during intervals in which such defects occur.
Because the far-end data from such intervals are suspect (biased on the
low side), we should have a flag that so indicates.

Here is what T1.231-1993 (Sec. 9.1.2.2, p. 46) says about this matter:

    "As a minumum, invalid data flags shall be provided for each
    period (15 minutes and day) for each direction (near end, far
    end) for each entity's group of parameters. For example:

            [ ... examples omitted ... ]

    Each parameter register should have an associated invalid data flag.

    This flag is set to indicate that data stored in that register is
    incomplete or otherwise invalid because:

      - the register contains data for a period greater or less than
      the nominal accumulation perion (see 9.3).  This occurs when a
      terminal is restarted or a register is reset in the middle of
      an accumulation period.  The invalid data flag is not set as a
      result of register saturation;

      - the terminal determines that there is missing data in an
      accumulation period.  For example, an incoming transmission
      failure or defect may prevent complete collection of far end
      performance reports." [emphasis added]               ^^^^^^^

> - CircuitIdentifier - keep as discussed in montreal
> 
> - ifGeneralGroup --> ifGeneralInformationGroup
> 
> - loopback issue is pending current list discussion
>
> anything i forgot?

I posted some typos & editorial suggestions to the list some time
ago ... are they on the editor's to-do list?  Let me know if you
want me to repost them.

> kaj

Mike
--
C. M. Heard
VVNET, Inc.                           phone:  +1 408 247 9376
4040 Moorpark Ave. Suite 206          fax:    +1 408 244 3651
San Jose, CA 95117 USA                e-mail: [email-masked]
stty -echo; cat>/dev/null; stty echo

Subject: Re: sonetng mib
From: Kaj Tesink <[email-masked]>
To: [email-masked] (Charles M. Heard), [email-masked]
Date: Mon, 29 Jul 96 12:39:24 EDT

At 06:26 PM 7/25/96 -0700, Charles M. Heard wrote:
>On Thu, 25 Jul 96 15:49:06 EDT Kaj Tesink <[email-masked]>
>wrote:
>> i'm revising the latest sonetng mib.
>> according to the list of issues identified in montreal the
>> following changes have been made:
>> 
>> - T1.231 alignment - will be addressed in a separate spec;
>>   no changes in sonetng mib
>>
>> - 24 hout totalTable + previous 24 hour tables
>>   will be addressed in a separate spec;
>>   no changes in sonetng mib
>
>Sounds good.
>
>> - IntervalValidData flag
>>   has been added to all IntervalTables, but, conform
>>   to DS1/3 mibs not yet to the farEndTables. DO WE NEED THAT?
>
>I believe that we do.  When a defect such as LOS is detected locally it
>becomes impossible to accumulate far end statistics, and the far end
>counts are not incremented during intervals in which such defects occur.
>Because the far-end data from such intervals are suspect (biased on the
>low side), we should have a flag that so indicates.

makes sense, so i included this flag in the far end tables as well.

>
>Here is what T1.231-1993 (Sec. 9.1.2.2, p. 46) says about this matter:
>
>    "As a minumum, invalid data flags shall be provided for each
>    period (15 minutes and day) for each direction (near end, far
>    end) for each entity's group of parameters. For example:
>
>            [ ... examples omitted ... ]
>
>    Each parameter register should have an associated invalid data flag.
>
>    This flag is set to indicate that data stored in that register is
>    incomplete or otherwise invalid because:
>
>      - the register contains data for a period greater or less than
>      the nominal accumulation perion (see 9.3).  This occurs when a
>      terminal is restarted or a register is reset in the middle of
>      an accumulation period.  The invalid data flag is not set as a
>      result of register saturation;
>
>      - the terminal determines that there is missing data in an
>      accumulation period.  For example, an incoming transmission
>      failure or defect may prevent complete collection of far end
>      performance reports." [emphasis added]               ^^^^^^^
>
>> - CircuitIdentifier - keep as discussed in montreal
>> 
>> - ifGeneralGroup --> ifGeneralInformationGroup
>> 
>> - loopback issue is pending current list discussion
>>
>> anything i forgot?
>
>I posted some typos & editorial suggestions to the list some time
>ago ... are they on the editor's to-do list?  Let me know if you
>want me to repost them.

i included all of them already

>
>> kaj
>
>Mike
>--
>C. M. Heard
>VVNET, Inc.                           phone:  +1 408 247 9376
>4040 Moorpark Ave. Suite 206          fax:    +1 408 244 3651
>San Jose, CA 95117 USA                e-mail: [email-masked]
>stty -echo; cat>/dev/null; stty echo
>
>
>
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/                                                                      _/
_/  Kaj Tesink                                                          _/
_/  Bellcore                                                            _/
_/  - Broadband Data Services & Consulting  vmail (908) 758-5254        _/
_/    331 Newman Springs Rd.                email [email-masked]   _/
_/    Red Bank, NJ 07701                  faxmail (908) 758-4177        _/
_/                                                                      _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/