Re: RE: FWD: Restart ifmib WG?

On Fri, 2 May 2003, Keith McCloghrie wrote:
>[On Thu, 1 May 2003, Dave Thaler wrote:]
> > There's been a number of suggestions on this list
> > for improvements that would be useful to add in a 
> > supplemental IF MIB module in a separate RFC.
> > On this topic, I recently received some IF MIB 
> > feedback from folks here in Microsoft on things 
> > they considered to be missing:
> > > I also see RFC to be inadequate in not being able 
> > > to report -not known- for -current- link state and 
> 
> The value 'unknown' is already defined got ifOperStatus.

Correct.

> > > speed (and instead using maximum link speed) 
> > > Not having separate [objects] for xmit and 
> > > receive link speeds, not having an object for 
> 
> The issue of link speed, both unknown speed and different speeds for
> xmit/rcv, has been discussed on several previous occasions, and on each
> such occasion the WG decided that any additional objects should be
> placed in media-specific MIBs.  As I recall, the argument went
> something like this: we have done dozens (maybe even hundreds) of
> media-specific MIBs; what has changed now that didn't apply to all
> those we have already done, and if it didn't apply to all those we
> have already done, why is it needed now??

I agree with this.  Allow me to point out that for 802.3 interfaces
the media-specific MIB modules in fact already do take care of the
"current" vs. "maximum" link speed issue.  Specifically, the MAU-MIB
object ifMauTypeListBits lists all the supported medium type /
interface speed / duplex combinations, with current medium type /
interface speed / duplex combination reported by ifMauType (see RFC
2668 or <draft-ietf-hubmib-mau-mib-v3-03.txt>).  The EtherLike-MIB
(see RFC 2665 or <draft-ietf-hubmib-etherif-mib-v3-03.txt>) states
that ifSpeed and ifHighSpeed report the _current_ speed.  Standard
behaviour for 802.3 interface types is that transmit and receive
speeds are the same, so any implementation that supports running at
different speeds is engaging in proprietary behaviour which I would
expect to be managed by an enterprise MIB module.

> > > permanent mac address, no support for power 
> > > management, etc.
> 
> The number of interface types which have MAC addresses and support
> "power management" is certainly *less* than the number of interface
> types which don't.  Thus, again, this is media-specific.

In fairness, it should be pointed out that some media-specific
things are managed in the IF-MIB, and MAC addresses are one such
thing;  however, "permanent" MAC address is something that probably
belongs in a proprietary MIB module.  Again using 802.3 interfaces
as an example, MAC addresses are maintained in the IF-MIB objects
ifPhysAddress and ifRcvAddressTable, with ifPhysAddress containing
the unicast address used as the source address and ifRcvAddressTable
contaning all unicast and multicast addresses for which the
interface will accept traffic.  Although the ifRcvAddressTable
allows for non-volatile entries, no allowance is made for having a
"permanent" but "inactive" unicast MAC address.  On the other hand,
the 802.3 standard does not provide for any such managed object
either, so it is probably not unreasonable to expect it to be in a
proprietary extension.  As for power management, the MAU-MIB object
ifMauStatus at least partially accomodates this function;  see the
definitions of the values standby(4) and shutdown(5).

//cmh