Subject: Proposed text for xyzValidIntervals/xyzInvalidIntervals

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Thu, 11 Jun 1998 23:30:06 -0700 (PDT)

On Fri, 05 Jun 1998 Kaj Tesink wrote:
[ ... ]
> i attach a version [of PerfHist-TC-MIB] that i was working on;
> obviously this version needs work given the
> recent debate and some minor comments i received.
>
> i'll be off-line until july 5
> i'm making the bold request here for some text that would
> resolve the debate?

This note is an attempt to answer that request.  Since Kaj's post
went only to the atommib list and not the trunk-mib list, I am going
to reference all proposed text to the drafts that are currently
available in the ftp://ftp.ietf.org/internet-drafts directory, viz:

    draft-ietf-atommib-perfhistTC-01.txt
    draft-ietf-atommib-sonetng-02.txt
    draft-ietf-trunkmib-ds1-mib-08.txt
    draft-ietf-trunkmib-ds3-mib-08.txt

The "recent debate" to which Kaj refers is the discussion that has
taken place on the atommib and trunk-mib lists in the past two weeks
concerning the description of xyzValidIntervals and xyzInvalidIntervals.
It is obvious that the text that is presently in the above-mentioned
drafts confuses some of us and is in need of editorial clarification.
Some of you would like to see deeper changes than that, but let me
remind you what Jeff Johnson pointed out on 03 Jun 1998:

> 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.

For this reason -- and avoid delaying the three trunk mibs any more than
the minimum necessary -- I wish to propose _nothing more_ than editorial
clarifications to the description clauses for these for these objects.

Also, this note addresses _only_ the xyzValidIntervals and
xyzInvalidIntervals objects.  I will address problems in the
descriptions of the xyzValidData objects in a subsequent memo.

Here is my list of the ambiguities, along with proposed fixes.

1.)  (From Jeff Johnson):  it is not clear from the description of
xyzInvalidIntervals that the value of xyzInvalidIntervals should be
zero (rather than the number of intervals supported) when an agent
first starts up.

Proposed fix (from David Fowler):  clarify that the number of invalid
intervals must be less than the number of valid intervals and that it
is intended for the proxy situation.

2.) (From Rajul Shah):  the description of sonetMediumValidIntervals
in RFC 1595 suggests that an agent is _not allowed_ to end its 15-minute
data collection intervals at 1/4 hour wall-clock boundaries, as required
by T1.231.  At issue are the words

	The value of this object will be n unless the device was
	brought online within the last (nx15) minutes, in which case
	the value will be the number of complete 15 minute intervals
	the device has been online.

Similar words appear in the descriptions of the various xyzValidIntervals
objects in all of the drafts.

Proposed fix:  clarify that if the device has come online within the
last (nx15) minutes the value of xyzValidIntervals is equal to the
number of past intervals for which the agent has collected at least
some valid data.  See also issue (3) below for how to handle an
incomplete initial interval.

[NOTE:  the trunk mib editors may wish to also consider adding some
text in the narrative part to the effect that an agent MAY choose
to align 15-minute data collection interval boundaries with 1/4
hour wall clock boundaries, but is not obliged to do so.  I believe
that this is consistent with the intent of the original RFCs, but I
could find no discussion of the issue in the atommib e-mail archives.]

3.)  (From Rajesh Abbi):  The present definition of 'xyzInvalidIntervals'
identifies an 'invalid' interval as one in which "no valid data is
available".  What about intervals in which 'some' valid data is available?

Proposed fix:  clarify that the words "valid data" in the description
of xyzValidIntervals mean "at least some valid data", and (in the
trunk mibs) clarify that the xyzIntervalValidData objects are set to
false(2) when the data the corresponding interval is incomplete (a
forthcoming memo will discuss proposals to fix the xyzIntervalValidData
description clause).

TEXT OF PROPOSED CHANGES:

In draft-ietf-atommib-perfhistTC-01.txt change

