Subject: split ifmib rfc

From: Ted Brunner <[email-masked]>
Date: Tue, 09 Jun 1998 09:48:51 -0700

Hello again-

> > First choice:
> > -split the document as follows,
> > -remove the ifStack table from the current internet draft,
> > -the module name ifMIB remains unchanged,
> > -this edited text moves forward to draft standard.
> > -create a second internet draft with the ifStack table,
> > -add the inverse stack table,
> > -this new text moves forward to proposed standard.

There have been a few comments about splitting out
the ifStack portion of the ifMib, and adding a reverse
Stack.  All positive.

So I have requested of the Editor that he make it be so.
When complete, the rest of the ifMib will be submitted to the IESG
for consideration as "draft standard", and the ifStack portion
as "proposed standard."

Ted Brunner		Video and Networking Division
			Tektronix
			MS 50-490
[email-masked]	14150 SW Karl Braun
503.627.1317		Beaverton OR 97005

---

From: Gary Hanson <[email-masked]>
Date: Tue, 9 Jun 1998 10:48:42 -0700 (PDT)

Ted,

Thanks for the update.

With the splitting of ifStackTable out to a separate MIB document,
to be rolled at the proposed standard state, I think it would be a
good idea to reconsider the legality of changing (or should I say,
clarifying) the SYNTAX of the INDEX objects of the ifStackTable from
Integer32 to InterfaceIndexOrZero.

Note that during the evolution from RFC 1213 to RFC 1573, the SYNTAX
of ifIndex itself was changed from INTEGER to InterfaceIndex, which 
in RFC 1573 was simply an Integer32.  This was done, presumably, to
take advantage of the new textual convention concept.

Later, in RFC 2233, the InterfaceIndex textual convention's SYNTAX
was sub-typed, from a Integer32 to Integer32 (1..2147483647), and a
new InterfaceIndexOrZero textual convention was added with the range
Integer32 (0..2147483647).  This second change was done, presumably, 
to clarify that negative values are NEVER acceptable, and that zero
values are SOMETIMES acceptable, depending on the semantics of the
individual objects.

I contend that changing the SYNTAX of INDEX objects from Integer32
to InterfaceIndexOrZero, although technically disallowed by RFC
1902, should be considered just as desirable as those previous
changes, and should be given special dispensation, especially given
that it clarifies how the objects are to be used, that no (correct)
agent implementations are likely to be adversely affected.

Comments?

By the way, would the new MIB be called "IF-STACK-MIB" with a module
name of "ifStackMIB"?  And would the new inverse stack table be
called "ifInverseStackTable" and its attribute descriptors each 
start with "ifInverseStack"?  Those would be my suggestions....

Regards,
Gary

---

From: "Brian O'Keefe" <[email-masked]>
Date: Tue, 09 Jun 1998 13:09:58 -0600

> > for consideration as "draft standard", and the ifStack portion

Is there any reason why the existing ifStackTable is not
ready to move to draft?  Is the only reason it is being
held back because it is desirable to co-locate that table
with the proposed new inverse stack table in the same RFC
(and MIB module)?

What does the proposed inverse stack table look like?
Same as ifStackTable except the index objects are reversed
(e.g., ifLowerLayer then ifHigherLayer)?

The existing ifStackTable is of great benefit as interface
layering has taken off... particularly w.r.t. the more WAN
oriented interfaces.  I'd sure like to see ifStackTable
advanced and more widely deployed ASAP.

bok

---

From: Gary Hanson <[email-masked]>
Date: Tue, 9 Jun 1998 12:28:14 -0700 (PDT)

Hi Brian,

On Tue, 9 Jun 1998, Brian O'Keefe wrote:

> [...]

One reason to move ifStackTable to a separate RFC was to allow "open
systems" that cannot implement the ifStackTable to be considered
fully compliant with the IF-MIB even if they did not support the
ifStackTable.  This was the "administrative shuffle" option, and was
part of the first choice, which presumably the ADs favored over the
second choice of not splitting the document.

> (e.g., ifLowerLayer then ifHigherLayer)?

You got it.

> advanced and more widely deployed ASAP.

I think the ifStackTable will be deployed more due its usefulness
than on whether it is part of a proposed or draft standard document. 
Ditto for its inverse variant.

I would think that the only sensitive reason for insisting on
keeping it in the existing document (i.e., choice two), would be if
other documents depend on the ifStackTable and THEY are supposed to
be evolving to draft standard.  Again, I am not sure how important
it is that any given MIB document get to draft standard or full
standard in a big hurry, since who's to say that we have all of the
implementation experience that is likely to come in?

