Re: FWD: Restart ifmib WG?

At 09:56 AM 10/7/2002 -0700, C. M. Heard wrote:
>[ Followups to [email protected] please ]
>>....
>
>> 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.

I agree any new objects should be in a separate module in
a separate RFC



>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.

I don't think the MAU-MIB objects are widely implemented.
Mike's proposal seems to address the precedence issue.



>Mike

Andy