current>       -- xyzValidIntervals OBJECT-TYPE
current>       --      SYNTAX  INTEGER (0..<n>)
current>       --            -- 1 =< n =< 96
current>       --       MAX-ACCESS  read-only
current>       --       STATUS  current
current>       --       DESCRIPTION
current>       --       "The number of previous near end intervals
current>       --       for which valid data was collected.  The value
current>       --       will be <n> unless the interface was brought
current>       --       online within the last 24 hours, in which case
current>       --       the value will be the number of complete 15
current>       --       minute near end intervals since the interface
current>       --       has been online.  In the case where the agent
current>       --       is a proxy, it is possible that some intervals
current>       --       are unavailable.  In this case, this
current>       --       interval is the maximum interval number for
current>       --       which valid data is available."
current>       --       ::= { xxx }

current>       -- xyzInvalidIntervals OBJECT-TYPE
current>       --     SYNTAX  INTEGER (0..<n>)
current>       --     MAX-ACCESS  read-only
current>       --     STATUS  current
current>       --     DESCRIPTION
current>       --       "The number of intervals for which no valid
current>       --       data is available."
current>       --       ::= { xxx }

to

proposed>      -- xyzValidIntervals OBJECT-TYPE
proposed>      --       SYNTAX  INTEGER (0..<n>)
proposed>      --               1 =< n =< 96
proposed>      --       MAX-ACCESS  read-only
proposed>      --       STATUS  current
proposed>      --       DESCRIPTION
proposed>      --       "The number of previous 15-minute intervals for
proposed>      --       which at least some valid data was collected.
proposed>      --       The value will be <n> unless the interface was
proposed>      --       brought online within the last (<n>*15) minutes,
proposed>      --       in which case the value will be the number of 
proposed>      --       past intervals for which the agent has at least
proposed>      --       some valid data.  In the case where the agent
proposed>      --       is a proxy it is possible that some intervals
proposed>      --       are unavailable.  In this case, the value of
proposed>      --       this object is the maximum interval number for
proposed>      --       which at least some some valid data is available."
proposed>      --       ::= { xxx }

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 }

                        =0=

In draft-ietf-atommib-sonetng-02.txt change

current>  sonetMediumValidIntervals OBJECT-TYPE
current>      SYNTAX  Integer32 (0..96)
current>      MAX-ACCESS  read-only
current>      STATUS  current
current>      DESCRIPTION
current>         "The number of previous intervals for which valid
current>         data has been stored.  A SONET interface must be
current>         capable of supporting at least n intervals.
current>         The minimum value of n is 4.
current>         The default of n is 32.
current>         The maximum value of n is 96.
current>         The value of this object will be n unless
current>         the device was brought online within the last
current>         (nx15) minutes, in which case the value will be the
current>         number of complete 15 minute intervals the device has
current>         been online. In the case where the agent
current>         is a proxy, it is possible that some intervals
current>         are unavailable.  In this case, this
current>         interval is the maximum interval number for
current>         which valid data is available."
current>      ::= { sonetMediumEntry 3 }

to

proposed> sonetMediumValidIntervals OBJECT-TYPE
proposed>     SYNTAX  Integer32 (0..96)
proposed>     MAX-ACCESS  read-only
proposed>     STATUS  current
proposed>     DESCRIPTION
proposed>        "The number of previous 15-minute intervals for
proposed>        which at least some valid data has been stored.
proposed>        A SONET interface must be capable of supporting
proposed>        at least n intervals.
proposed>        The minimum value of n is 4.
proposed>        The default of n is 32.
proposed>        The maximum value of n is 96.
proposed>        The value of this object will be n unless the
proposed>        device was brought online within the last (nx15)
proposed>        minutes, in which case the value will be the
proposed>        number of previous intervals for which the
proposed>        device has at least some data. In the case where
proposed>        the agent is a proxy, it is possible that some
proposed>        intervals are unavailable.  In this case, this
proposed>        interval is the maximum interval number for
proposed>        which at least some valid data is available."

and change

current>  sonetMediumInvalidIntervals OBJECT-TYPE
current>      SYNTAX  Integer32 (0..96)
current>      MAX-ACCESS  read-only
current>      STATUS  current
current>      DESCRIPTION
current>         "The number of intervals for which no valid
current>          data is available. This includes intervals
current>          of which valid data has been lost, e.g., due
current>          to restart of the agent."
current>      ::= { sonetMediumEntry 7 }

to

proposed> sonetMediumInvalidIntervals OBJECT-TYPE
proposed>     SYNTAX  Integer32 (0..96)
proposed>     MAX-ACCESS  read-only
proposed>     STATUS  current
proposed>     DESCRIPTION
proposed>        "The number of intervals in the range from 1
proposed>         to sonetMediumValidIntervals for which no
proposed>         valid data is available.  This object will
proposed>         typically be zero except in proxy situations."
proposed>     ::= { sonetMediumEntry 7 }

                        =0=

