Subject: Re: split ifmib rfc

From: Ted Brunner <[email-masked]>
Date: Mon, 06 Jul 1998 16:12:40 -0700

Hello-

It has been two weeks since the last message on this thread.
So it is time to call for closure on the topic.

As things stand, we had thought we agreed in LA to split the if-mib
so that the stack table and inverse stack table might be one separate RFC,
and raise the other for promotion to "draft standard".
But problems arise in splitting the IFMIB module.

An alternative was suggested on the list.  The message is included below.
That alternative is (I think) equivalent to the second choice
the working group came up with in LA.  That second choice is
also included below.

I have heard no disagreement to the alternative/second choice.
It sounds to me like we are all in agreement.
Unless someone quickly and convincingly objects,
I think we have come up with an action plan for our editor.

Going, going .....

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

------------
Forwarded message:
> From: Keith McCloghrie <kzm>
> Message-Id: <[email-masked]>
> Subject: Re: split ifmib rfc
> To: [email-masked]
> Date: Tue, 23 Jun 1998 11:58:56 -0700 (PDT)
> Cc: [email-masked], [email-masked], [email-masked],
>         [email-masked]
> 
> > 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?
> 
> 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.
> 
> > 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...
>  
> I agree.
> 
> Keith.
> 
---------------
snippet taken from minutes of the IFMIB meeting in LA:

> Second choice:
> -don't split the document.
> -in the compliance module ifCompliance2, object ifStackStatus,
>   change the MIN-ACCESS to not-accessible,
> -edit the compliance/conformance appropriately,
> -the module name ifMIB remains unchanged,
> -this edited text moves forward to draft standard.
> -create a second internet draft with the inverse stack table,
> -this new text moves forward to proposed standard.