From hubmib-bounces@ietf.org Wed May 03 07:31:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbFZy-00089w-Du; Wed, 03 May 2006 07:31:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbFZx-00089q-Tp for hubmib@ietf.org; Wed, 03 May 2006 07:31:37 -0400 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbFZw-0003LD-LE for hubmib@ietf.org; Wed, 03 May 2006 07:31:37 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k43BV7Mr014417 for ; Wed, 3 May 2006 07:31:08 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Wed, 3 May 2006 14:31:32 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Photo Thread-Index: AcZupSDfSZ/6inxnS/+OqmRi7NNccgAAAAIp From: "Romascanu, Dan \(Dan\)" To: "hubmib" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Hubmib] Out of Office AutoReply: Photo X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0246869027==" Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============0246869027== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66EA5.20E726D2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66EA5.20E726D2 Content-Type: text/plain; charset="Windows-1255" Content-Transfer-Encoding: quoted-printable I am out-of-office, travelling at a standards meeting, until May 7, = 2006. I may be late in reading and answering your mail. If you need to = contact me urgently, please leave a message at my office voice mail. Regards, Dan ------_=_NextPart_001_01C66EA5.20E726D2 Content-Type: text/html; charset="Windows-1255" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply: Photo

I am out-of-office, travelling at a standards meeting, = until May 7, 2006.  I may be late in reading and answering your = mail.  If you need to contact me urgently, please leave a message = at my office voice mail.

Regards,

Dan

------_=_NextPart_001_01C66EA5.20E726D2-- --===============0246869027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============0246869027==-- From hubmib-bounces@ietf.org Wed May 03 15:53:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbNPH-0002iA-Gc; Wed, 03 May 2006 15:53:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbNPF-0002aS-OB for hubmib@ietf.org; Wed, 03 May 2006 15:53:05 -0400 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbNPE-0007TR-FK for hubmib@ietf.org; Wed, 03 May 2006 15:53:05 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k43JqYsZ023404 for ; Wed, 3 May 2006 15:52:35 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Wed, 3 May 2006 22:53:02 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DSC-00465.jpg Thread-Index: AcZu6y/M/dN2XUH9Q5mVjMHf30umngAAAAC9 From: "Romascanu, Dan \(Dan\)" To: "hubmib" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Hubmib] Out of Office AutoReply: DSC-00465.jpg X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1295492966==" Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============1295492966== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66EEB.2FCE72BD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66EEB.2FCE72BD Content-Type: text/plain; charset="Windows-1255" Content-Transfer-Encoding: quoted-printable I am out-of-office, travelling at a standards meeting, until May 7, = 2006. I may be late in reading and answering your mail. If you need to = contact me urgently, please leave a message at my office voice mail. Regards, Dan ------_=_NextPart_001_01C66EEB.2FCE72BD Content-Type: text/html; charset="Windows-1255" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply: DSC-00465.jpg

I am out-of-office, travelling at a standards meeting, = until May 7, 2006.  I may be late in reading and answering your = mail.  If you need to contact me urgently, please leave a message = at my office voice mail.

Regards,

Dan

------_=_NextPart_001_01C66EEB.2FCE72BD-- --===============1295492966== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============1295492966==-- From hubmib-bounces@ietf.org Sun May 07 12:47:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcmPz-00007X-WE; Sun, 07 May 2006 12:47:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcmPz-00007R-18 for hubmib@ietf.org; Sun, 07 May 2006 12:47:39 -0400 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcmPx-0003kJ-Oi for hubmib@ietf.org; Sun, 07 May 2006 12:47:39 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k47GkuBG003832 for ; Sun, 7 May 2006 12:46:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 7 May 2006 19:47:35 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Photo Thread-Index: AcZx9fFkTbzkknF7TFqZ/jFWs0u8uwAAAACe From: "Romascanu, Dan \(Dan\)" To: "hubmib" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Hubmib] Out of Office AutoReply: Photo X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1187312464==" Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============1187312464== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C671F5.F1669D64" This is a multi-part message in MIME format. ------_=_NextPart_001_01C671F5.F1669D64 Content-Type: text/plain; charset="Windows-1255" Content-Transfer-Encoding: quoted-printable I am out-of-office, travelling at a standards meeting, until May 7, = 2006. I may be late in reading and answering your mail. If you need to = contact me urgently, please leave a message at my office voice mail. Regards, Dan ------_=_NextPart_001_01C671F5.F1669D64 Content-Type: text/html; charset="Windows-1255" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply: Photo

I am out-of-office, travelling at a standards meeting, = until May 7, 2006.  I may be late in reading and answering your = mail.  If you need to contact me urgently, please leave a message = at my office voice mail.

Regards,

Dan

------_=_NextPart_001_01C671F5.F1669D64-- --===============1187312464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============1187312464==-- From hubmib-bounces@ietf.org Mon May 08 09:00:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd5LE-0003R2-6C; Mon, 08 May 2006 09:00:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd5LD-0003Qx-FA for hubmib@ietf.org; Mon, 08 May 2006 08:59:59 -0400 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd5LC-00077n-8f for hubmib@ietf.org; Mon, 08 May 2006 08:59:59 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k48Cx1nP002060 for ; Mon, 8 May 2006 08:59:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 May 2006 15:59:56 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HUBMIB-Not having a session at IETF 66 Thread-Index: AcZynzsP0s1Ns1VKTEa2GJc2hRZruwAABAaQ From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Hubmib] FW: HUBMIB-Not having a session at IETF 66 X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org =20 =20 -----Original Message----- From: IETF Meeting Session Request Tool [mailto:session_request_developers@ietf.org]=20 Sent: Monday, May 08, 2006 3:59 PM To: session-request@ietf.org Cc: Romascanu, Dan (Dan); david.kessens@nokia.com; Romascanu, Dan (Dan) Subject: HUBMIB-Not having a session at IETF 66=20 Dan Romascanu, a chair of the HUBMIB working group, indicated that the HUBMIB working group does not plan to hold a session at IETF 66. This message was generated and sent by the IETF Meeting Session Request Tool. _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Wed May 10 09:56:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdpAh-0006Gk-NF; Wed, 10 May 2006 09:56:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdpAh-0006Gf-1W for hubmib@ietf.org; Wed, 10 May 2006 09:56:11 -0400 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdpAe-0006yy-Qx for hubmib@ietf.org; Wed, 10 May 2006 09:56:11 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4ADt30f023896 for ; Wed, 10 May 2006 09:55:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 10 May 2006 16:56:07 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Funny :) Thread-Index: AcZ0OXwalU63jPG2Tkm/3RUdH4Zi5QAAAAHO From: "Romascanu, Dan \(Dan\)" To: "hubmib" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Hubmib] Out of Office AutoReply: Funny :) X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1325062373==" Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============1325062373== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67439.7C1EDA74" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67439.7C1EDA74 Content-Type: text/plain; charset="Windows-1255" Content-Transfer-Encoding: quoted-printable I am out-of-office, travelling at a standards meeting, until May 21, = 2006. I may be late in reading and answering your mail. If you need to = contact me urgently, please leave a message at my office voice mail. Regards, Dan ------_=_NextPart_001_01C67439.7C1EDA74 Content-Type: text/html; charset="Windows-1255" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply: Funny :)

I am out-of-office, travelling at a standards meeting, = until May 21, 2006.  I may be late in reading and answering your = mail.  If you need to contact me urgently, please leave a message = at my office voice mail.

Regards,

Dan

