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