Question about draft-ietf-hubmib-rfc3636bis

["C. M. Heard" <heard@pobox.com>]

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