Regards,
Gary

---

From: "Brian O'Keefe" <[email-masked]>
Date: Tue, 09 Jun 1998 13:44:33 -0600

Gary,

Thanks for the clarification.  I'm ok with the split mib.
I'd just like to encourage agent vendors to implement the
ifStackTable where possible and as soon as possible.  It'll
sure help some work I'm doing on the manager side!

bok

---

From: "Ted Brunner 503.627.1317" <[email-masked]>
Date: Tue, 09 Jun 1998 14:24:48 -0700

> with the proposed new inverse stack table in the same RFC

Yes.

It is being split out to have a separate RFC number.
So then systems (eg unix boxes) which can implement
most of the ifMib but not ifStackTable can still
be compliant with much of what we now call the ifMib.

It is being held back (recycle at proposed) because
of co-location with the new reverse-of-the-ifStackTable.
(Name to be selected by the Editor.)

And when I can think of a good rational for a
never-seen-before table to enter at draft standard,
- after all it does has a familar look, and there
are no new objects - I will suggest it do so to the IESG.
But I don't want to mislead you into expecting this to
be successful.  I'm not counting on it.

> (e.g., ifLowerLayer then ifHigherLayer)?

That is it.

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 22 Jun 1998 23:31:52 -0700 (PDT)

I'm in the process of doing the edits, and I find there's a potential
problem.  If we remove all the ifStackXxxx definitions from the current
IF-MIB, but keep the module name IF-MIB unchanged, then it will break
any other MIB modules which IMPORT any of these ifStackXxxx definitions
from IF-MIB.

The alternative of renaming IF-MIB to, say, IF-MIB2, is better, but is
also not without difficulties, since it causes the same issue that 
currently exists with MIB-II, of having duplicate definitions in
multiple (differently-named) MIB modules.

Comments?

Keith.

---

From: Gary Hanson <[email-masked]>
Date: Tue, 23 Jun 1998 08:33:49 -0700 (PDT)

Keith,

> any other MIB modules which IMPORT any of these ifStackXxxx definitions

This sounds like a real problem rather than a potential problem, and
it seems to me that it stems from the inherent ambiguity of an
IMPORTS macro's module name when the module name has been used for
multiple versions of the same MIB.  Unless we wish to have users
hand-edit their standard MIBs before compiling them, it seems
prudent to recognize that removing objects from a MIB is unsafe, for
the reason you have identified.

