WG Status

Accordingly, I = would say that=20 we need to plan for our three MIB modules to be placed under MIB-II, and = probably separatily, do that dependencies are reduced to the possible = extent.=20

Rergards,

Dan

In particular, one big nagging question is how these new MIBs = are=20 organized within the existing MIB heirarchy. For the common = stuff, does=20 it get a new mib-2 branch, or do we somehow hang it under the dot3 = branch as=20 something under the Ethernet tree?

Hoping some of you MIB experts can lend some guidance. =20

The later Ethernet = MIB module=20 that went under review got the following structure, as result of the MIB = Doctor=20 comments:

powerEthernetMIB=20 MODULE-IDENTITY
         = ::=3D {=20 mib-2 XXX }
   -- RFC Ed.: replace XXX with IANA-assigned = number=20 & remove this notice

   pethNotifications OBJECT = IDENTIFIER=20 ::=3D { powerEthernetMIB 0 }
  =20 pethObjects       OBJECT IDENTIFIER ::=3D = {=20 powerEthernetMIB 1 }
   pethConformance   OBJECT=20 IDENTIFIER ::=3D { powerEthernetMIB 2 }

Accordingly, I = would say that=20 we need to plan for our three MIB modules to be placed under MIB-II, and = probably separatily, do that dependencies are reduced to the possible = extent.=20

Rergards,

Dan

In particular, one big nagging question is how these new MIBs = are=20 organized within the existing MIB heirarchy. For the common = stuff, does=20 it get a new mib-2 branch, or do we somehow hang it under the dot3 = branch as=20 something under the Ethernet tree?

Hoping some of you MIB experts can lend some guidance. =20

