RE: FWD: Restart ifmib WG?

Mike, were you guys not working on some MIB (I forget which one
it is) that needs ifmib to go to full std? So I would try very very
hard to get current mib to advance. If more work/changes is/are needed
then I'd prefer to do it in such a way that current MIB can advance.
That is of course assuming that we do not find any fatal flaws.

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:[email protected]]
> Sent: maandag 7 oktober 2002 18:56
> To: [email protected]
> Subject: Re: FWD: Restart ifmib WG?
> 
> 
> [ Followups to [email protected] please ]
> 
> At 01:36 PM 10/2/2002 -0400, Thomas Narten wrote:
> [ ... ]
> > The ifmib WG still exists on paper, but hasn't been active for some
> > time.
> > 
> > There are still (IMO) some important work items that would 
> be good to
> > get done. For example:
> > 
> >  - advance IF-MIB to full std
> >  - advance inverted stack table mib to DS
> > 
> > There might be some more possible items, but the above ones are
> > critical in the sense that there are other documents that can't
> > advance until the above takes place.
> [ ... ]
> > Are there other work items that should be considered?
> 
> On Thu, 3 Oct 2002, Andy Bierman replied:
> > bug fixes:
> > 
> >  - ifTableLastChange should be TimeStamp not TimeTicks
> >  - ifLastChange should be TimeStamp not TimeTicks
> >  - ifStackLastChange should be TimeStamp not TimeTicks
> 
> OK
> 
> > optional enhancements:
> > 
> >  - ifMtu needs a read-write version
> > 
> > the following objects may be available in a different MIB
> > for some media types:
> > 
> >  - ifSpeed needs a read-write version
> >  - ifHighSpeed needs a read-write version
> 
> If you add these new objects to the IF-MIB then it will have
> to recycle at proposed.  That would prevent any MIB modules
> that depend on the IF-MIB in a normative way -- and there
> are plenty of those -- from advancing past proposed standard.
> It might, therefore, be better to put these things into a
> supplemental IF MIB module.
> 
> 
> On Mon, 7 Oct 2002, Romascanu, Dan (Dan) wrote:
> > Hmmm. What happens now with those MIBs who already defined
> > their own objects, like the MAU MIB? It is very nice to fix
> > this problem now, in the 21st century, but we create a
> > compatibility problem, or at least a set of questions that
> > need to be asked. (will ifMauSpeed be deprecated, if not which
> > one takes precedence when their values are not consistent, etc.)
> 
> If the "extras" are defined in a supplemental IF MIB module,
> then one way to resolve these questions might be to require
> that applicability of the objects in the supplemental IF MIB be
> spelled out by each media-specific MIB module, in analogy with
> the requirements in Section 4 of RFC 2863.  The default, in the
> absence of any guidance in the media-specific MIB module, would
> be that the objects do not apply.  That would leave the meaning
> of existing media-specific MIBs that provide their own objects
> unchanged.
> 
> Mike
> 
>