------_=_NextPart_001_01C67439.7C1EDA74-- --===============1325062373== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============1325062373==-- From hubmib-bounces@ietf.org Wed May 10 19:03:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdxiW-000696-Ea; Wed, 10 May 2006 19:03:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdxiV-000691-AV for hubmib@ietf.org; Wed, 10 May 2006 19:03:39 -0400 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdxiU-0006PJ-W8 for hubmib@ietf.org; Wed, 10 May 2006 19:03:39 -0400 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k4AN3RsZ021837; Wed, 10 May 2006 16:03:27 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k4AN3Rpq021833; Wed, 10 May 2006 16:03:27 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 10 May 2006 16:03:26 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: hubmib@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: dromasca@avaya.com, msquire@hatterasnetworks.com Subject: [Hubmib] Review of EFM-04 I-D X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org HI, I finished reviewing I-D draft-ietf-hubmib-efm-mib-04.txt. My notes are below. General comments: The updated document looks very clean. It runs through both SMICng and smilint with no problems. I read through the document fairly quickly, and didn't try to verify all the references to other documents. (Even if there are a typo or two, a reader should be able to sort this out.) Specific Comments: 1) The last paragraph of section 5 reads a little strange to me. It seems more complex than needed. (Given that it is an overview, it's Ok to leave as is. However, I suggest that it be simplified to the following: "There are two notifications defined to report Ethernet OAM events and are contained in one conformance group." 2) The TC Dot3Oui is defined in the module and has general applicability to all IEEE 802 areas. It seems like this should be defined elsewhere are imported into this module. (This is a duplicate of the comment made in the previous review, and I cannot remember the response.) 3) Also, the TC Dot3Oui where used is specified as having the value of zero. Either this should be changed to say the value of 3 octets of zero, or the syntax of the TC be modified to the following: SYNTAX OCTET STRING(SIZE(0 | 3)) I favor saying that the value is 3 octets of zero, since a zero length value may break existing mgmt apps. Note: objects dot3OamPeerVendorOui, and dot3OamEventLogOui 4) The syntax of object dot3OamMaxOamPduSize is specified as "SYNTAX (0..1518)", but the text says values 1..63 are not allowed. So, why not "SYNTAX (0 | 64..1518) In summary, great job Matt and others that worked on the document. Regards, /david t. perkins _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Thu May 11 06:38:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe8Yq-0000Ip-3Q; Thu, 11 May 2006 06:38:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe8Yo-0000Ik-TK for hubmib@ietf.org; Thu, 11 May 2006 06:38:23 -0400 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe8Yo-0001m6-M0 for hubmib@ietf.org; Thu, 11 May 2006 06:38:22 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4BAb112020424 for ; Thu, 11 May 2006 06:37:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 May 2006 13:38:08 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of EFM-04 I-D Thread-Index: AcZ0hfaJ7/tyWvvrQzqkbjpdQ9+D6gAYHI4A From: "Romascanu, Dan \(Dan\)" To: "David T. Perkins" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: David Kessens , msquire@hatterasnetworks.com Subject: [Hubmib] RE: Review of EFM-04 I-D X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org Thank you David.=20 Matt, please address the comments. Could we consider the comments as initial comments for the IETF Last Call without necessarily doing a new iteration? If everybody agrees, I believe that David Kessens could prepare the document for IETFLC.=20 Dan =20 =20 > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com]=20 > Sent: Thursday, May 11, 2006 2:03 AM > To: hubmib@ietf.org > Cc: msquire@hatterasnetworks.com; Romascanu, Dan (Dan) > Subject: Review of EFM-04 I-D >=20 > HI, >=20 > I finished reviewing I-D draft-ietf-hubmib-efm-mib-04.txt. > My notes are below. >=20 > General comments: > The updated document looks very clean.=20 > It runs through both SMICng and smilint with no problems. > I read through the document fairly quickly, and didn't try=20 > to verify all the references to other documents. > (Even if there are a typo or two, a reader should be able=20 > to sort this out.) >=20 > Specific Comments: > 1) The last paragraph of section 5 reads a little strange > to me. It seems more complex than needed. (Given that it > is an overview, it's Ok to leave as is. However, I suggest > that it be simplified to the following: > "There are two notifications defined to report Ethernet OAM > events and are contained in one conformance group." >=20 > 2) The TC Dot3Oui is defined in the module and has general > applicability to all IEEE 802 areas. It seems like this > should be defined elsewhere are imported into this module. > (This is a duplicate of the comment made in the previous > review, and I cannot remember the response.) > =20 > 3) Also, the TC Dot3Oui where used is specified as having > the value of zero. Either this should be changed to say > the value of 3 octets of zero, or the syntax of the > TC be modified to the following: > SYNTAX OCTET STRING(SIZE(0 | 3)) > I favor saying that the value is 3 octets of zero, > since a zero length value may break existing mgmt apps. > Note: objects dot3OamPeerVendorOui, and > dot3OamEventLogOui > =20 > 4) The syntax of object dot3OamMaxOamPduSize is specified > as "SYNTAX (0..1518)", but the text says values > 1..63 are not allowed. So, why not > "SYNTAX (0 | 64..1518) >=20 > In summary, great job Matt and others that worked on the document. >=20 > Regards, > /david t. perkins >=20 >=20 >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Thu May 11 07:26:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe9JV-0001pt-Dc; Thu, 11 May 2006 07:26:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe9JU-0001po-BN for hubmib@ietf.org; Thu, 11 May 2006 07:26:36 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe9JT-0003x6-50 for hubmib@ietf.org; Thu, 11 May 2006 07:26:36 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4BBQQEq016431; Thu, 11 May 2006 06:26:27 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 May 2006 13:26:25 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550A004CFF@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "David T. Perkins" , hubmib@ietf.org Subject: RE: [Hubmib] Review of EFM-04 I-D Date: Thu, 11 May 2006 13:26:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: dromasca@avaya.com, msquire@hatterasnetworks.com X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org W.r.t. > > 4) The syntax of object dot3OamMaxOamPduSize is specified > as "SYNTAX (0..1518)", but the text says values > 1..63 are not allowed. So, why not > "SYNTAX (0 | 64..1518) > Mmmm... which document are you looking at? The that I have says (on page 15) dot3OamMaxOamPduSize OBJECT-TYPE SYNTAX Unsigned32 (64..1518) UNITS "octets" MAX-ACCESS read-only STATUS current DESCRIPTION "The largest OAMPDU that the OAM entity supports. OAM entities exchange maximum OAMPDU sizes and negotiate to use the smaller of the two maximum OAMPDU sizes between the peers. This value is determined by the local implementation. " REFERENCE "[802.3ah], 30.3.6.1.8" ::= { dot3OamEntry 4 } So it does not have (0..1518) and the DESCRIPTION clause also does not tell me what a value of zero would mean ?? I tried to find it in the 802.3ah spec, but have not found it (yet). Bert _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Thu May 11 08:58:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAkj-0005dv-DX; Thu, 11 May 2006 08:58:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAkh-0005dq-Tv for hubmib@ietf.org; Thu, 11 May 2006 08:58:47 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeAkg-00087v-Ko for hubmib@ietf.org; Thu, 11 May 2006 08:58:47 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4BCwY3S011770; Thu, 11 May 2006 07:58:35 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 May 2006 14:58:34 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550A004DB0@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: David_Law@3com.com Subject: RE: [Hubmib] Review of EFM-04 I-D Date: Thu, 11 May 2006 14:58:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: dromasca@avaya.com, msquire@hatterasnetworks.com, hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org Ok, I did not link through to clause 4.4.1. So then it seems that 0-63 are not valid values. Or is zero length=20 a special case? Bert > -----Original Message----- > From: David_Law@3com.com [mailto:David_Law@3com.com] > Sent: Thursday, May 11, 2006 13:46 > To: Wijnen, Bert (Bert) > Cc: David T. Perkins; dromasca@avaya.com; hubmib@ietf.org; > msquire@hatterasnetworks.com > Subject: RE: [Hubmib] Review of EFM-04 I-D >=20 >=20 > Hi Bert, >=20 > I don't know if the following is what you were looking for in=20 > IEEE Std=20 > 802.3ah-2004 (please note that IEEE 802.3ah-2004 has been=20 > superseded by=20 > IEEE 802.3-2005 which I will quote from): >=20 > Subclause 30.3.6.1.8 'aOAMLocalPDUConfiguration' of IEEE Std=20 > 802.3-2005=20 > reads: >=20 > ATTRIBUTE > APPROPRIATE SYNTAX: > INTEGER > BEHAVIOUR DEFINED AS: > An eleven bit value corresponding to the Maximum OAMPDU Size=20 > value within=20 > the OAMPDU Configuration field (see Table 57=E2=80=939) in the most = recently=20 > transmitted OAMPDU.; >=20 >=20 > In Table 57-9 of IEEE Std 802.3-2005 'Maximum OAMPDU Size' is=20 > described=20 > as: >=20 > 11-bit field which represents the largest OAMPDU, in octets,=20 > supported by=20 > the DTE. This value is compared to the remote=E2=80=99s Maximum PDU=20 > Size and the=20 > smaller of the two is used. Prior to exchanging and agreeing upon a=20 > Maximum OAMPDU Size, a DTE sends minFrameSize OAMPDUs. The=20 > minimum value=20 > is minFrameSize / 8. The maximum value is equal to=20 > maxUntaggedFrameSize,=20 > which is defined in 4.4.2. The OAMPDUs transmitted by a DTE=20 > are limited by=20 > both the local DTE=E2=80=99s Maximum OAMPDU size and the remote DTE's = Maximum=20 > OAMPDU size as indicated in received Information OAMPDUs. A=20 > DTE is not=20 > required to change the value transmitted in this field after=20 > negotiation=20 > to an agreed size as each end will dynamically. >=20 > Subclause 4.4.2 of IEEE Std 802.3-2005 'Allowable=20 > implementations' defines=20 > minFrameSize as 512 bits. >=20 > Hope this helps. >=20 > Regards, > David >=20 >=20 >=20 > "Wijnen, Bert (Bert)" wrote on=20 > 11/05/2006 12:26:16: >=20 > > W.r.t. >=20 > > > > > > 4) The syntax of object dot3OamMaxOamPduSize is specified > > > as "SYNTAX (0..1518)", but the text says values > > > 1..63 are not allowed. So, why not > > > "SYNTAX (0 | 64..1518) > > > >=20 > > Mmmm... which document are you looking at? > > The that I have says (on page 15) > > dot3OamMaxOamPduSize OBJECT-TYPE > > SYNTAX Unsigned32 (64..1518) > > UNITS "octets" > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The largest OAMPDU that the OAM entity supports. OAM > > entities exchange maximum OAMPDU sizes and negotiate to use > > the smaller of the two maximum OAMPDU sizes between the peers. > > This value is determined by the local implementation. > > " > > REFERENCE "[802.3ah], 30.3.6.1.8" > > ::=3D { dot3OamEntry 4 } > >=20 > > So it does not have (0..1518) and the DESCRIPTION clause=20 > also does not=20 > tell > > me what a value of zero would mean ?? > > I tried to find it in the 802.3ah spec, but have not found it = (yet). >=20 > > Bert >=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-bounces@ietf.org Thu May 11 10:44:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCP0-0006NI-Q1; Thu, 11 May 2006 10:44:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCOz-0006ND-AH for hubmib@ietf.org; Thu, 11 May 2006 10:44:29 -0400 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeCOx-000520-Vu for hubmib@ietf.org; Thu, 11 May 2006 10:44:29 -0400 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k4BEi3c9024819; Thu, 11 May 2006 07:44:03 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k4BEi24H024801; Thu, 11 May 2006 07:44:02 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 11 May 2006 07:44:02 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Wijnen, Bert (Bert)" Subject: RE: [Hubmib] Review of EFM-04 I-D In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550A004CFF@nl0006exch001u.nl.lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: dromasca@avaya.com, hubmib@ietf.org, msquire@hatterasnetworks.com X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org HI, oops. Cut and paste error on my part. Should be dot3OamPeerMaxOamPduSize. Regards, /david t. perkins On Thu, 11 May 2006, Wijnen, Bert (Bert) wrote: > W.r.t. > > > > > 4) The syntax of object dot3OamMaxOamPduSize is specified > > as "SYNTAX (0..1518)", but the text says values > > 1..63 are not allowed. So, why not > > "SYNTAX (0 | 64..1518) > > > > Mmmm... which document are you looking at? > The that I have says (on page 15) > dot3OamMaxOamPduSize OBJECT-TYPE > SYNTAX Unsigned32 (64..1518) > UNITS "octets" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The largest OAMPDU that the OAM entity supports. OAM > entities exchange maximum OAMPDU sizes and negotiate to use > the smaller of the two maximum OAMPDU sizes between the peers. > This value is determined by the local implementation. > " > REFERENCE "[802.3ah], 30.3.6.1.8" > ::= { dot3OamEntry 4 } > > So it does not have (0..1518) and the DESCRIPTION clause also does not tell > me what a value of zero would mean ?? > I tried to find it in the 802.3ah spec, but have not found it (yet). > > Bert > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Thu May 11 10:54:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCYN-0002en-77; Thu, 11 May 2006 10:54:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCYM-0002ei-N9 for hubmib@ietf.org; Thu, 11 May 2006 10:54:10 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeCYM-0005RI-Bv for hubmib@ietf.org; Thu, 11 May 2006 10:54:10 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4BEr886020313; Thu, 11 May 2006 09:53:09 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 May 2006 16:53:07 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550A004E84@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: David_Law@3com.com, "Wijnen, Bert (Bert)" Subject: RE: [Hubmib] Review of EFM-04 I-D Date: Thu, 11 May 2006 16:53:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: dromasca@avaya.com, msquire@hatterasnetworks.com, hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org OK, then, for me it seems that the revision 4 of the document has the proper SYNTYAX, namely SYNTAX Unsigned32 (64..1518) Bert > -----Original Message----- > From: David_Law@3com.com [mailto:David_Law@3com.com] > Sent: Thursday, May 11, 2006 15:45 > To: Wijnen, Bert (Bert) > Cc: David T. Perkins; dromasca@avaya.com; hubmib@ietf.org; > msquire@hatterasnetworks.com > Subject: RE: [Hubmib] Review of EFM-04 I-D >=20 >=20 > Hi Bert, >=20 > The following is just my personal view of what IEEE Std 802.3=20 > states, but=20 > based on the text in Table 57-9 of IEEE Std 802.3-2005 that=20 > states that=20 > 'The minimum value is minFrameSize / 8.' and subclause 4.4.2 defining = > minFrameSize as 512 bits the minimum value for Maximum OAMPDU=20 > Size is 64. >=20 > I therefore believe 0-63 inclusive are not valid, I don't see=20 > any special=20 > case for 0. >=20 > Regards, > David >=20 >=20 > "Wijnen, Bert (Bert)" wrote on=20 > 11/05/2006 13:58:24: >=20 > > Ok, I did not link through to clause 4.4.1. > > So then it seems that 0-63 are not valid values. Or is zero length > > a special case? >=20 > > Bert >=20 > > > -----Original Message----- > > > From: David_Law@3com.com [mailto:David_Law@3com.com] > > > Sent: Thursday, May 11, 2006 13:46 > > > To: Wijnen, Bert (Bert) > > > Cc: David T. Perkins; dromasca@avaya.com; hubmib@ietf.org; > > > msquire@hatterasnetworks.com > > > Subject: RE: [Hubmib] Review of EFM-04 I-D > > > > > > > > > Hi Bert, > > > > > > I don't know if the following is what you were looking for in > > > IEEE Std > > > 802.3ah-2004 (please note that IEEE 802.3ah-2004 has been > > > superseded by > > > IEEE 802.3-2005 which I will quote from): > > > > > > Subclause 30.3.6.1.8 'aOAMLocalPDUConfiguration' of IEEE Std > > > 802.3-2005 > > > reads: > > > > > > ATTRIBUTE > > > APPROPRIATE SYNTAX: > > > INTEGER > > > BEHAVIOUR DEFINED AS: > > > An eleven bit value corresponding to the Maximum OAMPDU Size > > > value within > > > the OAMPDU Configuration field (see Table 57=E2=80=939) in the=20 > most recently > > > transmitted OAMPDU.; > > > > > > > > > In Table 57-9 of IEEE Std 802.3-2005 'Maximum OAMPDU Size' is > > > described > > > as: > > > > > > 11-bit field which represents the largest OAMPDU, in octets, > > > supported by > > > the DTE. This value is compared to the remote=E2=80=99s Maximum = PDU > > > Size and the > > > smaller of the two is used. Prior to exchanging and=20 > agreeing upon a > > > Maximum OAMPDU Size, a DTE sends minFrameSize OAMPDUs. The > > > minimum value > > > is minFrameSize / 8. The maximum value is equal to > > > maxUntaggedFrameSize, > > > which is defined in 4.4.2. The OAMPDUs transmitted by a DTE > > > are limited by > > > both the local DTE=E2=80=99s Maximum OAMPDU size and the remote=20 > DTE's Maximum > > > OAMPDU size as indicated in received Information OAMPDUs. A > > > DTE is not > > > required to change the value transmitted in this field after > > > negotiation > > > to an agreed size as each end will dynamically. > > > > > > Subclause 4.4.2 of IEEE Std 802.3-2005 'Allowable > > > implementations' defines > > > minFrameSize as 512 bits. > > > > > > Hope this helps. > > > > > > Regards, > > > David > > > > > > > > > > > > "Wijnen, Bert (Bert)" wrote on > > > 11/05/2006 12:26:16: > > > > > > > W.r.t. > > > > > > > > > > > > > 4) The syntax of object dot3OamMaxOamPduSize is specified > > > > > as "SYNTAX (0..1518)", but the text says values > > > > > 1..63 are not allowed. So, why not > > > > > "SYNTAX (0 | 64..1518) > > > > > > > > > > > > Mmmm... which document are you looking at? > > > > The that I have says (on page 15) > > > > dot3OamMaxOamPduSize OBJECT-TYPE > > > > SYNTAX Unsigned32 (64..1518) > > > > UNITS "octets" > > > > MAX-ACCESS read-only > > > > STATUS current > > > > DESCRIPTION > > > > "The largest OAMPDU that the OAM entity supports. OAM > > > > entities exchange maximum OAMPDU sizes and negotiate to use > > > > the smaller of the two maximum OAMPDU sizes between the peers. > > > > This value is determined by the local implementation. > > > > " > > > > REFERENCE "[802.3ah], 30.3.6.1.8" > > > > ::=3D { dot3OamEntry 4 } > > > > > > > > So it does not have (0..1518) and the DESCRIPTION clause > > > also does not > > > tell > > > > me what a value of zero would mean ?? > > > > I tried to find it in the 802.3ah spec, but have not=20 > found it (yet). > > > > > > > Bert > > > > > > > > > > > _______________________________________________ > > > > Hubmib mailing list > > > > Hubmib@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/hubmib > > >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Thu May 11 11:07:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCl4-00013t-Rg; Thu, 11 May 2006 11:07:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCl3-00013n-Nd for hubmib@ietf.org; Thu, 11 May 2006 11:07:17 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeCl3-0005pH-Fp for hubmib@ietf.org; Thu, 11 May 2006 11:07:17 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4BF7Crg008363; Thu, 11 May 2006 10:07:13 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 May 2006 17:07:11 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550A004EA5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "David T. Perkins" , "Wijnen, Bert (Bert)" Subject: RE: [Hubmib] Review of EFM-04 I-D Date: Thu, 11 May 2006 17:07:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: dromasca@avaya.com, hubmib@ietf.org, msquire@hatterasnetworks.com X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org For that one I agree with your comment Dave. Bert > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Thursday, May 11, 2006 16:44 > To: Wijnen, Bert (Bert) > Cc: hubmib@ietf.org; dromasca@avaya.com; msquire@hatterasnetworks.com > Subject: RE: [Hubmib] Review of EFM-04 I-D > > > HI, > > oops. Cut and paste error on my part. Should be > dot3OamPeerMaxOamPduSize. > > Regards, > /david t. perkins > > On Thu, 11 May 2006, Wijnen, Bert (Bert) wrote: > > > W.r.t. > > > > > > > > 4) The syntax of object dot3OamMaxOamPduSize is specified > > > as "SYNTAX (0..1518)", but the text says values > > > 1..63 are not allowed. So, why not > > > "SYNTAX (0 | 64..1518) > > > > > > > Mmmm... which document are you looking at? > > The that I have says (on page 15) > > dot3OamMaxOamPduSize OBJECT-TYPE > > SYNTAX Unsigned32 (64..1518) > > UNITS "octets" > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The largest OAMPDU that the OAM entity supports. OAM > > entities exchange maximum OAMPDU sizes and > negotiate to use > > the smaller of the two maximum OAMPDU sizes > between the peers. > > This value is determined by the local implementation. > > " > > REFERENCE "[802.3ah], 30.3.6.1.8" > > ::= { dot3OamEntry 4 } > > > > So it does not have (0..1518) and the DESCRIPTION clause > also does not tell > > me what a value of zero would mean ?? > > I tried to find it in the 802.3ah spec, but have not found it (yet). > > > > Bert > > > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Thu May 11 13:09:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeEeu-0000tN-GW; Thu, 11 May 2006 13:09:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeEet-0000tA-PW for hubmib@ietf.org; Thu, 11 May 2006 13:09:03 -0400 Received: from mail.hatterasnetworks.com ([72.15.200.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeEer-0003EH-Gd for hubmib@ietf.org; Thu, 11 May 2006 13:09:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hubmib] Review of EFM-04 I-D Date: Thu, 11 May 2006 13:08:58 -0400 Message-ID: <467C77F6373BDE4BB16A3E8A62C039551ECB7C@Exchserv.hatteras.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hubmib] Review of EFM-04 I-D Thread-Index: AcZ1DJfOvAOyk527RsqdiyBIAzrzLgAEFFRQ From: "Matt Squire" To: "Wijnen, Bert \(Bert\)" , "David T. Perkins" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: dromasca@avaya.com, hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org You are correct, the zero part of (0|64..1518) is a mistake.=20 - Matt > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Thursday, May 11, 2006 11:07 AM > To: David T. Perkins; Wijnen, Bert (Bert) > Cc: hubmib@ietf.org; dromasca@avaya.com; Matt Squire > Subject: RE: [Hubmib] Review of EFM-04 I-D >=20 > For that one I agree with your comment Dave. >=20 > Bert >=20 > > -----Original Message----- > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Sent: Thursday, May 11, 2006 16:44 > > To: Wijnen, Bert (Bert) > > Cc: hubmib@ietf.org; dromasca@avaya.com; msquire@hatterasnetworks.com > > Subject: RE: [Hubmib] Review of EFM-04 I-D > > > > > > HI, > > > > oops. Cut and paste error on my part. Should be > > dot3OamPeerMaxOamPduSize. > > > > Regards, > > /david t. perkins > > > > On Thu, 11 May 2006, Wijnen, Bert (Bert) wrote: > > > > > W.r.t. > > > > > > > > > > > 4) The syntax of object dot3OamMaxOamPduSize is specified > > > > as "SYNTAX (0..1518)", but the text says values > > > > 1..63 are not allowed. So, why not > > > > "SYNTAX (0 | 64..1518) > > > > > > > > > > Mmmm... which document are you looking at? > > > The that I have says (on page 15) > > > dot3OamMaxOamPduSize OBJECT-TYPE > > > SYNTAX Unsigned32 (64..1518) > > > UNITS "octets" > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION > > > "The largest OAMPDU that the OAM entity supports. OAM > > > entities exchange maximum OAMPDU sizes and > > negotiate to use > > > the smaller of the two maximum OAMPDU sizes > > between the peers. > > > This value is determined by the local implementation. > > > " > > > REFERENCE "[802.3ah], 30.3.6.1.8" > > > ::=3D { dot3OamEntry 4 } > > > > > > So it does not have (0..1518) and the DESCRIPTION clause > > also does not tell > > > me what a value of zero would mean ?? > > > I tried to find it in the 802.3ah spec, but have not found it (yet). > > > > > > Bert > > > > > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Thu May 11 13:41:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFAc-000064-79; Thu, 11 May 2006 13:41:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFAb-00005u-0V for hubmib@ietf.org; Thu, 11 May 2006 13:41:49 -0400 Received: from mail.hatterasnetworks.com ([72.15.200.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeFAa-0004TN-NS for hubmib@ietf.org; Thu, 11 May 2006 13:41:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 May 2006 13:41:47 -0400 Message-ID: <467C77F6373BDE4BB16A3E8A62C039551ECB8F@Exchserv.hatteras.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of EFM-04 I-D Thread-Index: AcZ0hfVSZdRS4yW6QvOHV+wevlR+rgAl8gHw From: "Matt Squire" To: "David T. Perkins" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: dromasca@avaya.com Subject: [Hubmib] RE: Review of EFM-04 I-D X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org Hi David -=20 Thanks for the (re-)review. Responses are in-line.=20 >=20 > Specific Comments: > 1) The last paragraph of section 5 reads a little strange > to me. It seems more complex than needed. (Given that it > is an overview, it's Ok to leave as is. However, I suggest > that it be simplified to the following: > "There are two notifications defined to report Ethernet OAM > events and are contained in one conformance group." As a recap for those that don't have the document in front of them, the last paragraph says: "There are also a set of notifications (dot3OamNotifications) that define alert conditions to management. The [802.3ah] Event Notifications can each be implemented independently of any other, and therefore each has their own conformance group. "=20 And I agree that it's confusing. I'd offer a slight alteration to your proposal. "There are two notifications defined to report Ethernet OAM events (one for threshold crossing events, one for non-threshold crossing events). Both notifications are contained in the same conformance group. " >=20 > 2) The TC Dot3Oui is defined in the module and has general > applicability to all IEEE 802 areas. It seems like this > should be defined elsewhere are imported into this module. > (This is a duplicate of the comment made in the previous > review, and I cannot remember the response.) My response was that I theoretically agree, but I'm not sure how to address it. What MIB does it go in? Who updates that MIB? Do we wait until it's updated? =20 I'm just not sure what part falls on me, and what part falls on someone else (and who that someone else would be). =20 >=20 > 3) Also, the TC Dot3Oui where used is specified as having > the value of zero. Either this should be changed to say > the value of 3 octets of zero, or the syntax of the > TC be modified to the following: > SYNTAX OCTET STRING(SIZE(0 | 3)) > I favor saying that the value is 3 octets of zero, > since a zero length value may break existing mgmt apps. > Note: objects dot3OamPeerVendorOui, and > dot3OamEventLogOui Will do.=20 >=20 > 4) The syntax of object dot3OamMaxOamPduSize is specified > as "SYNTAX (0..1518)", but the text says values > 1..63 are not allowed. So, why not > "SYNTAX (0 | 64..1518) As has been discussed on the reflector and in private, there is a difference in the syntax for dot3OamMaxOamPduSize and dot3OamPeerMaxOamPduSize. The former should be (64..1518) as the local station knows its PDU size and it must be a value in the range 64-1518 octets. The latter may have an unknown value (you may not have received the value from the peer yet), and that is what the value of zero is for. >From the Description of dot3OamPeerMaxOamPduSize: =20 "A value of zero is returned if no Local Information TLV has been received. Otherwise, the value of the OAM peer's maximum OAMPDU size is returned in this value. Note that the values 1..63 are invalid sizes for Ethernet frames and should never appear " So (0 | 64..1518) is probably better then saying (0..1518) with 1..63 as "should never appear". So it's a good change to make. =20 - Matt _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Thu May 11 16:09:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeHTZ-0000th-AU; Thu, 11 May 2006 16:09:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeB9P-00021v-TH for hubmib@ietf.org; Thu, 11 May 2006 09:24:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe9nY-0005HJ-24 for hubmib@ietf.org; Thu, 11 May 2006 07:57:40 -0400 Received: from plmler2.mail.eds.com ([199.228.142.72]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fe9dO-0007mM-R5 for hubmib@ietf.org; Thu, 11 May 2006 07:47:15 -0400 Received: from plmlir2.mail.eds.com (plmlir2-2.mail.eds.com [199.228.142.132]) by plmler2.mail.eds.com (8.13.6/8.12.10) with ESMTP id k4BBl29C015887; Thu, 11 May 2006 06:47:02 -0500 Received: from plmlir2.mail.eds.com (localhost [127.0.0.1]) by plmlir2.mail.eds.com (8.13.4/8.12.10) with ESMTP id k4BBkWf4018909; Thu, 11 May 2006 06:46:32 -0500 Received: from usut001.3com.com ([205.142.126.149]) by plmlir2.mail.eds.com (8.13.4/8.12.10) with ESMTP id k4BBkWgv018904; Thu, 11 May 2006 06:46:32 -0500 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550A004CFF@nl0006exch001u.nl.lucent.com> To: "Wijnen, Bert (Bert)" Subject: RE: [Hubmib] Review of EFM-04 I-D MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004 Message-ID: From: David_Law@3com.com Date: Thu, 11 May 2006 12:46:19 +0100 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 05/11/2006 04:46:32 AM, Serialize complete at 05/11/2006 04:46:32 AM X-Spam-Score: -2.6 (--) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-Mailman-Approved-At: Thu, 11 May 2006 16:09:32 -0400 Cc: dromasca@avaya.com, msquire@hatterasnetworks.com, hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0746460243==" Errors-To: hubmib-bounces@ietf.org --===============0746460243== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgQmVydCwNCg0KSSBkb24ndCBrbm93IGlmIHRoZSBmb2xsb3dpbmcgaXMgd2hhdCB5b3Ugd2Vy ZSBsb29raW5nIGZvciBpbiBJRUVFIFN0ZCANCjgwMi4zYWgtMjAwNCAocGxlYXNlIG5vdGUgdGhh dCBJRUVFIDgwMi4zYWgtMjAwNCBoYXMgYmVlbiBzdXBlcnNlZGVkIGJ5IA0KSUVFRSA4MDIuMy0y MDA1IHdoaWNoIEkgd2lsbCBxdW90ZSBmcm9tKToNCg0KU3ViY2xhdXNlIDMwLjMuNi4xLjggJ2FP QU1Mb2NhbFBEVUNvbmZpZ3VyYXRpb24nIG9mIElFRUUgU3RkIDgwMi4zLTIwMDUgDQpyZWFkczoN Cg0KQVRUUklCVVRFDQpBUFBST1BSSUFURSBTWU5UQVg6DQpJTlRFR0VSDQpCRUhBVklPVVIgREVG SU5FRCBBUzoNCkFuIGVsZXZlbiBiaXQgdmFsdWUgY29ycmVzcG9uZGluZyB0byB0aGUgTWF4aW11 bSBPQU1QRFUgU2l6ZSB2YWx1ZSB3aXRoaW4gDQp0aGUgT0FNUERVIENvbmZpZ3VyYXRpb24gZmll bGQgKHNlZSBUYWJsZSA1N+KAkzkpIGluIHRoZSBtb3N0IHJlY2VudGx5IA0KdHJhbnNtaXR0ZWQg T0FNUERVLjsNCg0KDQpJbiBUYWJsZSA1Ny05IG9mIElFRUUgU3RkIDgwMi4zLTIwMDUgJ01heGlt dW0gT0FNUERVIFNpemUnIGlzIGRlc2NyaWJlZCANCmFzOg0KDQoxMS1iaXQgZmllbGQgd2hpY2gg cmVwcmVzZW50cyB0aGUgbGFyZ2VzdCBPQU1QRFUsIGluIG9jdGV0cywgc3VwcG9ydGVkIGJ5IA0K dGhlIERURS4gVGhpcyB2YWx1ZSBpcyBjb21wYXJlZCB0byB0aGUgcmVtb3Rl4oCZcyBNYXhpbXVt IFBEVSBTaXplIGFuZCB0aGUgDQpzbWFsbGVyIG9mIHRoZSB0d28gaXMgdXNlZC4gUHJpb3IgdG8g ZXhjaGFuZ2luZyBhbmQgYWdyZWVpbmcgdXBvbiBhIA0KTWF4aW11bSBPQU1QRFUgU2l6ZSwgYSBE VEUgc2VuZHMgbWluRnJhbWVTaXplIE9BTVBEVXMuIFRoZSBtaW5pbXVtIHZhbHVlIA0KaXMgbWlu RnJhbWVTaXplIC8gOC4gVGhlIG1heGltdW0gdmFsdWUgaXMgZXF1YWwgdG8gbWF4VW50YWdnZWRG cmFtZVNpemUsIA0Kd2hpY2ggaXMgZGVmaW5lZCBpbiA0LjQuMi4gVGhlIE9BTVBEVXMgdHJhbnNt aXR0ZWQgYnkgYSBEVEUgYXJlIGxpbWl0ZWQgYnkgDQpib3RoIHRoZSBsb2NhbCBEVEXigJlzIE1h eGltdW0gT0FNUERVIHNpemUgYW5kIHRoZSByZW1vdGUgRFRFJ3MgTWF4aW11bSANCk9BTVBEVSBz aXplIGFzIGluZGljYXRlZCBpbiByZWNlaXZlZCBJbmZvcm1hdGlvbiBPQU1QRFVzLiBBIERURSBp cyBub3QgDQpyZXF1aXJlZCB0byBjaGFuZ2UgdGhlIHZhbHVlIHRyYW5zbWl0dGVkIGluIHRoaXMg ZmllbGQgYWZ0ZXIgbmVnb3RpYXRpb24gDQp0byBhbiBhZ3JlZWQgc2l6ZSBhcyBlYWNoIGVuZCB3 aWxsIGR5bmFtaWNhbGx5Lg0KDQpTdWJjbGF1c2UgNC40LjIgb2YgSUVFRSBTdGQgODAyLjMtMjAw NSAnQWxsb3dhYmxlIGltcGxlbWVudGF0aW9ucycgZGVmaW5lcyANCm1pbkZyYW1lU2l6ZSBhcyA1 MTIgYml0cy4NCg0KSG9wZSB0aGlzIGhlbHBzLg0KDQpSZWdhcmRzLA0KICBEYXZpZA0KDQoNCg0K Ildpam5lbiwgQmVydCAoQmVydCkiIDxid2lqbmVuQGx1Y2VudC5jb20+IHdyb3RlIG9uIDExLzA1 LzIwMDYgMTI6MjY6MTY6DQoNCj4gVy5yLnQuDQoNCj4gPg0KPiA+IDQpIFRoZSBzeW50YXggb2Yg b2JqZWN0IGRvdDNPYW1NYXhPYW1QZHVTaXplIGlzIHNwZWNpZmllZA0KPiA+ICAgICBhcyAiU1lO VEFYICgwLi4xNTE4KSIsIGJ1dCB0aGUgdGV4dCBzYXlzIHZhbHVlcw0KPiA+ICAgICAxLi42MyBh cmUgbm90IGFsbG93ZWQuIFNvLCB3aHkgbm90DQo+ID4gICAgICJTWU5UQVggKDAgfCA2NC4uMTUx OCkNCj4gPg0KDQo+IE1tbW0uLi4gd2hpY2ggZG9jdW1lbnQgYXJlIHlvdSBsb29raW5nIGF0Pw0K PiBUaGUgICB0aGF0IEkgaGF2ZSBzYXlzIChvbiBwYWdlIDE1KQ0KPiBkb3QzT2FtTWF4T2FtUGR1 U2l6ZSBPQkpFQ1QtVFlQRQ0KPiBTWU5UQVggICAgICBVbnNpZ25lZDMyICg2NC4uMTUxOCkNCj4g VU5JVFMgICAgICAgIm9jdGV0cyINCj4gTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQo+IFNUQVRVUyAg ICAgIGN1cnJlbnQNCj4gREVTQ1JJUFRJT04NCj4gIlRoZSBsYXJnZXN0IE9BTVBEVSB0aGF0IHRo ZSBPQU0gZW50aXR5IHN1cHBvcnRzLiAgT0FNDQo+IGVudGl0aWVzIGV4Y2hhbmdlIG1heGltdW0g T0FNUERVIHNpemVzIGFuZCBuZWdvdGlhdGUgdG8gdXNlDQo+IHRoZSBzbWFsbGVyIG9mIHRoZSB0 d28gbWF4aW11bSBPQU1QRFUgc2l6ZXMgYmV0d2VlbiB0aGUgcGVlcnMuDQo+IFRoaXMgdmFsdWUg aXMgZGV0ZXJtaW5lZCBieSB0aGUgbG9jYWwgaW1wbGVtZW50YXRpb24uDQo+ICINCj4gUkVGRVJF TkNFICAgIls4MDIuM2FoXSwgMzAuMy42LjEuOCINCj4gOjo9IHsgZG90M09hbUVudHJ5IDQgfQ0K PiANCj4gU28gaXQgZG9lcyBub3QgaGF2ZSAoMC4uMTUxOCkgYW5kIHRoZSBERVNDUklQVElPTiBj bGF1c2UgYWxzbyBkb2VzIG5vdCANCnRlbGwNCj4gbWUgd2hhdCBhIHZhbHVlIG9mIHplcm8gd291 bGQgbWVhbiA/Pw0KPiBJIHRyaWVkIHRvIGZpbmQgaXQgaW4gdGhlIDgwMi4zYWggc3BlYywgYnV0 IGhhdmUgbm90IGZvdW5kIGl0ICh5ZXQpLg0KDQo+IEJlcnQNCg0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSHVibWliIG1haWxpbmcgbGlz dA0KPiBIdWJtaWJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaHVibWliDQo= --===============0746460243== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============0746460243==-- From hubmib-bounces@ietf.org Thu May 11 16:09:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeHTa-0000uw-0i; Thu, 11 May 2006 16:09:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeBUg-000482-Ca for hubmib@ietf.org; Thu, 11 May 2006 09:46:18 -0400 Received: from plmler5.mail.eds.com ([199.228.142.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeBUf-0002ON-1B for hubmib@ietf.org; Thu, 11 May 2006 09:46:18 -0400 Received: from plmlir1.mail.eds.com (plmlir1-2.mail.eds.com [199.228.142.131]) by plmler5.mail.eds.com (8.13.6/8.12.10) with ESMTP id k4BDk9Wh032506; Thu, 11 May 2006 08:46:10 -0500 Received: from plmlir1.mail.eds.com (localhost [127.0.0.1]) by plmlir1.mail.eds.com (8.13.6/8.12.10) with ESMTP id k4BDjR0h010221; Thu, 11 May 2006 08:45:27 -0500 Received: from usut001.3com.com ([205.142.126.149]) by plmlir1.mail.eds.com (8.13.6/8.12.10) with ESMTP id k4BDjQUC010208; Thu, 11 May 2006 08:45:27 -0500 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550A004DB0@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Subject: RE: [Hubmib] Review of EFM-04 I-D X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004 Message-ID: From: David_Law@3com.com Date: Thu, 11 May 2006 14:45:09 +0100 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 05/11/2006 06:45:26 AM, Serialize complete at 05/11/2006 06:45:26 AM X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-Mailman-Approved-At: Thu, 11 May 2006 16:09:32 -0400 Cc: dromasca@avaya.com, msquire@hatterasnetworks.com, hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1117806520==" Errors-To: hubmib-bounces@ietf.org --===============1117806520== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgQmVydCwNCg0KVGhlIGZvbGxvd2luZyBpcyBqdXN0IG15IHBlcnNvbmFsIHZpZXcgb2Ygd2hh dCBJRUVFIFN0ZCA4MDIuMyBzdGF0ZXMsIGJ1dCANCmJhc2VkIG9uIHRoZSB0ZXh0IGluIFRhYmxl IDU3LTkgb2YgSUVFRSBTdGQgODAyLjMtMjAwNSB0aGF0IHN0YXRlcyB0aGF0IA0KJ1RoZSBtaW5p bXVtIHZhbHVlIGlzIG1pbkZyYW1lU2l6ZSAvIDguJyBhbmQgc3ViY2xhdXNlIDQuNC4yIGRlZmlu aW5nIA0KbWluRnJhbWVTaXplIGFzIDUxMiBiaXRzIHRoZSBtaW5pbXVtIHZhbHVlIGZvciBNYXhp bXVtIE9BTVBEVSBTaXplIGlzIDY0Lg0KDQpJIHRoZXJlZm9yZSBiZWxpZXZlIDAtNjMgaW5jbHVz aXZlIGFyZSBub3QgdmFsaWQsIEkgZG9uJ3Qgc2VlIGFueSBzcGVjaWFsIA0KY2FzZSBmb3IgMC4N Cg0KUmVnYXJkcywNCiAgRGF2aWQNCg0KDQoiV2lqbmVuLCBCZXJ0IChCZXJ0KSIgPGJ3aWpuZW5A bHVjZW50LmNvbT4gd3JvdGUgb24gMTEvMDUvMjAwNiAxMzo1ODoyNDoNCg0KPiBPaywgSSBkaWQg bm90IGxpbmsgdGhyb3VnaCB0byBjbGF1c2UgNC40LjEuDQo+IFNvIHRoZW4gaXQgc2VlbXMgdGhh dCAwLTYzIGFyZSBub3QgdmFsaWQgdmFsdWVzLiBPciBpcyB6ZXJvIGxlbmd0aA0KPiBhIHNwZWNp YWwgY2FzZT8NCg0KPiBCZXJ0DQoNCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ IEZyb206IERhdmlkX0xhd0AzY29tLmNvbSBbbWFpbHRvOkRhdmlkX0xhd0AzY29tLmNvbV0NCj4g PiBTZW50OiBUaHVyc2RheSwgTWF5IDExLCAyMDA2IDEzOjQ2DQo+ID4gVG86IFdpam5lbiwgQmVy dCAoQmVydCkNCj4gPiBDYzogRGF2aWQgVC4gUGVya2luczsgZHJvbWFzY2FAYXZheWEuY29tOyBo dWJtaWJAaWV0Zi5vcmc7DQo+ID4gbXNxdWlyZUBoYXR0ZXJhc25ldHdvcmtzLmNvbQ0KPiA+IFN1 YmplY3Q6IFJFOiBbSHVibWliXSBSZXZpZXcgb2YgRUZNLTA0IEktRA0KPiA+DQo+ID4NCj4gPiBI aSBCZXJ0LA0KPiA+DQo+ID4gSSBkb24ndCBrbm93IGlmIHRoZSBmb2xsb3dpbmcgaXMgd2hhdCB5 b3Ugd2VyZSBsb29raW5nIGZvciBpbg0KPiA+IElFRUUgU3RkDQo+ID4gODAyLjNhaC0yMDA0IChw bGVhc2Ugbm90ZSB0aGF0IElFRUUgODAyLjNhaC0yMDA0IGhhcyBiZWVuDQo+ID4gc3VwZXJzZWRl ZCBieQ0KPiA+IElFRUUgODAyLjMtMjAwNSB3aGljaCBJIHdpbGwgcXVvdGUgZnJvbSk6DQo+ID4N Cj4gPiBTdWJjbGF1c2UgMzAuMy42LjEuOCAnYU9BTUxvY2FsUERVQ29uZmlndXJhdGlvbicgb2Yg SUVFRSBTdGQNCj4gPiA4MDIuMy0yMDA1DQo+ID4gcmVhZHM6DQo+ID4NCj4gPiBBVFRSSUJVVEUN Cj4gPiBBUFBST1BSSUFURSBTWU5UQVg6DQo+ID4gSU5URUdFUg0KPiA+IEJFSEFWSU9VUiBERUZJ TkVEIEFTOg0KPiA+IEFuIGVsZXZlbiBiaXQgdmFsdWUgY29ycmVzcG9uZGluZyB0byB0aGUgTWF4 aW11bSBPQU1QRFUgU2l6ZQ0KPiA+IHZhbHVlIHdpdGhpbg0KPiA+IHRoZSBPQU1QRFUgQ29uZmln dXJhdGlvbiBmaWVsZCAoc2VlIFRhYmxlIDU34oCTOSkgaW4gdGhlIG1vc3QgcmVjZW50bHkNCj4g PiB0cmFuc21pdHRlZCBPQU1QRFUuOw0KPiA+DQo+ID4NCj4gPiBJbiBUYWJsZSA1Ny05IG9mIElF RUUgU3RkIDgwMi4zLTIwMDUgJ01heGltdW0gT0FNUERVIFNpemUnIGlzDQo+ID4gZGVzY3JpYmVk DQo+ID4gYXM6DQo+ID4NCj4gPiAxMS1iaXQgZmllbGQgd2hpY2ggcmVwcmVzZW50cyB0aGUgbGFy Z2VzdCBPQU1QRFUsIGluIG9jdGV0cywNCj4gPiBzdXBwb3J0ZWQgYnkNCj4gPiB0aGUgRFRFLiBU aGlzIHZhbHVlIGlzIGNvbXBhcmVkIHRvIHRoZSByZW1vdGXigJlzIE1heGltdW0gUERVDQo+ID4g U2l6ZSBhbmQgdGhlDQo+ID4gc21hbGxlciBvZiB0aGUgdHdvIGlzIHVzZWQuIFByaW9yIHRvIGV4 Y2hhbmdpbmcgYW5kIGFncmVlaW5nIHVwb24gYQ0KPiA+IE1heGltdW0gT0FNUERVIFNpemUsIGEg RFRFIHNlbmRzIG1pbkZyYW1lU2l6ZSBPQU1QRFVzLiBUaGUNCj4gPiBtaW5pbXVtIHZhbHVlDQo+ ID4gaXMgbWluRnJhbWVTaXplIC8gOC4gVGhlIG1heGltdW0gdmFsdWUgaXMgZXF1YWwgdG8NCj4g PiBtYXhVbnRhZ2dlZEZyYW1lU2l6ZSwNCj4gPiB3aGljaCBpcyBkZWZpbmVkIGluIDQuNC4yLiBU aGUgT0FNUERVcyB0cmFuc21pdHRlZCBieSBhIERURQ0KPiA+IGFyZSBsaW1pdGVkIGJ5DQo+ID4g Ym90aCB0aGUgbG9jYWwgRFRF4oCZcyBNYXhpbXVtIE9BTVBEVSBzaXplIGFuZCB0aGUgcmVtb3Rl IERURSdzIE1heGltdW0NCj4gPiBPQU1QRFUgc2l6ZSBhcyBpbmRpY2F0ZWQgaW4gcmVjZWl2ZWQg SW5mb3JtYXRpb24gT0FNUERVcy4gQQ0KPiA+IERURSBpcyBub3QNCj4gPiByZXF1aXJlZCB0byBj aGFuZ2UgdGhlIHZhbHVlIHRyYW5zbWl0dGVkIGluIHRoaXMgZmllbGQgYWZ0ZXINCj4gPiBuZWdv dGlhdGlvbg0KPiA+IHRvIGFuIGFncmVlZCBzaXplIGFzIGVhY2ggZW5kIHdpbGwgZHluYW1pY2Fs bHkuDQo+ID4NCj4gPiBTdWJjbGF1c2UgNC40LjIgb2YgSUVFRSBTdGQgODAyLjMtMjAwNSAnQWxs b3dhYmxlDQo+ID4gaW1wbGVtZW50YXRpb25zJyBkZWZpbmVzDQo+ID4gbWluRnJhbWVTaXplIGFz IDUxMiBiaXRzLg0KPiA+DQo+ID4gSG9wZSB0aGlzIGhlbHBzLg0KPiA+DQo+ID4gUmVnYXJkcywN Cj4gPiAgIERhdmlkDQo+ID4NCj4gPg0KPiA+DQo+ID4gIldpam5lbiwgQmVydCAoQmVydCkiIDxi d2lqbmVuQGx1Y2VudC5jb20+IHdyb3RlIG9uDQo+ID4gMTEvMDUvMjAwNiAxMjoyNjoxNjoNCj4g Pg0KPiA+ID4gVy5yLnQuDQo+ID4NCj4gPiA+ID4NCj4gPiA+ID4gNCkgVGhlIHN5bnRheCBvZiBv YmplY3QgZG90M09hbU1heE9hbVBkdVNpemUgaXMgc3BlY2lmaWVkDQo+ID4gPiA+ICAgICBhcyAi U1lOVEFYICgwLi4xNTE4KSIsIGJ1dCB0aGUgdGV4dCBzYXlzIHZhbHVlcw0KPiA+ID4gPiAgICAg MS4uNjMgYXJlIG5vdCBhbGxvd2VkLiBTbywgd2h5IG5vdA0KPiA+ID4gPiAgICAgIlNZTlRBWCAo MCB8IDY0Li4xNTE4KQ0KPiA+ID4gPg0KPiA+DQo+ID4gPiBNbW1tLi4uIHdoaWNoIGRvY3VtZW50 IGFyZSB5b3UgbG9va2luZyBhdD8NCj4gPiA+IFRoZSAgIHRoYXQgSSBoYXZlIHNheXMgKG9uIHBh Z2UgMTUpDQo+ID4gPiBkb3QzT2FtTWF4T2FtUGR1U2l6ZSBPQkpFQ1QtVFlQRQ0KPiA+ID4gU1lO VEFYICAgICAgVW5zaWduZWQzMiAoNjQuLjE1MTgpDQo+ID4gPiBVTklUUyAgICAgICAib2N0ZXRz Ig0KPiA+ID4gTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQo+ID4gPiBTVEFUVVMgICAgICBjdXJyZW50 DQo+ID4gPiBERVNDUklQVElPTg0KPiA+ID4gIlRoZSBsYXJnZXN0IE9BTVBEVSB0aGF0IHRoZSBP QU0gZW50aXR5IHN1cHBvcnRzLiAgT0FNDQo+ID4gPiBlbnRpdGllcyBleGNoYW5nZSBtYXhpbXVt IE9BTVBEVSBzaXplcyBhbmQgbmVnb3RpYXRlIHRvIHVzZQ0KPiA+ID4gdGhlIHNtYWxsZXIgb2Yg dGhlIHR3byBtYXhpbXVtIE9BTVBEVSBzaXplcyBiZXR3ZWVuIHRoZSBwZWVycy4NCj4gPiA+IFRo aXMgdmFsdWUgaXMgZGV0ZXJtaW5lZCBieSB0aGUgbG9jYWwgaW1wbGVtZW50YXRpb24uDQo+ID4g PiAiDQo+ID4gPiBSRUZFUkVOQ0UgICAiWzgwMi4zYWhdLCAzMC4zLjYuMS44Ig0KPiA+ID4gOjo9 IHsgZG90M09hbUVudHJ5IDQgfQ0KPiA+ID4NCj4gPiA+IFNvIGl0IGRvZXMgbm90IGhhdmUgKDAu LjE1MTgpIGFuZCB0aGUgREVTQ1JJUFRJT04gY2xhdXNlDQo+ID4gYWxzbyBkb2VzIG5vdA0KPiA+ IHRlbGwNCj4gPiA+IG1lIHdoYXQgYSB2YWx1ZSBvZiB6ZXJvIHdvdWxkIG1lYW4gPz8NCj4gPiA+ IEkgdHJpZWQgdG8gZmluZCBpdCBpbiB0aGUgODAyLjNhaCBzcGVjLCBidXQgaGF2ZSBub3QgZm91 bmQgaXQgKHlldCkuDQo+ID4NCj4gPiA+IEJlcnQNCj4gPg0KPiA+ID4NCj4gPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBIdWJtaWIgbWFp bGluZyBsaXN0DQo+ID4gPiBIdWJtaWJAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3MS5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h1Ym1pYg0KPiA+IA0K --===============1117806520== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============1117806520==-- From hubmib-bounces@ietf.org Sat May 13 10:35:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FevD8-0000XQ-DE; Sat, 13 May 2006 10:35:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FevD6-0000XL-Pq for hubmib@ietf.org; Sat, 13 May 2006 10:35:12 -0400 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FevD5-0007Gw-Fj for hubmib@ietf.org; Sat, 13 May 2006 10:35:12 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4DEVkpQ017136 for ; Sat, 13 May 2006 10:33:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 13 May 2006 17:32:37 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IF types durring review of EPON-04 Thread-Index: AcZ16R6puLFMmXQcTWmGUV4Db9Aa+gAAxl7wACtRr3A= From: "Romascanu, Dan \(Dan\)" To: "Dave Thaler" , "David T. Perkins" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: David Kessens , hubmib@ietf.org Subject: [Hubmib] RE: IF types durring review of EPON-04 X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org (also copying the hubmib list) Thanks to DaveT for stepping up with this. Unless there is another volunteer who shows up during the coming week, 5/19 is a good date to start a second review.=20 Dan =20 =20 > -----Original Message----- > From: owner-mreview@ops.ietf.org=20 > [mailto:owner-mreview@ops.ietf.org] On Behalf Of Dave Thaler > Sent: Friday, May 12, 2006 8:49 PM > To: David T. Perkins; mreview@ops.ietf.org > Subject: RE: IF types durring review of EPON-04 >=20 > I've been doing the reviews of relationships to the=20 > Interfaces MIB, so I can do this, but I'm swamped right now. =20 > I could probably get to this by end of next week (5/19) if=20 > someone else doesn't get to it before then. >=20 > -Dave >=20 > -----Original Message----- > From: owner-mreview@ops.ietf.org=20 > [mailto:owner-mreview@ops.ietf.org] On Behalf Of David T. Perkins > Sent: Friday, May 12, 2006 10:25 AM > To: mreview@ops.ietf.org > Subject: IF types durring review of EPON-04 >=20 > HI, >=20 > I'm doing a second review of EPON-04 I-D, which is=20 > http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-epon > -mib-04.tx > t >=20 > It is very complex and the previous review raised many questions. > The good news is that it is MUCH better, and it is finally to=20 > the level that someone can make sense of it. However, given=20 > that it is an interface MIB module, there are many additional=20 > considerations that must be followed. I don't remember all of=20 > them, and would need to refresh myself with these=20 > considerations to do a complete job. Is there anyone that can=20 > do a scan after I finish the first pass? >=20 > One question that I have so far is what interface type to use=20 > for the virtual links. The document uses the same value as=20 > the physical (which is gigabitEthernet(117)), but it seems to=20 > me that the propVirtual(53) is more appropriate. > =20 > In trying to determine the value for ifType, I looked at=20 > http://www.iana.org/assignments/ianaiftype-mib > In it I see that there are 234 types defined. > This seems like an extremely large number. Also, there is not=20 > a reference for each assigned value. > Thus, I could not figure out from looking at these values=20 > what values the should be used in the EPON MIB module. This=20 > seems like a generic problem that anyone implementing object=20 > ifType would encounter. And a delemma for anyone creating a=20 > new interface MIB module.=20 >=20 > Are there any suggestions that would help me now with the=20 > EPON MIB module, and for making it easier for future=20 > interface MIB module developers? >=20 > Regards, > /david t. perkins >=20 >=20 >=20 >=20 >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Sat May 20 22:16:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhdUR-00037n-F9; Sat, 20 May 2006 22:16:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhdUQ-00037i-PE for hubmib@ietf.org; Sat, 20 May 2006 22:16:18 -0400 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhdUP-000800-D0 for hubmib@ietf.org; Sat, 20 May 2006 22:16:18 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4L2ENDX008516 for ; Sat, 20 May 2006 22:14:24 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Sun, 21 May 2006 05:16:08 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IF types durring review of EPON-04 Thread-Index: AcZ8UQzEgCDMn2RGSUq7LDYt8zmZ/AAJ2ypA From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: Dave Thaler Subject: [Hubmib] FW: IF types durring review of EPON-04 X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org This discussion on the mreview (MIB Doctors list) refers to the layering model and usage of ifType values in the EPON MIB.=20 Comments and feedback are welcome, please make sure to copy Dave Perkins and Dave Thaler.=20 Dan =20 -----Original Message----- From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org] On Behalf Of David T. Perkins Sent: Sunday, May 21, 2006 12:05 AM To: Dave Thaler Cc: mreview@ops.ietf.org Subject: RE: IF types durring review of EPON-04 HI, Thank you for the comments below. In my original message, I was asking for ifType for the virtual interfaces. What value do you think they should use, and why? Regards, /david t. perkins On Fri, 19 May 2006, Dave Thaler wrote: > Ok, I've looked through EPON-04 with respect to the relationship to=20 > the interfaces MIB and the Ethernet mib. (I also saw lots of typos=20 > and grammatical errors in EPON-04, so someone should probably go=20 > through it for those. It also has lots of acronyms which are not=20 > expanded on first > use.) >=20 > The key sentence in EPON-04 is in section 3.1: > > Implementing this module therefore MUST require implementation of =20 > > Interfaces MIB module [RFC2863] and Ethernet-like Interfaces MIB =20 > > module [RFC3635]. >=20 > This is fine, since throughout the doc it says that EPON interfaces=20 > are Ethernet-like interfaces and they don't want to duplicate all the=20 > objects in that MIB. >=20 > However, the problem is it uses gigabitEthernet(117). >=20 > Section 3.2.4 of RFC 3635 (which, as quoted above, is a MUST for EPON > interfaces) says: > > It is REQUIRED that all ethernet-like interfaces use an ifType of=20 > > ethernetCsmacd(6) regardless of the speed that the interface is=20 > > running or the link-layer encapsulation in use. > and > > A requirement for > > compliance with this document is that all ethernet-like interfaces > > MUST return ethernetCsmacd(6) for ifType, and MUST NOT return =20 > > fastEther(62), fastEtherFX(69), or gigabitEthernet(117). >=20 > It's pretty clear from the above that the only legal value for use in=20 > EPON is ethernetCsmacd(6). >=20 > Similarly, the ianaiftype-mib says: > > gigabitEthernet (117), -- Obsoleted via > RFC-draft-ietf-hubmib-etherif-mib-v3 ethernetCsmacd (6) should be=20 > used instead >=20 > (Yes the reference in the comment is stale... per=20 > http://www.ietf.org/internet-drafts/draft-ietf-hubmib-etherif-mib-v3-03. > txt it is the same as RFC 3635 quoted above.) >=20 > The layering model described on page 13 (of using one Ethernet-like=20 > interface that is stacked on top of a set of other Ethernet-like > interaces) is fine. This is equivalent to what RFC 3371 (the L2TP=20 > MIB) does for multilink PPP for similar reasons. >=20 > Since EPON is not defining a new ifType, the other requirements in RFC > 2863 don't apply to it as they are met by RFC 3635. >=20 > -Dave >=20 > > -----Original Message----- > > From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org] > On > > Behalf Of Dave Thaler > > Sent: Friday, May 12, 2006 10:49 AM > > To: David T. Perkins; mreview@ops.ietf.org > > Subject: RE: IF types durring review of EPON-04 > >=20 > > I've been doing the reviews of relationships to the Interfaces MIB,=20 > > so I can do this, but I'm swamped right now. I could probably get=20 > > to > this > > by end of next week (5/19) if someone else doesn't get to it before=20 > > then. > >=20 > > -Dave > >=20 > > -----Original Message----- > > From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org] > On > > Behalf Of David T. Perkins > > Sent: Friday, May 12, 2006 10:25 AM > > To: mreview@ops.ietf.org > > Subject: IF types durring review of EPON-04 > >=20 > > HI, > >=20 > > I'm doing a second review of EPON-04 I-D, which is > > > http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-epon-mib-04. > tx > > t > >=20 > > It is very complex and the previous review raised many questions. > > The good news is that it is MUCH better, and it is finally to the=20 > > level that someone can make sense of it. However, given that it is=20 > > an interface MIB module, there are many additional considerations=20 > > that must be followed. I don't remember all of them, and would need=20 > > to refresh myself with these considerations to do a complete job. Is > > there anyone that can do a scan after I finish the first pass? > >=20 > > One question that I have so far is what interface type to use for=20 > > the virtual links. The document uses the same value as the physical=20 > > (which is gigabitEthernet(117)), but it seems to me that the=20 > > propVirtual(53) is more appropriate. > >=20 > > In trying to determine the value for ifType, I looked at=20 > > http://www.iana.org/assignments/ianaiftype-mib > > In it I see that there are 234 types defined. > > This seems like an extremely large number. Also, there is not a=20 > > reference for each assigned value. > > Thus, I could not figure out from looking at these values what=20 > > values the should be used in the EPON MIB module. This seems like a=20 > > generic problem that anyone implementing object ifType would=20 > > encounter. And a delemma for anyone creating a new interface MIB=20 > > module. > >=20 > > Are there any suggestions that would help me now with the EPON MIB=20 > > module, and for making it easier for future interface MIB module=20 > > developers? > >=20 > > Regards, > > /david t. perkins > >=20 > >=20 > >=20 > >=20 >=20 >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Fri May 26 18:50:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjl8n-0007uK-7n; Fri, 26 May 2006 18:50:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjl8l-0007u0-VP for hubmib@ietf.org; Fri, 26 May 2006 18:50:43 -0400 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjl8l-0001II-Aq for hubmib@ietf.org; Fri, 26 May 2006 18:50:43 -0400 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k4QMoegm032571; Fri, 26 May 2006 15:50:40 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k4QModeF032568; Fri, 26 May 2006 15:50:39 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 26 May 2006 15:50:39 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: hubmib@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Cc: lior.khermosh@passave.com Subject: [Hubmib] Review of EPON-04 X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org HI, My comments are below. General comments: 1) The updated document looks much better than the -03 version. 2) It runs through both SMICng and smilint with no problems. 3) I read through the document fairly quickly, and didn't try to verify all the references to other documents. 4) There are many grammar problems throughout the document, and, thus, the document would be much improved by a pass from a "copy editor" for technical documents. 5) The interface model that the document covers is quite unusual, and thus requires more work in this document to describe it than other well known and simple interfaces. 6) This version resolved many of issues from the previous revision. However, I still have concerns with a few corner cases. These include: a) discontinuity of counters b) dependencies of stacked interfaces 7) I believe that the document needs to be updated and reviewed at least one more time. Specific Comments: 0) The interface type should be ethernetCsmacd(6) as specified in RFC 3635. 1) The abstract and the overview paragraphs are different. The abstract includes management of P2MP networks, which is not included in the overview. 2) The terminology and abbreviations need to be checked for completeness. I noticed the following that need to be added: FEC - forward error correction P2MP - point to multipoint 3) In section 1.3, "management I/F" should be written out as "management interface". In the next sentence, I believe that instead of text "The MIB document", it should read "The IEEE MIB document", since IETF MIB documents don't have "packages". 4) The most important goal for section 1 is to describe the interface model. This version is so much better than the previous version. However, I'm still somewhat confused. The figure in section 1.2.1 and in 1.2.5 show typical devices having OLT and ONU interfaces. I'd like to see two more figures and interface table dumps. These are: An "ONU modem": -------- ONU interface | ONU | 10megabit interface --------------| Modem |-------------------- --------- Does this device have two or three entries in the IF table? And does it have an entry in the IF stack table. I believe that there are 3 IF entries, and one IF stack entries. For example in IF table: ifIndex=1 - interface for 10megabit interface ifIndex=2 - interface for the optical interface ifIndex=200 - interface for the ONU interface And then in IF stack table: ifStackHigherLayer=200, ifStackLowerLayer=2 - map between the physical and the ONU An "headend" with 1 gigibit ethernet interface, and two "OLT" interfaces: -------- 1st OLT interface | Head | gigE interface ------------------| end |-------------------- | | ------------------| | 2nd OLT interface | | --------- With no currently connected ONUs, I believe that there would be the following IF table and IF Stack table entries: For example in IF table: ifIndex=1 - interface for gigE interface ifIndex=2 - interface for 1st optical interface ifIndex=3 - interface for 2nd optical interface ifIndex=200 - interface for the 1st OLT broadcast interface ifIndex=300 - interface for the 2nd OLT broadcast interface And then in IF stack table: ifStackHigherLayer=200, ifStackLowerLayer=2 - map between the 1st physical and its broadcast OLT ifStackHigherLayer=300, ifStackLowerLayer=3 - map between the 2nd physical and its broadcast OLT If two ONUs connected to the first OLT, then the following would be added: For example in the IF table: ifIndex=201 - interface for the 1st ONU of 1st OLT ifIndex=202 - interface for the 2nd ONU of 1st OLT And in the IF stack table: ifStackHigherLayer=201, ifStackLowerLayer=2 - map between the 1st physical and 1st ONU ifStackHigherLayer=202, ifStackLowerLayer=2 - map between the 1st physical and 2nd ONU It seems that for "ONU modems" that there is not a an interface instance for the physical interface, where there is one for "headend" devices? I suggest that you do the following: a) in section 1.3, take the paragraph that starts with "At the OLT", and end it after the second sentence. b) Add the following paragraphs and figures: ------ To illustrate the interface modeling, consider two devices. The first device has two physical interfaces, is typically located at a consumer's site, and may be called a "ONU modem". This is shown in figure X below: -------- ONU interface | ONU | 10megabit interface --------------| modem |-------------------- --------- Figure X: ONU modem This device would have 3 entries in the IF table, for example: ifIndex=1 - interface for 10megabit interface ifIndex=2 - interface for the optical interface ifIndex=200 - interface for the ONU interface The second device has three physical interfaces, is typically located at the provider's site, and may be called a "headend". This is shown in figure Y below: --------- 1st OLT interface | Head | gigE interface ------------------| end |-------------------- | | ------------------| | 2nd OLT interface | | --------- Figure Y: headend This device would have 5 entries (when no attached ONUs) in the IF table, for example: ifIndex=1 - interface for gigE interface ifIndex=2 - interface for 1st optical interface ifIndex=3 - interface for 2nd optical interface ifIndex=200 - interface for the 1st OLT broadcast interface ifIndex=300 - interface for the 2nd OLT broadcast interface If two ONUs connected to the first OLT interface, then for example, the following entries would be added to the IF table: ifIndex=201 - interface for the 1st ONU of 1st OLT ifIndex=202 - interface for the 2nd ONU of 1st OLT ------ c) Continue with a slight change of the sentence that starts with "Therefore the Interface". Rewrite it to be something like: ------ For each physical interface, there would be an entry in the tables of the MAU MIB module[RFC3636] and Etherlike MIB module[RFC3635]. And additionally, there would be entries for the virtual links of the ONU and OLT interfaces. ------ d) Update the figures and tables through the remainder of the document to match the ifIndex assignments. 5) The end of section 1.3, which starts with sentence "As an example provided below are the values for the MPCP" should be moved to section 2 - where the MIB structure is discussed. 6) The figures labeled "Table 1" through "Table 4" are useful, but due to their size are problematic. I suggest that only index columns, columns that linkage to other tables, and columns what are different between ONU and OLT entries be included. 7) The first sentence after "Table 2" sort of looks like it should be a section head. 8) The value for dot3MpcpRemoteMACAddress in "table 3" should be 6 octets of zero (and not one). For example: 00:00:00:00:00:00 9) There needs to be a footnote, or text that explains the meaning of values OLT_MAC_Address, ONU{1,2,3}_MAC_Address, and BRCT_MAC_Address 10) The paragraph after "Table 4" seems to be misplaced, and should come before "Table 2". 11) Section 2 ("MIB structure") is weak. Moving the text from section 1.3 should help. 12) How the "extended package" tables were related was not well explained in section 2 (nor in their definition). It took me a while to figure out that object dot3ExtPkgObjectReportMaximumNumQueues affected the number of entries in tables dot3ExtPkgQueueTable and dot3ExtPkgQueueSetsTable. And that object dot3ExtPkgObjectReportMaximumNumThreshold affected the number of entries in table dot3ExtPkgQueueSetsTable. In general, I couldn't completely figure out the use of the tables in the "extended package" nor the expected values. 13) In section 2, the same terminology should be used. There is used "MIB objects", "MIB module", and "managed object". 14) Section 3.1 is quite useful (and required by all interface MIB module documents). (Note "Ether-like" is misspelled as "Ehter-like" in one place that I saw.) Missing is a discussion and example of the IF stack table (and the inverted stack table). Also missing is a discussion of what happens to counters when operation is stopped. 15) Section 3.2 mentions the "amended MAU MIB document", but the references specifies the current MAU MIB document. I suggest that you specify the new MAU I-D in the references (if available). 16) The abbreviations in the MODULE-IDENTITY specification need to be checked and updated for completeness. 17) The MPCP stats table has stats for both OLTs and ONUs, and counters that only have meaning on one of the OLT or ONU. In the later case, the text says the value is always zero. For example, object dot3MpcpDiscoveryWindowsSent always has a value of zero on ONUs, and object dot3MpcpTxRegRequest always has a value of zero on OLTs. This is a valid approach, but somewhat confusing. Another approach would be to split the table (and other similar table) into three tables for both, OLT, and ONU stats. Or to split into two tables with some columns duplicated (but of course with different descriptors). I'd like to hear opinions from others on this. 18) In general, there is an inconsistent description specified per object as to whether or not the value is always zero (a place holder). This should be cleaned up, since it is confusing that different words are used. The read questions whether or not the same thing is being said, but just using different words. 19) At first, I didn't understand why table dot3OmpEmulationTable is present. It's single object dot3OmpEmulationType appears to me to be the same as object dot3MpcpMode. However, looking at the MODULE-COMPLIANCE definitions, I see the need since for interpreting values in table dot3OmpEmulationStatTable you need to know if the interface is an OLT or ONU. This is not well explained in section 2. Also, maybe table dot3MpcpStatTable should AUGMENT table dot3MpcpControlTable; table dot3OmpEmulationStatTable should AUGMENT table dot3OmpEmulationTable. Table dot3EponFecTable doesn't need another table to indicate if the interface is a OLT or ONU, since the stats apply to both. 20) There appear to be some character set problems in the description for object dot3EponFecPCSCodingViolation. 21) You should probably say that the value 'unknown(1)' cannot be written to object dot3EponFecMode. 22) You should probably rewrite the description of object dot3EponFecBufferHeadCodingViolation so it is clear that the value is meanful only when in 1000 Mbps operation, and zero otherwise. 23) Object dot3ExtPkgObjectReset is an action object to reset "EPON" interfaces. What does a reset do to counters? Is there an object that counts the number of resets or provides a timestamp of last reset operation? Does a reset of one of the virtual interfaces reset only it, or the physical interface? 24) Object dot3ExtPkgObjectPowerDown causes an interface to be powered down or up. How does this work for the virtual interfaces? 25) Object dot3ExtPkgObjectNumberOfLLIDs seems silly (useless). Please explain. 26) What happens to counters and instances in the FEC table when the value of object dot3ExtPkgObjectFecEnabled is changed? 27) Object dot3ExtPkgObjectReportMaximumNumQueues is not well described. Also, it SYNTAX value should probably be Unsigned32(0..7). What happens if it is changed, to counters in the the tables dot3ExtPkgQueueTable and dot3ExtPkgQueueSetsTable. 28) I don't understand the function of object dot3ExtPkgObjectRegisterAction. Does it cause instances to be created or deleted? 29) The index dot3QueueIndex is not well explained in table/row for the Queue table. 30) I couldn't figure out objects dot3ExtPkgObjectReportNumThreshold and dot3ExtPkgObjectReportMaximumNumThreshold other than one of them controlled the number of queue sets. 31) I believe that the syntax of object dot3ExtPkgObjectReportMaximumNumThreshold should be Unsigned32(0..7). 32) It doesn't seem to make sense that there would be entries in table dot3ExtPkgOptIfTable for virtual interfaces. --- that's all Regards, /david t. perkins _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Mon May 29 04:17:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkcwc-00086X-PZ; Mon, 29 May 2006 04:17:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkcwb-00086S-8J for hubmib@ietf.org; Mon, 29 May 2006 04:17:45 -0400 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkcwa-0000I8-GD for hubmib@ietf.org; Mon, 29 May 2006 04:17:45 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4T8FhbL032697 for ; Mon, 29 May 2006 04:15:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 May 2006 11:17:26 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review for the EPON-04 Thread-Index: AcaBHLn1gdjprOV0SsGe+P7jf8auywB21kuw From: "Romascanu, Dan \(Dan\)" To: "David T. Perkins" , , "Lior Khermosh" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 4cbeb0f20efb229aa93fae1468d20275 Cc: "David Kessens \(E-mail\)" , hubmib@ietf.org, Dave Thaler Subject: [Hubmib] RE: Review for the EPON-04 X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org Thank you DavidP for the extensive review.=20 Lior, Can you please address the issues raised by David and let us know when will a new draft be available?=20 Thanks and Regards, Dan =20 =20 > -----Original Message----- > From: owner-mreview@ops.ietf.org=20 > [mailto:owner-mreview@ops.ietf.org] On Behalf Of David T. Perkins > Sent: Saturday, May 27, 2006 2:33 AM > To: mreview@ops.ietf.org > Cc: Dave Thaler > Subject: Review for the EPON-04 >=20 > HI, >=20 > Below is the review that I did for the EPON MIB document=20 > http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-epon > -mib-04.txt >=20 > Repeating from a previous message, this document was=20 > difficult for me to review due to several factors. First, the=20 > technology is quite unusual, and since it is new, it is not=20 > well documented. > What is available is in almost unreadable IEEE documents. > Secondly, the interfaces model is unusual. > The final major issue was that it had quite a bit of grammar=20 > problems, which made it difficult to decode. >=20 > The reason that I bring this document to your attention is so=20 > that if such a document is developed in the future, that the=20 > review can do a much faster turn around than me. >=20 > I have a few questions for the this list: > 1) Interface documents are special in that they must provide > an interpretation of the values of columnar objects from > the IF tables. Look at the Ethernet-like MIB document, > RFC 3635. If describes the value of each object. > Text and example values seem to be a good thing, > but is this too much work for the document author? >=20 > 2) The interfaces have many counters, and thus counter > stops, resumes, and discontinuity need to be clear. > But where and how much should this be addressed. >=20 > 3) The EPON model is a little strange because there > is a "provider side" and an "customer side". Some > of the events occur only on one side or the other. > The approach taken with the EPON tables was to > put all counters in a single table (per area) > and specify in the DESCRIPTION clause whether > the counter was applicable for both, or just > the provider or customer. If not applicable, > then the value was zero. Instead, should > each such table be split into 2 tables > (or three tables). 2 tables - one for > provider, and one for customer. 3 tables - > one for common, one for just provider, > and one for customer. >=20 > I'm probalably forgetting a few more questions, but I'm a=20 > little burned out from the review. >=20 > Here are my review notes: > General comments: > 1) The updated document looks much better than the -03 version.=20 > 2) It runs through both SMICng and smilint with no problems. > 3) I read through the document fairly quickly, and didn't > try to verify all the references to other documents. > 4) There are many grammar problems throughout the document, > and, thus, the document would be much improved by > a pass from a "copy editor" for technical documents. > 5) The interface model that the document covers is quite > unusual, and thus requires more work in this document=20 > to describe it than other well known and simple interfaces. > 6) This version resolved many of issues from the previous > revision. However, I still have concerns with a=20 > few corner cases. These include: > a) discontinuity of counters > b) dependencies of stacked interfaces > 7) I believe that the document needs to be updated and > reviewed at least one more time. >=20 > Specific Comments: > 0) The interface type should be ethernetCsmacd(6) as specified > in RFC 3635.=20 > 1) The abstract and the overview paragraphs are different. > The abstract includes management of P2MP networks, > which is not included in the overview. > 2) The terminology and abbreviations need to be checked > for completeness. I noticed the following that need > to be added: > FEC - forward error correction > P2MP - point to multipoint > 3) In section 1.3, "management I/F" should be written out > as "management interface". In the next sentence, I believe > that instead of text "The MIB document", it should read > "The IEEE MIB document", since IETF MIB documents don't > have "packages". > 4) The most important goal for section 1 is to describe the > interface model. This version is so much better than > the previous version. However, I'm still somewhat > confused. The figure in section 1.2.1 and in 1.2.5 > show typical devices having OLT and ONU interfaces. > I'd like to see two more figures and interface table > dumps. These are: > An "ONU modem": > -------- > ONU interface | ONU | 10megabit interface > --------------| Modem |--------------------=20 > --------- > Does this device have two or three entries in the IF table? > And does it have an entry in the IF stack table. I believe > that there are 3 IF entries, and one IF stack entries. > For example in IF table: > ifIndex=3D1 - interface for 10megabit interface > ifIndex=3D2 - interface for the optical interface > ifIndex=3D200 - interface for the ONU interface > And then in IF stack table: > ifStackHigherLayer=3D200, ifStackLowerLayer=3D2 - map between > the physical and the ONU > =20 > An "headend" with 1 gigibit ethernet interface, and > two "OLT" interfaces: > -------- > 1st OLT interface | Head | gigE interface > ------------------| end |--------------------=20 > | | > ------------------| | > 2nd OLT interface | | > --------- > With no currently connected ONUs, I believe that there > would be the following IF table and IF Stack table entries: > For example in IF table: > ifIndex=3D1 - interface for gigE interface > ifIndex=3D2 - interface for 1st optical interface > ifIndex=3D3 - interface for 2nd optical interface > ifIndex=3D200 - interface for the 1st OLT broadcast interface > ifIndex=3D300 - interface for the 2nd OLT broadcast interface > And then in IF stack table: > ifStackHigherLayer=3D200, ifStackLowerLayer=3D2 - map between > the 1st physical and its broadcast OLT > ifStackHigherLayer=3D300, ifStackLowerLayer=3D3 - map between > the 2nd physical and its broadcast OLT > If two ONUs connected to the first OLT, then the following > would be added: > For example in the IF table: > ifIndex=3D201 - interface for the 1st ONU of 1st OLT > ifIndex=3D202 - interface for the 2nd ONU of 1st OLT > And in the IF stack table: > ifStackHigherLayer=3D201, ifStackLowerLayer=3D2 - map between > the 1st physical and 1st ONU > ifStackHigherLayer=3D202, ifStackLowerLayer=3D2 - map between > the 1st physical and 2nd ONU > =20 > It seems that for "ONU modems" that there is not a > an interface instance for the physical interface, > where there is one for "headend" devices? >=20 > I suggest that you do the following: > a) in section 1.3, take the paragraph that starts with > "At the OLT", and end it after the second sentence. > b) Add the following paragraphs and figures: > ------ > To illustrate the interface modeling, consider > two devices. The first device has two > physical interfaces, is typically located at > a consumer's site, and may be called a "ONU modem". > This is shown in figure X below: > -------- > ONU interface | ONU | 10megabit interface > --------------| modem |--------------------=20 > --------- > Figure X: ONU modem >=20 > This device would have 3 entries in the IF table, > for example: > ifIndex=3D1 - interface for 10megabit interface > ifIndex=3D2 - interface for the optical interface > ifIndex=3D200 - interface for the ONU interface >=20 > The second device has three physical interfaces, > is typically located at the provider's site, and > may be called a "headend". This is shown in > figure Y below: >=20 > --------- > 1st OLT interface | Head | gigE interface > ------------------| end |--------------------=20 > | | > ------------------| | > 2nd OLT interface | | > --------- > Figure Y: headend >=20 > This device would have 5 entries (when no attached ONUs) > in the IF table, for example: > ifIndex=3D1 - interface for gigE interface > ifIndex=3D2 - interface for 1st optical interface > ifIndex=3D3 - interface for 2nd optical interface > ifIndex=3D200 - interface for the 1st OLT broadcast = interface > ifIndex=3D300 - interface for the 2nd OLT broadcast = interface >=20 > If two ONUs connected to the first OLT interface, then > for example, the following entries would be added to > the IF table: > ifIndex=3D201 - interface for the 1st ONU of 1st OLT > ifIndex=3D202 - interface for the 2nd ONU of 1st OLT >=20 > ------ >=20 > c) Continue with a slight change of the sentence that starts > with "Therefore the Interface". Rewrite it to be something > like: > ------ > For each physical interface, there would be an entry in > the tables of the MAU MIB module[RFC3636] and Etherlike > MIB module[RFC3635]. And additionally, there would be > entries for the virtual links of the ONU and OLT interfaces. > ------ > d) Update the figures and tables through the remainder of the > document to match the ifIndex assignments. > =20 > 5) The end of section 1.3, which starts with sentence "As an > example provided below are the values for the MPCP" should > be moved to section 2 - where the MIB structure is discussed. > =20 > 6) The figures labeled "Table 1" through "Table 4" are useful, > but due to their size are problematic. I suggest that > only index columns, columns that linkage to other tables, > and columns what are different between ONU and OLT entries > be included. >=20 > 7) The first sentence after "Table 2" sort of looks like it should > be a section head. > =20 > 8) The value for dot3MpcpRemoteMACAddress in "table 3" should > be 6 octets of zero (and not one). For example: > 00:00:00:00:00:00 > =20 > 9) There needs to be a footnote, or text that explains the > meaning of values OLT_MAC_Address, ONU{1,2,3}_MAC_Address, > and BRCT_MAC_Address > =20 > 10) The paragraph after "Table 4" seems to be misplaced, > and should come before "Table 2". >=20 > 11) Section 2 ("MIB structure") is weak. Moving the text from > section 1.3 should help. >=20 > 12) How the "extended package" tables were related was not > well explained in section 2 (nor in their definition). > It took me a while to figure out that object > dot3ExtPkgObjectReportMaximumNumQueues affected > the number of entries in tables dot3ExtPkgQueueTable > and dot3ExtPkgQueueSetsTable. And that object > dot3ExtPkgObjectReportMaximumNumThreshold affected > the number of entries in table dot3ExtPkgQueueSetsTable. > In general, I couldn't completely figure out > the use of the tables in the "extended package" > nor the expected values. >=20 > 13) In section 2, the same terminology should be used. There > is used "MIB objects", "MIB module", and "managed object". >=20 >=20 > 14) Section 3.1 is quite useful (and required by all interface > MIB module documents). (Note "Ether-like" is misspelled > as "Ehter-like" in one place that I saw.) > Missing is a discussion and example of the IF stack table > (and the inverted stack table). Also missing is a discussion > of what happens to counters when operation is stopped. >=20 > 15) Section 3.2 mentions the "amended MAU MIB document", but > the references specifies the current MAU MIB > document. I suggest that you specify the new MAU I-D > in the references (if available). > =20 > 16) The abbreviations in the MODULE-IDENTITY specification > need to be checked and updated for completeness. > =20 > 17) The MPCP stats table has stats for both OLTs and ONUs, > and counters that only have meaning on one of the > OLT or ONU. In the later case, the text says the value > is always zero. For example, object dot3MpcpDiscoveryWindowsSent > always has a value of zero on ONUs, and object > dot3MpcpTxRegRequest always has a value of zero > on OLTs. This is a valid approach, but somewhat > confusing. Another approach would be to split > the table (and other similar table) into three > tables for both, OLT, and ONU stats. Or to split > into two tables with some columns duplicated (but > of course with different descriptors). I'd like > to hear opinions from others on this. >=20 > 18) In general, there is an inconsistent description specified > per object as to whether or not the value is always > zero (a place holder). This should be cleaned up, > since it is confusing that different words are used. > The read questions whether or not the same thing > is being said, but just using different words. > =20 > =20 > 19) At first, I didn't understand why table dot3OmpEmulationTable > is present. It's single object dot3OmpEmulationType appears > to me to be the same as object dot3MpcpMode. However, looking > at the MODULE-COMPLIANCE definitions, I see the need since > for interpreting values in table dot3OmpEmulationStatTable > you need to know if the interface is an OLT or ONU. > This is not well explained in section 2. > Also, maybe table dot3MpcpStatTable should AUGMENT > table dot3MpcpControlTable; table dot3OmpEmulationStatTable > should AUGMENT table dot3OmpEmulationTable. Table > dot3EponFecTable doesn't need another table to > indicate if the interface is a OLT or ONU, since > the stats apply to both. >=20 > 20) There appear to be some character set problems in the > description for object dot3EponFecPCSCodingViolation. >=20 > 21) You should probably say that the value 'unknown(1)' cannot > be written to object dot3EponFecMode. >=20 > 22) You should probably rewrite the description of > object dot3EponFecBufferHeadCodingViolation so it > is clear that the value is meanful only when in > 1000 Mbps operation, and zero otherwise. >=20 > 23) Object dot3ExtPkgObjectReset is an action object to > reset "EPON" interfaces. What does a reset do > to counters? Is there an object that counts the > number of resets or provides a timestamp of > last reset operation? Does a reset of one > of the virtual interfaces reset only it, > or the physical interface? >=20 > 24) Object dot3ExtPkgObjectPowerDown causes an interface > to be powered down or up. How does this work for the > virtual interfaces? > =20 > 25) Object dot3ExtPkgObjectNumberOfLLIDs seems silly (useless). > Please explain. >=20 > 26) What happens to counters and instances in the FEC table > when the value of object dot3ExtPkgObjectFecEnabled is > changed? >=20 > 27) Object dot3ExtPkgObjectReportMaximumNumQueues is not > well described. Also, it SYNTAX value should > probably be Unsigned32(0..7). What happens if > it is changed, to counters in the the tables=20 > dot3ExtPkgQueueTable and dot3ExtPkgQueueSetsTable. >=20 > 28) I don't understand the function of object > dot3ExtPkgObjectRegisterAction. Does it cause > instances to be created or deleted? >=20 > 29) The index dot3QueueIndex is not well explained > in table/row for the Queue table. >=20 > 30) I couldn't figure out objects dot3ExtPkgObjectReportNumThreshold > and dot3ExtPkgObjectReportMaximumNumThreshold other > than one of them controlled the number of=20 > queue sets. >=20 > 31) I believe that the syntax of object > dot3ExtPkgObjectReportMaximumNumThreshold should be > Unsigned32(0..7). >=20 > 32) It doesn't seem to make sense that there would be > entries in table dot3ExtPkgOptIfTable for virtual > interfaces.=20 >=20 > --- that's all >=20 >=20 > Regards, > /david t. perkins >=20 >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Mon May 29 04:17:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkcwg-00087G-TU; Mon, 29 May 2006 04:17:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkcwf-00087B-J3 for hubmib@ietf.org; Mon, 29 May 2006 04:17:49 -0400 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkcwe-0000IG-Us for hubmib@ietf.org; Mon, 29 May 2006 04:17:49 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4T8FhbN032697 for ; Mon, 29 May 2006 04:16:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 May 2006 11:17:33 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review for the EPON-04 Thread-Index: AcaBHLn1gdjprOV0SsGe+P7jf8auywB25TVA From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 Subject: [Hubmib] FW: Review for the EPON-04 X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org =20 =20 -----Original Message----- From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org] On Behalf Of David T. Perkins Sent: Saturday, May 27, 2006 2:33 AM To: mreview@ops.ietf.org Cc: Dave Thaler Subject: Review for the EPON-04 HI, Below is the review that I did for the EPON MIB document http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-epon-mib-04.tx t Repeating from a previous message, this document was difficult for me to review due to several factors. First, the technology is quite unusual, and since it is new, it is not well documented. What is available is in almost unreadable IEEE documents. Secondly, the interfaces model is unusual. The final major issue was that it had quite a bit of grammar problems, which made it difficult to decode. The reason that I bring this document to your attention is so that if such a document is developed in the future, that the review can do a much faster turn around than me. I have a few questions for the this list: 1) Interface documents are special in that they must provide an interpretation of the values of columnar objects from the IF tables. Look at the Ethernet-like MIB document, RFC 3635. If describes the value of each object. Text and example values seem to be a good thing, but is this too much work for the document author? 2) The interfaces have many counters, and thus counter stops, resumes, and discontinuity need to be clear. But where and how much should this be addressed. 3) The EPON model is a little strange because there is a "provider side" and an "customer side". Some of the events occur only on one side or the other. The approach taken with the EPON tables was to put all counters in a single table (per area) and specify in the DESCRIPTION clause whether the counter was applicable for both, or just the provider or customer. If not applicable, then the value was zero. Instead, should each such table be split into 2 tables (or three tables). 2 tables - one for provider, and one for customer. 3 tables - one for common, one for just provider, and one for customer. I'm probalably forgetting a few more questions, but I'm a little burned out from the review. Here are my review notes: General comments: 1) The updated document looks much better than the -03 version.=20 2) It runs through both SMICng and smilint with no problems. 3) I read through the document fairly quickly, and didn't try to verify all the references to other documents. 4) There are many grammar problems throughout the document, and, thus, the document would be much improved by a pass from a "copy editor" for technical documents. 5) The interface model that the document covers is quite unusual, and thus requires more work in this document=20 to describe it than other well known and simple interfaces. 6) This version resolved many of issues from the previous revision. However, I still have concerns with a=20 few corner cases. These include: a) discontinuity of counters b) dependencies of stacked interfaces 7) I believe that the document needs to be updated and reviewed at least one more time. Specific Comments: 0) The interface type should be ethernetCsmacd(6) as specified in RFC 3635.=20 1) The abstract and the overview paragraphs are different. The abstract includes management of P2MP networks, which is not included in the overview. 2) The terminology and abbreviations need to be checked for completeness. I noticed the following that need to be added: FEC - forward error correction P2MP - point to multipoint 3) In section 1.3, "management I/F" should be written out as "management interface". In the next sentence, I believe that instead of text "The MIB document", it should read "The IEEE MIB document", since IETF MIB documents don't have "packages". 4) The most important goal for section 1 is to describe the interface model. This version is so much better than the previous version. However, I'm still somewhat confused. The figure in section 1.2.1 and in 1.2.5 show typical devices having OLT and ONU interfaces. I'd like to see two more figures and interface table dumps. These are: An "ONU modem": -------- ONU interface | ONU | 10megabit interface --------------| Modem |--------------------=20 --------- Does this device have two or three entries in the IF table? And does it have an entry in the IF stack table. I believe that there are 3 IF entries, and one IF stack entries. For example in IF table: ifIndex=3D1 - interface for 10megabit interface ifIndex=3D2 - interface for the optical interface ifIndex=3D200 - interface for the ONU interface And then in IF stack table: ifStackHigherLayer=3D200, ifStackLowerLayer=3D2 - map between the physical and the ONU =20 An "headend" with 1 gigibit ethernet interface, and two "OLT" interfaces: -------- 1st OLT interface | Head | gigE interface ------------------| end |--------------------=20 | | ------------------| | 2nd OLT interface | | --------- With no currently connected ONUs, I believe that there would be the following IF table and IF Stack table entries: For example in IF table: ifIndex=3D1 - interface for gigE interface ifIndex=3D2 - interface for 1st optical interface ifIndex=3D3 - interface for 2nd optical interface ifIndex=3D200 - interface for the 1st OLT broadcast interface ifIndex=3D300 - interface for the 2nd OLT broadcast interface And then in IF stack table: ifStackHigherLayer=3D200, ifStackLowerLayer=3D2 - map between the 1st physical and its broadcast OLT ifStackHigherLayer=3D300, ifStackLowerLayer=3D3 - map between the 2nd physical and its broadcast OLT If two ONUs connected to the first OLT, then the following would be added: For example in the IF table: ifIndex=3D201 - interface for the 1st ONU of 1st OLT ifIndex=3D202 - interface for the 2nd ONU of 1st OLT And in the IF stack table: ifStackHigherLayer=3D201, ifStackLowerLayer=3D2 - map between the 1st physical and 1st ONU ifStackHigherLayer=3D202, ifStackLowerLayer=3D2 - map between the 1st physical and 2nd ONU =20 It seems that for "ONU modems" that there is not a an interface instance for the physical interface, where there is one for "headend" devices? I suggest that you do the following: a) in section 1.3, take the paragraph that starts with "At the OLT", and end it after the second sentence. b) Add the following paragraphs and figures: ------ To illustrate the interface modeling, consider two devices. The first device has two physical interfaces, is typically located at a consumer's site, and may be called a "ONU modem". This is shown in figure X below: -------- ONU interface | ONU | 10megabit interface --------------| modem |--------------------=20 --------- Figure X: ONU modem This device would have 3 entries in the IF table, for example: ifIndex=3D1 - interface for 10megabit interface ifIndex=3D2 - interface for the optical interface ifIndex=3D200 - interface for the ONU interface The second device has three physical interfaces, is typically located at the provider's site, and may be called a "headend". This is shown in figure Y below: --------- 1st OLT interface | Head | gigE interface ------------------| end |--------------------=20 | | ------------------| | 2nd OLT interface | | --------- Figure Y: headend This device would have 5 entries (when no attached ONUs) in the IF table, for example: ifIndex=3D1 - interface for gigE interface ifIndex=3D2 - interface for 1st optical interface ifIndex=3D3 - interface for 2nd optical interface ifIndex=3D200 - interface for the 1st OLT broadcast interface ifIndex=3D300 - interface for the 2nd OLT broadcast interface If two ONUs connected to the first OLT interface, then for example, the following entries would be added to the IF table: ifIndex=3D201 - interface for the 1st ONU of 1st OLT ifIndex=3D202 - interface for the 2nd ONU of 1st OLT ------ c) Continue with a slight change of the sentence that starts with "Therefore the Interface". Rewrite it to be something like: ------ For each physical interface, there would be an entry in the tables of the MAU MIB module[RFC3636] and Etherlike MIB module[RFC3635]. And additionally, there would be entries for the virtual links of the ONU and OLT interfaces. ------ d) Update the figures and tables through the remainder of the document to match the ifIndex assignments. =20 5) The end of section 1.3, which starts with sentence "As an example provided below are the values for the MPCP" should be moved to section 2 - where the MIB structure is discussed. =20 6) The figures labeled "Table 1" through "Table 4" are useful, but due to their size are problematic. I suggest that only index columns, columns that linkage to other tables, and columns what are different between ONU and OLT entries be included. 7) The first sentence after "Table 2" sort of looks like it should be a section head. =20 8) The value for dot3MpcpRemoteMACAddress in "table 3" should be 6 octets of zero (and not one). For example: 00:00:00:00:00:00 =20 9) There needs to be a footnote, or text that explains the meaning of values OLT_MAC_Address, ONU{1,2,3}_MAC_Address, and BRCT_MAC_Address =20 10) The paragraph after "Table 4" seems to be misplaced, and should come before "Table 2". 11) Section 2 ("MIB structure") is weak. Moving the text from section 1.3 should help. 12) How the "extended package" tables were related was not well explained in section 2 (nor in their definition). It took me a while to figure out that object dot3ExtPkgObjectReportMaximumNumQueues affected the number of entries in tables dot3ExtPkgQueueTable and dot3ExtPkgQueueSetsTable. And that object dot3ExtPkgObjectReportMaximumNumThreshold affected the number of entries in table dot3ExtPkgQueueSetsTable. In general, I couldn't completely figure out the use of the tables in the "extended package" nor the expected values. 13) In section 2, the same terminology should be used. There is used "MIB objects", "MIB module", and "managed object". 14) Section 3.1 is quite useful (and required by all interface MIB module documents). (Note "Ether-like" is misspelled as "Ehter-like" in one place that I saw.) Missing is a discussion and example of the IF stack table (and the inverted stack table). Also missing is a discussion of what happens to counters when operation is stopped. 15) Section 3.2 mentions the "amended MAU MIB document", but the references specifies the current MAU MIB document. I suggest that you specify the new MAU I-D in the references (if available). =20 16) The abbreviations in the MODULE-IDENTITY specification need to be checked and updated for completeness. =20 17) The MPCP stats table has stats for both OLTs and ONUs, and counters that only have meaning on one of the OLT or ONU. In the later case, the text says the value is always zero. For example, object dot3MpcpDiscoveryWindowsSent always has a value of zero on ONUs, and object dot3MpcpTxRegRequest always has a value of zero on OLTs. This is a valid approach, but somewhat confusing. Another approach would be to split the table (and other similar table) into three tables for both, OLT, and ONU stats. Or to split into two tables with some columns duplicated (but of course with different descriptors). I'd like to hear opinions from others on this. 18) In general, there is an inconsistent description specified per object as to whether or not the value is always zero (a place holder). This should be cleaned up, since it is confusing that different words are used. The read questions whether or not the same thing is being said, but just using different words. =20 =20 19) At first, I didn't understand why table dot3OmpEmulationTable is present. It's single object dot3OmpEmulationType appears to me to be the same as object dot3MpcpMode. However, looking at the MODULE-COMPLIANCE definitions, I see the need since for interpreting values in table dot3OmpEmulationStatTable you need to know if the interface is an OLT or ONU. This is not well explained in section 2. Also, maybe table dot3MpcpStatTable should AUGMENT table dot3MpcpControlTable; table dot3OmpEmulationStatTable should AUGMENT table dot3OmpEmulationTable. Table dot3EponFecTable doesn't need another table to indicate if the interface is a OLT or ONU, since the stats apply to both. 20) There appear to be some character set problems in the description for object dot3EponFecPCSCodingViolation. 21) You should probably say that the value 'unknown(1)' cannot be written to object dot3EponFecMode. 22) You should probably rewrite the description of object dot3EponFecBufferHeadCodingViolation so it is clear that the value is meanful only when in 1000 Mbps operation, and zero otherwise. 23) Object dot3ExtPkgObjectReset is an action object to reset "EPON" interfaces. What does a reset do to counters? Is there an object that counts the number of resets or provides a timestamp of last reset operation? Does a reset of one of the virtual interfaces reset only it, or the physical interface? 24) Object dot3ExtPkgObjectPowerDown causes an interface to be powered down or up. How does this work for the virtual interfaces? =20 25) Object dot3ExtPkgObjectNumberOfLLIDs seems silly (useless). Please explain. 26) What happens to counters and instances in the FEC table when the value of object dot3ExtPkgObjectFecEnabled is changed? 27) Object dot3ExtPkgObjectReportMaximumNumQueues is not well described. Also, it SYNTAX value should probably be Unsigned32(0..7). What happens if it is changed, to counters in the the tables=20 dot3ExtPkgQueueTable and dot3ExtPkgQueueSetsTable. 28) I don't understand the function of object dot3ExtPkgObjectRegisterAction. Does it cause instances to be created or deleted? 29) The index dot3QueueIndex is not well explained in table/row for the Queue table. 30) I couldn't figure out objects dot3ExtPkgObjectReportNumThreshold and dot3ExtPkgObjectReportMaximumNumThreshold other than one of them controlled the number of=20 queue sets. 31) I believe that the syntax of object dot3ExtPkgObjectReportMaximumNumThreshold should be Unsigned32(0..7). 32) It doesn't seem to make sense that there would be entries in table dot3ExtPkgOptIfTable for virtual interfaces.=20 --- that's all Regards, /david t. perkins _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Wed May 31 14:10:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlV8x-0002zm-EC; Wed, 31 May 2006 14:10:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlV8x-0002zc-2w for hubmib@ietf.org; Wed, 31 May 2006 14:10:07 -0400 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlV8u-0006X8-Qm for hubmib@ietf.org; Wed, 31 May 2006 14:10:07 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4VI7Yv5001561 for ; Wed, 31 May 2006 14:07:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 May 2006 21:10:02 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcaE3W/MMbawU14iQHijAVIBastAbQAAAAFI From: "Romascanu, Dan \(Dan\)" To: "hubmib" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Hubmib] Out of Office AutoReply: X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1113165123==" Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============1113165123== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C684DD.6FD32ADA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C684DD.6FD32ADA Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I am out-of-office on vacation and will be back on June 5, 2006. I will = not read e-mai during this period. If you need to contact me urgently, = please leave a voice mail message at my office number. Regards, Dan ------_=_NextPart_001_01C684DD.6FD32ADA Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply:

I am out-of-office on vacation and will be back on = June 5, 2006.  I will not read e-mai during this period.  If = you need to contact me urgently, please leave a voice mail message at my = office number.

Regards,

Dan

------_=_NextPart_001_01C684DD.6FD32ADA-- --===============1113165123== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============1113165123==--