------_=_NextPart_001_01C39976.A19E2B68-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Thu Oct 23 11:16:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28404 for ; Thu, 23 Oct 2003 11:16:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChBx-0004Oy-Qe for hubmib-archive@odin.ietf.org; Thu, 23 Oct 2003 11:16:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NFG1n6016872 for hubmib-archive@odin.ietf.org; Thu, 23 Oct 2003 11:16:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChBx-0004O1-2r; Thu, 23 Oct 2003 11:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChBI-0004Fi-Ur for hubmib@optimus.ietf.org; Thu, 23 Oct 2003 11:15:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28356 for ; Thu, 23 Oct 2003 11:15:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AChBI-00026m-00 for hubmib@ietf.org; Thu, 23 Oct 2003 11:15:20 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AChBH-00026j-00 for hubmib@ietf.org; Thu, 23 Oct 2003 11:15:19 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9NFDDJK008319 for ; Thu, 23 Oct 2003 10:13:13 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9NFD7JK008237 for ; Thu, 23 Oct 2003 10:13:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Date: Thu, 23 Oct 2003 17:15:12 +0200 Message-ID: Thread-Topic: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Thread-Index: AcOZdZ2x/rDm8JL3QgqRIHO2mn4v3gAAiOqQ From: "Romascanu, Dan (Dan)" To: "Edward Beili" Cc: , "Matt Squire " Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable 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.=20 I would defer the answer at the second question to John Flick - the = editor of the MAU MIB.=20 Regards, Dan > -----Original Message----- > From: Edward Beili [mailto:EdwardB@actelis.com] > Sent: 23 October, 2003 4:56 PM > To: Romascanu, Dan (Dan) > Cc: 'hubmib@ietf.org '; 'Matt Squire ' > Subject: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB=20 > Internet-Drafts, > WG Meetings >=20 >=20 > Hi, >=20 > I have a question as well - I assume that all new interfaces=20 > defined in > the EFM would be considered as Ethernet Like with mandatory=20 > EtherLike-MIB > and MAU-MIB implementation. Is this correct? Theoretically we=20 > could require > just IF-MIB, considering that most implementors choose not support > EtherLike-MIB. >=20 > We would also need to augment current MAU-MIB with new=20 > dot3MauType instances > defined for EPON and Copper interfaces. Do we have to open a=20 > new version of > MAU-MIB (and who does it) or there's another way of doing it? >=20 > -Edward >=20 >=20 > -----Original Message----- > From: Matt Squire > To: Romascanu, Dan (Dan); hubmib@ietf.org > Cc: stds-802-3-efm@ieee.org > Sent: 23/10/03 16:01 > Subject: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings >=20 > =20 > 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. =20 > =20 > In particular, one big nagging question is how these new MIBs are > organized within the existing MIB heirarchy. For the common=20 > 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? =20 > =20 > Hoping some of you MIB experts can lend some guidance. =20 > =20 >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Thursday, October 23, 2003 4:59 AM > To: hubmib@ietf.org > Cc: stds-802-3-efm@ieee.org; Bert Wijnen (E-mail) > Subject: [Hubmib] EFM MIB Internet-Drafts, WG Meetings >=20 >=20 >=20 > 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: >=20 > * > http://www.ietf.org/internet-drafts/draft-squire-hubmib-efm-mib-00.txt > * http://www.ietf.org/internet-drafts/draft-beili-hubmib-efm-cu-mib-00.txt =20 * http://www.ietf.org/internet-drafts/draft-khermosh-hubmib-epon-mib-00.tx t =20 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!=20 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 hubmib@ietf.org.=20 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.=20 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=20 - 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.=20 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 Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Oct 23 11:16:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28419 for ; Thu, 23 Oct 2003 11:16:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChBx-0004O1-2r; Thu, 23 Oct 2003 11:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChBI-0004Fi-Ur for hubmib@optimus.ietf.org; Thu, 23 Oct 2003 11:15:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28356 for ; Thu, 23 Oct 2003 11:15:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AChBI-00026m-00 for hubmib@ietf.org; Thu, 23 Oct 2003 11:15:20 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AChBH-00026j-00 for hubmib@ietf.org; Thu, 23 Oct 2003 11:15:19 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9NFDDJK008319 for ; Thu, 23 Oct 2003 10:13:13 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9NFD7JK008237 for ; Thu, 23 Oct 2003 10:13:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Date: Thu, 23 Oct 2003 17:15:12 +0200 Message-ID: Thread-Topic: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Thread-Index: AcOZdZ2x/rDm8JL3QgqRIHO2mn4v3gAAiOqQ From: "Romascanu, Dan (Dan)" To: "Edward Beili" Cc: , "Matt Squire " Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable 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.=20 I would defer the answer at the second question to John Flick - the = editor of the MAU MIB.=20 Regards, Dan > -----Original Message----- > From: Edward Beili [mailto:EdwardB@actelis.com] > Sent: 23 October, 2003 4:56 PM > To: Romascanu, Dan (Dan) > Cc: 'hubmib@ietf.org '; 'Matt Squire ' > Subject: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB=20 > Internet-Drafts, > WG Meetings >=20 >=20 > Hi, >=20 > I have a question as well - I assume that all new interfaces=20 > defined in > the EFM would be considered as Ethernet Like with mandatory=20 > EtherLike-MIB > and MAU-MIB implementation. Is this correct? Theoretically we=20 > could require > just IF-MIB, considering that most implementors choose not support > EtherLike-MIB. >=20 > We would also need to augment current MAU-MIB with new=20 > dot3MauType instances > defined for EPON and Copper interfaces. Do we have to open a=20 > new version of > MAU-MIB (and who does it) or there's another way of doing it? >=20 > -Edward >=20 >=20 > -----Original Message----- > From: Matt Squire > To: Romascanu, Dan (Dan); hubmib@ietf.org > Cc: stds-802-3-efm@ieee.org > Sent: 23/10/03 16:01 > Subject: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings >=20 > =20 > 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. =20 > =20 > In particular, one big nagging question is how these new MIBs are > organized within the existing MIB heirarchy. For the common=20 > 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? =20 > =20 > Hoping some of you MIB experts can lend some guidance. =20 > =20 >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Thursday, October 23, 2003 4:59 AM > To: hubmib@ietf.org > Cc: stds-802-3-efm@ieee.org; Bert Wijnen (E-mail) > Subject: [Hubmib] EFM MIB Internet-Drafts, WG Meetings >=20 >=20 >=20 > 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: >=20 > * > http://www.ietf.org/internet-drafts/draft-squire-hubmib-efm-mib-00.txt > * http://www.ietf.org/internet-drafts/draft-beili-hubmib-efm-cu-mib-00.txt =20 * http://www.ietf.org/internet-drafts/draft-khermosh-hubmib-epon-mib-00.tx t =20 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!=20 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 hubmib@ietf.org.=20 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.=20 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=20 - 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.=20 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 Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Oct 23 11:22:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28851 for ; Thu, 23 Oct 2003 11:22:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChHk-0005aF-R6; Thu, 23 Oct 2003 11:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChHW-0005XH-2i for hubmib@optimus.ietf.org; Thu, 23 Oct 2003 11:21:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28819 for ; Thu, 23 Oct 2003 11:21:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AChHV-0002HP-00 for hubmib@ietf.org; Thu, 23 Oct 2003 11:21:45 -0400 Received: from mail14a.sanjose14-verio.com ([128.121.143.14]) by ietf-mx with smtp (Exim 4.12) id 1AChHU-0002HH-00 for hubmib@ietf.org; Thu, 23 Oct 2003 11:21:44 -0400 Received: from www.passave.com (128.121.207.126) by mail14a.sanjose14-verio.com (RS ver 1.0.87vs) with SMTP id 2-089142492; Thu, 23 Oct 2003 11:21:35 -0400 (EDT) From: "Lior Khermosh" To: "Edward Beili" , "'Romascanu, Dan \(Dan\) '" Cc: , "'Matt Squire '" Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Date: Thu, 23 Oct 2003 17:24:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <36EB88BFB60BD711B29C00062939CDF2741C94@il-mail02.actelis.net> X-Loop-Detect: 1 Content-Transfer-Encoding: 7bit Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Edward, I added some suggestion to amendments to the MAU MIBs in my draft for EPON to adapt it. I do not know if it should be under dot3MauType or elsewhere. Lior -----Original Message----- From: hubmib-admin@ietf.org [mailto:hubmib-admin@ietf.org]On Behalf Of Edward Beili Sent: Thursday, October 23, 2003 4:56 PM To: 'Romascanu, Dan (Dan) ' Cc: 'hubmib@ietf.org '; '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); hubmib@ietf.org Cc: stds-802-3-efm@ieee.org 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:dromasca@avaya.com] Sent: Thursday, October 23, 2003 4:59 AM To: hubmib@ietf.org Cc: stds-802-3-efm@ieee.org; 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-beili-hubmib-efm-cu-mib-00.txt * http://www.ietf.org/internet-drafts/draft-khermosh-hubmib-epon-mib-00.tx t 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 hubmib@ietf.org. 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 Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Thu Oct 23 11:22:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28864 for ; Thu, 23 Oct 2003 11:22:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChHl-0005bK-Ds for hubmib-archive@odin.ietf.org; Thu, 23 Oct 2003 11:22:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NFM1Wn021515 for hubmib-archive@odin.ietf.org; Thu, 23 Oct 2003 11:22:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChHk-0005aF-R6; Thu, 23 Oct 2003 11:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChHW-0005XH-2i for hubmib@optimus.ietf.org; Thu, 23 Oct 2003 11:21:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28819 for ; Thu, 23 Oct 2003 11:21:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AChHV-0002HP-00 for hubmib@ietf.org; Thu, 23 Oct 2003 11:21:45 -0400 Received: from mail14a.sanjose14-verio.com ([128.121.143.14]) by ietf-mx with smtp (Exim 4.12) id 1AChHU-0002HH-00 for hubmib@ietf.org; Thu, 23 Oct 2003 11:21:44 -0400 Received: from www.passave.com (128.121.207.126) by mail14a.sanjose14-verio.com (RS ver 1.0.87vs) with SMTP id 2-089142492; Thu, 23 Oct 2003 11:21:35 -0400 (EDT) From: "Lior Khermosh" To: "Edward Beili" , "'Romascanu, Dan \(Dan\) '" Cc: , "'Matt Squire '" Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Date: Thu, 23 Oct 2003 17:24:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <36EB88BFB60BD711B29C00062939CDF2741C94@il-mail02.actelis.net> X-Loop-Detect: 1 Content-Transfer-Encoding: 7bit Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Edward, I added some suggestion to amendments to the MAU MIBs in my draft for EPON to adapt it. I do not know if it should be under dot3MauType or elsewhere. Lior -----Original Message----- From: hubmib-admin@ietf.org [mailto:hubmib-admin@ietf.org]On Behalf Of Edward Beili Sent: Thursday, October 23, 2003 4:56 PM To: 'Romascanu, Dan (Dan) ' Cc: 'hubmib@ietf.org '; '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); hubmib@ietf.org Cc: stds-802-3-efm@ieee.org 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:dromasca@avaya.com] Sent: Thursday, October 23, 2003 4:59 AM To: hubmib@ietf.org Cc: stds-802-3-efm@ieee.org; 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-beili-hubmib-efm-cu-mib-00.txt * http://www.ietf.org/internet-drafts/draft-khermosh-hubmib-epon-mib-00.tx t 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 hubmib@ietf.org. 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 Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Oct 23 11:41:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00346 for ; Thu, 23 Oct 2003 11:41:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACha9-0001oP-T1; Thu, 23 Oct 2003 11:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACha4-0001md-MS for hubmib@optimus.ietf.org; Thu, 23 Oct 2003 11:40:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00257 for ; Thu, 23 Oct 2003 11:40:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACha3-0002fb-00 for hubmib@ietf.org; Thu, 23 Oct 2003 11:40:55 -0400 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1ACha3-0002fD-00 for hubmib@ietf.org; Thu, 23 Oct 2003 11:40:55 -0400 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Oct 2003 17:42:13 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF2741C99@il-mail02.actelis.net> From: Edward Beili To: "'hubmib@ietf.org '" Cc: "'Matt Squire '" , "'Romascanu, Dan (Dan) '" , "'stds-802-3-efm-copper@ieee.org'" Date: Thu, 23 Oct 2003 17:42:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [Hubmib] Discovery and Aggregation operation in EFM-CU-MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I would like to discuss the following problem related to Discovery and Aggregation operation in EFM-CU-MIB: In the MIB I proposed to use ifStackTable for actual PCS to PMD connections (and changing them) while a new read-only table efmCuAvailableStackTable defined in the EFM-CU-MIB, would list possible cross-connections (see 3.1 and 3.3 in the draft). An alternative would be to use ifStackTable to describe cross-connect capability and efmCuAvailableStackTable to describe actual connections, so that the cross-connect action would be done in the EFM-CU-MIB by modifying the efmCuAvailableStackTable (and not in IF-MIB). I would like to hear some opinions on that. Regards, -Edward _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Thu Oct 23 11:41:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00358 for ; Thu, 23 Oct 2003 11:41:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChaA-0001op-1n for hubmib-archive@odin.ietf.org; Thu, 23 Oct 2003 11:41:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NFf2mU006976 for hubmib-archive@odin.ietf.org; Thu, 23 Oct 2003 11:41:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACha9-0001oP-T1; Thu, 23 Oct 2003 11:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACha4-0001md-MS for hubmib@optimus.ietf.org; Thu, 23 Oct 2003 11:40:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00257 for ; Thu, 23 Oct 2003 11:40:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACha3-0002fb-00 for hubmib@ietf.org; Thu, 23 Oct 2003 11:40:55 -0400 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1ACha3-0002fD-00 for hubmib@ietf.org; Thu, 23 Oct 2003 11:40:55 -0400 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Oct 2003 17:42:13 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF2741C99@il-mail02.actelis.net> From: Edward Beili To: "'hubmib@ietf.org '" Cc: "'Matt Squire '" , "'Romascanu, Dan (Dan) '" , "'stds-802-3-efm-copper@ieee.org'" Date: Thu, 23 Oct 2003 17:42:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [Hubmib] Discovery and Aggregation operation in EFM-CU-MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I would like to discuss the following problem related to Discovery and Aggregation operation in EFM-CU-MIB: In the MIB I proposed to use ifStackTable for actual PCS to PMD connections (and changing them) while a new read-only table efmCuAvailableStackTable defined in the EFM-CU-MIB, would list possible cross-connections (see 3.1 and 3.3 in the draft). An alternative would be to use ifStackTable to describe cross-connect capability and efmCuAvailableStackTable to describe actual connections, so that the cross-connect action would be done in the EFM-CU-MIB by modifying the efmCuAvailableStackTable (and not in IF-MIB). I would like to hear some opinions on that. Regards, -Edward _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Oct 23 12:20:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04977 for ; Thu, 23 Oct 2003 12:20:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACiBu-0000uQ-MK; Thu, 23 Oct 2003 12:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACiBO-0000nu-QC for hubmib@optimus.ietf.org; Thu, 23 Oct 2003 12:19:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04908 for ; Thu, 23 Oct 2003 12:19:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACiBM-00049l-00 for hubmib@ietf.org; Thu, 23 Oct 2003 12:19:28 -0400 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1ACiBL-00046S-00 for hubmib@ietf.org; Thu, 23 Oct 2003 12:19:27 -0400 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Oct 2003 18:20:24 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF2741C9A@il-mail02.actelis.net> From: Edward Beili To: "'Romascanu, Dan (Dan) '" Cc: "'hubmib@ietf.org '" , "'Matt Squire '" Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Draft s, WG Meetings Date: Thu, 23 Oct 2003 18:20:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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: hubmib@ietf.org; 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:EdwardB@actelis.com] > Sent: 23 October, 2003 4:56 PM > To: Romascanu, Dan (Dan) > Cc: 'hubmib@ietf.org '; '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); hubmib@ietf.org > Cc: stds-802-3-efm@ieee.org > 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:dromasca@avaya.com] > Sent: Thursday, October 23, 2003 4:59 AM > To: hubmib@ietf.org > Cc: stds-802-3-efm@ieee.org; 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-beili-hubmib-efm-cu-mib-00.txt * http://www.ietf.org/internet-drafts/draft-khermosh-hubmib-epon-mib-00.tx t 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 hubmib@ietf.org. 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 Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Thu Oct 23 12:20:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04992 for ; Thu, 23 Oct 2003 12:20:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACiBw-0000vu-1U for hubmib-archive@odin.ietf.org; Thu, 23 Oct 2003 12:20:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NGK3n8003517 for hubmib-archive@odin.ietf.org; Thu, 23 Oct 2003 12:20:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACiBu-0000uQ-MK; Thu, 23 Oct 2003 12:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACiBO-0000nu-QC for hubmib@optimus.ietf.org; Thu, 23 Oct 2003 12:19:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04908 for ; Thu, 23 Oct 2003 12:19:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACiBM-00049l-00 for hubmib@ietf.org; Thu, 23 Oct 2003 12:19:28 -0400 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1ACiBL-00046S-00 for hubmib@ietf.org; Thu, 23 Oct 2003 12:19:27 -0400 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Oct 2003 18:20:24 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF2741C9A@il-mail02.actelis.net> From: Edward Beili To: "'Romascanu, Dan (Dan) '" Cc: "'hubmib@ietf.org '" , "'Matt Squire '" Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Draft s, WG Meetings Date: Thu, 23 Oct 2003 18:20:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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: hubmib@ietf.org; 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:EdwardB@actelis.com] > Sent: 23 October, 2003 4:56 PM > To: Romascanu, Dan (Dan) > Cc: 'hubmib@ietf.org '; '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); hubmib@ietf.org > Cc: stds-802-3-efm@ieee.org > 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:dromasca@avaya.com] > Sent: Thursday, October 23, 2003 4:59 AM > To: hubmib@ietf.org > Cc: stds-802-3-efm@ieee.org; 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-beili-hubmib-efm-cu-mib-00.txt * http://www.ietf.org/internet-drafts/draft-khermosh-hubmib-epon-mib-00.tx t 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 hubmib@ietf.org. 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 Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Oct 23 12:28:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05419 for ; Thu, 23 Oct 2003 12:28:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACiJd-0002Ba-7j; Thu, 23 Oct 2003 12:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACiJL-00027S-6r for hubmib@optimus.ietf.org; Thu, 23 Oct 2003 12:27:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05407 for ; Thu, 23 Oct 2003 12:27:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACiJJ-0004Ig-00 for hubmib@ietf.org; Thu, 23 Oct 2003 12:27:41 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACiJJ-0004Id-00 for hubmib@ietf.org; Thu, 23 Oct 2003 12:27:41 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9NGPYJK025190 for ; Thu, 23 Oct 2003 11:25:35 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9NGPWJK025141 for ; Thu, 23 Oct 2003 11:25:33 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Date: Thu, 23 Oct 2003 18:27:36 +0200 Message-ID: Thread-Topic: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Thread-Index: AcOZgV0RvVjlXfXCSKOEX0GIB+F8dAAAJpTg From: "Romascanu, Dan (Dan)" To: "Edward Beili" Cc: , "Matt Squire " Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Edward, (speaking as a contributor) We agree on everything but the statistics. Obviously deprecated groups = are deprecated, and non-relevant functions need not be supported. The = remaining - statistics objects - are however very useful. They are not = too big a MIB (fifteen objects or so?) and the compliance clauses would = clarify what is needed. I can hardly see how you can debug an Ethernet = interface in their absence, and I do not think that IF-MIB objects or = specific EFM-CU-MIB objects can replace them. Regards, Dan > -----Original Message----- > From: Edward Beili [mailto:EdwardB@actelis.com] > Sent: 23 October, 2003 6:20 PM > To: Romascanu, Dan (Dan) > Cc: 'hubmib@ietf.org '; 'Matt Squire ' > Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB > Internet-Drafts, WG Meetings >=20 >=20 > Dan, >=20 > Here are some arguments for not supporting the EtherLike-MIB > (just for the purpose of argument): >=20 > Let's look at some of the control groups in EtherLike-MIB (rfc-3635): > - dot3PauseTable - The EFMCu interfaces do not support Pause=20 > frames so this > may be omitted. > - dot3Tests - is already deprecated > - dot3Errors - is already deprecated > - dot3ColTable - no collisions on EFMCu >=20 > So this leaves just the dot3ControlTable with currently=20 > supported Pause() > function - see above for applicability. >=20 > The rest are statistics. There are some rudimentary=20 > statistics in the IF-MIB > + interface specific stats in EFM-CU-MIB which could be just=20 > enough for the > trouble shooting. >=20 > The advantage of not implementing EtherLike-MIB - well, not=20 > implementing a > pretty big MIB. >=20 > Regards, > -E. >=20 >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) > To: Edward Beili > Cc: hubmib@ietf.org; Matt Squire=20 > Sent: 23/10/03 17:15 > Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB=20 > Internet-Drafts, > WG Meetings >=20 > 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.=20 >=20 > I would defer the answer at the second question to John Flick - the > editor of the MAU MIB.=20 >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: Edward Beili [mailto:EdwardB@actelis.com] > > Sent: 23 October, 2003 4:56 PM > > To: Romascanu, Dan (Dan) > > Cc: 'hubmib@ietf.org '; 'Matt Squire ' > > Subject: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB=20 > > Internet-Drafts, > > WG Meetings > >=20 > >=20 > > Hi, > >=20 > > I have a question as well - I assume that all new interfaces=20 > > defined in > > the EFM would be considered as Ethernet Like with mandatory=20 > > EtherLike-MIB > > and MAU-MIB implementation. Is this correct? Theoretically we=20 > > could require > > just IF-MIB, considering that most implementors choose not support > > EtherLike-MIB. > >=20 > > We would also need to augment current MAU-MIB with new=20 > > dot3MauType instances > > defined for EPON and Copper interfaces. Do we have to open a=20 > > new version of > > MAU-MIB (and who does it) or there's another way of doing it? > >=20 > > -Edward > >=20 > >=20 > > -----Original Message----- > > From: Matt Squire > > To: Romascanu, Dan (Dan); hubmib@ietf.org > > Cc: stds-802-3-efm@ieee.org > > Sent: 23/10/03 16:01 > > Subject: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings > >=20 > > =20 > > Just speaking for the draft I submitted, it is a very early=20 > draft that > > still has a lot of holes. All input is very appreciated. =20 > > =20 > > In particular, one big nagging question is how these new MIBs are > > organized within the existing MIB heirarchy. For the common=20 > > 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? =20 > > =20 > > Hoping some of you MIB experts can lend some guidance. =20 > > =20 > >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Thursday, October 23, 2003 4:59 AM > > To: hubmib@ietf.org > > Cc: stds-802-3-efm@ieee.org; Bert Wijnen (E-mail) > > Subject: [Hubmib] EFM MIB Internet-Drafts, WG Meetings > >=20 > >=20 > >=20 > > As you have seen in the announcements that went out in the=20 > last couple > > of days, the three individual submission Internet-Drafts=20 > including the > > initial submissions for the EFM MIBs are now available. The relevant > > URLs are: > >=20 > > * > >=20 > http://www.ietf.org/internet-drafts/draft-squire-hubmib-efm-mib-00.txt > > ib-00.txt> >=20 > * > http://www.ietf.org/internet-drafts/draft-beili-hubmib-efm-cu- > mib-00.txt > -mib-00.tx > t>=20 > * > http://www.ietf.org/internet-drafts/draft-khermosh-hubmib-epon > -mib-00.tx > t > n-mib-00.t > xt>=20 >=20 >=20 > First, I would like to thank the editors of the three=20 > documents - Matt, > Edward, and Lior for the effort, and for meeting the submission > deadline. With this we have already accomplished in time the=20 > first item > in our new charter!=20 >=20 > 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 hubmib@ietf.org.=20 >=20 > Third, if there are other contributions, let me know, and prepare them > in Internet-Draft format. Our next milestone is issuing the=20 > first round > of WG Internet-Drafts in December - we need to know if the=20 > three drafts > already published are the only contributions, or there will be other > I-Ds to be considered.=20 >=20 > 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=20 > 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: >=20 > - an interim meeting in Vancouver, BC in January (I do not know the > exact week) co-located with the IEEE 802.3 Interim meeting=20 >=20 > - meeting at the IETF meeting in Seoul, Korea (2/29-3/5) >=20 > Everybody who thinks that they can/will attend one or both of the > meetings - please send me an e-mail - we need a headcount=20 > before making > a decision and engaging in any logistics.=20 >=20 > 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=20 > meeting space in > Vancouver (maybe IEEE 802.3ah can help?). >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Thu Oct 23 12:28:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05423 for ; Thu, 23 Oct 2003 12:28:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACiJe-0002Ci-0F for hubmib-archive@odin.ietf.org; Thu, 23 Oct 2003 12:28:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NGS1t8008435 for hubmib-archive@odin.ietf.org; Thu, 23 Oct 2003 12:28:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACiJd-0002Ba-7j; Thu, 23 Oct 2003 12:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACiJL-00027S-6r for hubmib@optimus.ietf.org; Thu, 23 Oct 2003 12:27:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05407 for ; Thu, 23 Oct 2003 12:27:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACiJJ-0004Ig-00 for hubmib@ietf.org; Thu, 23 Oct 2003 12:27:41 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1ACiJJ-0004Id-00 for hubmib@ietf.org; Thu, 23 Oct 2003 12:27:41 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9NGPYJK025190 for ; Thu, 23 Oct 2003 11:25:35 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id h9NGPWJK025141 for ; Thu, 23 Oct 2003 11:25:33 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Date: Thu, 23 Oct 2003 18:27:36 +0200 Message-ID: Thread-Topic: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Thread-Index: AcOZgV0RvVjlXfXCSKOEX0GIB+F8dAAAJpTg From: "Romascanu, Dan (Dan)" To: "Edward Beili" Cc: , "Matt Squire " Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Edward, (speaking as a contributor) We agree on everything but the statistics. Obviously deprecated groups = are deprecated, and non-relevant functions need not be supported. The = remaining - statistics objects - are however very useful. They are not = too big a MIB (fifteen objects or so?) and the compliance clauses would = clarify what is needed. I can hardly see how you can debug an Ethernet = interface in their absence, and I do not think that IF-MIB objects or = specific EFM-CU-MIB objects can replace them. Regards, Dan > -----Original Message----- > From: Edward Beili [mailto:EdwardB@actelis.com] > Sent: 23 October, 2003 6:20 PM > To: Romascanu, Dan (Dan) > Cc: 'hubmib@ietf.org '; 'Matt Squire ' > Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB > Internet-Drafts, WG Meetings >=20 >=20 > Dan, >=20 > Here are some arguments for not supporting the EtherLike-MIB > (just for the purpose of argument): >=20 > Let's look at some of the control groups in EtherLike-MIB (rfc-3635): > - dot3PauseTable - The EFMCu interfaces do not support Pause=20 > frames so this > may be omitted. > - dot3Tests - is already deprecated > - dot3Errors - is already deprecated > - dot3ColTable - no collisions on EFMCu >=20 > So this leaves just the dot3ControlTable with currently=20 > supported Pause() > function - see above for applicability. >=20 > The rest are statistics. There are some rudimentary=20 > statistics in the IF-MIB > + interface specific stats in EFM-CU-MIB which could be just=20 > enough for the > trouble shooting. >=20 > The advantage of not implementing EtherLike-MIB - well, not=20 > implementing a > pretty big MIB. >=20 > Regards, > -E. >=20 >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) > To: Edward Beili > Cc: hubmib@ietf.org; Matt Squire=20 > Sent: 23/10/03 17:15 > Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB=20 > Internet-Drafts, > WG Meetings >=20 > 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.=20 >=20 > I would defer the answer at the second question to John Flick - the > editor of the MAU MIB.=20 >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: Edward Beili [mailto:EdwardB@actelis.com] > > Sent: 23 October, 2003 4:56 PM > > To: Romascanu, Dan (Dan) > > Cc: 'hubmib@ietf.org '; 'Matt Squire ' > > Subject: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB=20 > > Internet-Drafts, > > WG Meetings > >=20 > >=20 > > Hi, > >=20 > > I have a question as well - I assume that all new interfaces=20 > > defined in > > the EFM would be considered as Ethernet Like with mandatory=20 > > EtherLike-MIB > > and MAU-MIB implementation. Is this correct? Theoretically we=20 > > could require > > just IF-MIB, considering that most implementors choose not support > > EtherLike-MIB. > >=20 > > We would also need to augment current MAU-MIB with new=20 > > dot3MauType instances > > defined for EPON and Copper interfaces. Do we have to open a=20 > > new version of > > MAU-MIB (and who does it) or there's another way of doing it? > >=20 > > -Edward > >=20 > >=20 > > -----Original Message----- > > From: Matt Squire > > To: Romascanu, Dan (Dan); hubmib@ietf.org > > Cc: stds-802-3-efm@ieee.org > > Sent: 23/10/03 16:01 > > Subject: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings > >=20 > > =20 > > Just speaking for the draft I submitted, it is a very early=20 > draft that > > still has a lot of holes. All input is very appreciated. =20 > > =20 > > In particular, one big nagging question is how these new MIBs are > > organized within the existing MIB heirarchy. For the common=20 > > 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? =20 > > =20 > > Hoping some of you MIB experts can lend some guidance. =20 > > =20 > >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Thursday, October 23, 2003 4:59 AM > > To: hubmib@ietf.org > > Cc: stds-802-3-efm@ieee.org; Bert Wijnen (E-mail) > > Subject: [Hubmib] EFM MIB Internet-Drafts, WG Meetings > >=20 > >=20 > >=20 > > As you have seen in the announcements that went out in the=20 > last couple > > of days, the three individual submission Internet-Drafts=20 > including the > > initial submissions for the EFM MIBs are now available. The relevant > > URLs are: > >=20 > > * > >=20 > http://www.ietf.org/internet-drafts/draft-squire-hubmib-efm-mib-00.txt > > ib-00.txt> >=20 > * > http://www.ietf.org/internet-drafts/draft-beili-hubmib-efm-cu- > mib-00.txt > -mib-00.tx > t>=20 > * > http://www.ietf.org/internet-drafts/draft-khermosh-hubmib-epon > -mib-00.tx > t > n-mib-00.t > xt>=20 >=20 >=20 > First, I would like to thank the editors of the three=20 > documents - Matt, > Edward, and Lior for the effort, and for meeting the submission > deadline. With this we have already accomplished in time the=20 > first item > in our new charter!=20 >=20 > 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 hubmib@ietf.org.=20 >=20 > Third, if there are other contributions, let me know, and prepare them > in Internet-Draft format. Our next milestone is issuing the=20 > first round > of WG Internet-Drafts in December - we need to know if the=20 > three drafts > already published are the only contributions, or there will be other > I-Ds to be considered.=20 >=20 > 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=20 > 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: >=20 > - an interim meeting in Vancouver, BC in January (I do not know the > exact week) co-located with the IEEE 802.3 Interim meeting=20 >=20 > - meeting at the IETF meeting in Seoul, Korea (2/29-3/5) >=20 > Everybody who thinks that they can/will attend one or both of the > meetings - please send me an e-mail - we need a headcount=20 > before making > a decision and engaging in any logistics.=20 >=20 > 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=20 > meeting space in > Vancouver (maybe IEEE 802.3ah can help?). >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Oct 23 12:45:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06375 for ; Thu, 23 Oct 2003 12:45:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACia5-0005P6-56; Thu, 23 Oct 2003 12:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACiZC-0005DZ-U0 for hubmib@optimus.ietf.org; Thu, 23 Oct 2003 12:44:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06115 for ; Thu, 23 Oct 2003 12:43:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACiZB-0004WY-00 for hubmib@ietf.org; Thu, 23 Oct 2003 12:44:05 -0400 Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1ACiZA-0004WV-00 for hubmib@ietf.org; Thu, 23 Oct 2003 12:44:04 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id MAA19362 for ; Thu, 23 Oct 2003 12:44:37 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma019341; Thu, 23 Oct 03 12:44:19 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 23 Oct 2003 12:43:42 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 23 Oct 2003 12:43:42 -0400 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Oct 2003 12:43:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Date: Thu, 23 Oct 2003 12:43:41 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA0113937F@NHROCMBX1.ets.enterasys.com> Thread-Topic: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Thread-Index: AcOZgYsewH1eVgV+TRelYrwZKPNIEAAAdipA From: "Harrington, David" To: "Edward Beili" , "Romascanu, Dan (Dan) " Cc: , "Matt Squire " X-OriginalArrivalTime: 23 Oct 2003 16:43:42.0528 (UTC) FILETIME=[D1740400:01C39984] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:99.5902 M:89.0982 P:95.9108 R:95.9108 S:92.3673 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable 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.=20 dbh > -----Original Message----- > From: Edward Beili [mailto:EdwardB@actelis.com]=20 > Sent: Thursday, October 23, 2003 12:20 PM > To: 'Romascanu, Dan (Dan) ' > Cc: 'hubmib@ietf.org '; 'Matt Squire ' > Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB=20 > Internet-Drafts, WG Meetings >=20 >=20 > Dan, >=20 > Here are some arguments for not supporting the EtherLike-MIB > (just for the purpose of argument): >=20 > Let's look at some of the control groups in EtherLike-MIB (rfc-3635): > - dot3PauseTable - The EFMCu interfaces do not support Pause=20 > frames so this > may be omitted. > - dot3Tests - is already deprecated > - dot3Errors - is already deprecated > - dot3ColTable - no collisions on EFMCu >=20 > So this leaves just the dot3ControlTable with currently=20 > supported Pause() > function - see above for applicability. >=20 > The rest are statistics. There are some rudimentary=20 > statistics in the IF-MIB > + interface specific stats in EFM-CU-MIB which could be just=20 > enough for the > trouble shooting. >=20 > The advantage of not implementing EtherLike-MIB - well, not=20 > implementing a > pretty big MIB. >=20 > Regards, > -E. >=20 >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) > To: Edward Beili > Cc: hubmib@ietf.org; Matt Squire=20 > Sent: 23/10/03 17:15 > Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB=20 > Internet-Drafts, > WG Meetings >=20 > 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.=20 >=20 > I would defer the answer at the second question to John Flick - the > editor of the MAU MIB.=20 >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: Edward Beili [mailto:EdwardB@actelis.com] > > Sent: 23 October, 2003 4:56 PM > > To: Romascanu, Dan (Dan) > > Cc: 'hubmib@ietf.org '; 'Matt Squire ' > > Subject: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB=20 > > Internet-Drafts, > > WG Meetings > >=20 > >=20 > > Hi, > >=20 > > I have a question as well - I assume that all new interfaces=20 > > defined in > > the EFM would be considered as Ethernet Like with mandatory=20 > > EtherLike-MIB > > and MAU-MIB implementation. Is this correct? Theoretically we=20 > > could require > > just IF-MIB, considering that most implementors choose not support > > EtherLike-MIB. > >=20 > > We would also need to augment current MAU-MIB with new=20 > > dot3MauType instances > > defined for EPON and Copper interfaces. Do we have to open a=20 > > new version of > > MAU-MIB (and who does it) or there's another way of doing it? > >=20 > > -Edward > >=20 > >=20 > > -----Original Message----- > > From: Matt Squire > > To: Romascanu, Dan (Dan); hubmib@ietf.org > > Cc: stds-802-3-efm@ieee.org > > Sent: 23/10/03 16:01 > > Subject: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings > >=20 > > =20 > > Just speaking for the draft I submitted, it is a very early=20 > draft that > > still has a lot of holes. All input is very appreciated. =20 > > =20 > > In particular, one big nagging question is how these new MIBs are > > organized within the existing MIB heirarchy. For the common=20 > > 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? =20 > > =20 > > Hoping some of you MIB experts can lend some guidance. =20 > > =20 > >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Thursday, October 23, 2003 4:59 AM > > To: hubmib@ietf.org > > Cc: stds-802-3-efm@ieee.org; Bert Wijnen (E-mail) > > Subject: [Hubmib] EFM MIB Internet-Drafts, WG Meetings > >=20 > >=20 > >=20 > > As you have seen in the announcements that went out in the=20 > last couple > > of days, the three individual submission Internet-Drafts=20 > including the > > initial submissions for the EFM MIBs are now available. The relevant > > URLs are: > >=20 > > * > >=20 > http://www.ietf.org/internet-drafts/draft-squire-hubmib-efm-mib-00.txt > > ib-00.txt> >=20 > * > http://www.ietf.org/internet-drafts/draft-beili-hubmib-efm-cu- > mib-00.txt > -mib-00.tx > t>=20 > * > http://www.ietf.org/internet-drafts/draft-khermosh-hubmib-epon > -mib-00.tx > t > n-mib-00.t > xt>=20 >=20 >=20 > First, I would like to thank the editors of the three=20 > documents - Matt, > Edward, and Lior for the effort, and for meeting the submission > deadline. With this we have already accomplished in time the=20 > first item > in our new charter!=20 >=20 > 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 hubmib@ietf.org.=20 >=20 > Third, if there are other contributions, let me know, and prepare them > in Internet-Draft format. Our next milestone is issuing the=20 > first round > of WG Internet-Drafts in December - we need to know if the=20 > three drafts > already published are the only contributions, or there will be other > I-Ds to be considered.=20 >=20 > 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=20 > 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: >=20 > - an interim meeting in Vancouver, BC in January (I do not know the > exact week) co-located with the IEEE 802.3 Interim meeting=20 >=20 > - meeting at the IETF meeting in Seoul, Korea (2/29-3/5) >=20 > Everybody who thinks that they can/will attend one or both of the > meetings - please send me an e-mail - we need a headcount=20 > before making > a decision and engaging in any logistics.=20 >=20 > 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=20 > meeting space in > Vancouver (maybe IEEE 802.3ah can help?). >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Thu Oct 23 12:45:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06379 for ; Thu, 23 Oct 2003 12:45:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACia7-0005Qh-Pb for hubmib-archive@odin.ietf.org; Thu, 23 Oct 2003 12:45:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NGj3Dl020854 for hubmib-archive@odin.ietf.org; Thu, 23 Oct 2003 12:45:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACia5-0005P6-56; Thu, 23 Oct 2003 12:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACiZC-0005DZ-U0 for hubmib@optimus.ietf.org; Thu, 23 Oct 2003 12:44:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06115 for ; Thu, 23 Oct 2003 12:43:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACiZB-0004WY-00 for hubmib@ietf.org; Thu, 23 Oct 2003 12:44:05 -0400 Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1ACiZA-0004WV-00 for hubmib@ietf.org; Thu, 23 Oct 2003 12:44:04 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id MAA19362 for ; Thu, 23 Oct 2003 12:44:37 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma019341; Thu, 23 Oct 03 12:44:19 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 23 Oct 2003 12:43:42 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 23 Oct 2003 12:43:42 -0400 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Oct 2003 12:43:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Date: Thu, 23 Oct 2003 12:43:41 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA0113937F@NHROCMBX1.ets.enterasys.com> Thread-Topic: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Thread-Index: AcOZgYsewH1eVgV+TRelYrwZKPNIEAAAdipA From: "Harrington, David" To: "Edward Beili" , "Romascanu, Dan (Dan) " Cc: , "Matt Squire " X-OriginalArrivalTime: 23 Oct 2003 16:43:42.0528 (UTC) FILETIME=[D1740400:01C39984] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:99.5902 M:89.0982 P:95.9108 R:95.9108 S:92.3673 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable 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.=20 dbh > -----Original Message----- > From: Edward Beili [mailto:EdwardB@actelis.com]=20 > Sent: Thursday, October 23, 2003 12:20 PM > To: 'Romascanu, Dan (Dan) ' > Cc: 'hubmib@ietf.org '; 'Matt Squire ' > Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB=20 > Internet-Drafts, WG Meetings >=20 >=20 > Dan, >=20 > Here are some arguments for not supporting the EtherLike-MIB > (just for the purpose of argument): >=20 > Let's look at some of the control groups in EtherLike-MIB (rfc-3635): > - dot3PauseTable - The EFMCu interfaces do not support Pause=20 > frames so this > may be omitted. > - dot3Tests - is already deprecated > - dot3Errors - is already deprecated > - dot3ColTable - no collisions on EFMCu >=20 > So this leaves just the dot3ControlTable with currently=20 > supported Pause() > function - see above for applicability. >=20 > The rest are statistics. There are some rudimentary=20 > statistics in the IF-MIB > + interface specific stats in EFM-CU-MIB which could be just=20 > enough for the > trouble shooting. >=20 > The advantage of not implementing EtherLike-MIB - well, not=20 > implementing a > pretty big MIB. >=20 > Regards, > -E. >=20 >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) > To: Edward Beili > Cc: hubmib@ietf.org; Matt Squire=20 > Sent: 23/10/03 17:15 > Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB=20 > Internet-Drafts, > WG Meetings >=20 > 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.=20 >=20 > I would defer the answer at the second question to John Flick - the > editor of the MAU MIB.=20 >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: Edward Beili [mailto:EdwardB@actelis.com] > > Sent: 23 October, 2003 4:56 PM > > To: Romascanu, Dan (Dan) > > Cc: 'hubmib@ietf.org '; 'Matt Squire ' > > Subject: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB=20 > > Internet-Drafts, > > WG Meetings > >=20 > >=20 > > Hi, > >=20 > > I have a question as well - I assume that all new interfaces=20 > > defined in > > the EFM would be considered as Ethernet Like with mandatory=20 > > EtherLike-MIB > > and MAU-MIB implementation. Is this correct? Theoretically we=20 > > could require > > just IF-MIB, considering that most implementors choose not support > > EtherLike-MIB. > >=20 > > We would also need to augment current MAU-MIB with new=20 > > dot3MauType instances > > defined for EPON and Copper interfaces. Do we have to open a=20 > > new version of > > MAU-MIB (and who does it) or there's another way of doing it? > >=20 > > -Edward > >=20 > >=20 > > -----Original Message----- > > From: Matt Squire > > To: Romascanu, Dan (Dan); hubmib@ietf.org > > Cc: stds-802-3-efm@ieee.org > > Sent: 23/10/03 16:01 > > Subject: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings > >=20 > > =20 > > Just speaking for the draft I submitted, it is a very early=20 > draft that > > still has a lot of holes. All input is very appreciated. =20 > > =20 > > In particular, one big nagging question is how these new MIBs are > > organized within the existing MIB heirarchy. For the common=20 > > 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? =20 > > =20 > > Hoping some of you MIB experts can lend some guidance. =20 > > =20 > >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Thursday, October 23, 2003 4:59 AM > > To: hubmib@ietf.org > > Cc: stds-802-3-efm@ieee.org; Bert Wijnen (E-mail) > > Subject: [Hubmib] EFM MIB Internet-Drafts, WG Meetings > >=20 > >=20 > >=20 > > As you have seen in the announcements that went out in the=20 > last couple > > of days, the three individual submission Internet-Drafts=20 > including the > > initial submissions for the EFM MIBs are now available. The relevant > > URLs are: > >=20 > > * > >=20 > http://www.ietf.org/internet-drafts/draft-squire-hubmib-efm-mib-00.txt > > ib-00.txt> >=20 > * > http://www.ietf.org/internet-drafts/draft-beili-hubmib-efm-cu- > mib-00.txt > -mib-00.tx > t>=20 > * > http://www.ietf.org/internet-drafts/draft-khermosh-hubmib-epon > -mib-00.tx > t > n-mib-00.t > xt>=20 >=20 >=20 > First, I would like to thank the editors of the three=20 > documents - Matt, > Edward, and Lior for the effort, and for meeting the submission > deadline. With this we have already accomplished in time the=20 > first item > in our new charter!=20 >=20 > 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 hubmib@ietf.org.=20 >=20 > Third, if there are other contributions, let me know, and prepare them > in Internet-Draft format. Our next milestone is issuing the=20 > first round > of WG Internet-Drafts in December - we need to know if the=20 > three drafts > already published are the only contributions, or there will be other > I-Ds to be considered.=20 >=20 > 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=20 > 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: >=20 > - an interim meeting in Vancouver, BC in January (I do not know the > exact week) co-located with the IEEE 802.3 Interim meeting=20 >=20 > - meeting at the IETF meeting in Seoul, Korea (2/29-3/5) >=20 > Everybody who thinks that they can/will attend one or both of the > meetings - please send me an e-mail - we need a headcount=20 > before making > a decision and engaging in any logistics.=20 >=20 > 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=20 > meeting space in > Vancouver (maybe IEEE 802.3ah can help?). >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Oct 23 13:03:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07109 for ; Thu, 23 Oct 2003 13:03:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACirV-0000P1-EQ; Thu, 23 Oct 2003 13:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACiqw-0000FI-Jq for hubmib@optimus.ietf.org; Thu, 23 Oct 2003 13:02:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07085 for ; Thu, 23 Oct 2003 13:02:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACiqu-0004p2-00 for hubmib@ietf.org; Thu, 23 Oct 2003 13:02:24 -0400 Received: from [213.70.90.131] (helo=mail.advaoptical.de) by ietf-mx with esmtp (Exim 4.12) id 1ACiqt-0004oU-00 for hubmib@ietf.org; Thu, 23 Oct 2003 13:02:23 -0400 Received: from adva-mailer.advaoptical.com (unverified) by mail.advaoptical.de (Content Technologies SMTPRS 4.3.1) with ESMTP id ; Thu, 23 Oct 2003 18:54:36 +0200 Received: by adva-mailer.advaoptical.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Oct 2003 19:01:47 +0200 Message-ID: <33BB463469A3D411B08F00508BDD1626E18DCA@ntsyork.yrk.advaoptical.com> From: John Messenger To: "'Matt Squire'" , "Romascanu, Dan (Dan)" , hubmib@ietf.org Cc: "'Kevin Daines'" Subject: RE: [EFM] RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Date: Thu, 23 Oct 2003 19:01:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C39987.5104CE50" Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C39987.5104CE50 Content-Type: text/plain; charset="windows-1255" Hi Matt, Thanks very much for your EFM MIB proposal. I have a few comments, editorial and technical. You use both "Ethernet like" and "Ethernet-like" - I think the latter is better. dot3OamUnidirectionalSupport: could you give an example of when it might be good to be able to write this? Seems to me perhaps better as read-only. dot3OamParserState: in the Description there is a cut-and-paste error: it says "multiplexor" but should say "parser". dot3OamPeerEntry: somehow the Description needs to mention that the information relates to the Peer. dot3OamPeerVendorInfo: Error in 802.3ah! (30.11.1.1.12 D2.1 refers to table 57-10, but should refer to table 57-11). What about traps? Is it usual to define a set of traps, which in this case might correspond with the OAM Events, and traps based on the important bits in the OAM Flags field (critical event, dying gasp, link fault). You have included a commented-out block of config variables for the parameters associated with error reporting. If we have OAM Event traps, then we may need these config variables, otherwise probably not I feel. Regards, -- John John Messenger (JMessenger@advaoptical.com) R&D Manager, Software ADVA Optical Networking Ltd. +44-1904-699309 www.advaoptical.com -----Original Message----- From: Matt Squire [mailto:MSquire@HatterasNetworks.com] Sent: 23 October 2003 15:01 To: Romascanu, Dan (Dan); hubmib@ietf.org Cc: stds-802-3-efm@ieee.org Subject: [EFM] 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. ------_=_NextPart_001_01C39987.5104CE50 Content-Type: text/html; charset="windows-1255" EFM MIB Internet-Drafts, WG Meetings