Another related problem is that any changes to the conformance
statements (such as to make the ifStackXxxx objects optional, or to
fully remove them from the IF-MIB) would necessitate new descriptors
for the compliance definitions.  This is not as severe a problem,
since it does not break the MIBs themselves but only the
documentation accompanying the MIBs that identify which IF-MIB
object groups are required to be supported for a given ifType. 
Perhaps this is not a real problem, but only reveals the vintage of
the MIB document (e.g., documents that refer to the ifGeneralGroup
and ifStackGroup are obviously of RFC 1573 vintage, whereas
documents that refer to the ifGeneralInformationGroup,
ifStackGroup2, and ifCounterDiscontinuityGroup are obviously of RFC
2233 vintage.  However, it is an ongoing educational struggle to
convince MIB document editors to update the cross-references to the
groups.

> multiple (differently-named) MIB modules.

Are these the only two alternatives?

Perhaps its time to reiterate the goals of the changes.  My last
understanding (please correct me if I'm wrong) was:
- Fix typos identified in RFC 2233
- Make ifStackXxxx objects "optional" (in some well-defined cases)
- Add inverse stack table

It seems that another possibility would be to make all the changes
in a single IF-MIB successor to RFC 2233, and roll it at proposed
again.  (Is there a real hurry to get to draft and full standard for
this and other dependent MIB documents?)

Regards,
Gary

---

From: "Brian O'Keefe" <[email-masked]>
Date: Tue, 23 Jun 1998 11:43:37 -0600

> multiple (differently-named) MIB modules.

Regardless of approach, if the end result is that ifStackTable
is to become optional instead of mandatory, then the ifCompliance
MODULE-COMPLIANCE statement needs to be revised to omit
ifStackGroup from the list of MANDATORY-GROUPS.  What affect
does this have on the IF-MIB standards track disposition?

Assuming we can move something from mandatory to optional and
still advance the status, then I'd recommend the following:

. Leave the ifStackTable definitions in IF-MIB (as in RFC2233)
. Change ifCompliance or write a new one to omit ifStackGroup
  as a mandatory group
. Republish as draft or full, as appropriate.

. Write a new mib module IF-MIBx5 (In think that's the number
  of interface mib related extensions that have occurred since
  the days of MIB-I) that defines the new ifInverseStackTable
  and let that MIB embark on its standards-track journey...

A completely different approach would be:

. Leave ifStackTable as an IF-MIB mandatory group.
  Those systems that have layered interfaces but cannot
  support the ifStackTable simply are not 100% conformant.
  Reality is that for systems with layered interfcases,
  this information is vital to effective management.

. Don't add the ifInverseStackTable at all.  Is it really
  necessary?  I see that it makes the "what's the higher layer
  interface for a given interface"
  query easier on the manager (and I'd use it if it existed), 
  but that's not been motivation in the past.  Plus,
  I still have to write my application to deal with existing
  cases where only the ifStackTable is present.

I could rally behind either approach; but I simply don't see
any advantages to moving ifStackTable out into a separate
MIB module.

bok

---

From: sdurham <[email-masked]>
Date: Tue, 23 Jun 1998 14:58:51 -0700

while i agree with most of bok's comments, i disagree with :

>   necessary?  

In draft-ietf-trunkmib-ds0-mib-06.txt, there is an added object who's
sole existance seems to be because we don't have an ifInverseStackTable.
Would it not be preferrable to centralize this kind of information
rather than leaving it up to each media mib author to determine if it is
necessary or not? And isn' there precedence set for something like this
in rmon already with the two versions of the matrix table (one indexed
by source/destination mac, the other by destination/source mac)?

(in example below, the ds0Bundle sits on the DS0, and this object is in
a table for the DS0's):

          dsx0Ds0BundleMappedIfIndex OBJECT-TYPE
               SYNTAX InterfaceIndexOrZero
               MAX-ACCESS  read-only
               STATUS  current
               DESCRIPTION
                      "This object indicates the ifIndex value assigned
                      by the agent for the ds0Bundle(82) ifEntry to
                      which the given ds0(81) ifEntry may belong.

                      If the given ds0(81) ifEntry does not belong
to 		      any ds0Bundle(82) ifEntry, then this object has a
                      value of zero.

                      While this object provides information that can
                      also be found in the ifStackTable, it provides
                      this same information with a single table lookup,
                      rather than by walking the ifStackTable to find
                      the possibly non-existent ds0Bundle(82) ifEntry
                      that may be stacked above the given ds0(81)
                      ifTable entry."
              ::= { dsx0ConfigEntry 8 }

---

From: Keith McCloghrie <[email-masked]>
Date: Tue, 23 Jun 1998 11:58:56 -0700 (PDT)

> does this have on the IF-MIB standards track disposition?

I'm sure that one can completely omit something and progress in the
standards track, and I don't see how downgrading from mandatory to
optional is different.

>   and let that MIB embark on its standards-track journey...
 
I agree.

Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Tue, 23 Jun 1998 11:55:35 -0700 (PDT)

> convince MIB document editors to update the cross-references to the

I think this is the price of progress.

> this and other dependent MIB documents?)

Rather than this, I suggest leaving the ifStackTable where it is,
putting the inverted stack table in a new document, and progressing the
existing document to Draft, and yes, I believe that recycling at
Proposed would hold up the advancement of other MIBs which cannot
progress to Draft until the Interfaces Group MIB does.

My understanding of the desire to move the ifStackTable to the new
document was:

- having all the ifStack stuff in one MIB module, which is desirable,
  but not necessary, and
- presuming that there will be vendors who will not implement the
  ifStackTable allowing such a vendor to be able to say that they
  support RFC-NNNN, but not RFC-MMMM.

Can we live without these ?

Keith.

---

From: Dave Thaler <[email-masked]>
Date: Tue, 23 Jun 1998 13:41:16 -0400 (EDT)

> any other MIB modules which IMPORT any of these ifStackXxxx definitions

Someone said at the meeting that there weren't any known MIB modules
which import ifStackXxxx.  Do we have some examples of such mibs now?

-Dave

---

From: Keith McCloghrie <[email-masked]>
Date: Tue, 23 Jun 1998 11:40:47 -0700 (PDT)

> which import ifStackXxxx.  Do we have some examples of such mibs now?
 
That's why I described it as a "potential" problem.  While we can check
whether any standard MIBs import ifStackXxxx, it's not feasible to do
so for Enterprise MIBs.  I can think of two reasons why an Enterprise
would IMPORT an ifStackXxxx definition:

- to AUGMENT the ifStackTable - this is probably unlikely.
- within an AGENT CAPABILITIES statement - this is quite likely.

Keith.