Subject: RE: [Hubmib] IETF 50 HUBMIB Working Group Meeting Minutes

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 9 Apr 2001 23:10:49 +0200

From the minutes

>    The comment was made from the floor that in general we should tighten
>    up this text with respect to MUST/SHOULD.
>    
>    Action Item:  Get procedure from IANA for fixing the ifTypes mess.
>    The interface MIB does request that IANA deprecate these old ifType
>    values. 
> 
Can someone give me some more detail as to what we want from IANA?
I guess I was either not in the meeting room at this point, or I was too
busy
typing on my laptop.

Bert

_______________________________________________
Hubmib mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/hubmib

---

From: John Flick <[email-masked]>
Date: Wed, 11 Apr 2001 18:38:34 -0700

Bert,

There was a long lag time between when 100Mbit Ethernet was
standardised by IEEE, and when we completed the updated Ethernet
MIB for 100Mbit.  In the meantime, IEEE actually almost finished
standardising gigabit Ethernet, while we were still working on 
100 Mbit.

Without any guidance from us, some vendors went ahead and registered
ifType values for 100 Mbit and gigabit Ethernet.  When we published
the updated Ethernet MIB, we recommended that vendors should always
return ethernetCsmacd for any flavor of Ethernet, and should never
use these vendor-registered ifType values.  Different types/speeds
of Ethernet are distinguished using ifSpeed and the MAU MIB.

However, the ifType MIB from IANA has these spurious values:
fastEther, fastEtherFX, and gigabitEthernet.

A few years ago, the ifMIB requested that IANA mark some of the
values that had been added to the ifType TC as obsolete.  These
include e1, frameRelayInterconnect, and g703at2mb.  These
enumerations have ASN.1 comments stating that they are obsolete.

We would like IANA to add similar comments to the fastEther,
fastEtherFX, and gigabitEthernet values, so that agent vendors
do not mistakenly continue to use these values.  In addition, we
will be tightening up the text in the update to RFC 2665, to state
that agents MUST not return these values, but that management apps
SHOULD be prepared to receive them from older agents.

John