Hi Matt,

Thanks very much for your EFM MIB proposal. I have a few comments, editorial and technical.

You use both "Ethernet like" and "Ethernet-like" - I think the latter is better.

dot3OamUnidirectionalSupport: could you give an example of when it might be good to be able to write this? Seems to me perhaps better as read-only.

dot3OamParserState: in the Description there is a cut-and-paste error: it says "multiplexor" but should say "parser".

dot3OamPeerEntry: somehow the Description needs to mention that the information relates to the Peer.

dot3OamPeerVendorInfo: Error in 802.3ah! (30.11.1.1.12 D2.1 refers to table 57-10, but should refer to table 57-11).

What about traps? Is it usual to define a set of traps, which in this case might correspond with the OAM Events, and traps based on the important bits in the OAM Flags field (critical event, dying gasp, link fault).

You have included a commented-out block of config variables for the parameters associated with error reporting. If we have OAM Event traps, then we may need these config variables, otherwise probably not I feel.

Regards,

-- John

John Messenger (JMessenger@advaoptical.com)
R&D Manager, Software
ADVA Optical Networking Ltd.
+44-1904-699309
www.advaoptical.com

-----Original Message-----
From: Matt Squire [mailto:MSquire@HatterasNetworks.com]
Sent: 23 October 2003 15:01
To: Romascanu, Dan (Dan); hubmib@ietf.org
Cc: stds-802-3-efm@ieee.org
Subject: [EFM] 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.

