RE: Question about draft-ietf-hubmib-rfc3636bis

["David B Harrington" <dbharrington@comcast.net>]

I would suggest moving it to IANA control and not worry about the
backwards compatibility, since no MIB module is known to import the
values, and presumably it has been discussed in the HUBMIB WG, so
vendors have had notice of the pending change.

If a MIB module shows up that does import them, it's a very easy text
fix to change where it imports from. I would make sure the updated
MAU-MIB discusses how to change any existing MIB module imports.

David Harrington
dbharrington@comcast.net

> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of C. M. Heard
> Sent: Monday, April 18, 2005 12:21 AM
> To: Mreview (E-mail)
> Subject: Question about draft-ietf-hubmib-rfc3636bis
> 
> MIB Doctors -
> 
> I am preparing some working group last call comments on
> draft-ietf-hubmib-rfc3636bis, which is a proposed update to the
> MAU-MIB, and there is a matter about which I would like some other
> opinions.
> 
> First some background.  Historically, each standard MAU type has
> been represented both as an OBJECT IDENTIFIER, which can figure as a
> value for rpMauType, ifMauType, or ifMauDefaultType, and also as a
> bit position in ifMauTypeListBits.  These values have been entered
> directly into the MAU-MIB itself as a set of OBJECT-IDENTITY
> definitions and as bit positions in the type for ifMauTypeListBits.

> The WG wants to move these into an IANA-maintained MIB module so
> that it is not necessary to open up the MAU-MIB every time the IEEE
> defines a new 802.3 phyisical layer variant.  So far so good, I
> agree with this goal.
> 
> There is, however, a potential backward compatibility issue in
> moving the existing OBJECT-IDENTITY definitions out of the MAU-MIB,
> namely that it would break any MIB modules that happened to import
> those definitions from the MAU-MIB.  I suggested to the author to
> turn the existing definitions as OBJECT IDENTIFIER assignments (as
> permitted by RFC 2578 Section 3.6) so that they could continue to be
> imported from the MAU-MIB.  That suggestion has, however, met with
> some resistance:  it causes lots of smilint warnings, assuming that
> default settings are used, and no one has been able to find any
> example of a MIB module that imports one of the definitions in
> question (for sure no IETF standard MIB module does so).
> 
> What would you other MIB Doctors advise in this case?
> 
> Mike
> 
> 
>