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

Mike,

The new copper interfaces can be administratively controlled and
auto-negotiated, so I guess a new RFC should be issued to replace RFC 3636.
I would suspect that new EPON interfaces can be auto-negotiated as well.

Dan,
Can we ask to open a new version of MAU-MIB?

Regards,
-Edward

> -----Original Message-----
> From: C. M. Heard [mailto:[email protected]]
> Sent: Wednesday, October 29, 2003 07:51 AM
> To: '[email protected] '
> Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] 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
> 
> 
> _______________________________________________
> Hubmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/hubmib
>