In draft-ietf-trunkmib-ds1-mib-08.txt change

current>  dsx1ValidIntervals OBJECT-TYPE
current>       SYNTAX  INTEGER (0..96)
current>       MAX-ACCESS  read-only
current>       STATUS  current
current>       DESCRIPTION
current>              "The number of previous near end intervals for
current>              which valid data was collected.  The value will be
current>              96 unless the interface was brought online within
current>              the last 24 hours, in which case the value will be
current>              the number of complete 15 minute near end
current>              intervals since the interface has been online.  In
current>              the case where the agent is a proxy, it is
current>              possible that some intervals are unavailable.  In
current>              this case, this interval is the maximum interval
current>              number for which valid data is available."
current>       ::= { dsx1ConfigEntry 4 }

to

proposed> dsx1ValidIntervals OBJECT-TYPE
proposed>      SYNTAX  INTEGER (0..96)
proposed>      MAX-ACCESS  read-only
proposed>      STATUS  current
proposed>      DESCRIPTION
proposed>             "The number of previous 15-minute intervals for
proposed>             which at least some valid data was collected.
proposed>             The value will be 96 unless the interface was
proposed>             brought online within the last 24 hours, in
proposed>             which case the value will be the number of past
proposed>             intervals for which the agent has at least some
proposed>             valid data.  In the case where the agent is a
proposed>             proxy, it is possible that some intervals are
proposed>             unavailable.  In this case, the value of this
proposed>             object is the maximum interval number for which
proposed>             which at least some some valid data is available."
proposed>      ::= { dsx1ConfigEntry 4 }

and change

current>  dsx1InvalidIntervals OBJECT-TYPE
current>       SYNTAX  INTEGER (0..96)
current>       MAX-ACCESS  read-only
current>       STATUS  current
current>       DESCRIPTION
current>              "The number of intervals for which no valid data
current>              is available."
current>       ::= { dsx1ConfigEntry 14 }

to

proposed> dsx1InvalidIntervals OBJECT-TYPE
proposed>      SYNTAX  INTEGER (0..96)
proposed>      MAX-ACCESS  read-only
proposed>      STATUS  current
proposed>      DESCRIPTION
proposed>            "The number of intervals in the range from 1
proposed>             to dsx1ValidIntervals for which no valid data
proposed>             is available.  This object will typically be
proposed>             zero except in proxy situations."
proposed>      ::= { dsx1ConfigEntry 14 }

                        =0=

In draft-ietf-trunkmib-ds3-mib-08.txt change

current>  dsx3ValidIntervals OBJECT-TYPE
current>       SYNTAX  INTEGER (0..96)
current>       MAX-ACCESS  read-only
current>       STATUS  current
current>       DESCRIPTION
current>              "The number of previous near end intervals for
current>              which valid data was collected.  The value will be
current>              96 unless the interface was brought online within
current>              the last 24 hours, in which case the value will be
current>              the number of complete 15 minute near end
current>              intervals since the interface has been online.  In
current>              the case where the agent is a proxy, it is
current>              possible that some intervals are unavailable.  In
current>              this case, this interval is the maximum interval
current>              number for which valid data is available."
current>       ::= { dsx3ConfigEntry 4 }

to

proposed> dsx3ValidIntervals OBJECT-TYPE
proposed>      SYNTAX  INTEGER (0..96)
proposed>      MAX-ACCESS  read-only
proposed>      STATUS  current
proposed>      DESCRIPTION
proposed>             "The number of previous 15-minute intervals for
proposed>             which at least some valid data was collected.
proposed>             The value will be 96 unless the interface was
proposed>             brought online within the last 24 hours, in
proposed>             which case the value will be the number of past
proposed>             intervals for which the agent has at least some
proposed>             valid data.  In the case where the agent is a
proposed>             proxy, it is possible that some intervals are
proposed>             unavailable.  In this case, the value of this
proposed>             object is the maximum interval number for which
proposed>             which at least some some valid data is available."
proposed>      ::= { dsx3ConfigEntry 4 }

and change

