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

See in-line. Thanks, Dan

> -----Original Message-----
> From: Edward Beili [mailto:[email protected]]
> Sent: 29 October, 2003 3:10 PM
> To: 'C. M. Heard'; Romascanu, Dan (Dan)
> Cc: '[email protected]'; Lior Khermosh (E-mail)
> Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] 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?
> 

Yes, you can. 

(speaking as chair)

I would like to hear more opinions - especially from the MAU MIB Editor before taking an action.

(speaking as contributor)

I think that we cannot avoid it. 


> -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
> > 
>