RE: Augmenting MAU-MIB - was: RE: EFM MIB Internet-Draft s, WG Meetings

On Thu, 23 Oct 2003, Edward Beili wrote:
> We would also need to augment current MAU-MIB with new
> dot3MauType instances defined for EPON and Copper interfaces. Do
> we have to open a new version of MAU-MIB (and who does it) or
> there's another way of doing it?

and on Tue, 28 Oct 2003, Edward Beili wrote:
> Going back to my original question: what is the procedure for
> updating the MAU-MIB?

What actually needs to be done is to generate some new
OBJECT-IDENTITY definitions to specify OIDs that can figure as
values of rpMauType or ifMauType and ifMauDefaultType.  I think that
the question is whether it is feasible to put the new
OBJECT-IDENTITY definitions in another MIB module or whether they
need to go into the MAU-MIB.  Here is my take on that question.

If the new MAU types could be potentially auto-negotiated, then they
must have corresponding bit positions in ifMauTypeListBits.  In that
case the right thing to do would be to register the new values under
dot3MauType (as has been done for other "standard" MAU types) and to
add corresponding bit positions to ifMauDefaultType.  This would
require that the MAU-MIB be revised and that a new RFC be issued to
replace RFC 3636.  The WG group has the authority to do this if it's
deemed necessary.  I don't believe that small modifications like
this would necessarily affect "time in grade" for the purposes of
standards track advancement since no new objects would be added.

On the other hand, if the new MAU types could NOT be auto-negotiated
but could only be set statically or reported, then there would be no
need to add bit positions to ifMauDefaultType, and the new OID
values could in principle be registered anywhere convenient.  If
they were registered under some top-level OID other than dot3MauType
then there would be no need to revise the MAU-MIB.  This is how
proprietary MAU types are handled, BTW.

Mike