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

David,

I would certainly use the compliance clause in the MIB to identify needed
parts from the existing MIBs. I was just questioning the rational behind
using a MIB with almost 40 counters our of which only about 3 are
applicable.

-Edward

> -----Original Message-----
> From: Harrington, David [mailto:[email protected]]
> Sent: Thursday, October 23, 2003 06:44 PM
> To: Edward Beili; Romascanu, Dan (Dan) 
> Cc: [email protected]; Matt Squire 
> Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB 
> Internet-Drafts, WG Meetings
> 
> 
> Hi,
> 
> Yo say the advantage of duplicating the subset of objects you 
> care about
> is that it saves you from implementing a pretty big mib, what about
> those people who want to implement the pretty big Etherlike mib *and*
> the EFM mib? Using your approach means they would need to not only
> implement the pretty big mib but your unnecessary duplication of the
> same functionality as well. How is that a win?
> 
> Would a compliance clause in the EFM MIB identifying which subset of
> objects in the Etherlike MIB are needed for EFM functionality make it
> less painful? This would promote reuse of at least parts of 
> the existing
> standard. 
> 
> dbh
> 
> > -----Original Message-----
> > From: Edward Beili [mailto:[email protected]] 
> > Sent: Thursday, October 23, 2003 12:20 PM
> > To: 'Romascanu, Dan (Dan) '
> > Cc: '[email protected] '; 'Matt Squire '
> > Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB 
> > Internet-Drafts, WG Meetings
> > 
> > 
> > Dan,
> > 
> > Here are some arguments for not supporting the EtherLike-MIB
> > (just for the purpose of argument):
> > 
> > Let's look at some of the control groups in EtherLike-MIB 
> (rfc-3635):
> > - dot3PauseTable - The EFMCu interfaces do not support Pause 
> > frames so this
> > may be omitted.
> > - dot3Tests - is already deprecated
> > - dot3Errors - is already deprecated
> > - dot3ColTable - no collisions on EFMCu
> > 
> > So this leaves just the dot3ControlTable with currently 
> > supported Pause()
> > function - see above for applicability.
> > 
> > The rest are statistics. There are some rudimentary 
> > statistics in the IF-MIB
> > + interface specific stats in EFM-CU-MIB which could be just 
> > enough for the
> > trouble shooting.
> > 
> > The advantage of not implementing EtherLike-MIB - well, not 
> > implementing a
> > pretty big MIB.
> > 
> > Regards,
> > -E.
> > 
> > 
> > -----Original Message-----
> > From: Romascanu, Dan (Dan)
> > To: Edward Beili
> > Cc: [email protected]; Matt Squire 
> > Sent: 23/10/03 17:15
> > Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB 
> > Internet-Drafts,
> > WG Meetings
> > 
> > My opinion (as a contributor) is that the Etherlike-MIB needs to be
> > supported. It would be the first MIB in the family that would be
> > excepted, and I would like to hear some technical arguments why we
> > should do it. IF_MIB does not provide any Ethernet specific 
> objects to
> > manage the interface. 
> > 
> > I would defer the answer at the second question to John Flick - the
> > editor of the MAU MIB. 
> > 
> > Regards,
> > 
> > Dan
> > 
> > 
> > > -----Original Message-----
> > > From: Edward Beili [mailto:[email protected]]
> > > Sent: 23 October, 2003 4:56 PM
> > > To: Romascanu, Dan (Dan)
> > > Cc: '[email protected] '; 'Matt Squire '
> > > Subject: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB 
> > > Internet-Drafts,
> > > WG Meetings
> > > 
> > > 
> > > Hi,
> > > 
> > > I have a question as well - I assume that all new interfaces 
> > > defined in
> > > the EFM would be considered as Ethernet Like with mandatory 
> > > EtherLike-MIB
> > > and MAU-MIB implementation. Is this correct? Theoretically we 
> > > could require
> > > just IF-MIB, considering that most implementors choose not support
> > > EtherLike-MIB.
> > > 
> > > 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?
> > > 
> > > -Edward
> > > 
> > > 
> > > -----Original Message-----
> > > From: Matt Squire
> > > To: Romascanu, Dan (Dan); [email protected]
> > > Cc: [email protected]
> > > Sent: 23/10/03 16:01
> > > Subject: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings
> > > 
> > >  
> > > Just speaking for the draft I submitted, it is a very early 
> > draft that
> > > still has a lot of holes.  All input is very appreciated.  
> > >  
> > > In particular, one big nagging question is how these new MIBs are
> > > organized within the existing MIB heirarchy.  For the common 
> > > stuff, does
> > > it get a new mib-2 branch, or do we somehow hang it under the dot3
> > > branch as something under the Ethernet tree?  
> > >  
> > > Hoping some of you MIB experts can lend some guidance.  
> > >  
> > > 
> > > -----Original Message-----
> > > From: Romascanu, Dan (Dan) [mailto:[email protected]]
> > > Sent: Thursday, October 23, 2003 4:59 AM
> > > To: [email protected]
> > > Cc: [email protected]; Bert Wijnen (E-mail)
> > > Subject: [Hubmib] EFM MIB Internet-Drafts, WG Meetings
> > > 
> > > 
> > > 
> > > As you have seen in the announcements that went out in the 
> > last couple
> > > of days, the three individual submission Internet-Drafts 
> > including the
> > > initial submissions for the EFM MIBs are now available. 
> The relevant
> > > URLs are:
> > > 
> > > *
> > > 
> > 
> http://www.ietf.org/internet-drafts/draft-squire-hubmib-efm-mib-00.txt
> > > <http://www.ietf.org/internet-drafts/draft-squire-hubmib-efm-m
> > ib-00.txt>
> > 
> > *
> > http://www.ietf.org/internet-drafts/draft-beili-hubmib-efm-cu-
> > mib-00.txt
> > <http://www.ietf.org/internet-drafts/draft-beili-hubmib-efm-cu
> > -mib-00.tx
> > t> 
> > *
> > http://www.ietf.org/internet-drafts/draft-khermosh-hubmib-epon
> > -mib-00.tx
> > t
> > <http://www.ietf.org/internet-drafts/draft-khermosh-hubmib-epo
> > n-mib-00.t
> > xt> 
> > 
> > 
> > First, I would like to thank the editors of the three 
> > documents - Matt,
> > Edward, and Lior for the effort, and for meeting the submission
> > deadline. With this we have already accomplished in time the 
> > first item
> > in our new charter! 
> > 
> > Second, I would strongly suggest that you read the 
> proposals and send
> > your comments. The final work can happen only with your support and
> > contribution, and will be as good as we all make it. Take 
> into account
> > that these are only initial proposals, and there is a long 
> way to go.
> > All comments need to be sent to the WG list, at [email protected]. 
> > 
> > Third, if there are other contributions, let me know, and 
> prepare them
> > in Internet-Draft format. Our next milestone is issuing the 
> > first round
> > of WG Internet-Drafts in December - we need to know if the 
> > three drafts
> > already published are the only contributions, or there will be other
> > I-Ds to be considered. 
> > 
> > Now about WG meetings. The Ethernet Interfaces and Hub MIB 
> WG will not
> > meet during the November IETF meeting, because of the 
> conflict between
> > the IETF meeting and the IEEE Plenary that are scheduled 
> for the same
> > week. Personally I think that we do need face-to-face 
> > meetings, although
> > much of the work can be done on the mailing list. The next two
> > opportunities for face to face meetings seem to be:
> > 
> > - an interim meeting in Vancouver, BC in January (I do not know the
> > exact week) co-located with the IEEE 802.3 Interim meeting 
> > 
> > - meeting at the IETF meeting in Seoul, Korea (2/29-3/5)
> > 
> > Everybody who thinks that they can/will attend one or both of the
> > meetings - please send me an e-mail - we need a headcount 
> > before making
> > a decision and engaging in any logistics. 
> > 
> > If we decide for an Interim, we need to have it approved by the IETF
> > Area Director, and we might need a sponsor for the room 
> > meeting space in
> > Vancouver (maybe IEEE 802.3ah can help?).
> > 
> > Thanks and Regards,
> > 
> > Dan
> > 
> > 
> > _______________________________________________
> > Hubmib mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/hubmib
> > 
>