current>  dsx3InvalidIntervals OBJECT-TYPE
current>       SYNTAX  INTEGER (0..96)
current>       MAX-ACCESS  read-only
current>       STATUS  current
current>       DESCRIPTION
current>              "The number of intervals for which no valid data
current>              is available."
current>       ::= { dsx3ConfigEntry 12 }

to

proposed> dsx3InvalidIntervals OBJECT-TYPE
proposed>      SYNTAX  INTEGER (0..96)
proposed>      MAX-ACCESS  read-only
proposed>      STATUS  current
proposed>      DESCRIPTION
proposed>            "The number of intervals in the range from 1
proposed>             to dsx3ValidIntervals for which no valid data
proposed>             is available.  This object will typically be
proposed>             zero except in proxy situations."
proposed>      ::= { dsx3ConfigEntry 12 }

What say the document editors, quality reviewers, and other WG members?

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

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Thu, 11 Jun 1998 23:30:06 -0700 (PDT)

to

                        =0=

to

and change

to

                        =0=

to

and change

to

                        =0=

to

and change

to

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

---

From: Rajesh Abbi <[email-masked]>
Date: Fri, 12 Jun 1998 10:28:07 -0400

Mike,

I have following comments on your proposal ...

> proposed>      --       which at least some some valid data is available."

I believe that this object 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.

> proposed>      --       be zero except in proxy situations."

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)
B) The entry is present, but all counters are set to '0' AND the
     'xyzIntervalValidData' flag is set to 'false'.

Note that is option (A) is used, the meaning of interval 'count' would
be different.  Option (A) would be preferable, but I know many SNMP
managers have problems dealing with 'missing' (noSuch) objects.

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'.

Rajesh

---

From: Rajesh Abbi <[email-masked]>
Date: Fri, 12 Jun 1998 10:28:07 -0400

Mike,

Rajesh

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Fri, 12 Jun 1998 12:09:15 -0700 (PDT)

[ ... ]
> 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:

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.

> A) The corresponding entry is NOT PRESENT in the table (ie: noSuch)

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

>      'xyzIntervalValidData' flag is set to 'false'.

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

[ ... ]
> ' 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?

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

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Fri, 12 Jun 1998 12:09:15 -0700 (PDT)

[ ... ]

[ ... ]

Here is a summary:

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

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

---

From: Gary Hanson <[email-masked]>
Date: Fri, 12 Jun 1998 13:58:13 -0700 (PDT)

Hi Mike,

> and corrections are invited if someone feels that I have

Note that xyzValidIntervals up through RFC 1406, RFC 1407, and RFC
1595 have never described proxy cases.  If the new text added in the
current drafts reflects fielded implementations, then it would still
be possible to change the definitions once more provided:
- (a) you can convince the implementors of existing fielded
      implementations to agree to the change (if you can identify
      who these implementors are)
- (b) you can convince the IESG and WG chairmen to allow the
      changes, in the best interests of future network management

If the new text only reflects SOME of the fielded implementations,
and if others match your modified interpretation, you have a better
case still (albeit one that would likely be considered late in
coming :-).

As you know, the xyzInvalidIntervals are likely to be less ingrained
in fielded implementations, since they are new in the current
drafts.  For those objects, at least, there would not be any issue
with having to deprecate them, since they don't "officially" exist
yet until the RFC is published (at least based on my interpretation
of how these things evolve).

> [...]

Gary

 ______
| ///  |       TM   Gary Hanson                [email-masked]
|   ADC|Kentrox     14375 NW Science Park Dr.  503-641-3321 (FAX)
|______|            Portland, Oregon  97229    800-733-5511 x6333

---

From: Gary Hanson <[email-masked]>
Date: Fri, 12 Jun 1998 13:58:13 -0700 (PDT)

Hi Mike,

Gary

 ______

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Fri, 12 Jun 1998 15:51:13 -0700 (PDT)

On Fri, 12 Jun 1998, Gary Hanson wrote:
[ ... ]
>       changes, in the best interests of future network management

I was trying vary hard to avoid that!

> case still (albeit one that would likely be considered late in

Let me make clear (if it's not already) that the _intent_ behind my
proposals was just to say more clearly what the current drafts were
intended to say.

> of how these things evolve).

I really hope that won't be necessary.

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

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Fri, 12 Jun 1998 15:51:13 -0700 (PDT)

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