Subject: Non-member submission from ["Gregory Waines" <[email-masked]>]

From: "Ted Brunner 503.627.1317" <[email-masked]>
Date: Wed, 10 Jun 1998 17:11:02 -0700

------- Forwarded Message

Date: 10 Jun 1998 08:41 EDT
Sender: "Gregory Waines" <[email-masked]>
To: [email-masked]
From: "Gregory Waines" <[email-masked]>
Subject: Re: split ifmib rfc

In message "Re: split ifmib rfc", [email-masked]' writes:

>
>Hi Brian,
>
>On Tue, 9 Jun 1998, Brian O'Keefe wrote:
>
>> [...]
>> 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)?
>
>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.  

    Shouldn't the ifStackTable be mandatory if the ifmib implementation
    chooses to put 'logical' (as opposed to just physical) interfaces
    in the iftable.
    Otherwise, you get a bunch of rows in the iftable, that are related,
    except you cannot sort out the relationship.

    greg.

>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.
>
>> What does the proposed inverse stack table look like?
>> Same as ifStackTable except the index objects are reversed
>> (e.g., ifLowerLayer then ifHigherLayer)?
>
>You got it.
>
>> 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.
>
>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?
>
>> bok
>
>Regards,
>Gary
>
>                   

------- End of Forwarded Message

---

From: sdurham <[email-masked]>
Date: Thu, 11 Jun 1998 21:04:20 -0700

>     except you cannot sort out the relationship.

I would be inclined to agree.  If the ifStackTable is not mandatory for
implementations supporting sublayering, how "less manageable" does this
make sublayers?  You can manage the layers independently, but you can
not determine inter-layer relationships. You also can not manage the
inter-relationships for other mibs which depend on ifIndex. Imagine the
full management solution to an atm interface.  You need the ifmib, Sonet
or DS3 mibs, atm mib(s) aal5 information, and potentially some other
layers ontop of that.  How do you know how the atm mib information
relates to the DS3 information if you don't know which if atm sublayer
is sitting on which DS3 layer?

Sandra

---

From: "Brian O'Keefe" <[email-masked]>
Date: Fri, 12 Jun 1998 10:36:26 -0600

I would also concur with these opinions.
How the docs are structure is less a concern for me;
but if an implementation uses interface sub-layering,
then, we (as management applications) really need the
ifStackTable type relationships supported.

bok

---

From: sdurham <[email-masked]>
Date: Fri, 12 Jun 1998 09:49:36 -0700

> My understanding here is that we're loosening the requirement in the face
> of reality rather than for good management reasons.
> 
> Open systems like Unix may find it impossible to implement the
> ifStackTable, so we're making it not required, even though it is necessary
> for seeing how things are strung together.

I don't follow  this logic. What is the benefit of saying a system like
UNIX is Compliant to the IFMIB, if it is not able to be managed
properly? It becomes a marketing checkoff item, instead of a management
tool. In my warped little world, if a system supports subinterfaces, and
doesn't support the ifStackTable, then the system does not provide the
appropriate management solution, and should not be compliant.  They can
maintain compliance with rfc1213, and have support for rfc2233 without
claiming compliance to rfc2233.

If these open systems do not support sublayers, then they are compliant
w/o the ifStackTable. But if they do support sublayers, and they don't
have the ifStackTable, they provide only a partial management solution.

Sandra