Hi Matt,

Thanks very much for your EFM MIB proposal. I have a few comments, editorial and technical.

You use both "Ethernet like" and "Ethernet-like" - I think the latter is better.

dot3OamUnidirectionalSupport: could you give an example of when it might be good to be able to write this? Seems to me perhaps better as read-only.

dot3OamParserState: in the Description there is a cut-and-paste error: it says "multiplexor" but should say "parser".

dot3OamPeerEntry: somehow the Description needs to mention that the information relates to the Peer.

dot3OamPeerVendorInfo: Error in 802.3ah! (30.11.1.1.12 D2.1 refers to table 57-10, but should refer to table 57-11).

Regards,

-- John

John Messenger (JMessenger@advaoptical.com)
R&D Manager, Software
ADVA Optical Networking Ltd.
+44-1904-699309
www.advaoptical.com

-----Original Message-----
From: Matt Squire [mailto:MSquire@HatterasNetworks.com]
Sent: 23 October 2003 15:01
To: Romascanu, Dan (Dan); hubmib@ietf.org
Cc: stds-802-3-efm@ieee.org
Subject: [EFM] 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.

------_=_NextPart_001_01C39987.5104CE50-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Oct 27 09:48:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16788 for ; Mon, 27 Oct 2003 09:48:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8f2-0001fB-KD; Mon, 27 Oct 2003 09:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8eC-0001cD-DC for hubmib@optimus.ietf.org; Mon, 27 Oct 2003 09:47:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16710 for ; Mon, 27 Oct 2003 09:46:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE8eA-00061z-00 for hubmib@ietf.org; Mon, 27 Oct 2003 09:47:06 -0500 Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx with esmtp (Exim 4.12) id 1AE8e9-00061C-00 for hubmib@ietf.org; Mon, 27 Oct 2003 09:47:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Date: Mon, 27 Oct 2003 09:46:33 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA39971401D901D0@mailserv.hatteras.com> Thread-Topic: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Thread-Index: AcOZgVCC/Y5nfLRAS7S1bYTzPQpfigDF251g From: "Matt Squire" To: "Edward Beili" , "Romascanu, Dan (Dan) " Cc: Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Dan, >=20 > Here are some arguments for not supporting the EtherLike-MIB > (just for the purpose of argument): >=20 > Let's look at some of the control groups in EtherLike-MIB (rfc-3635): > - dot3PauseTable - The EFMCu interfaces do not support Pause=20 > frames so this > may be omitted. I don't know this is true. I know that it is discussed that PAUSE can = slow down or interfere with OAM operation on Ethernet links. But = nothing really stops one from implementing PAUSE if they wanted to. =20 > - dot3Tests - is already deprecated > - dot3Errors - is already deprecated > - dot3ColTable - no collisions on EFMCu >=20 > So this leaves just the dot3ControlTable with currently=20 > supported Pause() > function - see above for applicability. >=20 > The rest are statistics. There are some rudimentary=20 > statistics in the IF-MIB > + interface specific stats in EFM-CU-MIB which could be just=20 > enough for the > trouble shooting. >=20 The Ethernet stats were developed over a number of years, mostly with = good reason. Throwing them away and just going with IF-MIB is quick but = short-sighted. =20 > The advantage of not implementing EtherLike-MIB - well, not=20 > implementing a > pretty big MIB. >=20 > Regards, > -E. >=20 >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) > To: Edward Beili > Cc: hubmib@ietf.org; Matt Squire=20 > Sent: 23/10/03 17:15 > Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB=20 > Internet-Drafts, > WG Meetings >=20 > 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.=20 >=20 > I would defer the answer at the second question to John Flick - the > editor of the MAU MIB.=20 >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: Edward Beili [mailto:EdwardB@actelis.com] > > Sent: 23 October, 2003 4:56 PM > > To: Romascanu, Dan (Dan) > > Cc: 'hubmib@ietf.org '; 'Matt Squire ' > > Subject: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB=20 > > Internet-Drafts, > > WG Meetings > >=20 > >=20 > > Hi, > >=20 > > I have a question as well - I assume that all new interfaces=20 > > defined in > > the EFM would be considered as Ethernet Like with mandatory=20 > > EtherLike-MIB > > and MAU-MIB implementation. Is this correct? Theoretically we=20 > > could require > > just IF-MIB, considering that most implementors choose not support > > EtherLike-MIB. > >=20 > > We would also need to augment current MAU-MIB with new=20 > > dot3MauType instances > > defined for EPON and Copper interfaces. Do we have to open a=20 > > new version of > > MAU-MIB (and who does it) or there's another way of doing it? > >=20 > > -Edward > >=20 > >=20 > > -----Original Message----- > > From: Matt Squire > > To: Romascanu, Dan (Dan); hubmib@ietf.org > > Cc: stds-802-3-efm@ieee.org > > Sent: 23/10/03 16:01 > > Subject: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings > >=20 > > =20 > > Just speaking for the draft I submitted, it is a very early=20 > draft that > > still has a lot of holes. All input is very appreciated. =20 > > =20 > > In particular, one big nagging question is how these new MIBs are > > organized within the existing MIB heirarchy. For the common=20 > > 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? =20 > > =20 > > Hoping some of you MIB experts can lend some guidance. =20 > > =20 > >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Thursday, October 23, 2003 4:59 AM > > To: hubmib@ietf.org > > Cc: stds-802-3-efm@ieee.org; Bert Wijnen (E-mail) > > Subject: [Hubmib] EFM MIB Internet-Drafts, WG Meetings > >=20 > >=20 > >=20 > > As you have seen in the announcements that went out in the=20 > last couple > > of days, the three individual submission Internet-Drafts=20 > including the > > initial submissions for the EFM MIBs are now available. The relevant > > URLs are: > >=20 > > * > >=20 http://www.ietf.org/internet-drafts/draft-squire-hubmib-efm-mib-00.txt > * http://www.ietf.org/internet-drafts/draft-beili-hubmib-efm-cu-mib-00.txt =20 * http://www.ietf.org/internet-drafts/draft-khermosh-hubmib-epon-mib-00.tx t =20 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!=20 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 hubmib@ietf.org.=20 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.=20 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=20 - 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.=20 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 Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Oct 27 09:48:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16804 for ; Mon, 27 Oct 2003 09:48:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8f3-0001fc-Ee for hubmib-archive@odin.ietf.org; Mon, 27 Oct 2003 09:48:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9REm18B006410 for hubmib-archive@odin.ietf.org; Mon, 27 Oct 2003 09:48:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8f2-0001fB-KD; Mon, 27 Oct 2003 09:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8eC-0001cD-DC for hubmib@optimus.ietf.org; Mon, 27 Oct 2003 09:47:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16710 for ; Mon, 27 Oct 2003 09:46:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE8eA-00061z-00 for hubmib@ietf.org; Mon, 27 Oct 2003 09:47:06 -0500 Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx with esmtp (Exim 4.12) id 1AE8e9-00061C-00 for hubmib@ietf.org; Mon, 27 Oct 2003 09:47:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Date: Mon, 27 Oct 2003 09:46:33 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA39971401D901D0@mailserv.hatteras.com> Thread-Topic: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Thread-Index: AcOZgVCC/Y5nfLRAS7S1bYTzPQpfigDF251g From: "Matt Squire" To: "Edward Beili" , "Romascanu, Dan (Dan) " Cc: Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Dan, >=20 > Here are some arguments for not supporting the EtherLike-MIB > (just for the purpose of argument): >=20 > Let's look at some of the control groups in EtherLike-MIB (rfc-3635): > - dot3PauseTable - The EFMCu interfaces do not support Pause=20 > frames so this > may be omitted. I don't know this is true. I know that it is discussed that PAUSE can = slow down or interfere with OAM operation on Ethernet links. But = nothing really stops one from implementing PAUSE if they wanted to. =20 > - dot3Tests - is already deprecated > - dot3Errors - is already deprecated > - dot3ColTable - no collisions on EFMCu >=20 > So this leaves just the dot3ControlTable with currently=20 > supported Pause() > function - see above for applicability. >=20 > The rest are statistics. There are some rudimentary=20 > statistics in the IF-MIB > + interface specific stats in EFM-CU-MIB which could be just=20 > enough for the > trouble shooting. >=20 The Ethernet stats were developed over a number of years, mostly with = good reason. Throwing them away and just going with IF-MIB is quick but = short-sighted. =20 > The advantage of not implementing EtherLike-MIB - well, not=20 > implementing a > pretty big MIB. >=20 > Regards, > -E. >=20 >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) > To: Edward Beili > Cc: hubmib@ietf.org; Matt Squire=20 > Sent: 23/10/03 17:15 > Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB=20 > Internet-Drafts, > WG Meetings >=20 > 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.=20 >=20 > I would defer the answer at the second question to John Flick - the > editor of the MAU MIB.=20 >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: Edward Beili [mailto:EdwardB@actelis.com] > > Sent: 23 October, 2003 4:56 PM > > To: Romascanu, Dan (Dan) > > Cc: 'hubmib@ietf.org '; 'Matt Squire ' > > Subject: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB=20 > > Internet-Drafts, > > WG Meetings > >=20 > >=20 > > Hi, > >=20 > > I have a question as well - I assume that all new interfaces=20 > > defined in > > the EFM would be considered as Ethernet Like with mandatory=20 > > EtherLike-MIB > > and MAU-MIB implementation. Is this correct? Theoretically we=20 > > could require > > just IF-MIB, considering that most implementors choose not support > > EtherLike-MIB. > >=20 > > We would also need to augment current MAU-MIB with new=20 > > dot3MauType instances > > defined for EPON and Copper interfaces. Do we have to open a=20 > > new version of > > MAU-MIB (and who does it) or there's another way of doing it? > >=20 > > -Edward > >=20 > >=20 > > -----Original Message----- > > From: Matt Squire > > To: Romascanu, Dan (Dan); hubmib@ietf.org > > Cc: stds-802-3-efm@ieee.org > > Sent: 23/10/03 16:01 > > Subject: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings > >=20 > > =20 > > Just speaking for the draft I submitted, it is a very early=20 > draft that > > still has a lot of holes. All input is very appreciated. =20 > > =20 > > In particular, one big nagging question is how these new MIBs are > > organized within the existing MIB heirarchy. For the common=20 > > 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? =20 > > =20 > > Hoping some of you MIB experts can lend some guidance. =20 > > =20 > >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Thursday, October 23, 2003 4:59 AM > > To: hubmib@ietf.org > > Cc: stds-802-3-efm@ieee.org; Bert Wijnen (E-mail) > > Subject: [Hubmib] EFM MIB Internet-Drafts, WG Meetings > >=20 > >=20 > >=20 > > As you have seen in the announcements that went out in the=20 > last couple > > of days, the three individual submission Internet-Drafts=20 > including the > > initial submissions for the EFM MIBs are now available. The relevant > > URLs are: > >=20 > > * > >=20 http://www.ietf.org/internet-drafts/draft-squire-hubmib-efm-mib-00.txt > * http://www.ietf.org/internet-drafts/draft-beili-hubmib-efm-cu-mib-00.txt =20 * http://www.ietf.org/internet-drafts/draft-khermosh-hubmib-epon-mib-00.tx t =20 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!=20 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 hubmib@ietf.org.=20 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.=20 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=20 - 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.=20 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 Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Oct 27 09:59:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17364 for ; Mon, 27 Oct 2003 09:59:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8pg-0002wt-Tl; Mon, 27 Oct 2003 09:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8ok-0002sc-NN for hubmib@optimus.ietf.org; Mon, 27 Oct 2003 09:58:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17283 for ; Mon, 27 Oct 2003 09:57:50 -0500 (EST) From: Michael.Beck@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE8oi-00068Z-00 for hubmib@ietf.org; Mon, 27 Oct 2003 09:58:00 -0500 Received: from alc250.alcatel.be ([195.207.101.250] helo=bt0g2p.god.bel.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 1AE8oh-00068E-00 for hubmib@ietf.org; Mon, 27 Oct 2003 09:58:00 -0500 Received: from bemail03.net.alcatel.be (bemail03.net.alcatel.be [138.203.147.7]) by bt0g2p.god.bel.alcatel.be (8.12.10/8.12.10) with ESMTP id h9RD0cr2001036; Mon, 27 Oct 2003 14:00:38 +0100 Received: from alcatel.be ([138.203.64.125]) by bemail03.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003102715572437:2165 ; Mon, 27 Oct 2003 15:57:24 +0100 Message-ID: <3F9D3253.C9F9E42A@alcatel.be> Date: Mon, 27 Oct 2003 15:57:23 +0100 Organization: Alcatel R&I X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Matt Squire Cc: Edward Beili , "Romascanu, Dan (Dan)" , hubmib@ietf.org Subject: Re: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings References: <8052E2EA753D144EB906B7A7AA39971401D901D0@mailserv.hatteras.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL03/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 10/27/2003 15:57:24, Serialize by Router on BEMAIL03/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 10/27/2003 15:57:25, Serialize complete at 10/27/2003 15:57:25 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.37 Content-Transfer-Encoding: 7bit Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Matt, Since EFMCu uses the half-duplex mode of the MAC to do MAC-PHY rate matching, PAUSE frames cannot be used. The current text of the draft (D2.1) states: "Both EFM Copper port PHYs are only defined for full duplex operation (notwithstanding the definition of PHY-MAC Rate Matching (see 61.2.1) which requires that the MAC operates in half-duplex mode for the purposes of flow control). PAUSE frame transmission via EFM Copper PHYs is therefore precluded, since the requirements of 31B.1 (see Clause 31) restrict the transmission of PAUSE frames to DTEs configured to the full duplex mode of operation." Regards, Michael Beck Editor, EFM/Copper Matt Squire wrote: > > > 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. > > I don't know this is true. I know that it is discussed that PAUSE can slow down or interfere with OAM operation on Ethernet links. But nothing really stops one from implementing PAUSE if they wanted to. _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Oct 27 09:59:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17380 for ; Mon, 27 Oct 2003 09:59:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8ph-0002xo-Ju for hubmib-archive@odin.ietf.org; Mon, 27 Oct 2003 09:59:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9REx10I011346 for hubmib-archive@odin.ietf.org; Mon, 27 Oct 2003 09:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8pg-0002wt-Tl; Mon, 27 Oct 2003 09:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8ok-0002sc-NN for hubmib@optimus.ietf.org; Mon, 27 Oct 2003 09:58:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17283 for ; Mon, 27 Oct 2003 09:57:50 -0500 (EST) From: Michael.Beck@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE8oi-00068Z-00 for hubmib@ietf.org; Mon, 27 Oct 2003 09:58:00 -0500 Received: from alc250.alcatel.be ([195.207.101.250] helo=bt0g2p.god.bel.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 1AE8oh-00068E-00 for hubmib@ietf.org; Mon, 27 Oct 2003 09:58:00 -0500 Received: from bemail03.net.alcatel.be (bemail03.net.alcatel.be [138.203.147.7]) by bt0g2p.god.bel.alcatel.be (8.12.10/8.12.10) with ESMTP id h9RD0cr2001036; Mon, 27 Oct 2003 14:00:38 +0100 Received: from alcatel.be ([138.203.64.125]) by bemail03.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003102715572437:2165 ; Mon, 27 Oct 2003 15:57:24 +0100 Message-ID: <3F9D3253.C9F9E42A@alcatel.be> Date: Mon, 27 Oct 2003 15:57:23 +0100 Organization: Alcatel R&I X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Matt Squire Cc: Edward Beili , "Romascanu, Dan (Dan)" , hubmib@ietf.org Subject: Re: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings References: <8052E2EA753D144EB906B7A7AA39971401D901D0@mailserv.hatteras.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL03/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 10/27/2003 15:57:24, Serialize by Router on BEMAIL03/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 10/27/2003 15:57:25, Serialize complete at 10/27/2003 15:57:25 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.37 Content-Transfer-Encoding: 7bit Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Matt, Since EFMCu uses the half-duplex mode of the MAC to do MAC-PHY rate matching, PAUSE frames cannot be used. The current text of the draft (D2.1) states: "Both EFM Copper port PHYs are only defined for full duplex operation (notwithstanding the definition of PHY-MAC Rate Matching (see 61.2.1) which requires that the MAC operates in half-duplex mode for the purposes of flow control). PAUSE frame transmission via EFM Copper PHYs is therefore precluded, since the requirements of 31B.1 (see Clause 31) restrict the transmission of PAUSE frames to DTEs configured to the full duplex mode of operation." Regards, Michael Beck Editor, EFM/Copper Matt Squire wrote: > > > 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. > > I don't know this is true. I know that it is discussed that PAUSE can slow down or interfere with OAM operation on Ethernet links. But nothing really stops one from implementing PAUSE if they wanted to. _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Oct 27 10:14:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19028 for ; Mon, 27 Oct 2003 10:14:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE94D-0004pO-7c; Mon, 27 Oct 2003 10:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE93t-0004o8-2y for hubmib@optimus.ietf.org; Mon, 27 Oct 2003 10:13:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18944 for ; Mon, 27 Oct 2003 10:13:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE93q-0006P8-00 for hubmib@ietf.org; Mon, 27 Oct 2003 10:13:38 -0500 Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx with esmtp (Exim 4.12) id 1AE93q-0006Ob-00 for hubmib@ietf.org; Mon, 27 Oct 2003 10:13:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [EFM] RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Date: Mon, 27 Oct 2003 10:13:08 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA399714E5F934@mailserv.hatteras.com> Thread-Topic: [EFM] RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Thread-Index: AcOZh1m9miL+AN1wTQS4tYQN0f+uhADEePRg From: "Matt Squire" To: "John Messenger" , "Romascanu, Dan (Dan)" , Cc: "Kevin Daines" Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Thanks very much for your EFM MIB proposal. I have a few comments, = editorial and technical. Thanks a bunch. =20 > You use both "Ethernet like" and "Ethernet-like" - I think the latter = is better. Can do. > dot3OamUnidirectionalSupport: could you give an example of when it = might be good to be able to write this? Seems to me perhaps better as = read-only. Probably right. I couldn't justify it when I wrote it. =20 > dot3OamParserState: in the Description there is a cut-and-paste error: = it says "multiplexor" but should say "parser". Will fix.=20 > dot3OamPeerEntry: somehow the Description needs to mention that the = information relates to the Peer. Can do. > dot3OamPeerVendorInfo: Error in 802.3ah! (30.11.1.1.12 D2.1 refers to = table 57-10, but should refer to table 57-11). There's a comment cycle open, so hopefully one of us can log this. > What about traps? Is it usual to define a set of traps, which in this = case might correspond with the OAM Events, and traps based on the = important bits in the OAM Flags field (critical event, dying gasp, link = fault). Yea, I wasnt sure at the time what to do with events (which is why I = skipped that part the first go-round). My expectation is that there = will be a set of traps defined for the events. It just gets tricky when = you have non-standard events happening. I assume I'll end up defining a = "organization specific trap" for each of the organization specific = event.=20 > You have included a commented-out block of config variables for the = parameters associated with error reporting. If we have OAM Event traps, = then we may need these config variables, otherwise probably not I feel. Agreed. Since I didn't fill in the event part, I felt it was premature = to include the other part. But I also didn't want to delete and forget = it. So its there commented out. But it will (hopefully) be consistent = and uncommented in the next revision. =20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Oct 27 10:14:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19049 for ; Mon, 27 Oct 2003 10:14:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE94D-0004pu-DY for hubmib-archive@odin.ietf.org; Mon, 27 Oct 2003 10:14:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RFE13s018575 for hubmib-archive@odin.ietf.org; Mon, 27 Oct 2003 10:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE94D-0004pO-7c; Mon, 27 Oct 2003 10:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE93t-0004o8-2y for hubmib@optimus.ietf.org; Mon, 27 Oct 2003 10:13:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18944 for ; Mon, 27 Oct 2003 10:13:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE93q-0006P8-00 for hubmib@ietf.org; Mon, 27 Oct 2003 10:13:38 -0500 Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx with esmtp (Exim 4.12) id 1AE93q-0006Ob-00 for hubmib@ietf.org; Mon, 27 Oct 2003 10:13:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [EFM] RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Date: Mon, 27 Oct 2003 10:13:08 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA399714E5F934@mailserv.hatteras.com> Thread-Topic: [EFM] RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Thread-Index: AcOZh1m9miL+AN1wTQS4tYQN0f+uhADEePRg From: "Matt Squire" To: "John Messenger" , "Romascanu, Dan (Dan)" , Cc: "Kevin Daines" Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > Thanks very much for your EFM MIB proposal. I have a few comments, = editorial and technical. Thanks a bunch. =20 > You use both "Ethernet like" and "Ethernet-like" - I think the latter = is better. Can do. > dot3OamUnidirectionalSupport: could you give an example of when it = might be good to be able to write this? Seems to me perhaps better as = read-only. Probably right. I couldn't justify it when I wrote it. =20 > dot3OamParserState: in the Description there is a cut-and-paste error: = it says "multiplexor" but should say "parser". Will fix.=20 > dot3OamPeerEntry: somehow the Description needs to mention that the = information relates to the Peer. Can do. > dot3OamPeerVendorInfo: Error in 802.3ah! (30.11.1.1.12 D2.1 refers to = table 57-10, but should refer to table 57-11). There's a comment cycle open, so hopefully one of us can log this. > What about traps? Is it usual to define a set of traps, which in this = case might correspond with the OAM Events, and traps based on the = important bits in the OAM Flags field (critical event, dying gasp, link = fault). Yea, I wasnt sure at the time what to do with events (which is why I = skipped that part the first go-round). My expectation is that there = will be a set of traps defined for the events. It just gets tricky when = you have non-standard events happening. I assume I'll end up defining a = "organization specific trap" for each of the organization specific = event.=20 > You have included a commented-out block of config variables for the = parameters associated with error reporting. If we have OAM Event traps, = then we may need these config variables, otherwise probably not I feel. Agreed. Since I didn't fill in the event part, I felt it was premature = to include the other part. But I also didn't want to delete and forget = it. So its there commented out. But it will (hopefully) be consistent = and uncommented in the next revision. =20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Oct 27 10:15:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19159 for ; Mon, 27 Oct 2003 10:15:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE95C-0004wG-AO for hubmib-archive@odin.ietf.org; Mon, 27 Oct 2003 10:15:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RFF2om018927 for hubmib-archive@odin.ietf.org; Mon, 27 Oct 2003 10:15:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE95C-0004v9-0q; Mon, 27 Oct 2003 10:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE94T-0004rl-Sn for hubmib@optimus.ietf.org; Mon, 27 Oct 2003 10:14:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19004 for ; Mon, 27 Oct 2003 10:14:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE94R-0006PK-00 for hubmib@ietf.org; Mon, 27 Oct 2003 10:14:15 -0500 Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx with esmtp (Exim 4.12) id 1AE94R-0006PB-00 for hubmib@ietf.org; Mon, 27 Oct 2003 10:14:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Date: Mon, 27 Oct 2003 10:13:45 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA39971401D901D2@mailserv.hatteras.com> Thread-Topic: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Thread-Index: AcOcmqPgE3h+QjviRRi2nU5WkxiUrgAAjxww From: "Matt Squire" To: Cc: "Edward Beili" , "Romascanu, Dan (Dan)" , Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Yep, my bad. Forgot about that half-dup stuff. =20 - Matt > -----Original Message----- > From: Michael.Beck@alcatel.be [mailto:Michael.Beck@alcatel.be] > Sent: Monday, October 27, 2003 9:57 AM > To: Matt Squire > Cc: Edward Beili; Romascanu, Dan (Dan); hubmib@ietf.org > Subject: Re: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB > Internet-Drafts, WG Meetings >=20 >=20 > Matt, >=20 > Since EFMCu uses the half-duplex mode of the MAC to do MAC-PHY rate > matching, PAUSE frames cannot be used. The current text of the draft > (D2.1) states: >=20 > "Both EFM Copper port PHYs are only defined for full duplex operation > (notwithstanding the definition of PHY-MAC Rate Matching (see 61.2.1) > which requires that the MAC operates in half-duplex mode for=20 > the purposes > of flow control). PAUSE frame transmission via EFM Copper PHYs is > therefore precluded, since the requirements of 31B.1 (see Clause 31) > restrict the transmission of PAUSE frames to DTEs configured=20 > to the full > duplex mode of operation." >=20 > Regards, >=20 > Michael Beck > Editor, EFM/Copper >=20 > Matt Squire wrote: > >=20 > > > 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=20 > (rfc-3635): > > > - dot3PauseTable - The EFMCu interfaces do not support Pause > > > frames so this > > > may be omitted. > >=20 > > I don't know this is true. I know that it is discussed=20 > that PAUSE can slow down or interfere with OAM operation on=20 > Ethernet links. But nothing really stops one from=20 > implementing PAUSE if they wanted to. >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Oct 27 11:09:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19157 for ; Mon, 27 Oct 2003 10:15:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE95C-0004v9-0q; Mon, 27 Oct 2003 10:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE94T-0004rl-Sn for hubmib@optimus.ietf.org; Mon, 27 Oct 2003 10:14:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19004 for ; Mon, 27 Oct 2003 10:14:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE94R-0006PK-00 for hubmib@ietf.org; Mon, 27 Oct 2003 10:14:15 -0500 Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx with esmtp (Exim 4.12) id 1AE94R-0006PB-00 for hubmib@ietf.org; Mon, 27 Oct 2003 10:14:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Date: Mon, 27 Oct 2003 10:13:45 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA39971401D901D2@mailserv.hatteras.com> Thread-Topic: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings Thread-Index: AcOcmqPgE3h+QjviRRi2nU5WkxiUrgAAjxww From: "Matt Squire" To: Cc: "Edward Beili" , "Romascanu, Dan (Dan)" , Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Yep, my bad. Forgot about that half-dup stuff. =20 - Matt > -----Original Message----- > From: Michael.Beck@alcatel.be [mailto:Michael.Beck@alcatel.be] > Sent: Monday, October 27, 2003 9:57 AM > To: Matt Squire > Cc: Edward Beili; Romascanu, Dan (Dan); hubmib@ietf.org > Subject: Re: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB > Internet-Drafts, WG Meetings >=20 >=20 > Matt, >=20 > Since EFMCu uses the half-duplex mode of the MAC to do MAC-PHY rate > matching, PAUSE frames cannot be used. The current text of the draft > (D2.1) states: >=20 > "Both EFM Copper port PHYs are only defined for full duplex operation > (notwithstanding the definition of PHY-MAC Rate Matching (see 61.2.1) > which requires that the MAC operates in half-duplex mode for=20 > the purposes > of flow control). PAUSE frame transmission via EFM Copper PHYs is > therefore precluded, since the requirements of 31B.1 (see Clause 31) > restrict the transmission of PAUSE frames to DTEs configured=20 > to the full > duplex mode of operation." >=20 > Regards, >=20 > Michael Beck > Editor, EFM/Copper >=20 > Matt Squire wrote: > >=20 > > > 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=20 > (rfc-3635): > > > - dot3PauseTable - The EFMCu interfaces do not support Pause > > > frames so this > > > may be omitted. > >=20 > > I don't know this is true. I know that it is discussed=20 > that PAUSE can slow down or interfere with OAM operation on=20 > Ethernet links. But nothing really stops one from=20 > implementing PAUSE if they wanted to. >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Tue Oct 28 08:18:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19259 for ; Tue, 28 Oct 2003 08:18:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AETjV-0001Mg-9I; Tue, 28 Oct 2003 08:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AETjL-0001LA-JW for hubmib@optimus.ietf.org; Tue, 28 Oct 2003 08:17:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19245 for ; Tue, 28 Oct 2003 08:17:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AETjK-0002Xq-00 for hubmib@ietf.org; Tue, 28 Oct 2003 08:17:50 -0500 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1AETjJ-0002XV-00 for hubmib@ietf.org; Tue, 28 Oct 2003 08:17:50 -0500 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Oct 2003 15:19:53 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF2741CC2@il-mail02.actelis.net> From: Edward Beili To: "'Matt Squire'" , "Romascanu, Dan (Dan) " Cc: hubmib@ietf.org Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Draft s, WG Meetings Date: Tue, 28 Oct 2003 15:19:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Dan, Matt, While I don't have any strong feelings against EtherLike-MIB I do think that its usefulness in case of EFMCu interfaces is a bit exaggerated. I already went through the Control variables. Let's look at the statistics. Dot3StatsEntry: - dot3StatsIndex - ifIndex - dot3StatsAlignmentErrors - would probably be always 0 for EFMCu, as EFMCu framer is octet aligned. - dot3StatsFCSErrors - - dot3StatsSingleCollisionFrames - always 0, no collisions in EFMCu - dot3StatsMultipleCollisionFrames - always 0, no collisions in EFMCu - dot3StatsSQETestErrors - always 0, Full-Duplex - dot3StatsDeferredTransmissions - always 0, Full-Duplex - dot3StatsLateCollisions - always 0, no collisions in EFMCu - dot3StatsExcessiveCollisions - always 0, no collisions in EFMCu - dot3StatsInternalMacTransmitErrors - implementation specific would probably be 0. - dot3StatsCarrierSenseErrors - always 0, Full-duplex - dot3StatsFrameTooLongs - - dot3StatsInternalMacReceiveErrors - implementation specific would probably be 0. - dot3StatsEtherChipSet - deprecated - dot3StatsSymbolErrors - - dot3StatsDuplexStatus - redundant, given in ifMautype always Full-Duplex - dot3StatsRateControlAbility - always No - dot3StatsRateControlStatus - always Disabled Dot3HCStatsEntry is not required for EFMCu interfaces as they are below 100Mbps. So in the end we have only 3 counters that have any meaning for an EFMCu interface: dot3StatsFCSErrors, dot3StatsFrameTooLongs dot3StatsSymbolErrors I agree these are important statistics. However we may decide to provide them in the EFM-CU-MIB, especially taking into consideration that textual description for these counters should be updated to include EFMCu specific explanation (e.g. for dot3StatsSymbolErrors). What do you think? -Edward > -----Original Message----- > From: Matt Squire [mailto:MSquire@HatterasNetworks.com] > Sent: Monday, October 27, 2003 04:47 PM > To: Edward Beili; Romascanu, Dan (Dan) > Cc: hubmib@ietf.org > 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. > > I don't know this is true. I know that it is discussed that > PAUSE can slow down or interfere with OAM operation on > Ethernet links. But nothing really stops one from > implementing PAUSE if they wanted to. > > > - 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 Ethernet stats were developed over a number of years, > mostly with good reason. Throwing them away and just going > with IF-MIB is quick but short-sighted. > > > 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: hubmib@ietf.org; 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:EdwardB@actelis.com] > > > Sent: 23 October, 2003 4:56 PM > > > To: Romascanu, Dan (Dan) > > > Cc: 'hubmib@ietf.org '; '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); hubmib@ietf.org > > > Cc: stds-802-3-efm@ieee.org > > > 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:dromasca@avaya.com] > > > Sent: Thursday, October 23, 2003 4:59 AM > > > To: hubmib@ietf.org > > > Cc: stds-802-3-efm@ieee.org; 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 > > ib-00.txt> > > * > http://www.ietf.org/internet-drafts/draft-beili-hubmib-efm-cu- > mib-00.txt > -mib-00.tx > t> > * > http://www.ietf.org/internet-drafts/draft-khermosh-hubmib-epon > -mib-00.tx > t > 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 hubmib@ietf.org. > > 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 Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Tue Oct 28 08:18:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19261 for ; Tue, 28 Oct 2003 08:18:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AETjV-0001My-NJ for hubmib-archive@odin.ietf.org; Tue, 28 Oct 2003 08:18:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SDI1to005263 for hubmib-archive@odin.ietf.org; Tue, 28 Oct 2003 08:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AETjV-0001Mg-9I; Tue, 28 Oct 2003 08:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AETjL-0001LA-JW for hubmib@optimus.ietf.org; Tue, 28 Oct 2003 08:17:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19245 for ; Tue, 28 Oct 2003 08:17:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AETjK-0002Xq-00 for hubmib@ietf.org; Tue, 28 Oct 2003 08:17:50 -0500 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1AETjJ-0002XV-00 for hubmib@ietf.org; Tue, 28 Oct 2003 08:17:50 -0500 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Oct 2003 15:19:53 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF2741CC2@il-mail02.actelis.net> From: Edward Beili