From mailman-bounces@ietf.org Sun Aug 1 08:20:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16935 for ; Sun, 1 Aug 2004 08:20:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrCgt-0002QP-08 for hubmib-archive@lists.ietf.org; Sun, 01 Aug 2004 05:31:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: hubmib-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sun, 01 Aug 2004 05:08:51 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for hubmib-archive@lists.ietf.org: List Password // URL ---- -------- hubmib@ietf.org XUKx https://www1.ietf.org/mailman/options/hubmib/hubmib-archive%40lists.ietf.org From hubmib-bounces@ietf.org Sun Aug 1 10:32:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02877 for ; Sun, 1 Aug 2004 10:32:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrGhz-0001U6-2s; Sun, 01 Aug 2004 09:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrEA7-0006BW-CR for hubmib@megatron.ietf.org; Sun, 01 Aug 2004 07:05:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12052 for ; Sun, 1 Aug 2004 07:05:52 -0400 (EDT) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrECk-0001Mg-Hj for hubmib@ietf.org; Sun, 01 Aug 2004 07:08:39 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i71B4OGa015019 for ; Sun, 1 Aug 2004 07:04:24 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i71B4MGa015001 for ; Sun, 1 Aug 2004 07:04:23 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Sun, 1 Aug 2004 14:05:50 +0300 Message-ID: Thread-Topic: draft-ietf-hubmib-efm-epon-mib-01.txt Thread-Index: AcR3t4CJqBnbf60qSaedrBIrEPVAoA== From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8df1ceff7d5e1ba4a25ab9834397277b Subject: [Hubmib] draft-ietf-hubmib-efm-epon-mib-01.txt X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1189167551==" Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============1189167551== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C477B7.81255A35" This is a multi-part message in MIME format. ------_=_NextPart_001_01C477B7.81255A35 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Technical T1. None of the two MIB modules compiles correctly. While the first MIB = modules warnings are caused by illegal characters in the DESCRIPTION = clauses, the EPON Device MIB has 'true compilation errors. Here is the = smilint log for these: This command (smilint 0.4.3-pre1, as of Tue Jul 27 14:25:07 2004) has been processed to get the following results: smilint -m -s -m -s -l 6 -i namelength-32 epon-device-mib.txt ... epon-device-mib.txt:230: [5] {integer-misuse} warning: use Integer32 = instead of INTEGER in SMIv2 epon-device-mib.txt:230: [2] {access-invalid-smiv2} invalid access = `read-Only' in SMIv2 MIB epon-device-mib.txt:329: [1] {other} parse error, unexpected '}', = expecting LOWERCASE_IDENTIFIER epon-device-mib.txt:329: [5] {} warning: flushing recent incorrect = declaration, see previous error(s) epon-device-mib.txt:330: [1] {other} parse error, unexpected MAX_ACCESS epon-device-mib.txt:334: [5] {} warning: flushing recent incorrect = declaration, see previous error(s) epon-device-mib.txt:341: [1] {other} parse error, unexpected '}', = expecting ')' epon-device-mib.txt:341: [5] {} warning: flushing recent incorrect = declaration, see previous error(s) epon-device-mib.txt:342: [1] {other} parse error, unexpected MAX_ACCESS epon-device-mib.txt:346: [5] {} warning: flushing recent incorrect = declaration, see previous error(s) ... epon-device-mib.txt:115: [3] {sequence-no-column} SEQUENCE element #9 = `eponDeviceObjectRemoteMACAddressLLIDTable' is not a child node under = `eponDeviceControlEntry' epon-device-mib.txt:115: [3] {sequence-no-column} SEQUENCE element #10 = `eponDeviceObjectReportThreshold' is not a child node under = `eponDeviceControlEntry' epon-device-mib.txt:125: [1] {} unknown object identifier label = `eponDeviceObjectRemoteMACAddressLLIDTable' epon-device-mib.txt:278: [3] {sequence-no-column} SEQUENCE element #4 = `eponDeviceRMadlRemoteMACAddress' is not a child node under = `eponDeviceRemoteMACAddressLLIDEntry' epon-device-mib.txt:278: [3] {sequence-no-column} SEQUENCE element #5 = `eponDeviceRMadlType' is not a child node under = `eponDeviceRemoteMACAddressLLIDEntry' epon-device-mib.txt:278: [3] {sequence-no-column} SEQUENCE element #6 = `eponDeviceRMadlAction' is not a child node under = `eponDeviceRemoteMACAddressLLIDEntry' epon-device-mib.txt:278: [3] {sequence-missing-column} SEQUENCE of = `EponDeviceRemoteMACAddressLLIDEntry' is missing columnar object = `eponDeviceRMadlRemoteMacAddress' epon-device-mib.txt:266: [5] {index-element-accessible} warning: index = element `eponDeviceRMadlLLID' of row = `eponDeviceRemoteMACAddressLLIDEntry' should be not-accessible in SMIv2 = MIB epon-device-mib.txt:282: [1] {} unknown object identifier label = `eponDeviceRMadlRemoteMACAddress' epon-device-mib.txt:283: [1] {} unknown object identifier label = `eponDeviceRMadlType' epon-device-mib.txt:284: [1] {} unknown object identifier label = `eponDeviceRMadlAction' epon-device-mib.txt:1218: [3] {group-member-invalid} node = `eponDeviceRMadlLogName' is an invalid member of group = `eponDeviceGroupRMadLTable' epon-device-mib.txt:316: [4] {group-membership} warning: node = `eponDeviceRMadlRemoteMacAddress' must be contained in at least one = conformance group T2. The document does not take a clear position about required changes = from the MAU MIB. As wit the efm-cu document, my preference would be = that we change the MAU MIB structure so that it is re-written as a = IANA-maintained module, but we need a volunteer to do this. T3. Clarify how are dot3MpcpID numbers assigned T4. Is dot3MpcpAdminState an admin state object as the name suggests, or = an oper state object as the read-only MAX-ACCESS and the DESCRIPTION = clause suggests? Same about dot3MPCPAdminControl T5. According to the DESCRIPTION dot3MpcpMaximumPendingGrants should be = in range (0..255) T6. Some of the objects in the dot3MpcpStatsTable seem to be mandatory = just for ONUs? What does an OLT which does not support the counter do? = Maybe the table should be broken into two tables. In any case the = Conformance clauses should reflect the optional support for some of the = counters.=20 T7. dot3OmpEmulationStatTable has objects mandatory for OLT and optional = for ONU. This should be reflected in the conformance cases, and maybe = the table should be broken in separate tables accordingly T8. Clarify what is being returned on a read operation for = eponDeviceObjectReset T9. It is not clear what values are allowed for write for the object = eponDeviceObjectReportThreshold. what does the reference to '2 octets = increments' mean? T10. Are values in eponDeviceRemoteMACAddressLLIDTable persitent, or can = they be erased on a reset? T11. The DESCRIPTION of the eponDeviceRemoteMACAddressLLIDTable is very = unclear - I did not understand how this works T12. What does the object eponDeviceRMadLogID with a SYNTAX of OBJECT = IDENTIFIER point to?=20 T13. The design of the eponDeviceEventsLogTable is not clear. What = notifications are being referred by this table? Why does this need to be = a dynamic row creation table?=20 T14. The security section claims that most objects are writeable when = the link is down. First there is a need to clarify what exactly is meant = by the link is down (ifAdminStatus =3D off(2)? for what ifIndex value?). = Second, this restriction needs to be mentioned for every specific = objects in the MIB module itself (DESCRIPTION clauses) and not left in = an external section.=20 T15. Why define a eponDeviceSerialNumber, and not use = entPhysicalSerialNumber from the Entity MIB? (RFC 2737, or = http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-entmib-v3-04= .txt) =20 Editorial E1. The Internet-Draft has awful formatting errors. Please follow the = guidelines at http://www.ietf.org/ietf/1id-guidelines.txt.=20 E2. Among these formatting errors, one very obvious, with effects on = compilation of the MIB modules as well is the use of illegal characters. E3. There is a new Intellectual Property Template that needs to be used. = See the same reference. E4. An IANA Consideration section needs to be added E5. Copyright year needs to be updated to 2004. E6. There are many spelling and syntax errors, that make the text = sometimes impossible to understand. In fact there are that many that I = will not list them all here, but rather forward a scribbled hardcopy to = the editors with hand-written markings. E7. All over the document - say 'MIB module' instead of MIB when = referring to the module, and not a specific MIB, and 'MIB modules' = instead of 'MIBs'=20 E8. DESCRIPTION clause of dot3MpcpTable - expand MPCP at the first = occurrence of the acronyms E9. There are many DEFVAL clauses missing for read-write or read-create = objects. For example: dot3MpcpMode, dot3EponMauFecMode, = eponDeviceObjectModes, eponDeviceObjectFecEnabled, = eponDeviceObjectOamMode, eponDeviceRMadLogID, = eponDeviceRMadRemoteMacAddress, eponDeviceRMadType, = eponDeviceRMadAction, eponDeviceSampleMinimum,=20 E10. There are many UNITS clauses missing. For example: = dot3MpcpTransmitElapsed, all counters in dot3MpcpStatsTable, all = counters in dot3OmpEmulationStatTable, counters in dot3EponMauTable, = counters in eponDeviceStatsTable E11. dot3OmpEmulationID DESCRIPTION includes reference to an IEEE = object. E12. I recommend that the tables that map the MIB objects defined in = this document into IEEE 802.3 objects be separated from the MIB objects = definition section. E13. All enumerated and BITS values need to be explained in DESCRIPTION. = E.g. 'A value of olt(1) means...' - Foe example in = eponDeviceObjectModes, eponDeviceObjectFecEnabled, = eponDeviceObjectOamMode,=20 E14. eponDeviceObjectPowerDown should refer to value true(1) E15. The significance of the events defined by the enumerated values of = eponDeviceEventsLogTable needs to be expanded E16. Why are DOCSIS MIB, Event MIB, Bridge MIB and Source Routing Bridge = MIB referenced?=20 Regards, Dan ------_=_NextPart_001_01C477B7.81255A35 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable draft-ietf-hubmib-efm-epon-mib-01.txt

Technical

T1. None of the two MIB = modules compiles correctly. While the first MIB modules warnings are = caused by illegal characters in the DESCRIPTION clauses, the EPON Device = MIB has 'true compilation errors. Here is the smilint log for = these:

This command (smilint = 0.4.3-pre1, as of Tue Jul 27 14:25:07 2004)

has been processed to get the = following results:

smilint -m -s -m -s -l 6 -i = namelength-32 epon-device-mib.txt

...

epon-device-mib.txt:230: [5] = {integer-misuse} warning: use Integer32 instead of INTEGER in = SMIv2

epon-device-mib.txt:230: [2] = {access-invalid-smiv2} invalid access `read-Only' in SMIv2 = MIB

epon-device-mib.txt:329: [1] = {other} parse error, unexpected '}', expecting = LOWERCASE_IDENTIFIER

epon-device-mib.txt:329: [5] = {} warning: flushing recent incorrect declaration, see previous = error(s)

epon-device-mib.txt:330: [1] = {other} parse error, unexpected MAX_ACCESS

epon-device-mib.txt:334: [5] = {} warning: flushing recent incorrect declaration, see previous = error(s)

epon-device-mib.txt:341: [1] = {other} parse error, unexpected '}', expecting ')'

epon-device-mib.txt:341: [5] = {} warning: flushing recent incorrect declaration, see previous = error(s)

epon-device-mib.txt:342: [1] = {other} parse error, unexpected MAX_ACCESS

epon-device-mib.txt:346: [5] = {} warning: flushing recent incorrect declaration, see previous = error(s)

...

epon-device-mib.txt:115: [3] = {sequence-no-column} SEQUENCE element #9 = `eponDeviceObjectRemoteMACAddressLLIDTable' is not a child node under = `eponDeviceControlEntry'

epon-device-mib.txt:115: [3] = {sequence-no-column} SEQUENCE element #10 = `eponDeviceObjectReportThreshold' is not a child node under = `eponDeviceControlEntry'

epon-device-mib.txt:125: [1] = {} unknown object identifier label = `eponDeviceObjectRemoteMACAddressLLIDTable'

epon-device-mib.txt:278: [3] = {sequence-no-column} SEQUENCE element #4 = `eponDeviceRMadlRemoteMACAddress' is not a child node under = `eponDeviceRemoteMACAddressLLIDEntry'

epon-device-mib.txt:278: [3] = {sequence-no-column} SEQUENCE element #5 `eponDeviceRMadlType' is not a = child node under `eponDeviceRemoteMACAddressLLIDEntry'

epon-device-mib.txt:278: [3] = {sequence-no-column} SEQUENCE element #6 `eponDeviceRMadlAction' is not = a child node under `eponDeviceRemoteMACAddressLLIDEntry'

epon-device-mib.txt:278: [3] = {sequence-missing-column} SEQUENCE of = `EponDeviceRemoteMACAddressLLIDEntry' is missing columnar object = `eponDeviceRMadlRemoteMacAddress'

epon-device-mib.txt:266: [5] = {index-element-accessible} warning: index element `eponDeviceRMadlLLID' = of row `eponDeviceRemoteMACAddressLLIDEntry' should be not-accessible in = SMIv2 MIB

epon-device-mib.txt:282: [1] = {} unknown object identifier label = `eponDeviceRMadlRemoteMACAddress'

epon-device-mib.txt:283: [1] = {} unknown object identifier label `eponDeviceRMadlType'

epon-device-mib.txt:284: [1] = {} unknown object identifier label `eponDeviceRMadlAction'

epon-device-mib.txt:1218: [3] = {group-member-invalid} node `eponDeviceRMadlLogName' is an invalid = member of group `eponDeviceGroupRMadLTable'

epon-device-mib.txt:316: [4] = {group-membership} warning: node `eponDeviceRMadlRemoteMacAddress' must = be contained in at least one conformance group

T2. The document does not = take a clear position about required changes from the MAU MIB. As wit = the efm-cu document, my preference would be that we change the MAU MIB = structure so that it is re-written as a IANA-maintained module, but we = need a volunteer to do this.

T3. Clarify how are = dot3MpcpID numbers assigned

T4. Is dot3MpcpAdminState an = admin state object as the name suggests, or an oper state object as the = read-only MAX-ACCESS and the DESCRIPTION clause suggests? Same about = dot3MPCPAdminControl

T5. According to the = DESCRIPTION dot3MpcpMaximumPendingGrants should be in range = (0..255)

T6. Some of the objects in = the dot3MpcpStatsTable seem to be mandatory just for ONUs? What does an = OLT which does not support the counter do? Maybe the table should be = broken into two tables. In any case the Conformance clauses should = reflect the optional support for some of the counters.

T7. dot3OmpEmulationStatTable = has objects mandatory for OLT and optional for ONU. This should be = reflected in the conformance cases, and maybe the table should be broken = in separate tables accordingly

T8. Clarify what is being = returned on a read operation for eponDeviceObjectReset

T9. It is not clear what = values are allowed for write for the object = eponDeviceObjectReportThreshold. what does the reference to '2 octets = increments' mean?

T10. Are values in = eponDeviceRemoteMACAddressLLIDTable persitent, or can they be erased on = a reset?

T11. The DESCRIPTION of the = eponDeviceRemoteMACAddressLLIDTable is very unclear - I did not = understand how this works

T12. What does the object = eponDeviceRMadLogID with a SYNTAX of OBJECT IDENTIFIER point to? =

T13. The design of the = eponDeviceEventsLogTable is not clear. What notifications are being = referred by this table? Why does this need to be a dynamic row creation = table?

T14. The security section = claims that most objects are writeable when the link is down. First = there is a need to clarify what exactly is meant by the link is down = (ifAdminStatus =3D off(2)? for what ifIndex value?). Second, this = restriction needs to be mentioned for every specific objects in the MIB = module itself (DESCRIPTION clauses) and not left in an external section. =

T15. Why define a = eponDeviceSerialNumber, and not use entPhysicalSerialNumber from the = Entity MIB? (RFC 2737, or http://www.ietf.cnri.reston.va.us/internet-drafts/draft-iet= f-entmib-v3-04.txt)

 

Editorial

E1. The Internet-Draft has = awful formatting errors. Please follow the guidelines at http://www.ietf.org/= ietf/1id-guidelines.txt.

E2. Among these formatting = errors, one very obvious, with effects on compilation of the MIB modules = as well is the use of illegal characters.

E3. There is a new = Intellectual Property Template that needs to be used. See the same = reference.

E4. An IANA Consideration = section needs to be added

E5. Copyright year needs to = be updated to 2004.

E6. There are many spelling = and syntax errors, that make the text sometimes impossible to = understand. In fact there are that many that I will not list them all = here, but rather forward a scribbled hardcopy to the editors with = hand-written markings.

E7. All over the document - = say 'MIB module' instead of MIB when referring to the module, and not a = specific MIB, and 'MIB modules' instead of 'MIBs'

E8. DESCRIPTION clause of = dot3MpcpTable - expand MPCP at the first occurrence of the = acronyms

E9. There are many DEFVAL = clauses missing for read-write or read-create objects. For example: = dot3MpcpMode, dot3EponMauFecMode, eponDeviceObjectModes, = eponDeviceObjectFecEnabled, eponDeviceObjectOamMode, = eponDeviceRMadLogID, eponDeviceRMadRemoteMacAddress, eponDeviceRMadType, = eponDeviceRMadAction, eponDeviceSampleMinimum,

E10. There are many UNITS = clauses missing. For example: dot3MpcpTransmitElapsed, all counters in = dot3MpcpStatsTable, all counters in dot3OmpEmulationStatTable, counters = in dot3EponMauTable, counters in eponDeviceStatsTable

E11. dot3OmpEmulationID = DESCRIPTION includes reference to an IEEE object.

E12. I recommend that the = tables that map the MIB objects defined in this document into IEEE 802.3 = objects be separated from the MIB objects definition section.

E13. All enumerated and BITS = values need to be explained in DESCRIPTION. E.g. 'A value of olt(1) = means...' - Foe example in eponDeviceObjectModes, = eponDeviceObjectFecEnabled, eponDeviceObjectOamMode,

E14. = eponDeviceObjectPowerDown should refer to value true(1)

E15. The significance of the = events defined by the enumerated values of eponDeviceEventsLogTable = needs to be expanded

E16. Why are DOCSIS MIB, = Event MIB, Bridge MIB and Source Routing Bridge MIB referenced? =



Regards,

Dan

------_=_NextPart_001_01C477B7.81255A35-- --===============1189167551== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============1189167551==-- From hubmib-bounces@ietf.org Sun Aug 1 12:43:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10022 for ; Sun, 1 Aug 2004 12:43:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrJD7-0005uJ-GO; Sun, 01 Aug 2004 12:29:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrJ1d-0000xn-8Z for hubmib@megatron.ietf.org; Sun, 01 Aug 2004 12:17:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08798 for ; Sun, 1 Aug 2004 12:17:26 -0400 (EDT) Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrJ4J-0005N7-2U for hubmib@ietf.org; Sun, 01 Aug 2004 12:20:16 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hubmib] draft-ietf-hubmib-efm-cu-01 comments X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Sun, 1 Aug 2004 12:16:57 -0400 Message-ID: <8052E2EA753D144EB906B7A7AA399714026F3CFA@mailserv.hatteras.com> Thread-Topic: draft-ietf-hubmib-efm-cu-01 comments Thread-Index: AcR132oeMtAeZUTTSNGIEf/TgZKOAQCA1qpA From: "Matt Squire" To: "Edward Beili (E-mail)" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Ed -=20 I went back and looked at various other counters in .3, and you can = ignore the following comment from my previous email. I think its right = the way you have it. - Matt >=20 > P25, PAF counters. Seems like it might be better to zero the=20 > counters when PAF is reset/disabled. E.g. You can disable=20 > the PAF, change out the whole set of PMEs, re-enable it, and=20 > it look like there's been a lot of problems on that PAF=20 > because the counters weren't reset, even though those=20 > counters have nothing to do with the current PMEs. =20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Mon Aug 2 20:39:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18237 for ; Mon, 2 Aug 2004 20:39:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brn9G-0006Wl-Id; Mon, 02 Aug 2004 20:27:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brmux-0000mw-S3 for hubmib@megatron.ietf.org; Mon, 02 Aug 2004 20:12:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16830 for ; Mon, 2 Aug 2004 20:12:34 -0400 (EDT) Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brmxu-0007dm-T9 for hubmib@ietf.org; Mon, 02 Aug 2004 20:15:40 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 2 Aug 2004 20:12:03 -0400 Message-ID: <8052E2EA753D144EB906B7A7AA39971402B07804@mailserv.hatteras.com> Thread-Topic: ifSpeed & 2BASE-TL/10PASS-TS Thread-Index: AcR47nt83507Qe6mSEy+SQuPacCB7Q== From: "Matt Squire" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: "Edward Beili \(E-mail\)" Subject: [Hubmib] ifSpeed & 2BASE-TL/10PASS-TS X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I figured I'd fire off a note to the reflectors to get this discussion = started. =20 During the discussions today in the hubmib WG, the question arose as to = what should be the ifSpeed for 2BASE-TL & 10PASS-TS interfaces. =20 Traditionally, it seems the ifSpeed has been tied to the speed of the = MAC (e.g. 10Mbps, 100Mbps, etc.). With 2BASE/10PASS, the PHY may be = running at a much lower speed than the 100Mbps MAC, so its not = particularly useful to the administrator to call all of these interfaces = 100M when the PHYs aren't there. =20 Options for ifSpeed of 2BASE/10PASS seem to include the following: 0) Use 100 Mbps (MAC speed). =20 1) Sum the physical date rates of PMEs in the aggregate (PHY speed). =20 2) Use the rate of "goodput" on the PHYs (e.g. how much data can ge = thru). This would ignore any overhead of the PHY (PAF, 64/65) and = overhead of the MAC (preamble, IPG). This most accurately reflects how = much data can get thru. =20 3) Use the rate at the MAC/MII. E.g. include preamble/IPG (even though = its not transmitted), but not PHY overhead (PAF, 64/65). This seems = consistent with other PHYs, but is kinda weird in that we're not = actually transmitting preamble/ipg. =20 There are probably other options too. Thoughts/opinions? =20 - Matt _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Mon Aug 2 23:57:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27495 for ; Mon, 2 Aug 2004 23:57:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrqIT-0006A5-TO; Mon, 02 Aug 2004 23:49:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrqCw-0004fI-8P for hubmib@megatron.ietf.org; Mon, 02 Aug 2004 23:43:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26890 for ; Mon, 2 Aug 2004 23:43:19 -0400 (EDT) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrqFu-00027g-Q8 for hubmib@ietf.org; Mon, 02 Aug 2004 23:46:28 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i733fnGa022059 for ; Mon, 2 Aug 2004 23:41:49 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i733flGa022049 for ; Mon, 2 Aug 2004 23:41:48 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 3 Aug 2004 06:43:15 +0300 Message-ID: Thread-Topic: hubmib meeting summary Thread-Index: AcR5DAG8lOBWLDIMTlq4WLBv/tNGbg== From: "Romascanu, Dan (Dan)" To: , X-Spam-Score: 0.5 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: hubmib@ietf.org Subject: [Hubmib] hubmib meeting summary X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0373608774==" Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============0373608774== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4790C.022276F6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4790C.022276F6 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable The Ethernet interfaces and hub MIB WG (hubmib) met for one session at = the 60th IETF. The WG discussed the latest changes, comments and open = issues for the three chartered WG Internet-Drafts related to the = Ethernet First Mile (EFM) technology. The participants in the meeting = recommended that the MAU MIB be re-written to refer to a IANA-maintained = Textual Convention, which would ease the support for new MAUs in the = future, without requiring opening of the MAU MIB documents. A new = version of the Internet-Drafts will be submitted by the editors of the = three documents until September 8, 2004.=20 Regards, Dan ------_=_NextPart_001_01C4790C.022276F6 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable hubmib meeting summary

The Ethernet interfaces and = hub MIB WG (hubmib) met for one session at the 60th IETF. The WG = discussed the latest changes, comments and open issues for the three = chartered WG Internet-Drafts related to the Ethernet First Mile (EFM) = technology. The participants in the meeting recommended that the MAU MIB = be re-written to refer to a IANA-maintained Textual Convention, which = would ease the support for new MAUs in the future, without requiring = opening of the MAU MIB documents. A new version of the Internet-Drafts = will be submitted by the editors of the three documents until September = 8, 2004.

Regards,

Dan

------_=_NextPart_001_01C4790C.022276F6-- --===============0373608774== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============0373608774==-- From hubmib-bounces@ietf.org Tue Aug 3 12:59:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21704 for ; Tue, 3 Aug 2004 12:59:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2QY-00025w-N6; Tue, 03 Aug 2004 12:46:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2No-0001Nn-LR for hubmib@megatron.ietf.org; Tue, 03 Aug 2004 12:43:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20125 for ; Tue, 3 Aug 2004 12:43:20 -0400 (EDT) Received: from [62.90.13.193] (helo=il-mail.actelis.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2Qq-0004Q6-OT for hubmib@ietf.org; Tue, 03 Aug 2004 12:46:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Aug 2004 19:42:42 +0300 Message-ID: <9C1CAB2B65E62D49A10E49DFCD68EF3E03BE57@il-mail.actelis.net> Thread-Topic: [EFM] ifSpeed & 2BASE-TL/10PASS-TS Thread-Index: AcR5FoUmonokpW7OQLaUH3qmtKHLnwAXx/Ci From: "Edward Beili" To: "Hugh Barrass" , , "Matt Squire" X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: hubmib@ietf.org Subject: [Hubmib] RE: [EFM] ifSpeed & 2BASE-TL/10PASS-TS X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1877063506==" Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============1877063506== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47978.E54F4534" This is a multi-part message in MIME format. ------_=_NextPart_001_01C47978.E54F4534 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SHVnaCwNCiANCkkgZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQgeW91ciAzKzEgb3B0aW9uLg0KIA0K SW4gbXkgdmlldyB0aGUgY3JpdGVyaWEgc2hhbGwgYmUgYXMgZm9sbG93czoNClN1cHBvc2UgeW91 IGhhdmUgdGhlIGZvbGxvd2luZyBzeXN0ZW0gY29uZmlndXJhdGlvbjoNCiANCltTbWFydGJpdHNd LS0tLTEwQmFzZVQtLS0tW0VGTUN1IENPXS0tLS0yQmFzZVRMLS0tLS1bRUZNQ3UgUlRdLS0tLTEw QmFzZVQtLS1bU21hcnRiaXRzXQ0KICAgICAgICAgICAgICAgICAgICBpZlNwZWVkPTEwTWJwcyAg ICAgICAgICAgICAgICAgICBpZlNwZWVkPTEwTWJwcyAgICAgICAgICAgICAgICAgICAgIGlmU3Bl ZWQ9MTBNYnBzDQogDQpJZiB0aGUgRUZNQ3UgbGluayByZXBvcnRzIGl0cyBpZlNwZWVkIGFzIDEw TWJwcywgcHJvdmlkZWQgdGhhdCB0aGUgTUFDIGJyaWRnZSBpbiB0aGUgRUZNQ3UgQ08gYW5kIFJU IGlzIHdpcmUtc3BlZWQsIHRoZXJlIHNob3VsZCBiZSBubyBwYWNrZXQgbG9zcyB3aGVuIEkgZmly ZSB0aGUgU21hcnRiaXRzIGluIGZ1bGwgZHVwbGV4IDEwTWJwcyAxMDAlIHdpdGggbWluIElGRyB3 aXRoIGZyYW1lIGxlbmd0aCBvZiA2NCBCeXRlcyBhbmQgMTUxOCBCeXRlcy4NCiANCkl0IGxvb2tz IHRvIG1lIHRoYXQgb3B0aW9uIDMsIGkuZS4gc3VtIG9mIG1vZGVtIGRhdGEgcmF0ZXMgd2l0aG91 dCA2NC82NUIgZW5jYXBzdWxhdGlvbiBhbmQgUEFGIG92ZXJoZWFkIGJ1dCB3aXRoIElGRywgYW5z d2VycyB0aGlzIGNyaXRlcmlhIGJlc3QuDQpUaGUgcmVwb3J0ZWQgaWZTUGVlZCBtYXkgbm90IGJl IHN1cGVyIGFjY3VyYXRlLCB0aGUgZXJyb3IgaG93ZXZlciBzaG91bGQgYWx3YXlzIGJlIHBvc2l0 aXZlLCBpLmUuIG5vIHBvc3NpYmxlIHBhY2tldCBsb3NzIGluIHRoZSBjb25maWd1cmF0aW9uIGFi b3ZlLiBPYnZpb3VzbHkgb3B0aW9uIDIgKGdvb2RwdXQpIHdvdWxkIHdvcmsgYXMgd2VsbC4NCiAN ClJlZ2FyZHMsDQotRS4NCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IG93 bmVyLXN0ZHMtODAyLTMtZWZtQGxpc3RzZXJ2LmllZWUub3JnIG9uIGJlaGFsZiBvZiBIdWdoIEJh cnJhc3MgDQoJU2VudDogVHVlIDgvMy8yMDA0IDc6NDggQU0gDQoJVG86IFNURFMtODAyLTMtRUZN QGxpc3RzZXJ2LmllZWUub3JnIA0KCUNjOiANCglTdWJqZWN0OiBSZTogW0VGTV0gaWZTcGVlZCAm IDJCQVNFLVRMLzEwUEFTUy1UUw0KCQ0KCQ0KDQoJTWF0dCwNCgkNCglJIHdvdWxkIGdvIHdpdGgg MykgcGx1cyAxKSAtIHJlYXNvbnM6DQoJDQoJMCkgaXMganVzdCBwbGFpbiB3cm9uZyENCgkNCgkx KSBUaGUgYWdncmVnYXRlZCBsaW5rcyBhcHBlYXIgdG8gdGhlIE1BQyBhbmQgdXBwZXIgbGF5ZXJz IGFzIGEgc2luZ2xlDQoJbGluay4gVGhlIGFnZ3JlZ2F0ZWQgbGluayBzcGVlZCBnb3Zlcm5zIHRo ZSByYXRlIGFjcm9zcyB0aGUgTUlJLg0KCQ0KCTIpIFdlJ3ZlIG5ldmVyIGFjY291bnRlZCBmb3Ig Imdvb2RwdXQiIGJlZm9yZQ0KCQ0KCTMpIFRoYXQncyBob3cgd2UgaGF2ZSBkb25lIGl0IGZvciBh bGwgb3RoZXIgUEhZcy4gVGhlIG92ZXJoZWFkIG9mDQoJZW5jYXBzdWxhdGlvbiBpcyBhYnNvcmJl ZCBieSB0aGUgbGluayBydW5uaW5nIGF0IGEgZmFzdGVyIHJhdGUgdGhhbiB0aGUNCglNSUkgKHdo ZXRoZXIgaXQncyA0YjViLCA4Yi8xMGIgb3IgNjRiLzY2YikuIEJ1dCB0aGUgZWZmZWN0IG9mIHRo ZSBJUEcNCglkZXBlbmRzIG9uIHRoZSBmcmFtZSBzaXplLCBzbyBpcyBpZ25vcmVkLg0KCQ0KCVNv LCBJIHRoaW5rIGl0IHNob3VsZCBiZSB0aGUgYWdncmVnYXRlIHJhdGUgYXQgdGhlIE1JSSBmb3Ig YW4gaW1hZ2luYXJ5LA0KCWluZmluaXRlIGxlbmd0aCBmcmFtZS4NCgkNCglIdWdoLg0KCQ0KCU1h dHQgU3F1aXJlIHdyb3RlOg0KCQ0KCT5JIGZpZ3VyZWQgSSdkIGZpcmUgb2ZmIGEgbm90ZSB0byB0 aGUgcmVmbGVjdG9ycyB0byBnZXQgdGhpcyBkaXNjdXNzaW9uIHN0YXJ0ZWQuDQoJPg0KCT5EdXJp bmcgdGhlIGRpc2N1c3Npb25zIHRvZGF5IGluIHRoZSBodWJtaWIgV0csIHRoZSBxdWVzdGlvbiBh cm9zZSBhcyB0byB3aGF0IHNob3VsZCBiZSB0aGUgaWZTcGVlZCBmb3IgMkJBU0UtVEwgJiAxMFBB U1MtVFMgaW50ZXJmYWNlcy4NCgk+DQoJPlRyYWRpdGlvbmFsbHksIGl0IHNlZW1zIHRoZSBpZlNw ZWVkIGhhcyBiZWVuIHRpZWQgdG8gdGhlIHNwZWVkIG9mIHRoZSBNQUMgKGUuZy4gMTBNYnBzLCAx MDBNYnBzLCBldGMuKS4gIFdpdGggMkJBU0UvMTBQQVNTLCB0aGUgUEhZIG1heSBiZSBydW5uaW5n IGF0IGEgbXVjaCBsb3dlciBzcGVlZCB0aGFuIHRoZSAxMDBNYnBzIE1BQywgc28gaXRzIG5vdCBw YXJ0aWN1bGFybHkgdXNlZnVsIHRvIHRoZSBhZG1pbmlzdHJhdG9yIHRvIGNhbGwgYWxsIG9mIHRo ZXNlIGludGVyZmFjZXMgMTAwTSB3aGVuIHRoZSBQSFlzIGFyZW4ndCB0aGVyZS4NCgk+DQoJPk9w dGlvbnMgZm9yIGlmU3BlZWQgb2YgMkJBU0UvMTBQQVNTIHNlZW0gdG8gaW5jbHVkZSB0aGUgZm9s bG93aW5nOg0KCT4NCgk+MCkgVXNlIDEwMCBNYnBzIChNQUMgc3BlZWQpLg0KCT4NCgk+MSkgU3Vt IHRoZSBwaHlzaWNhbCBkYXRlIHJhdGVzIG9mIFBNRXMgaW4gdGhlIGFnZ3JlZ2F0ZSAoUEhZIHNw ZWVkKS4NCgk+DQoJPjIpIFVzZSB0aGUgcmF0ZSBvZiAiZ29vZHB1dCIgb24gdGhlIFBIWXMgKGUu Zy4gaG93IG11Y2ggZGF0YSBjYW4gZ2UgdGhydSkuICBUaGlzIHdvdWxkIGlnbm9yZSBhbnkgb3Zl cmhlYWQgb2YgdGhlIFBIWSAoUEFGLCA2NC82NSkgYW5kIG92ZXJoZWFkIG9mIHRoZSBNQUMgKHBy ZWFtYmxlLCBJUEcpLiAgVGhpcyBtb3N0IGFjY3VyYXRlbHkgcmVmbGVjdHMgaG93IG11Y2ggZGF0 YSBjYW4gZ2V0IHRocnUuDQoJPg0KCT4zKSBVc2UgdGhlIHJhdGUgYXQgdGhlIE1BQy9NSUkuICBF LmcuIGluY2x1ZGUgcHJlYW1ibGUvSVBHIChldmVuIHRob3VnaCBpdHMgbm90IHRyYW5zbWl0dGVk KSwgYnV0IG5vdCBQSFkgb3ZlcmhlYWQgKFBBRiwgNjQvNjUpLiAgVGhpcyBzZWVtcyBjb25zaXN0 ZW50IHdpdGggb3RoZXIgUEhZcywgYnV0IGlzIGtpbmRhIHdlaXJkIGluIHRoYXQgd2UncmUgbm90 IGFjdHVhbGx5IHRyYW5zbWl0dGluZyBwcmVhbWJsZS9pcGcuDQoJPg0KCT5UaGVyZSBhcmUgcHJv YmFibHkgb3RoZXIgb3B0aW9ucyB0b28uICBUaG91Z2h0cy9vcGluaW9ucz8NCgk+DQoJPi0gTWF0 dA0KCT4NCgk+DQoJPg0KCQ0KDQo= ------_=_NextPart_001_01C47978.E54F4534 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjY1NTYuMCI+CjxUSVRMRT5SZTogW0VGTV0gaWZTcGVl ZCAmYW1wOyAyQkFTRS1UTC8xMFBBU1MtVFM8L1RJVExFPgo8L0hFQUQ+CjxCT0RZIGRpcj1sdHI+ CjxESVY+SHVnaCw8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5JIGRvbid0IHJlYWxseSB1 bmRlcnN0YW5kIHlvdXIgMysxIG9wdGlvbi48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5J biBteSB2aWV3IHRoZSBjcml0ZXJpYSBzaGFsbCBiZSBhcyBmb2xsb3dzOjwvRElWPgo8RElWPlN1 cHBvc2UgeW91IGhhdmUgdGhlIGZvbGxvd2luZyBzeXN0ZW0gY29uZmlndXJhdGlvbjo8L0RJVj4K PERJVj4mbmJzcDs8L0RJVj4KPERJVj5bU21hcnRiaXRzXS0tLS0xMEJhc2VULS0tLVtFRk1DdSBD T10tLS0tMkJhc2VUTC0tLS0tW0VGTUN1IApSVF0tLS0tMTBCYXNlVC0tLVtTbWFydGJpdHNdPC9E SVY+CjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IAppZlNwZWVkPTEwTWJwcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2lmU3BlZWQ9MTBNYnBzJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aWZTcGVl ZD0xME1icHM8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5JZiB0aGUgRUZNQ3UgbGluayBy ZXBvcnRzIGl0cyBpZlNwZWVkIGFzIDEwTWJwcywgcHJvdmlkZWQgdGhhdCB0aGUgTUFDIApicmlk Z2UgaW4gdGhlIEVGTUN1IENPIGFuZCBSVCBpcyB3aXJlLXNwZWVkLCB0aGVyZSBzaG91bGQgYmUg bm8gcGFja2V0IGxvc3Mgd2hlbiAKSSBmaXJlIHRoZSBTbWFydGJpdHMgaW4gZnVsbCBkdXBsZXgg MTBNYnBzIDEwMCUgd2l0aCBtaW4gSUZHIHdpdGggZnJhbWUgbGVuZ3RoIApvZiA2NCBCeXRlcyBh bmQgMTUxOCBCeXRlcy48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5JdCBsb29rcyB0byBt ZSB0aGF0IG9wdGlvbiAzLCBpLmUuIHN1bSBvZiBtb2RlbSBkYXRhIHJhdGVzIHdpdGhvdXQgNjQv NjVCIAplbmNhcHN1bGF0aW9uIGFuZCBQQUYgb3ZlcmhlYWQgYnV0IHdpdGggSUZHLCBhbnN3ZXJz IHRoaXMgY3JpdGVyaWEgYmVzdC48L0RJVj4KPERJVj5UaGUgcmVwb3J0ZWQgaWZTUGVlZCBtYXkg bm90IGJlIHN1cGVyIGFjY3VyYXRlLCB0aGUgZXJyb3IgaG93ZXZlciBzaG91bGQgCmFsd2F5cyBi ZSBwb3NpdGl2ZSwgaS5lLiBubyBwb3NzaWJsZSBwYWNrZXQgbG9zcyBpbiB0aGUgY29uZmlndXJh dGlvbiBhYm92ZS4gCk9idmlvdXNseSBvcHRpb24gMiAoZ29vZHB1dCkgd291bGQgd29yayBhcyB3 ZWxsLjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPlJlZ2FyZHMsPC9ESVY+CjxESVY+LUUu PC9ESVY+CjxCTE9DS1FVT1RFIGRpcj1sdHIgc3R5bGU9Ik1BUkdJTi1SSUdIVDogMHB4Ij4KICA8 RElWPjxGT05UIHNpemU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSA8QlI+PEI+RnJvbTo8 L0I+IAogIG93bmVyLXN0ZHMtODAyLTMtZWZtQGxpc3RzZXJ2LmllZWUub3JnJm5ic3A7b24gYmVo YWxmIG9mJm5ic3A7SHVnaCBCYXJyYXNzIAogIDxCUj48Qj5TZW50OjwvQj4gVHVlIDgvMy8yMDA0 IDc6NDggQU0gPEJSPjxCPlRvOjwvQj4gCiAgU1REUy04MDItMy1FRk1AbGlzdHNlcnYuaWVlZS5v cmcgPEJSPjxCPkNjOjwvQj4gPEJSPjxCPlN1YmplY3Q6PC9CPiBSZTogW0VGTV0gCiAgaWZTcGVl ZCAmYW1wOyAyQkFTRS1UTC8xMFBBU1MtVFM8QlI+PEJSPjwvRk9OVD48L0RJVj4KICA8UD48Rk9O VCBzaXplPTI+TWF0dCw8QlI+PEJSPkkgd291bGQgZ28gd2l0aCAzKSBwbHVzIDEpIC0gcmVhc29u czo8QlI+PEJSPjApIAogIGlzIGp1c3QgcGxhaW4gd3JvbmchPEJSPjxCUj4xKSBUaGUgYWdncmVn YXRlZCBsaW5rcyBhcHBlYXIgdG8gdGhlIE1BQyBhbmQgCiAgdXBwZXIgbGF5ZXJzIGFzIGEgc2lu Z2xlPEJSPmxpbmsuIFRoZSBhZ2dyZWdhdGVkIGxpbmsgc3BlZWQgZ292ZXJucyB0aGUgcmF0ZSAK ICBhY3Jvc3MgdGhlIE1JSS48QlI+PEJSPjIpIFdlJ3ZlIG5ldmVyIGFjY291bnRlZCBmb3IgImdv b2RwdXQiIGJlZm9yZTxCUj48QlI+MykgCiAgVGhhdCdzIGhvdyB3ZSBoYXZlIGRvbmUgaXQgZm9y IGFsbCBvdGhlciBQSFlzLiBUaGUgb3ZlcmhlYWQgCiAgb2Y8QlI+ZW5jYXBzdWxhdGlvbiBpcyBh YnNvcmJlZCBieSB0aGUgbGluayBydW5uaW5nIGF0IGEgZmFzdGVyIHJhdGUgdGhhbiAKICB0aGU8 QlI+TUlJICh3aGV0aGVyIGl0J3MgNGI1YiwgOGIvMTBiIG9yIDY0Yi82NmIpLiBCdXQgdGhlIGVm ZmVjdCBvZiB0aGUgCiAgSVBHPEJSPmRlcGVuZHMgb24gdGhlIGZyYW1lIHNpemUsIHNvIGlzIGln bm9yZWQuPEJSPjxCUj5TbywgSSB0aGluayBpdCBzaG91bGQgCiAgYmUgdGhlIGFnZ3JlZ2F0ZSBy YXRlIGF0IHRoZSBNSUkgZm9yIGFuIGltYWdpbmFyeSw8QlI+aW5maW5pdGUgbGVuZ3RoIAogIGZy YW1lLjxCUj48QlI+SHVnaC48QlI+PEJSPk1hdHQgU3F1aXJlIHdyb3RlOjxCUj48QlI+Jmd0O0kg ZmlndXJlZCBJJ2QgZmlyZSAKICBvZmYgYSBub3RlIHRvIHRoZSByZWZsZWN0b3JzIHRvIGdldCB0 aGlzIGRpc2N1c3Npb24gCiAgc3RhcnRlZC48QlI+Jmd0OzxCUj4mZ3Q7RHVyaW5nIHRoZSBkaXNj dXNzaW9ucyB0b2RheSBpbiB0aGUgaHVibWliIFdHLCB0aGUgCiAgcXVlc3Rpb24gYXJvc2UgYXMg dG8gd2hhdCBzaG91bGQgYmUgdGhlIGlmU3BlZWQgZm9yIDJCQVNFLVRMICZhbXA7IDEwUEFTUy1U UyAKICBpbnRlcmZhY2VzLjxCUj4mZ3Q7PEJSPiZndDtUcmFkaXRpb25hbGx5LCBpdCBzZWVtcyB0 aGUgaWZTcGVlZCBoYXMgYmVlbiB0aWVkIAogIHRvIHRoZSBzcGVlZCBvZiB0aGUgTUFDIChlLmcu IDEwTWJwcywgMTAwTWJwcywgZXRjLikuJm5ic3A7IFdpdGggMkJBU0UvMTBQQVNTLCAKICB0aGUg UEhZIG1heSBiZSBydW5uaW5nIGF0IGEgbXVjaCBsb3dlciBzcGVlZCB0aGFuIHRoZSAxMDBNYnBz IE1BQywgc28gaXRzIG5vdCAKICBwYXJ0aWN1bGFybHkgdXNlZnVsIHRvIHRoZSBhZG1pbmlzdHJh dG9yIHRvIGNhbGwgYWxsIG9mIHRoZXNlIGludGVyZmFjZXMgMTAwTSAKICB3aGVuIHRoZSBQSFlz IGFyZW4ndCB0aGVyZS48QlI+Jmd0OzxCUj4mZ3Q7T3B0aW9ucyBmb3IgaWZTcGVlZCBvZiAyQkFT RS8xMFBBU1MgCiAgc2VlbSB0byBpbmNsdWRlIHRoZSBmb2xsb3dpbmc6PEJSPiZndDs8QlI+Jmd0 OzApIFVzZSAxMDAgTWJwcyAoTUFDIAogIHNwZWVkKS48QlI+Jmd0OzxCUj4mZ3Q7MSkgU3VtIHRo ZSBwaHlzaWNhbCBkYXRlIHJhdGVzIG9mIFBNRXMgaW4gdGhlIGFnZ3JlZ2F0ZSAKICAoUEhZIHNw ZWVkKS48QlI+Jmd0OzxCUj4mZ3Q7MikgVXNlIHRoZSByYXRlIG9mICJnb29kcHV0IiBvbiB0aGUg UEhZcyAoZS5nLiBob3cgCiAgbXVjaCBkYXRhIGNhbiBnZSB0aHJ1KS4mbmJzcDsgVGhpcyB3b3Vs ZCBpZ25vcmUgYW55IG92ZXJoZWFkIG9mIHRoZSBQSFkgKFBBRiwgCiAgNjQvNjUpIGFuZCBvdmVy aGVhZCBvZiB0aGUgTUFDIChwcmVhbWJsZSwgSVBHKS4mbmJzcDsgVGhpcyBtb3N0IGFjY3VyYXRl bHkgCiAgcmVmbGVjdHMgaG93IG11Y2ggZGF0YSBjYW4gZ2V0IHRocnUuPEJSPiZndDs8QlI+Jmd0 OzMpIFVzZSB0aGUgcmF0ZSBhdCB0aGUgCiAgTUFDL01JSS4mbmJzcDsgRS5nLiBpbmNsdWRlIHBy ZWFtYmxlL0lQRyAoZXZlbiB0aG91Z2ggaXRzIG5vdCB0cmFuc21pdHRlZCksIAogIGJ1dCBub3Qg UEhZIG92ZXJoZWFkIChQQUYsIDY0LzY1KS4mbmJzcDsgVGhpcyBzZWVtcyBjb25zaXN0ZW50IHdp dGggb3RoZXIgCiAgUEhZcywgYnV0IGlzIGtpbmRhIHdlaXJkIGluIHRoYXQgd2UncmUgbm90IGFj dHVhbGx5IHRyYW5zbWl0dGluZyAKICBwcmVhbWJsZS9pcGcuPEJSPiZndDs8QlI+Jmd0O1RoZXJl IGFyZSBwcm9iYWJseSBvdGhlciBvcHRpb25zIHRvby4mbmJzcDsgCiAgVGhvdWdodHMvb3Bpbmlv bnM/PEJSPiZndDs8QlI+Jmd0Oy0gCk1hdHQ8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDs8QlI+PC9G T05UPjwvUD48L0JMT0NLUVVPVEU+Cgo8L0JPRFk+CjwvSFRNTD4= ------_=_NextPart_001_01C47978.E54F4534-- --===============1877063506== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============1877063506==-- From hubmib-bounces@ietf.org Tue Aug 3 13:48:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26193 for ; Tue, 3 Aug 2004 13:48:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs327-0000JV-Pd; Tue, 03 Aug 2004 13:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs2wV-0007fG-GK for hubmib@megatron.ietf.org; Tue, 03 Aug 2004 13:19:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23256 for ; Tue, 3 Aug 2004 13:19:12 -0400 (EDT) Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs2zc-0005EM-Ht for hubmib@ietf.org; Tue, 03 Aug 2004 13:22:28 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 3 Aug 2004 13:18:40 -0400 Message-ID: <8052E2EA753D144EB906B7A7AA39971402B07840@mailserv.hatteras.com> Thread-Topic: [EFM] ifSpeed & 2BASE-TL/10PASS-TS Thread-Index: AcR5FoUmonokpW7OQLaUH3qmtKHLnwAXx/CiAAE+wyA= From: "Matt Squire" To: "Edward Beili" , "Hugh Barrass" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: hubmib@ietf.org Subject: [Hubmib] RE: [EFM] ifSpeed & 2BASE-TL/10PASS-TS X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0845383273==" Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============0845383273== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4797D.EBEE29CB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4797D.EBEE29CB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkaXNhZ3JlZSB3aXRoIHVzaW5nIFNtYXJ0Yml0cyBhcyBhIGNyaXRlcmlhLCBidXQgYWdyZWUg d2l0aCB0aGUgZW5kIGNvbmNsdXNpb24uICBUaGVyZSdzIGEgdG9uIG9mIG90aGVyIEV0aGVybmV0 IGludGVyZmFjZXMgb3V0IHRoZXJlIGFuZCBsb29raW5nIGF0IGEgcGFydGljdWxhciBjb25maWd1 cmF0aW9uIGFzIGEgZ3VpZGUgZm9yIHdoYXQgdGhlIGlmU3BlZWQgc2hvdWxkIGJlIHNlZW1zIGxp a2UgYSBtaXN0YWtlLiAgDQogDQpJZiB0aGVyZSBpZlNwZWVkIGlzIG5vdCBzdXBlciBhY2N1cmF0 ZSwgYW5kIHRoZXJlIGlzIG5vIGxvc3MgaW4gDQogICAxMEJBU0UtVC0tLS0tLT4xMFBBU1MtVFMs IChlLmcuIDEwTWJwcyBpbiAxMEJBU0UtVCA+IDEwIE1icHMgaW4gMTBQQVNTLVRTKQ0KdGhlbiB0 aGVyZSBpcyBsb3NzIGZyb20gDQogICAxMFBBU1MtVFMtLS0+MTBCQVNFLVQNCkFsdGhvdWdoIHRo ZXJlJ3Mgbm8gc21hcnRiaXRzIDEwUEFTUy1UUyBwb3J0IHlldCwgSSBhc3N1bWUgdGhlcmUgZXZl bnR1YWxseSB3aWxsIGJlLiAgU28gbG9va2luZyBhdCBsb3NzIGluIGEgaW50ZXJtZWRpYXRlIGRl dmljZSBhcyBhIGNyaXRlcmlhL3JlYXNvbiBkb2Vzbid0IGZlZWwgcmlnaHQuICANCiANClRoYXQg c2FpZCwgdXNpbmcgdGhlIE1JSSBhcyB0aGUgcG9pbnQgb2YgbWVhc3VyZW1lbnQgZG9lcyBmZWVs IHJpZ2h0ICh0byBtZSBhbnl3YXkpLiAgIEknbSBvbmx5IGNvbmNlcm5lZCB0aGF0IHdlIGNvbWUg dXAgd2l0aCBhIGNvbnNpc3RlbnQgYW5kIGNvcnJlY3Qgd2F5IHRvIGV4cHJlc3MgdGhpcyAoaGVu Y2UgdGhlIHByZXZpb3VzIHF1ZXN0aW9ucy9leGFtcGxlKS4gIA0KIA0KIA0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRWR3YXJkIEJlaWxpIFttYWlsdG86RWR3YXJkQkBhY3Rl bGlzLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwMywgMjAwNCAxMjo0MyBQTQ0KVG86IEh1 Z2ggQmFycmFzczsgU1REUy04MDItMy1FRk1AbGlzdHNlcnYuaWVlZS5vcmc7IE1hdHQgU3F1aXJl DQpDYzogaHVibWliQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0VGTV0gaWZTcGVlZCAmIDJCQVNF LVRMLzEwUEFTUy1UUw0KDQoNCkh1Z2gsDQogDQpJIGRvbid0IHJlYWxseSB1bmRlcnN0YW5kIHlv dXIgMysxIG9wdGlvbi4NCiANCkluIG15IHZpZXcgdGhlIGNyaXRlcmlhIHNoYWxsIGJlIGFzIGZv bGxvd3M6DQpTdXBwb3NlIHlvdSBoYXZlIHRoZSBmb2xsb3dpbmcgc3lzdGVtIGNvbmZpZ3VyYXRp b246DQogDQpbU21hcnRiaXRzXS0tLS0xMEJhc2VULS0tLVtFRk1DdSBDT10tLS0tMkJhc2VUTC0t LS0tW0VGTUN1IFJUXS0tLS0xMEJhc2VULS0tW1NtYXJ0Yml0c10NCiAgICAgICAgICAgICAgICAg ICAgaWZTcGVlZD0xME1icHMgICAgICAgICAgICAgICAgICAgaWZTcGVlZD0xME1icHMgICAgICAg ICAgICAgICAgICAgICBpZlNwZWVkPTEwTWJwcw0KIA0KSWYgdGhlIEVGTUN1IGxpbmsgcmVwb3J0 cyBpdHMgaWZTcGVlZCBhcyAxME1icHMsIHByb3ZpZGVkIHRoYXQgdGhlIE1BQyBicmlkZ2UgaW4g dGhlIEVGTUN1IENPIGFuZCBSVCBpcyB3aXJlLXNwZWVkLCB0aGVyZSBzaG91bGQgYmUgbm8gcGFj a2V0IGxvc3Mgd2hlbiBJIGZpcmUgdGhlIFNtYXJ0Yml0cyBpbiBmdWxsIGR1cGxleCAxME1icHMg MTAwJSB3aXRoIG1pbiBJRkcgd2l0aCBmcmFtZSBsZW5ndGggb2YgNjQgQnl0ZXMgYW5kIDE1MTgg Qnl0ZXMuDQogDQpJdCBsb29rcyB0byBtZSB0aGF0IG9wdGlvbiAzLCBpLmUuIHN1bSBvZiBtb2Rl bSBkYXRhIHJhdGVzIHdpdGhvdXQgNjQvNjVCIGVuY2Fwc3VsYXRpb24gYW5kIFBBRiBvdmVyaGVh ZCBidXQgd2l0aCBJRkcsIGFuc3dlcnMgdGhpcyBjcml0ZXJpYSBiZXN0Lg0KVGhlIHJlcG9ydGVk IGlmU1BlZWQgbWF5IG5vdCBiZSBzdXBlciBhY2N1cmF0ZSwgdGhlIGVycm9yIGhvd2V2ZXIgc2hv dWxkIGFsd2F5cyBiZSBwb3NpdGl2ZSwgaS5lLiBubyBwb3NzaWJsZSBwYWNrZXQgbG9zcyBpbiB0 aGUgY29uZmlndXJhdGlvbiBhYm92ZS4gT2J2aW91c2x5IG9wdGlvbiAyIChnb29kcHV0KSB3b3Vs ZCB3b3JrIGFzIHdlbGwuDQogDQpSZWdhcmRzLA0KLUUuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tIA0KRnJvbTogb3duZXItc3Rkcy04MDItMy1lZm1AbGlzdHNlcnYuaWVlZS5vcmcgb24g YmVoYWxmIG9mIEh1Z2ggQmFycmFzcyANClNlbnQ6IFR1ZSA4LzMvMjAwNCA3OjQ4IEFNIA0KVG86 IFNURFMtODAyLTMtRUZNQGxpc3RzZXJ2LmllZWUub3JnIA0KQ2M6IA0KU3ViamVjdDogUmU6IFtF Rk1dIGlmU3BlZWQgJiAyQkFTRS1UTC8xMFBBU1MtVFMNCg0KDQoNCk1hdHQsDQoNCkkgd291bGQg Z28gd2l0aCAzKSBwbHVzIDEpIC0gcmVhc29uczoNCg0KMCkgaXMganVzdCBwbGFpbiB3cm9uZyEN Cg0KMSkgVGhlIGFnZ3JlZ2F0ZWQgbGlua3MgYXBwZWFyIHRvIHRoZSBNQUMgYW5kIHVwcGVyIGxh eWVycyBhcyBhIHNpbmdsZQ0KbGluay4gVGhlIGFnZ3JlZ2F0ZWQgbGluayBzcGVlZCBnb3Zlcm5z IHRoZSByYXRlIGFjcm9zcyB0aGUgTUlJLg0KDQoyKSBXZSd2ZSBuZXZlciBhY2NvdW50ZWQgZm9y ICJnb29kcHV0IiBiZWZvcmUNCg0KMykgVGhhdCdzIGhvdyB3ZSBoYXZlIGRvbmUgaXQgZm9yIGFs bCBvdGhlciBQSFlzLiBUaGUgb3ZlcmhlYWQgb2YNCmVuY2Fwc3VsYXRpb24gaXMgYWJzb3JiZWQg YnkgdGhlIGxpbmsgcnVubmluZyBhdCBhIGZhc3RlciByYXRlIHRoYW4gdGhlDQpNSUkgKHdoZXRo ZXIgaXQncyA0YjViLCA4Yi8xMGIgb3IgNjRiLzY2YikuIEJ1dCB0aGUgZWZmZWN0IG9mIHRoZSBJ UEcNCmRlcGVuZHMgb24gdGhlIGZyYW1lIHNpemUsIHNvIGlzIGlnbm9yZWQuDQoNClNvLCBJIHRo aW5rIGl0IHNob3VsZCBiZSB0aGUgYWdncmVnYXRlIHJhdGUgYXQgdGhlIE1JSSBmb3IgYW4gaW1h Z2luYXJ5LA0KaW5maW5pdGUgbGVuZ3RoIGZyYW1lLg0KDQpIdWdoLg0KDQpNYXR0IFNxdWlyZSB3 cm90ZToNCg0KPkkgZmlndXJlZCBJJ2QgZmlyZSBvZmYgYSBub3RlIHRvIHRoZSByZWZsZWN0b3Jz IHRvIGdldCB0aGlzIGRpc2N1c3Npb24gc3RhcnRlZC4NCj4NCj5EdXJpbmcgdGhlIGRpc2N1c3Np b25zIHRvZGF5IGluIHRoZSBodWJtaWIgV0csIHRoZSBxdWVzdGlvbiBhcm9zZSBhcyB0byB3aGF0 IHNob3VsZCBiZSB0aGUgaWZTcGVlZCBmb3IgMkJBU0UtVEwgJiAxMFBBU1MtVFMgaW50ZXJmYWNl cy4NCj4NCj5UcmFkaXRpb25hbGx5LCBpdCBzZWVtcyB0aGUgaWZTcGVlZCBoYXMgYmVlbiB0aWVk IHRvIHRoZSBzcGVlZCBvZiB0aGUgTUFDIChlLmcuIDEwTWJwcywgMTAwTWJwcywgZXRjLikuICBX aXRoIDJCQVNFLzEwUEFTUywgdGhlIFBIWSBtYXkgYmUgcnVubmluZyBhdCBhIG11Y2ggbG93ZXIg c3BlZWQgdGhhbiB0aGUgMTAwTWJwcyBNQUMsIHNvIGl0cyBub3QgcGFydGljdWxhcmx5IHVzZWZ1 bCB0byB0aGUgYWRtaW5pc3RyYXRvciB0byBjYWxsIGFsbCBvZiB0aGVzZSBpbnRlcmZhY2VzIDEw ME0gd2hlbiB0aGUgUEhZcyBhcmVuJ3QgdGhlcmUuDQo+DQo+T3B0aW9ucyBmb3IgaWZTcGVlZCBv ZiAyQkFTRS8xMFBBU1Mgc2VlbSB0byBpbmNsdWRlIHRoZSBmb2xsb3dpbmc6DQo+DQo+MCkgVXNl IDEwMCBNYnBzIChNQUMgc3BlZWQpLg0KPg0KPjEpIFN1bSB0aGUgcGh5c2ljYWwgZGF0ZSByYXRl cyBvZiBQTUVzIGluIHRoZSBhZ2dyZWdhdGUgKFBIWSBzcGVlZCkuDQo+DQo+MikgVXNlIHRoZSBy YXRlIG9mICJnb29kcHV0IiBvbiB0aGUgUEhZcyAoZS5nLiBob3cgbXVjaCBkYXRhIGNhbiBnZSB0 aHJ1KS4gIFRoaXMgd291bGQgaWdub3JlIGFueSBvdmVyaGVhZCBvZiB0aGUgUEhZIChQQUYsIDY0 LzY1KSBhbmQgb3ZlcmhlYWQgb2YgdGhlIE1BQyAocHJlYW1ibGUsIElQRykuICBUaGlzIG1vc3Qg YWNjdXJhdGVseSByZWZsZWN0cyBob3cgbXVjaCBkYXRhIGNhbiBnZXQgdGhydS4NCj4NCj4zKSBV c2UgdGhlIHJhdGUgYXQgdGhlIE1BQy9NSUkuICBFLmcuIGluY2x1ZGUgcHJlYW1ibGUvSVBHIChl dmVuIHRob3VnaCBpdHMgbm90IHRyYW5zbWl0dGVkKSwgYnV0IG5vdCBQSFkgb3ZlcmhlYWQgKFBB RiwgNjQvNjUpLiAgVGhpcyBzZWVtcyBjb25zaXN0ZW50IHdpdGggb3RoZXIgUEhZcywgYnV0IGlz IGtpbmRhIHdlaXJkIGluIHRoYXQgd2UncmUgbm90IGFjdHVhbGx5IHRyYW5zbWl0dGluZyBwcmVh bWJsZS9pcGcuDQo+DQo+VGhlcmUgYXJlIHByb2JhYmx5IG90aGVyIG9wdGlvbnMgdG9vLiAgVGhv dWdodHMvb3BpbmlvbnM/DQo+DQo+LSBNYXR0DQo+DQo+DQo+DQoNCg0K ------_=_NextPart_001_01C4797D.EBEE29CB Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPFRJVExFPlJlOiBbRUZNXSBpZlNwZWVk ICYgMkJBU0UtVEwvMTBQQVNTLVRTPC9USVRMRT4NCg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDYu MDAuMjgwMC4xNDAwIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWSBkaXI9bHRyPg0KPERJ Vj48U1BBTiBjbGFzcz05ODMwNDU1MTYtMDMwODIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIHNpemU9Mj5JIA0KZGlzYWdyZWUgd2l0aCB1c2luZyBTbWFydGJpdHMgYXMgYSBjcml0 ZXJpYSwgYnV0IGFncmVlIHdpdGggdGhlIGVuZCANCmNvbmNsdXNpb24uJm5ic3A7IFRoZXJlJ3Mg YSB0b24gb2Ygb3RoZXIgRXRoZXJuZXQgaW50ZXJmYWNlcyBvdXQgdGhlcmUgYW5kIA0KbG9va2lu ZyBhdCBhIHBhcnRpY3VsYXIgY29uZmlndXJhdGlvbiBhcyBhIGd1aWRlIGZvciB3aGF0IHRoZSBp ZlNwZWVkIHNob3VsZCBiZSANCnNlZW1zIGxpa2UgYSBtaXN0YWtlLiZuYnNwOyA8L0ZPTlQ+PC9T UEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz05ODMwNDU1MTYtMDMwODIwMDQ+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+ DQo8RElWPjxTUEFOIGNsYXNzPTk4MzA0NTUxNi0wMzA4MjAwND48Rk9OVCBmYWNlPUFyaWFsIGNv bG9yPSMwMDAwZmYgc2l6ZT0yPklmIA0KdGhlcmUgaWZTcGVlZCBpcyBub3Qgc3VwZXIgYWNjdXJh dGUsIGFuZCB0aGVyZSBpcyBubyBsb3NzIGluIA0KPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+ PFNQQU4gY2xhc3M9OTgzMDQ1NTE2LTAzMDgyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAw MDBmZiANCnNpemU9Mj4mbmJzcDsmbmJzcDsgMTBCQVNFLVQtLS0tLS0mZ3Q7MTBQQVNTLVRTLCAo ZS5nLiAxME1icHMgaW4gMTBCQVNFLVQgJmd0OyANCjEwIE1icHMgaW4gMTBQQVNTLVRTKTwvRk9O VD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTk4MzA0NTUxNi0wMzA4MjAwND48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPnRoZW4gDQp0aGVyZSBpcyBsb3NzIGZy b20gPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9OTgzMDQ1NTE2LTAzMDgy MDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj4mbmJzcDsmbmJzcDsm bmJzcDsxMFBBU1MtVFMtLS0mZ3Q7MTBCQVNFLVQ8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48 U1BBTiBjbGFzcz05ODMwNDU1MTYtMDMwODIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAw MGZmIA0Kc2l6ZT0yPkFsdGhvdWdoIHRoZXJlJ3Mgbm8gc21hcnRiaXRzIDEwUEFTUy1UUyBwb3J0 IHlldCwgSSBhc3N1bWUgdGhlcmUgDQpldmVudHVhbGx5IHdpbGwgYmUuJm5ic3A7IFNvIGxvb2tp bmcgYXQgbG9zcyBpbiBhIGludGVybWVkaWF0ZSBkZXZpY2UmbmJzcDthcyBhIA0KY3JpdGVyaWEv cmVhc29uIGRvZXNuJ3QgZmVlbCByaWdodC4mbmJzcDsgPC9GT05UPjwvU1BBTj48L0RJVj4NCjxE SVY+PFNQQU4gY2xhc3M9OTgzMDQ1NTE2LTAzMDgyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 IzAwMDBmZiANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBj bGFzcz05ODMwNDU1MTYtMDMwODIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNp emU9Mj5UaGF0IA0Kc2FpZCwgdXNpbmcgdGhlIE1JSSBhcyB0aGUgcG9pbnQgb2YgbWVhc3VyZW1l bnQgZG9lcyBmZWVsIHJpZ2h0ICh0byBtZSANCmFueXdheSkuJm5ic3A7Jm5ic3A7IEknbSBvbmx5 IGNvbmNlcm5lZCB0aGF0IHdlIGNvbWUgdXAgd2l0aCZuYnNwO2EgY29uc2lzdGVudCANCmFuZCBj b3JyZWN0IHdheSZuYnNwO3RvIGV4cHJlc3MmbmJzcDt0aGlzIChoZW5jZSB0aGUgcHJldmlvdXMg DQpxdWVzdGlvbnMvZXhhbXBsZSkuJm5ic3A7IDwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48U1BBTiBjbGFzcz05ODMwNDU1MTYtMDMwODIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj0jMDAwMGZmIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8QkxPQ0tRVU9U RSBkaXI9bHRyIA0Kc3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBC T1JERVItTEVGVDogIzAwMDBmZiAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJ ViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFj ZT1UYWhvbWEgDQogIHNpemU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj48Qj5Gcm9t OjwvQj4gRWR3YXJkIEJlaWxpIA0KICBbbWFpbHRvOkVkd2FyZEJAYWN0ZWxpcy5jb21dPEJSPjxC PlNlbnQ6PC9CPiBUdWVzZGF5LCBBdWd1c3QgMDMsIDIwMDQgMTI6NDMgDQogIFBNPEJSPjxCPlRv OjwvQj4gSHVnaCBCYXJyYXNzOyBTVERTLTgwMi0zLUVGTUBsaXN0c2Vydi5pZWVlLm9yZzsgTWF0 dCANCiAgU3F1aXJlPEJSPjxCPkNjOjwvQj4gaHVibWliQGlldGYub3JnPEJSPjxCPlN1YmplY3Q6 PC9CPiBSRTogW0VGTV0gaWZTcGVlZCANCiAgJmFtcDsgMkJBU0UtVEwvMTBQQVNTLVRTPEJSPjxC Uj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+SHVnaCw8L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj4N CiAgPERJVj5JIGRvbid0IHJlYWxseSB1bmRlcnN0YW5kIHlvdXIgMysxIG9wdGlvbi48L0RJVj4N CiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj5JbiBteSB2aWV3IHRoZSBjcml0ZXJpYSBzaGFs bCBiZSBhcyBmb2xsb3dzOjwvRElWPg0KICA8RElWPlN1cHBvc2UgeW91IGhhdmUgdGhlIGZvbGxv d2luZyBzeXN0ZW0gY29uZmlndXJhdGlvbjo8L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAg PERJVj5bU21hcnRiaXRzXS0tLS0xMEJhc2VULS0tLVtFRk1DdSBDT10tLS0tMkJhc2VUTC0tLS0t W0VGTUN1IA0KICBSVF0tLS0tMTBCYXNlVC0tLVtTbWFydGJpdHNdPC9ESVY+DQogIDxESVY+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K ICBpZlNwZWVkPTEwTWJwcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO2lmU3BlZWQ9MTBNYnBzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aWZTcGVlZD0xME1icHM8 L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj5JZiB0aGUgRUZNQ3UgbGluayByZXBv cnRzIGl0cyBpZlNwZWVkIGFzIDEwTWJwcywgcHJvdmlkZWQgdGhhdCB0aGUgTUFDIA0KICBicmlk Z2UgaW4gdGhlIEVGTUN1IENPIGFuZCBSVCBpcyB3aXJlLXNwZWVkLCB0aGVyZSBzaG91bGQgYmUg bm8gcGFja2V0IGxvc3MgDQogIHdoZW4gSSBmaXJlIHRoZSBTbWFydGJpdHMgaW4gZnVsbCBkdXBs ZXggMTBNYnBzIDEwMCUgd2l0aCBtaW4gSUZHIHdpdGggZnJhbWUgDQogIGxlbmd0aCBvZiA2NCBC eXRlcyBhbmQgMTUxOCBCeXRlcy48L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj5J dCBsb29rcyB0byBtZSB0aGF0IG9wdGlvbiAzLCBpLmUuIHN1bSBvZiBtb2RlbSBkYXRhIHJhdGVz IHdpdGhvdXQgNjQvNjVCIA0KICBlbmNhcHN1bGF0aW9uIGFuZCBQQUYgb3ZlcmhlYWQgYnV0IHdp dGggSUZHLCBhbnN3ZXJzIHRoaXMgY3JpdGVyaWEgYmVzdC48L0RJVj4NCiAgPERJVj5UaGUgcmVw b3J0ZWQgaWZTUGVlZCBtYXkgbm90IGJlIHN1cGVyIGFjY3VyYXRlLCB0aGUgZXJyb3IgaG93ZXZl ciBzaG91bGQgDQogIGFsd2F5cyBiZSBwb3NpdGl2ZSwgaS5lLiBubyBwb3NzaWJsZSBwYWNrZXQg bG9zcyBpbiB0aGUgY29uZmlndXJhdGlvbiBhYm92ZS4gDQogIE9idmlvdXNseSBvcHRpb24gMiAo Z29vZHB1dCkgd291bGQgd29yayBhcyB3ZWxsLjwvRElWPg0KICA8RElWPiZuYnNwOzwvRElWPg0K ICA8RElWPlJlZ2FyZHMsPC9ESVY+DQogIDxESVY+LUUuPC9ESVY+DQogIDxCTE9DS1FVT1RFIGRp cj1sdHIgc3R5bGU9Ik1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICA8RElWPjxGT05UIHNpemU9Mj4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSA8QlI+PEI+RnJvbTo8L0I+IA0KICAgIG93bmVyLXN0 ZHMtODAyLTMtZWZtQGxpc3RzZXJ2LmllZWUub3JnJm5ic3A7b24gYmVoYWxmIG9mJm5ic3A7SHVn aCBCYXJyYXNzIA0KICAgIDxCUj48Qj5TZW50OjwvQj4gVHVlIDgvMy8yMDA0IDc6NDggQU0gPEJS PjxCPlRvOjwvQj4gDQogICAgU1REUy04MDItMy1FRk1AbGlzdHNlcnYuaWVlZS5vcmcgPEJSPjxC PkNjOjwvQj4gPEJSPjxCPlN1YmplY3Q6PC9CPiBSZTogDQogICAgW0VGTV0gaWZTcGVlZCAmYW1w OyAyQkFTRS1UTC8xMFBBU1MtVFM8QlI+PEJSPjwvRk9OVD48L0RJVj4NCiAgICA8UD48Rk9OVCBz aXplPTI+TWF0dCw8QlI+PEJSPkkgd291bGQgZ28gd2l0aCAzKSBwbHVzIDEpIC0gcmVhc29uczo8 QlI+PEJSPjApIA0KICAgIGlzIGp1c3QgcGxhaW4gd3JvbmchPEJSPjxCUj4xKSBUaGUgYWdncmVn YXRlZCBsaW5rcyBhcHBlYXIgdG8gdGhlIE1BQyBhbmQgDQogICAgdXBwZXIgbGF5ZXJzIGFzIGEg c2luZ2xlPEJSPmxpbmsuIFRoZSBhZ2dyZWdhdGVkIGxpbmsgc3BlZWQgZ292ZXJucyB0aGUgcmF0 ZSANCiAgICBhY3Jvc3MgdGhlIE1JSS48QlI+PEJSPjIpIFdlJ3ZlIG5ldmVyIGFjY291bnRlZCBm b3IgImdvb2RwdXQiIA0KICAgIGJlZm9yZTxCUj48QlI+MykgVGhhdCdzIGhvdyB3ZSBoYXZlIGRv bmUgaXQgZm9yIGFsbCBvdGhlciBQSFlzLiBUaGUgb3ZlcmhlYWQgDQogICAgb2Y8QlI+ZW5jYXBz dWxhdGlvbiBpcyBhYnNvcmJlZCBieSB0aGUgbGluayBydW5uaW5nIGF0IGEgZmFzdGVyIHJhdGUg dGhhbiANCiAgICB0aGU8QlI+TUlJICh3aGV0aGVyIGl0J3MgNGI1YiwgOGIvMTBiIG9yIDY0Yi82 NmIpLiBCdXQgdGhlIGVmZmVjdCBvZiB0aGUgDQogICAgSVBHPEJSPmRlcGVuZHMgb24gdGhlIGZy YW1lIHNpemUsIHNvIGlzIGlnbm9yZWQuPEJSPjxCUj5TbywgSSB0aGluayBpdCANCiAgICBzaG91 bGQgYmUgdGhlIGFnZ3JlZ2F0ZSByYXRlIGF0IHRoZSBNSUkgZm9yIGFuIGltYWdpbmFyeSw8QlI+ aW5maW5pdGUgbGVuZ3RoIA0KICAgIGZyYW1lLjxCUj48QlI+SHVnaC48QlI+PEJSPk1hdHQgU3F1 aXJlIHdyb3RlOjxCUj48QlI+Jmd0O0kgZmlndXJlZCBJJ2QgZmlyZSANCiAgICBvZmYgYSBub3Rl IHRvIHRoZSByZWZsZWN0b3JzIHRvIGdldCB0aGlzIGRpc2N1c3Npb24gDQogICAgc3RhcnRlZC48 QlI+Jmd0OzxCUj4mZ3Q7RHVyaW5nIHRoZSBkaXNjdXNzaW9ucyB0b2RheSBpbiB0aGUgaHVibWli IFdHLCB0aGUgDQogICAgcXVlc3Rpb24gYXJvc2UgYXMgdG8gd2hhdCBzaG91bGQgYmUgdGhlIGlm U3BlZWQgZm9yIDJCQVNFLVRMICZhbXA7IDEwUEFTUy1UUyANCiAgICBpbnRlcmZhY2VzLjxCUj4m Z3Q7PEJSPiZndDtUcmFkaXRpb25hbGx5LCBpdCBzZWVtcyB0aGUgaWZTcGVlZCBoYXMgYmVlbiB0 aWVkIA0KICAgIHRvIHRoZSBzcGVlZCBvZiB0aGUgTUFDIChlLmcuIDEwTWJwcywgMTAwTWJwcywg ZXRjLikuJm5ic3A7IFdpdGggDQogICAgMkJBU0UvMTBQQVNTLCB0aGUgUEhZIG1heSBiZSBydW5u aW5nIGF0IGEgbXVjaCBsb3dlciBzcGVlZCB0aGFuIHRoZSAxMDBNYnBzIA0KICAgIE1BQywgc28g aXRzIG5vdCBwYXJ0aWN1bGFybHkgdXNlZnVsIHRvIHRoZSBhZG1pbmlzdHJhdG9yIHRvIGNhbGwg YWxsIG9mIA0KICAgIHRoZXNlIGludGVyZmFjZXMgMTAwTSB3aGVuIHRoZSBQSFlzIGFyZW4ndCB0 aGVyZS48QlI+Jmd0OzxCUj4mZ3Q7T3B0aW9ucyBmb3IgDQogICAgaWZTcGVlZCBvZiAyQkFTRS8x MFBBU1Mgc2VlbSB0byBpbmNsdWRlIHRoZSBmb2xsb3dpbmc6PEJSPiZndDs8QlI+Jmd0OzApIFVz ZSANCiAgICAxMDAgTWJwcyAoTUFDIHNwZWVkKS48QlI+Jmd0OzxCUj4mZ3Q7MSkgU3VtIHRoZSBw aHlzaWNhbCBkYXRlIHJhdGVzIG9mIFBNRXMgDQogICAgaW4gdGhlIGFnZ3JlZ2F0ZSAoUEhZIHNw ZWVkKS48QlI+Jmd0OzxCUj4mZ3Q7MikgVXNlIHRoZSByYXRlIG9mICJnb29kcHV0IiBvbiANCiAg ICB0aGUgUEhZcyAoZS5nLiBob3cgbXVjaCBkYXRhIGNhbiBnZSB0aHJ1KS4mbmJzcDsgVGhpcyB3 b3VsZCBpZ25vcmUgYW55IA0KICAgIG92ZXJoZWFkIG9mIHRoZSBQSFkgKFBBRiwgNjQvNjUpIGFu ZCBvdmVyaGVhZCBvZiB0aGUgTUFDIChwcmVhbWJsZSwgDQogICAgSVBHKS4mbmJzcDsgVGhpcyBt b3N0IGFjY3VyYXRlbHkgcmVmbGVjdHMgaG93IG11Y2ggZGF0YSBjYW4gZ2V0IA0KICAgIHRocnUu PEJSPiZndDs8QlI+Jmd0OzMpIFVzZSB0aGUgcmF0ZSBhdCB0aGUgTUFDL01JSS4mbmJzcDsgRS5n LiBpbmNsdWRlIA0KICAgIHByZWFtYmxlL0lQRyAoZXZlbiB0aG91Z2ggaXRzIG5vdCB0cmFuc21p dHRlZCksIGJ1dCBub3QgUEhZIG92ZXJoZWFkIChQQUYsIA0KICAgIDY0LzY1KS4mbmJzcDsgVGhp cyBzZWVtcyBjb25zaXN0ZW50IHdpdGggb3RoZXIgUEhZcywgYnV0IGlzIGtpbmRhIHdlaXJkIGlu IA0KICAgIHRoYXQgd2UncmUgbm90IGFjdHVhbGx5IHRyYW5zbWl0dGluZyBwcmVhbWJsZS9pcGcu PEJSPiZndDs8QlI+Jmd0O1RoZXJlIGFyZSANCiAgICBwcm9iYWJseSBvdGhlciBvcHRpb25zIHRv by4mbmJzcDsgVGhvdWdodHMvb3BpbmlvbnM/PEJSPiZndDs8QlI+Jmd0Oy0gDQogICAgTWF0dDxC Uj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OzxCUj48L0ZPTlQ+PC9QPjwvQkxPQ0tRVU9URT48L0JMT0NL UVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C4797D.EBEE29CB-- --===============0845383273== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============0845383273==-- From hubmib-bounces@ietf.org Tue Aug 3 14:14:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28786 for ; Tue, 3 Aug 2004 14:14:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3UT-0006p0-0W; Tue, 03 Aug 2004 13:54:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Brh5r-0005cm-5u for hubmib@megatron.ietf.org; Mon, 02 Aug 2004 13:59:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22478 for ; Mon, 2 Aug 2004 13:59:26 -0400 (EDT) Received: from mail14b.sanjose14-verio.com ([128.121.143.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Brh8j-0001FH-KN for hubmib@ietf.org; Mon, 02 Aug 2004 14:02:27 -0400 Received: from mxw1400.sanjose14-verio.com (128.121.143.19) by mail14b.sanjose14-verio.com (RS ver 1.0.94vs) with SMTP id 1-3966042855; Mon, 2 Aug 2004 09:21:05 -0400 (EDT) From: "Lior khermosh" To: "'Romascanu, Dan \(Dan\)'" , Subject: RE: [Hubmib] draft-ietf-hubmib-efm-epon-mib-01.txt Date: Mon, 2 Aug 2004 16:17:36 +0200 Message-ID: <035201c4789b$7be97d20$2b0b0b0b@passave.co.il> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: X-Loop-Detect: 1 X-Spam-Score: 0.6 (/) X-Scan-Signature: 53b2663681a067d6bc137eb1242b2dac X-Mailman-Approved-At: Tue, 03 Aug 2004 13:54:19 -0400 X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0454437817==" Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============0454437817== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0353_01C478AC.3F724D20" This is a multi-part message in MIME format. ------=_NextPart_000_0353_01C478AC.3F724D20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dan, Thank you very much for the review and the comments. They are very helpful. > T1. Thanks, will be fixed. One of the reasons to the strange fonts is a difference in the file in the web. This font will be removed. > T2. The document does not take a clear position about required changes from the MAU MIB. As wit the efm-cu document, my preference would be that we change the MAU MIB structure so that it is re-written as a IANA-maintained module, but we need a volunteer to do this. Sorry for being not clear but my intention is that MAU type objects in the MAU section should be added to the MAUMIBs as with the efm-cu document. If it is not done there then the MAU section in the efm-epon mib should contain them (as now). > T3. Clarify how are dot3MpcpID numbers assigned dot3MPCPID is referenced to IEEE802.3ah aMPCPID attribute. It is a read-only attribute for the MIB object. > T4. Is dot3MpcpAdminState an admin state object as the name suggests, or an oper state object as the read-only MAX-ACCESS and the DESCRIPTION clause suggests? Same about dot3MPCPAdminControl dot3MpcpAdminState is an oper state object and can only be read as the MAX-ACCESS and description suggest. dot3MPCPAdminControl is for changing the former state and has a read-write MAX-ACCESS. We can modify the names to make it more clear, however I would rather stay very close to the names which are used in the IEEE802.3ah clause 30. > T5. According to the DESCRIPTION dot3MpcpMaximumPendingGrants should be in range (0..255) Agreed and will be added. > T6. Some of the objects in the dot3MpcpStatsTable seem to be mandatory just for ONUs? What does an OLT which does not support the counter do? Maybe the table should be broken into two tables. In any case the Conformance clauses should reflect the optional support for some of the counters. I also saw the problem but I want to be aligned with the IEEE802.3ah clause 30 which does not implement such separation. We may add in, that the states which are dedicated to the OLT and ONU can return 0 (and the opposite). > T7. dot3OmpEmulationStatTable has objects mandatory for OLT and optional for ONU. This should be reflected in the conformance cases, and maybe the table should be broken in separate tables accordingly I also saw the problem but I want to be aligned with the IEEE802.3ah clause 30 which does not implement such separation. We may add in that the stats which are dedicated to the OLT and ONU can return 0 (and the opposite). > T8. Clarify what is being returned on a read operation for eponDeviceObjectReset When the value is running(0) the device is ready for operation/during normal operation. and when the value is reset(1) the device is in reset sequence and not ready for operation. I would add the read values explanations into the description. > T9. It is not clear what values are allowed for write for the object eponDeviceObjectReportThreshold. what does the reference to '2 octets increments' mean? As referenced to the IEEE802.3ah the reports message values are in Time quanta which are equivalent to 16nsec or 2 bytes/octets. I will clarify that in the text. > T10. Are values in eponDeviceRemoteMACAddressLLIDTable persitent, or can they be erased on a reset? Thanks for your suggestion. I must agree that they could also be erased on a reset. I will add to the text. > T11. The DESCRIPTION of the eponDeviceRemoteMACAddressLLIDTable is very unclear - I did not understand how this works I will clarify the text. The purpose of this table is to hold an LLID to MAC address table. This mapping is needed for the EPON network emulation as a bridge where its LLID is acting as a bridge port. > T12. What does the object eponDeviceRMadLogID with a SYNTAX of OBJECT IDENTIFIER point to? Should be eponDeviceRMadlLogID. This object creates an entry in the LLID MAC address table. > T13. The design of the eponDeviceEventsLogTable is not clear. What notifications are being referred by this table? Why does this need to be a dynamic row creation table? The table intention is to create and store a log of events. The types of events are defined by: eponDeviceEventsLogType: eponDeviceDyingGaspAlarmState (1), eponDeviceCriticalEventState (2), eponDeviceLocalLinkFaultAlarmState (3), eponDeviceTemperatureEventIndicationState (4), eponDevicePowerVoltageEventIndicationState (5), eponDeviceGlobalEventState (6), eponDeviceErroredSymbolPeriodEventState (7), eponDeviceErroredFrameEventState (8), eponDeviceErroredFramePeriodEventState (9), eponDeviceErroredFrameSecondsSummaryEventState (10), eponDeviceOrganizationSpecificEventState (11) Entries in the table are created dynamically once events happens. When event happens it receives the following parameters.: eponDeviceEventsLogName , eponDeviceEventsLogIndex , eponDeviceEventsLogID , eponDeviceEventsLogFirstTime , eponDeviceEventsLogLastTime , eponDeviceEventsLogCounts , eponDeviceEventsLogType , eponDeviceEventsLogEntryStatus > T14. The security section claims that most objects are writeable when the link is down. First there is a need to clarify what exactly is meant by the link is down (ifAdminStatus = off(2)? for what ifIndex value?). Second, this restriction needs to be mentioned for every specific objects in the MIB module itself (DESCRIPTION clauses) and not left in an external section. Agree - can't use "most" here. I will add specification for each attribute and specify the state of the change for it. > T15. Why define a eponDeviceSerialNumber, and not use entPhysicalSerialNumber from the Entity MIB? (RFC 2737, or http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-entmib-v3-0 4.txt) I agree, we can use it. Editorial Thanks, will be fixed. A few remarks in the text. > E1. The Internet-Draft has awful formatting errors. Please follow the guidelines at http://www.ietf.org/ietf/1id-guidelines.txt. > E2. Among these formatting errors, one very obvious, with effects on compilation of the MIB modules as well is the use of illegal characters. > E3. There is a new Intellectual Property Template that needs to be used. See the same reference. > E4. An IANA Consideration section needs to be added > E5. Copyright year needs to be updated to 2004. > E6. There are many spelling and syntax errors, that make the text sometimes impossible to understand. In fact there are that many that I will not list them all here, but rather forward a scribbled hardcopy to the editors with hand-written markings. > E7. All over the document - say 'MIB module' instead of MIB when referring to the module, and not a specific MIB, and 'MIB modules' instead of 'MIBs' > E8. DESCRIPTION clause of dot3MpcpTable - expand MPCP at the first occurrence of the acronyms > E9. There are many DEFVAL clauses missing for read-write or read-create objects. For example: dot3MpcpMode, dot3EponMauFecMode, eponDeviceObjectModes, eponDeviceObjectFecEnabled, eponDeviceObjectOamMode, eponDeviceRMadLogID, eponDeviceRMadRemoteMacAddress, eponDeviceRMadType, eponDeviceRMadAction, eponDeviceSampleMinimum, > E10. There are many UNITS clauses missing. For example: dot3MpcpTransmitElapsed, all counters in dot3MpcpStatsTable, all counters in dot3OmpEmulationStatTable, counters in dot3EponMauTable, counters in eponDeviceStatsTable > E11. dot3OmpEmulationID DESCRIPTION includes reference to an IEEE object. I know. I think it is an error in the text of the IEEE802.3ah. I marked it to myself and did not change it automatically to dot3OmpEmulationID as to figure this issue out. If I change it we are not aligned with the IEEE. I would rather see here a different ID than the OAMID (for the EFM-MIB document I guess) since it is different. Any suggestion? > E12. I recommend that the tables that map the MIB objects defined in this document into IEEE 802.3 objects be separated from the MIB objects definition section. I don't understand the comment It has a separate section: 4 Definitions - The EFM EPON MIB 6 5 Relationship table of the EFM EPON MIBs objects to the IEEE802.3ah objects 32 6 Definitions - The EPON Device MIB 34 > E13. All enumerated and BITS values need to be explained in DESCRIPTION. E.g. 'A value of olt(1) means...' - Foe example in eponDeviceObjectModes, eponDeviceObjectFecEnabled, eponDeviceObjectOamMode, > E14. eponDeviceObjectPowerDown should refer to value true(1) > E15. The significance of the events defined by the enumerated values of eponDeviceEventsLogTable needs to be expanded > E16. Why are DOCSIS MIB, Event MIB, Bridge MIB and Source Routing Bridge MIB referenced? In the document the methodology and formatting are used. It is not a direct reference rather a "styling" reference. Lior -----Original Message----- From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Sunday, August 01, 2004 1:06 PM To: hubmib@ietf.org Subject: [Hubmib] draft-ietf-hubmib-efm-epon-mib-01.txt Technical T1. None of the two MIB modules compiles correctly. While the first MIB modules warnings are caused by illegal characters in the DESCRIPTION clauses, the EPON Device MIB has 'true compilation errors. Here is the smilint log for these: This command (smilint 0.4.3-pre1, as of Tue Jul 27 14:25:07 2004) has been processed to get the following results: smilint -m -s -m -s -l 6 -i namelength-32 epon-device-mib.txt ... epon-device-mib.txt:230: [5] {integer-misuse} warning: use Integer32 instead of INTEGER in SMIv2 epon-device-mib.txt:230: [2] {access-invalid-smiv2} invalid access `read-Only' in SMIv2 MIB epon-device-mib.txt:329: [1] {other} parse error, unexpected '}', expecting LOWERCASE_IDENTIFIER epon-device-mib.txt:329: [5] {} warning: flushing recent incorrect declaration, see previous error(s) epon-device-mib.txt:330: [1] {other} parse error, unexpected MAX_ACCESS epon-device-mib.txt:334: [5] {} warning: flushing recent incorrect declaration, see previous error(s) epon-device-mib.txt:341: [1] {other} parse error, unexpected '}', expecting ')' epon-device-mib.txt:341: [5] {} warning: flushing recent incorrect declaration, see previous error(s) epon-device-mib.txt:342: [1] {other} parse error, unexpected MAX_ACCESS epon-device-mib.txt:346: [5] {} warning: flushing recent incorrect declaration, see previous error(s) ... epon-device-mib.txt:115: [3] {sequence-no-column} SEQUENCE element #9 `eponDeviceObjectRemoteMACAddressLLIDTable' is not a child node under `eponDeviceControlEntry' epon-device-mib.txt:115: [3] {sequence-no-column} SEQUENCE element #10 `eponDeviceObjectReportThreshold' is not a child node under `eponDeviceControlEntry' epon-device-mib.txt:125: [1] {} unknown object identifier label `eponDeviceObjectRemoteMACAddressLLIDTable' epon-device-mib.txt:278: [3] {sequence-no-column} SEQUENCE element #4 `eponDeviceRMadlRemoteMACAddress' is not a child node under `eponDeviceRemoteMACAddressLLIDEntry' epon-device-mib.txt:278: [3] {sequence-no-column} SEQUENCE element #5 `eponDeviceRMadlType' is not a child node under `eponDeviceRemoteMACAddressLLIDEntry' epon-device-mib.txt:278: [3] {sequence-no-column} SEQUENCE element #6 `eponDeviceRMadlAction' is not a child node under `eponDeviceRemoteMACAddressLLIDEntry' epon-device-mib.txt:278: [3] {sequence-missing-column} SEQUENCE of `EponDeviceRemoteMACAddressLLIDEntry' is missing columnar object `eponDeviceRMadlRemoteMacAddress' epon-device-mib.txt:266: [5] {index-element-accessible} warning: index element `eponDeviceRMadlLLID' of row `eponDeviceRemoteMACAddressLLIDEntry' should be not-accessible in SMIv2 MIB epon-device-mib.txt:282: [1] {} unknown object identifier label `eponDeviceRMadlRemoteMACAddress' epon-device-mib.txt:283: [1] {} unknown object identifier label `eponDeviceRMadlType' epon-device-mib.txt:284: [1] {} unknown object identifier label `eponDeviceRMadlAction' epon-device-mib.txt:1218: [3] {group-member-invalid} node `eponDeviceRMadlLogName' is an invalid member of group `eponDeviceGroupRMadLTable' epon-device-mib.txt:316: [4] {group-membership} warning: node `eponDeviceRMadlRemoteMacAddress' must be contained in at least one conformance group T2. The document does not take a clear position about required changes from the MAU MIB. As wit the efm-cu document, my preference would be that we change the MAU MIB structure so that it is re-written as a IANA-maintained module, but we need a volunteer to do this. T3. Clarify how are dot3MpcpID numbers assigned T4. Is dot3MpcpAdminState an admin state object as the name suggests, or an oper state object as the read-only MAX-ACCESS and the DESCRIPTION clause suggests? Same about dot3MPCPAdminControl T5. According to the DESCRIPTION dot3MpcpMaximumPendingGrants should be in range (0..255) T6. Some of the objects in the dot3MpcpStatsTable seem to be mandatory just for ONUs? What does an OLT which does not support the counter do? Maybe the table should be broken into two tables. In any case the Conformance clauses should reflect the optional support for some of the counters. T7. dot3OmpEmulationStatTable has objects mandatory for OLT and optional for ONU. This should be reflected in the conformance cases, and maybe the table should be broken in separate tables accordingly T8. Clarify what is being returned on a read operation for eponDeviceObjectReset T9. It is not clear what values are allowed for write for the object eponDeviceObjectReportThreshold. what does the reference to '2 octets increments' mean? T10. Are values in eponDeviceRemoteMACAddressLLIDTable persitent, or can they be erased on a reset? T11. The DESCRIPTION of the eponDeviceRemoteMACAddressLLIDTable is very unclear - I did not understand how this works T12. What does the object eponDeviceRMadLogID with a SYNTAX of OBJECT IDENTIFIER point to? T13. The design of the eponDeviceEventsLogTable is not clear. What notifications are being referred by this table? Why does this need to be a dynamic row creation table? T14. The security section claims that most objects are writeable when the link is down. First there is a need to clarify what exactly is meant by the link is down (ifAdminStatus = off(2)? for what ifIndex value?). Second, this restriction needs to be mentioned for every specific objects in the MIB module itself (DESCRIPTION clauses) and not left in an external section. T15. Why define a eponDeviceSerialNumber, and not use entPhysicalSerialNumber from the Entity MIB? (RFC 2737, or http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-entmib-v3-0 4.txt) Editorial E1. The Internet-Draft has awful formatting errors. Please follow the guidelines at http://www.ietf.org/ietf/1id-guidelines.txt. E2. Among these formatting errors, one very obvious, with effects on compilation of the MIB modules as well is the use of illegal characters. E3. There is a new Intellectual Property Template that needs to be used. See the same reference. E4. An IANA Consideration section needs to be added E5. Copyright year needs to be updated to 2004. E6. There are many spelling and syntax errors, that make the text sometimes impossible to understand. In fact there are that many that I will not list them all here, but rather forward a scribbled hardcopy to the editors with hand-written markings. E7. All over the document - say 'MIB module' instead of MIB when referring to the module, and not a specific MIB, and 'MIB modules' instead of 'MIBs' E8. DESCRIPTION clause of dot3MpcpTable - expand MPCP at the first occurrence of the acronyms E9. There are many DEFVAL clauses missing for read-write or read-create objects. For example: dot3MpcpMode, dot3EponMauFecMode, eponDeviceObjectModes, eponDeviceObjectFecEnabled, eponDeviceObjectOamMode, eponDeviceRMadLogID, eponDeviceRMadRemoteMacAddress, eponDeviceRMadType, eponDeviceRMadAction, eponDeviceSampleMinimum, E10. There are many UNITS clauses missing. For example: dot3MpcpTransmitElapsed, all counters in dot3MpcpStatsTable, all counters in dot3OmpEmulationStatTable, counters in dot3EponMauTable, counters in eponDeviceStatsTable E11. dot3OmpEmulationID DESCRIPTION includes reference to an IEEE object. E12. I recommend that the tables that map the MIB objects defined in this document into IEEE 802.3 objects be separated from the MIB objects definition section. E13. All enumerated and BITS values need to be explained in DESCRIPTION. E.g. 'A value of olt(1) means...' - Foe example in eponDeviceObjectModes, eponDeviceObjectFecEnabled, eponDeviceObjectOamMode, E14. eponDeviceObjectPowerDown should refer to value true(1) E15. The significance of the events defined by the enumerated values of eponDeviceEventsLogTable needs to be expanded E16. Why are DOCSIS MIB, Event MIB, Bridge MIB and Source Routing Bridge MIB referenced? Regards, Dan ------=_NextPart_000_0353_01C478AC.3F724D20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Dan,
Thank=20 you very much for the review and the comments. They are very=20 helpful.
 
>=20 T1.
Thanks, will be=20 fixed. One of the reasons to the strange fonts is a difference in the = file in=20 the web. This font will be removed.
 

> T2. The document does not take a = clear=20 position about required changes from the MAU MIB. As wit the efm-cu = document, my=20 preference would be that we change the MAU MIB structure so that it is=20 re-written as a IANA-maintained module, but we need a volunteer to do=20 this.

Sorry for being not clear but my intention is that MAU = type objects=20 in the MAU section should be added to the MAUMIBs as with the efm-cu = document.=20 If it is not done there then the MAU section in the efm-epon mib should = contain=20 them (as now).

> T3. Clarify how are dot3MpcpID = numbers=20 assigned

dot3MPCPID is referenced to IEEE802.3ah aMPCPID attribute. It = is a=20 read-only attribute for the MIB object.

> T4. Is dot3MpcpAdminState an = admin state=20 object as the name suggests, or an oper state object as the read-only = MAX-ACCESS=20 and the DESCRIPTION clause suggests? Same about = dot3MPCPAdminControl

dot3MpcpAdminState is an = oper state=20 object and can only be read as the MAX-ACCESS and description suggest.=20 dot3MPCPAdminControl is for changing the former state and has a = read-write=20 MAX-ACCESS. We can modify the names to make it more clear, however I = would=20 rather stay very close to the names which are used in the IEEE802.3ah = clause=20 30.

> T5. According to the DESCRIPTION=20 dot3MpcpMaximumPendingGrants should be in range (0..255)

Agreed and will be added.

 

> T6. Some of the objects in the=20 dot3MpcpStatsTable seem to be mandatory just for ONUs? What does an OLT = which=20 does not support the counter do? Maybe the table should be broken into = two=20 tables. In any case the Conformance clauses should reflect the optional = support=20 for some of the counters.

I also saw the problem but I want to be = aligned with=20 the IEEE802.3ah clause 30 which does not implement such separation. We = may add=20 in, that the states which are dedicated to the OLT and ONU can return 0 = (and the=20 opposite).

> T7. dot3OmpEmulationStatTable has = objects=20 mandatory for OLT and optional for ONU. This should be reflected in the=20 conformance cases, and maybe the table should be broken in separate = tables=20 accordingly

I also saw the problem but I want to be = aligned with=20 the IEEE802.3ah clause 30 which does not implement such separation. We = may add=20 in that the stats which are dedicated to the OLT and ONU can return 0 = (and the=20 opposite).

> T8. Clarify what is being = returned on a=20 read operation for eponDeviceObjectReset

When the value is running(0) the device is = ready for=20 operation/during normal operation. and when the value is reset(1) the = device is=20 in reset sequence and not ready for operation. I would add the read = values=20 explanations into the description.

 

> T9. It is not clear what values = are allowed=20 for write for the object eponDeviceObjectReportThreshold. what does the=20 reference to '2 octets increments' mean?

As referenced to the IEEE802.3ah the reports message values are = in Time=20 quanta which are equivalent to 16nsec or 2 bytes/octets. I will clarify = that in=20 the text.

> T10. Are values in=20 eponDeviceRemoteMACAddressLLIDTable persitent, or can they be erased on = a=20 reset?

Thanks for your suggestion. I must agree that they could also = be erased=20 on a reset. I will add to the text.

> T11. The DESCRIPTION of the=20 eponDeviceRemoteMACAddressLLIDTable is very unclear - I did not = understand how=20 this works

I will clarify the text. The purpose of this table is to hold = an LLID to=20 MAC address table. This mapping is needed for the EPON network emulation = as a=20 bridge where its LLID is acting as a bridge port.

> T12. What does the object=20 eponDeviceRMadLogID with a SYNTAX of OBJECT IDENTIFIER point = to?

Should be eponDeviceRMadlLogID. This object = creates an=20 entry in the LLID MAC address=20 table. 

> T13. The design of the=20 eponDeviceEventsLogTable is not clear. What notifications are being = referred by=20 this table? Why does this need to be a dynamic row creation table? =

The table intention is to create and store a log of events. The = types of=20 events are defined by:

 eponDeviceEventsLogType:

eponDeviceDyingGaspAlarmState (1),
    =20 eponDeviceCriticalEventState (2),
    =20 eponDeviceLocalLinkFaultAlarmState (3),
    =20 eponDeviceTemperatureEventIndicationState = (4),
    =20 eponDevicePowerVoltageEventIndicationState = (5),
    =20 eponDeviceGlobalEventState (6),
    =20 eponDeviceErroredSymbolPeriodEventState (7),
     = eponDeviceErroredFrameEventState   = (8),
    =20 eponDeviceErroredFramePeriodEventState (9),
    =20 eponDeviceErroredFrameSecondsSummaryEventState = (10),
    =20 eponDeviceOrganizationSpecificEventState (11)

Entries in the table are created dynamically once events = happens. When=20 event happens it receives the following parameters.:

eponDeviceEventsLogName       = ;            =    =20 ,
   =20 eponDeviceEventsLogIndex        &= nbsp;           &n= bsp;=20 ,
   =20 eponDeviceEventsLogID        &nbs= p;            = ;   =20 ,
   =20 eponDeviceEventsLogFirstTime       &nb= sp;          =20 ,
   =20 eponDeviceEventsLogLastTime       &nbs= p;           =20 ,
   =20 eponDeviceEventsLogCounts        =             &= nbsp;=20 ,

  =20 eponDeviceEventsLogType        &n= bsp;           &nb= sp;=20 ,
   =20 eponDeviceEventsLogEntryStatus       &= nbsp;       =20

 

> T14. The security section claims = that most=20 objects are writeable when the link is down. First there is a need to = clarify=20 what exactly is meant by the link is down (ifAdminStatus =3D off(2)? for = what=20 ifIndex value?). Second, this restriction needs to be mentioned for = every=20 specific objects in the MIB module itself (DESCRIPTION clauses) and not = left in=20 an external section.

Agree - can't use "most" here. I will add specification for = each=20 attribute and specify the state of the change for it.

> T15. Why define a = eponDeviceSerialNumber,=20 and not use entPhysicalSerialNumber from the Entity MIB? (RFC 2737, or = http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-ent= mib-v3-04.txt)

I agree, we can use it.

 

 

Editorial

Thanks, will be fixed. A few remarks in the=20 text.

> E1. The Internet-Draft has awful = formatting=20 errors. Please follow the guidelines at http://www.ietf.org/ietf/1id-guidelines.txt.

> E2. Among these formatting = errors, one very=20 obvious, with effects on compilation of the MIB modules as well is the = use of=20 illegal characters.

> E3. There is a new Intellectual = Property=20 Template that needs to be used. See the same reference.

> E4. An IANA Consideration section = needs to=20 be added

> E5. Copyright year needs to be = updated to=20 2004.

> E6. There are many spelling and = syntax=20 errors, that make the text sometimes impossible to understand. In fact = there are=20 that many that I will not list them all here, but rather forward a = scribbled=20 hardcopy to the editors with hand-written markings.

> E7. All over the document - say = 'MIB=20 module' instead of MIB when referring to the module, and not a specific = MIB, and=20 'MIB modules' instead of 'MIBs'

> E8. DESCRIPTION clause of = dot3MpcpTable -=20 expand MPCP at the first occurrence of the acronyms

> E9. There are many DEFVAL clauses = missing=20 for read-write or read-create objects. For example: dot3MpcpMode,=20 dot3EponMauFecMode, eponDeviceObjectModes, eponDeviceObjectFecEnabled,=20 eponDeviceObjectOamMode, eponDeviceRMadLogID, = eponDeviceRMadRemoteMacAddress,=20 eponDeviceRMadType, eponDeviceRMadAction, = eponDeviceSampleMinimum,=20

> E10. There are many UNITS clauses = missing.=20 For example: dot3MpcpTransmitElapsed, all counters in = dot3MpcpStatsTable, all=20 counters in dot3OmpEmulationStatTable, counters in dot3EponMauTable, = counters in=20 eponDeviceStatsTable

> E11. dot3OmpEmulationID = DESCRIPTION=20 includes reference to an IEEE object.

I know. I think it is an error in the text of the IEEE802.3ah. = I marked=20 it to myself and did not change it automatically to dot3OmpEmulationID = as to=20 figure this issue out. If I change it we are not aligned with the IEEE. = I would=20 rather see here a different ID than the OAMID (for the EFM-MIB document = I guess)=20 since it is different. Any suggestion?

> E12. I recommend that the tables = that map=20 the MIB objects defined in this document into IEEE 802.3 objects be = separated=20 from the MIB objects definition section.

I don't understand the comment It has a separate=20 section:

4  Definitions – The EFM EPON=20 MIB           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;    =20 6
5  Relationship table of the EFM EPON MIBs objects to the = IEEE802.3ah=20 objects          =20 32
6  Definitions - The EPON Device=20 MIB           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;=20 34

> E13. All enumerated and BITS = values need to=20 be explained in DESCRIPTION. E.g. 'A value of olt(1) means...' - Foe = example in=20 eponDeviceObjectModes, eponDeviceObjectFecEnabled, = eponDeviceObjectOamMode,=20

> E14. eponDeviceObjectPowerDown = should refer=20 to value true(1)

> E15. The significance of the = events defined=20 by the enumerated values of eponDeviceEventsLogTable needs to be=20 expanded

> E16. Why are DOCSIS MIB, Event = MIB, Bridge=20 MIB and Source Routing Bridge MIB referenced?

In the document the methodology and formatting are used. It is = not a=20 direct reference rather a "styling" reference.

 

Lior

 

-----Original Message-----
From:=20 hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org] On Behalf = Of=20 Romascanu, Dan (Dan)
Sent: Sunday, August 01, 2004 1:06=20 PM
To: hubmib@ietf.org
Subject: [Hubmib]=20 draft-ietf-hubmib-efm-epon-mib-01.txt

Technical

T1. None of the two MIB = modules compiles=20 correctly. While the first MIB modules warnings are caused by illegal=20 characters in the DESCRIPTION clauses, the EPON Device MIB has 'true=20 compilation errors. Here is the smilint log for these:

This command (smilint = 0.4.3-pre1, as of Tue=20 Jul 27 14:25:07 2004)

has been processed to get the = following=20 results:

smilint -m -s -m -s -l 6 -i = namelength-32=20 epon-device-mib.txt

...

epon-device-mib.txt:230: [5]=20 {integer-misuse} warning: use Integer32 instead of INTEGER in = SMIv2

epon-device-mib.txt:230: [2]=20 {access-invalid-smiv2} invalid access `read-Only' in SMIv2 = MIB

epon-device-mib.txt:329: [1] = {other} parse=20 error, unexpected '}', expecting LOWERCASE_IDENTIFIER

epon-device-mib.txt:329: [5] = {} warning:=20 flushing recent incorrect declaration, see previous = error(s)

epon-device-mib.txt:330: [1] = {other} parse=20 error, unexpected MAX_ACCESS

epon-device-mib.txt:334: [5] = {} warning:=20 flushing recent incorrect declaration, see previous = error(s)

epon-device-mib.txt:341: [1] = {other} parse=20 error, unexpected '}', expecting ')'

epon-device-mib.txt:341: [5] = {} warning:=20 flushing recent incorrect declaration, see previous = error(s)

epon-device-mib.txt:342: [1] = {other} parse=20 error, unexpected MAX_ACCESS

epon-device-mib.txt:346: [5] = {} warning:=20 flushing recent incorrect declaration, see previous = error(s)

...

epon-device-mib.txt:115: [3]=20 {sequence-no-column} SEQUENCE element #9=20 `eponDeviceObjectRemoteMACAddressLLIDTable' is not a child node under=20 `eponDeviceControlEntry'

epon-device-mib.txt:115: [3]=20 {sequence-no-column} SEQUENCE element #10 = `eponDeviceObjectReportThreshold' is=20 not a child node under `eponDeviceControlEntry'

epon-device-mib.txt:125: [1] = {} unknown=20 object identifier label = `eponDeviceObjectRemoteMACAddressLLIDTable'

epon-device-mib.txt:278: [3]=20 {sequence-no-column} SEQUENCE element #4 = `eponDeviceRMadlRemoteMACAddress' is=20 not a child node under = `eponDeviceRemoteMACAddressLLIDEntry'

epon-device-mib.txt:278: [3]=20 {sequence-no-column} SEQUENCE element #5 `eponDeviceRMadlType' is not = a child=20 node under `eponDeviceRemoteMACAddressLLIDEntry'

epon-device-mib.txt:278: [3]=20 {sequence-no-column} SEQUENCE element #6 `eponDeviceRMadlAction' is = not a=20 child node under `eponDeviceRemoteMACAddressLLIDEntry'

epon-device-mib.txt:278: [3]=20 {sequence-missing-column} SEQUENCE of = `EponDeviceRemoteMACAddressLLIDEntry' is=20 missing columnar object `eponDeviceRMadlRemoteMacAddress'

epon-device-mib.txt:266: [5]=20 {index-element-accessible} warning: index element = `eponDeviceRMadlLLID' of row=20 `eponDeviceRemoteMACAddressLLIDEntry' should be not-accessible in = SMIv2=20 MIB

epon-device-mib.txt:282: [1] = {} unknown=20 object identifier label `eponDeviceRMadlRemoteMACAddress'

epon-device-mib.txt:283: [1] = {} unknown=20 object identifier label `eponDeviceRMadlType'

epon-device-mib.txt:284: [1] = {} unknown=20 object identifier label `eponDeviceRMadlAction'

epon-device-mib.txt:1218: [3] = {group-member-invalid} node `eponDeviceRMadlLogName' is an invalid = member of=20 group `eponDeviceGroupRMadLTable'

epon-device-mib.txt:316: [4]=20 {group-membership} warning: node `eponDeviceRMadlRemoteMacAddress' = must be=20 contained in at least one conformance group

T2. The document does not = take a clear=20 position about required changes from the MAU MIB. As wit the efm-cu = document,=20 my preference would be that we change the MAU MIB structure so that it = is=20 re-written as a IANA-maintained module, but we need a volunteer to do=20 this.

T3. Clarify how are = dot3MpcpID numbers=20 assigned

T4. Is dot3MpcpAdminState an = admin state=20 object as the name suggests, or an oper state object as the read-only=20 MAX-ACCESS and the DESCRIPTION clause suggests? Same about=20 dot3MPCPAdminControl

T5. According to the = DESCRIPTION=20 dot3MpcpMaximumPendingGrants should be in range (0..255)

T6. Some of the objects in = the=20 dot3MpcpStatsTable seem to be mandatory just for ONUs? What does an = OLT which=20 does not support the counter do? Maybe the table should be broken into = two=20 tables. In any case the Conformance clauses should reflect the = optional=20 support for some of the counters.

T7. dot3OmpEmulationStatTable = has objects=20 mandatory for OLT and optional for ONU. This should be reflected in = the=20 conformance cases, and maybe the table should be broken in separate = tables=20 accordingly

T8. Clarify what is being = returned on a=20 read operation for eponDeviceObjectReset

T9. It is not clear what = values are allowed=20 for write for the object eponDeviceObjectReportThreshold. what does = the=20 reference to '2 octets increments' mean?

T10. Are values in=20 eponDeviceRemoteMACAddressLLIDTable persitent, or can they be erased = on a=20 reset?

T11. The DESCRIPTION of the=20 eponDeviceRemoteMACAddressLLIDTable is very unclear - I did not = understand how=20 this works

T12. What does the object=20 eponDeviceRMadLogID with a SYNTAX of OBJECT IDENTIFIER point to? =

T13. The design of the=20 eponDeviceEventsLogTable is not clear. What notifications are being = referred=20 by this table? Why does this need to be a dynamic row creation table?=20

T14. The security section = claims that most=20 objects are writeable when the link is down. First there is a need to = clarify=20 what exactly is meant by the link is down (ifAdminStatus =3D off(2)? = for what=20 ifIndex value?). Second, this restriction needs to be mentioned for = every=20 specific objects in the MIB module itself (DESCRIPTION clauses) and = not left=20 in an external section.

T15. Why define a = eponDeviceSerialNumber,=20 and not use entPhysicalSerialNumber from the Entity MIB? (RFC 2737, or = http://www.ietf.cnri.reston.va.us/internet-drafts/draft-iet= f-entmib-v3-04.txt)

 

Editorial

E1. The Internet-Draft has = awful formatting=20 errors. Please follow the guidelines at http://www.ietf.org/= ietf/1id-guidelines.txt.=20

E2. Among these formatting = errors, one very=20 obvious, with effects on compilation of the MIB modules as well is the = use of=20 illegal characters.

E3. There is a new = Intellectual Property=20 Template that needs to be used. See the same reference.

E4. An IANA Consideration = section needs to=20 be added

E5. Copyright year needs to = be updated to=20 2004.

E6. There are many spelling = and syntax=20 errors, that make the text sometimes impossible to understand. In fact = there=20 are that many that I will not list them all here, but rather forward a = scribbled hardcopy to the editors with hand-written = markings.

E7. All over the document - = say 'MIB=20 module' instead of MIB when referring to the module, and not a = specific MIB,=20 and 'MIB modules' instead of 'MIBs'

E8. DESCRIPTION clause of = dot3MpcpTable -=20 expand MPCP at the first occurrence of the acronyms

E9. There are many DEFVAL = clauses missing=20 for read-write or read-create objects. For example: dot3MpcpMode,=20 dot3EponMauFecMode, eponDeviceObjectModes, eponDeviceObjectFecEnabled, = eponDeviceObjectOamMode, eponDeviceRMadLogID, = eponDeviceRMadRemoteMacAddress,=20 eponDeviceRMadType, eponDeviceRMadAction, = eponDeviceSampleMinimum,=20

E10. There are many UNITS = clauses missing.=20 For example: dot3MpcpTransmitElapsed, all counters in = dot3MpcpStatsTable, all=20 counters in dot3OmpEmulationStatTable, counters in dot3EponMauTable, = counters=20 in eponDeviceStatsTable

E11. dot3OmpEmulationID = DESCRIPTION=20 includes reference to an IEEE object.

E12. I recommend that the = tables that map=20 the MIB objects defined in this document into IEEE 802.3 objects be = separated=20 from the MIB objects definition section.

E13. All enumerated and BITS = values need to=20 be explained in DESCRIPTION. E.g. 'A value of olt(1) means...' - Foe = example=20 in eponDeviceObjectModes, eponDeviceObjectFecEnabled, = eponDeviceObjectOamMode,=20

E14. = eponDeviceObjectPowerDown should refer=20 to value true(1)

E15. The significance of the = events defined=20 by the enumerated values of eponDeviceEventsLogTable needs to be=20 expanded

E16. Why are DOCSIS MIB, = Event MIB, Bridge=20 MIB and Source Routing Bridge MIB referenced?



Regards,

Dan

------=_NextPart_000_0353_01C478AC.3F724D20-- --===============0454437817== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============0454437817==-- From hubmib-bounces@ietf.org Tue Aug 3 14:37:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00941 for ; Tue, 3 Aug 2004 14:37:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs46m-0005wK-DX; Tue, 03 Aug 2004 14:33:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3pc-0002u7-GZ for hubmib@megatron.ietf.org; Tue, 03 Aug 2004 14:16:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28867 for ; Tue, 3 Aug 2004 14:16:11 -0400 (EDT) Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs3si-0006ov-Oj for hubmib@ietf.org; Tue, 03 Aug 2004 14:19:26 -0400 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id i73IEXVO010257; Tue, 3 Aug 2004 11:14:33 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id i73IEUgd010224; Tue, 3 Aug 2004 11:14:30 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 3 Aug 2004 11:14:30 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Matt Squire Subject: Re: [Hubmib] ifSpeed & 2BASE-TL/10PASS-TS In-Reply-To: <8052E2EA753D144EB906B7A7AA39971402B07804@mailserv.hatteras.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "Edward Beili \(E-mail\)" , hubmib@ietf.org, stds-802-3-efm@ieee.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org On Mon, 2 Aug 2004, Matt Squire wrote: > During the discussions today in the hubmib WG, the question > arose as to what should be the ifSpeed for 2BASE-TL & 10PASS-TS > interfaces. > > Traditionally, it seems the ifSpeed has been tied to the speed > of the MAC (e.g. 10Mbps, 100Mbps, etc.). With 2BASE/10PASS, the > PHY may be running at a much lower speed than the 100Mbps MAC, > so its not particularly useful to the administrator to call all > of these interfaces 100M when the PHYs aren't there. > > Options for ifSpeed of 2BASE/10PASS seem to include the > following: > > 0) Use 100 Mbps (MAC speed). > > 1) Sum the physical date rates of PMEs in the aggregate (PHY > speed). > > 2) Use the rate of "goodput" on the PHYs (e.g. how much data can > ge thru). This would ignore any overhead of the PHY (PAF, > 64/65) and overhead of the MAC (preamble, IPG). This most > accurately reflects how much data can get thru. > > 3) Use the rate at the MAC/MII. E.g. include preamble/IPG (even > though its not transmitted), but not PHY overhead (PAF, 64/65). > This seems consistent with other PHYs, but is kinda weird in > that we're not actually transmitting preamble/ipg. > > There are probably other options too. Thoughts/opinions? You might want to take a look at RFCs 3635 and 3637 to see what was done for 10GBASE-W. In that case we used a layering model (specified via the ifStackTable) that had different ifSpeed values for different sublayers, and the speed at each sublayer corresponded to the rate at which that sublayer transmitted bit to and/or received bits from the sublayer below. The ifSpeed values for the ifTable entries representing the SONET sublayers were specified in RFC 3637 Section 3.4, and the ifSpeed value for the ifEntry representing the PCS/RS/MAC/LLC sublayers was specified in RFC 3635 Section 3.2.8. Hope this helps. Mike Heard WIS MIB editor P.S. It would probably be a Good Thing (tm) to have a stack table diagram in the next rev of draft-ietf-hubmib-efm-cu-mib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Tue Aug 3 23:07:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06081 for ; Tue, 3 Aug 2004 23:07:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsC1D-000782-Q9; Tue, 03 Aug 2004 23:00:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsBxD-0006eX-V7 for hubmib@megatron.ietf.org; Tue, 03 Aug 2004 22:56:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04909 for ; Tue, 3 Aug 2004 22:56:32 -0400 (EDT) Received: from [62.90.13.193] (helo=il-mail.actelis.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsC0O-0007R5-Je for hubmib@ietf.org; Tue, 03 Aug 2004 22:59:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Hubmib] ifSpeed & 2BASE-TL/10PASS-TS Date: Wed, 4 Aug 2004 05:55:44 +0300 Message-ID: <9C1CAB2B65E62D49A10E49DFCD68EF3E03BE6C@il-mail.actelis.net> Thread-Topic: [Hubmib] ifSpeed & 2BASE-TL/10PASS-TS Thread-Index: AcR5hc0Us+layGMJRgG4KsxY+p7vsAARzp8x From: "Edward Beili" To: "C. M. Heard" , "Matt Squire" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: hubmib@ietf.org, stds-802-3-efm@ieee.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1657312143==" Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============1657312143== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C479CE.8964643C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C479CE.8964643C Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWlrZSwNCkkgYWdyZWUgdGhhdCBpdCB3b3VsZCBwcm9iYWJseSBiZSBhIGdvb2QgaWRlYSB0byBp bmNsdWRlIHRoZSBsYXllcmluZyBkaWFncmFtIGludG8gdGhlIGVmbS1jdS1taWIuDQogDQpUaGUg UENTIGluIHRoZSBFRk1DdSBwb3J0cyBwZXJmb3JtcyByYXRlIG1hdGNoaW5nIHVzaW5nIGZsb3cg Y29udHJvbCwgd2hpbGUgdGhlIE1BQyBpcyBydW5uaW5nIGF0IDEwME1icHMuIFNpbmNlIEVGTUN1 IGludGVyZmFjZSBzcGVlZHMgbWF5IHZhcnkgZGVwZW5kaW5nIG9uIHRoZSBjb3BwZXIgY29uZGl0 aW9ucywgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzIGFuZCBhbW91bnQgb2YgUE1FcyBhZ2dyZWdh dGVkLCByZXBvcnRpbmcgdGhlIGlmU3BlZWQgb2YgdGhlIFBDUyBhcyAxMDBNYnBzIHdvdWxkbid0 IHJlYWxseSBoZWxwLiBSZXBvcnRpbmcgdGhlIGlmU3BlZWQgb2YgdGhlIFBDUyBhcyB0aGUgc3Vt IG9mIHRoZSBQTUUgc3BlZWRzIGlzIGFsc28gaW5jb3JyZWN0IGFzIHRoZXJlJ3MgNjQvNjVCIGVu Y2Fwc3VsYXRpb24gb3ZlcmhlYWQgd2l0aCBvcHRpb25hbCBQQUYgb3ZlcmhlYWQuDQogDQpSZWdh cmRzLA0KLUVkd2FyZCANCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IEMu IE0uIEhlYXJkIFttYWlsdG86aGVhcmRAcG9ib3guY29tXSANCglTZW50OiBUdWUgOC8zLzIwMDQg OToxNCBQTSANCglUbzogTWF0dCBTcXVpcmUgDQoJQ2M6IHN0ZHMtODAyLTMtZWZtQGllZWUub3Jn OyBodWJtaWJAaWV0Zi5vcmc7IEVkd2FyZCBCZWlsaSANCglTdWJqZWN0OiBSZTogW0h1Ym1pYl0g aWZTcGVlZCAmIDJCQVNFLVRMLzEwUEFTUy1UUw0KCQ0KCQ0KDQoJT24gTW9uLCAyIEF1ZyAyMDA0 LCBNYXR0IFNxdWlyZSB3cm90ZToNCgk+IER1cmluZyB0aGUgZGlzY3Vzc2lvbnMgdG9kYXkgaW4g dGhlIGh1Ym1pYiBXRywgdGhlIHF1ZXN0aW9uDQoJPiBhcm9zZSBhcyB0byB3aGF0IHNob3VsZCBi ZSB0aGUgaWZTcGVlZCBmb3IgMkJBU0UtVEwgJiAxMFBBU1MtVFMNCgk+IGludGVyZmFjZXMuDQoJ Pg0KCT4gVHJhZGl0aW9uYWxseSwgaXQgc2VlbXMgdGhlIGlmU3BlZWQgaGFzIGJlZW4gdGllZCB0 byB0aGUgc3BlZWQNCgk+IG9mIHRoZSBNQUMgKGUuZy4gMTBNYnBzLCAxMDBNYnBzLCBldGMuKS4g IFdpdGggMkJBU0UvMTBQQVNTLCB0aGUNCgk+IFBIWSBtYXkgYmUgcnVubmluZyBhdCBhIG11Y2gg bG93ZXIgc3BlZWQgdGhhbiB0aGUgMTAwTWJwcyBNQUMsDQoJPiBzbyBpdHMgbm90IHBhcnRpY3Vs YXJseSB1c2VmdWwgdG8gdGhlIGFkbWluaXN0cmF0b3IgdG8gY2FsbCBhbGwNCgk+IG9mIHRoZXNl IGludGVyZmFjZXMgMTAwTSB3aGVuIHRoZSBQSFlzIGFyZW4ndCB0aGVyZS4NCgk+DQoJPiBPcHRp b25zIGZvciBpZlNwZWVkIG9mIDJCQVNFLzEwUEFTUyBzZWVtIHRvIGluY2x1ZGUgdGhlDQoJPiBm b2xsb3dpbmc6DQoJPg0KCT4gMCkgVXNlIDEwMCBNYnBzIChNQUMgc3BlZWQpLg0KCT4NCgk+IDEp IFN1bSB0aGUgcGh5c2ljYWwgZGF0ZSByYXRlcyBvZiBQTUVzIGluIHRoZSBhZ2dyZWdhdGUgKFBI WQ0KCT4gc3BlZWQpLg0KCT4NCgk+IDIpIFVzZSB0aGUgcmF0ZSBvZiAiZ29vZHB1dCIgb24gdGhl IFBIWXMgKGUuZy4gaG93IG11Y2ggZGF0YSBjYW4NCgk+IGdlIHRocnUpLiAgVGhpcyB3b3VsZCBp Z25vcmUgYW55IG92ZXJoZWFkIG9mIHRoZSBQSFkgKFBBRiwNCgk+IDY0LzY1KSBhbmQgb3Zlcmhl YWQgb2YgdGhlIE1BQyAocHJlYW1ibGUsIElQRykuICBUaGlzIG1vc3QNCgk+IGFjY3VyYXRlbHkg cmVmbGVjdHMgaG93IG11Y2ggZGF0YSBjYW4gZ2V0IHRocnUuDQoJPg0KCT4gMykgVXNlIHRoZSBy YXRlIGF0IHRoZSBNQUMvTUlJLiAgRS5nLiBpbmNsdWRlIHByZWFtYmxlL0lQRyAoZXZlbg0KCT4g dGhvdWdoIGl0cyBub3QgdHJhbnNtaXR0ZWQpLCBidXQgbm90IFBIWSBvdmVyaGVhZCAoUEFGLCA2 NC82NSkuIA0KCT4gVGhpcyBzZWVtcyBjb25zaXN0ZW50IHdpdGggb3RoZXIgUEhZcywgYnV0IGlz IGtpbmRhIHdlaXJkIGluDQoJPiB0aGF0IHdlJ3JlIG5vdCBhY3R1YWxseSB0cmFuc21pdHRpbmcg cHJlYW1ibGUvaXBnLg0KCT4NCgk+IFRoZXJlIGFyZSBwcm9iYWJseSBvdGhlciBvcHRpb25zIHRv by4gIFRob3VnaHRzL29waW5pb25zPw0KCQ0KCVlvdSBtaWdodCB3YW50IHRvIHRha2UgYSBsb29r IGF0IFJGQ3MgMzYzNSBhbmQgMzYzNyB0byBzZWUgd2hhdCB3YXMNCglkb25lIGZvciAxMEdCQVNF LVcuICBJbiB0aGF0IGNhc2Ugd2UgdXNlZCBhIGxheWVyaW5nIG1vZGVsDQoJKHNwZWNpZmllZCB2 aWEgdGhlIGlmU3RhY2tUYWJsZSkgdGhhdCBoYWQgZGlmZmVyZW50IGlmU3BlZWQgdmFsdWVzDQoJ Zm9yIGRpZmZlcmVudCBzdWJsYXllcnMsIGFuZCB0aGUgc3BlZWQgYXQgZWFjaCBzdWJsYXllciBj b3JyZXNwb25kZWQNCgl0byB0aGUgcmF0ZSBhdCB3aGljaCB0aGF0IHN1YmxheWVyIHRyYW5zbWl0 dGVkIGJpdCB0byBhbmQvb3INCglyZWNlaXZlZCBiaXRzIGZyb20gdGhlIHN1YmxheWVyIGJlbG93 LiAgVGhlIGlmU3BlZWQgdmFsdWVzIGZvciB0aGUNCglpZlRhYmxlIGVudHJpZXMgcmVwcmVzZW50 aW5nIHRoZSBTT05FVCBzdWJsYXllcnMgd2VyZSBzcGVjaWZpZWQgaW4NCglSRkMgMzYzNyBTZWN0 aW9uIDMuNCwgYW5kIHRoZSBpZlNwZWVkIHZhbHVlIGZvciB0aGUgaWZFbnRyeQ0KCXJlcHJlc2Vu dGluZyB0aGUgUENTL1JTL01BQy9MTEMgc3VibGF5ZXJzIHdhcyBzcGVjaWZpZWQgaW4gUkZDIDM2 MzUNCglTZWN0aW9uIDMuMi44Lg0KCQ0KCUhvcGUgdGhpcyBoZWxwcy4NCgkNCglNaWtlIEhlYXJk DQoJV0lTIE1JQiBlZGl0b3INCgkNCglQLlMuIEl0IHdvdWxkIHByb2JhYmx5IGJlIGEgR29vZCBU aGluZyAodG0pIHRvIGhhdmUgYSBzdGFjayB0YWJsZQ0KCWRpYWdyYW0gaW4gdGhlIG5leHQgcmV2 IG9mIGRyYWZ0LWlldGYtaHVibWliLWVmbS1jdS1taWINCgkNCgkNCg0K ------_=_NextPart_001_01C479CE.8964643C Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjY1NTYuMCI+CjxUSVRMRT5SZTogW0h1Ym1pYl0gaWZT cGVlZCAmYW1wOyAyQkFTRS1UTC8xMFBBU1MtVFM8L1RJVExFPgo8L0hFQUQ+CjxCT0RZIGRpcj1s dHI+CjxESVY+TWlrZSw8L0RJVj4KPERJVj5JIGFncmVlIHRoYXQgaXQgd291bGQgcHJvYmFibHkg YmUgYSBnb29kIGlkZWEgdG8gaW5jbHVkZSB0aGUgbGF5ZXJpbmcgCmRpYWdyYW0gaW50byB0aGUg ZWZtLWN1LW1pYi48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5UaGUgUENTIGluIHRoZSBF Rk1DdSBwb3J0cyBwZXJmb3JtcyByYXRlIG1hdGNoaW5nIHVzaW5nIGZsb3cgY29udHJvbCwgd2hp bGUgCnRoZSBNQUMgaXMgcnVubmluZyBhdCAxMDBNYnBzLiBTaW5jZSBFRk1DdSBpbnRlcmZhY2Ug c3BlZWRzIG1heSB2YXJ5IGRlcGVuZGluZyAKb24gdGhlIGNvcHBlciBjb25kaXRpb25zLCBjb25m aWd1cmF0aW9uIHBhcmFtZXRlcnMgYW5kIGFtb3VudCBvZiBQTUVzIAphZ2dyZWdhdGVkLCZuYnNw O3JlcG9ydGluZyB0aGUgaWZTcGVlZCBvZiB0aGUgUENTIGFzIDEwME1icHMgd291bGRuJ3QgcmVh bGx5IApoZWxwLiBSZXBvcnRpbmcgdGhlIGlmU3BlZWQgb2YgdGhlIFBDUyBhcyB0aGUgc3VtIG9m IHRoZSBQTUUgc3BlZWRzIGlzIGFsc28gCmluY29ycmVjdCBhcyZuYnNwO3RoZXJlJ3MgNjQvNjVC IGVuY2Fwc3VsYXRpb24gb3ZlcmhlYWQgd2l0aCBvcHRpb25hbCBQQUYgCm92ZXJoZWFkLjwvRElW Pgo8RElWPiZuYnNwOzwvRElWPgo8RElWPlJlZ2FyZHMsPC9ESVY+CjxESVY+LUVkd2FyZCZuYnNw OzwvRElWPgo8QkxPQ0tRVU9URSBkaXI9bHRyIHN0eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+CiAg PERJVj48Rk9OVCBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gPEJSPjxCPkZyb206 PC9CPiBDLiBNLiBIZWFyZCAKICBbbWFpbHRvOmhlYXJkQHBvYm94LmNvbV0gPEJSPjxCPlNlbnQ6 PC9CPiBUdWUgOC8zLzIwMDQgOToxNCBQTSA8QlI+PEI+VG86PC9CPiAKICBNYXR0IFNxdWlyZSA8 QlI+PEI+Q2M6PC9CPiBzdGRzLTgwMi0zLWVmbUBpZWVlLm9yZzsgaHVibWliQGlldGYub3JnOyBF ZHdhcmQgCiAgQmVpbGkgPEJSPjxCPlN1YmplY3Q6PC9CPiBSZTogW0h1Ym1pYl0gaWZTcGVlZCAm YW1wOyAKICAyQkFTRS1UTC8xMFBBU1MtVFM8QlI+PEJSPjwvRk9OVD48L0RJVj4KICA8UD48Rk9O VCBzaXplPTI+T24gTW9uLCAyIEF1ZyAyMDA0LCBNYXR0IFNxdWlyZSB3cm90ZTo8QlI+Jmd0OyBE dXJpbmcgdGhlIAogIGRpc2N1c3Npb25zIHRvZGF5IGluIHRoZSBodWJtaWIgV0csIHRoZSBxdWVz dGlvbjxCUj4mZ3Q7IGFyb3NlIGFzIHRvIHdoYXQgCiAgc2hvdWxkIGJlIHRoZSBpZlNwZWVkIGZv ciAyQkFTRS1UTCAmYW1wOyAxMFBBU1MtVFM8QlI+Jmd0OyAKICBpbnRlcmZhY2VzLjxCUj4mZ3Q7 PEJSPiZndDsgVHJhZGl0aW9uYWxseSwgaXQgc2VlbXMgdGhlIGlmU3BlZWQgaGFzIGJlZW4gdGll ZCAKICB0byB0aGUgc3BlZWQ8QlI+Jmd0OyBvZiB0aGUgTUFDIChlLmcuIDEwTWJwcywgMTAwTWJw cywgZXRjLikuJm5ic3A7IFdpdGggCiAgMkJBU0UvMTBQQVNTLCB0aGU8QlI+Jmd0OyBQSFkgbWF5 IGJlIHJ1bm5pbmcgYXQgYSBtdWNoIGxvd2VyIHNwZWVkIHRoYW4gdGhlIAogIDEwME1icHMgTUFD LDxCUj4mZ3Q7IHNvIGl0cyBub3QgcGFydGljdWxhcmx5IHVzZWZ1bCB0byB0aGUgYWRtaW5pc3Ry YXRvciB0byAKICBjYWxsIGFsbDxCUj4mZ3Q7IG9mIHRoZXNlIGludGVyZmFjZXMgMTAwTSB3aGVu IHRoZSBQSFlzIGFyZW4ndCAKICB0aGVyZS48QlI+Jmd0OzxCUj4mZ3Q7IE9wdGlvbnMgZm9yIGlm U3BlZWQgb2YgMkJBU0UvMTBQQVNTIHNlZW0gdG8gaW5jbHVkZSAKICB0aGU8QlI+Jmd0OyBmb2xs b3dpbmc6PEJSPiZndDs8QlI+Jmd0OyAwKSBVc2UgMTAwIE1icHMgKE1BQyAKICBzcGVlZCkuPEJS PiZndDs8QlI+Jmd0OyAxKSBTdW0gdGhlIHBoeXNpY2FsIGRhdGUgcmF0ZXMgb2YgUE1FcyBpbiB0 aGUgCiAgYWdncmVnYXRlIChQSFk8QlI+Jmd0OyBzcGVlZCkuPEJSPiZndDs8QlI+Jmd0OyAyKSBV c2UgdGhlIHJhdGUgb2YgImdvb2RwdXQiIG9uIAogIHRoZSBQSFlzIChlLmcuIGhvdyBtdWNoIGRh dGEgY2FuPEJSPiZndDsgZ2UgdGhydSkuJm5ic3A7IFRoaXMgd291bGQgaWdub3JlIGFueSAKICBv dmVyaGVhZCBvZiB0aGUgUEhZIChQQUYsPEJSPiZndDsgNjQvNjUpIGFuZCBvdmVyaGVhZCBvZiB0 aGUgTUFDIChwcmVhbWJsZSwgCiAgSVBHKS4mbmJzcDsgVGhpcyBtb3N0PEJSPiZndDsgYWNjdXJh dGVseSByZWZsZWN0cyBob3cgbXVjaCBkYXRhIGNhbiBnZXQgCiAgdGhydS48QlI+Jmd0OzxCUj4m Z3Q7IDMpIFVzZSB0aGUgcmF0ZSBhdCB0aGUgTUFDL01JSS4mbmJzcDsgRS5nLiBpbmNsdWRlIAog IHByZWFtYmxlL0lQRyAoZXZlbjxCUj4mZ3Q7IHRob3VnaCBpdHMgbm90IHRyYW5zbWl0dGVkKSwg YnV0IG5vdCBQSFkgb3ZlcmhlYWQgCiAgKFBBRiwgNjQvNjUpLiZuYnNwOzxCUj4mZ3Q7IFRoaXMg c2VlbXMgY29uc2lzdGVudCB3aXRoIG90aGVyIFBIWXMsIGJ1dCBpcyAKICBraW5kYSB3ZWlyZCBp bjxCUj4mZ3Q7IHRoYXQgd2UncmUgbm90IGFjdHVhbGx5IHRyYW5zbWl0dGluZyAKICBwcmVhbWJs ZS9pcGcuPEJSPiZndDs8QlI+Jmd0OyBUaGVyZSBhcmUgcHJvYmFibHkgb3RoZXIgb3B0aW9ucyB0 b28uJm5ic3A7IAogIFRob3VnaHRzL29waW5pb25zPzxCUj48QlI+WW91IG1pZ2h0IHdhbnQgdG8g dGFrZSBhIGxvb2sgYXQgUkZDcyAzNjM1IGFuZCAzNjM3IAogIHRvIHNlZSB3aGF0IHdhczxCUj5k b25lIGZvciAxMEdCQVNFLVcuJm5ic3A7IEluIHRoYXQgY2FzZSB3ZSB1c2VkIGEgbGF5ZXJpbmcg CiAgbW9kZWw8QlI+KHNwZWNpZmllZCB2aWEgdGhlIGlmU3RhY2tUYWJsZSkgdGhhdCBoYWQgZGlm ZmVyZW50IGlmU3BlZWQgCiAgdmFsdWVzPEJSPmZvciBkaWZmZXJlbnQgc3VibGF5ZXJzLCBhbmQg dGhlIHNwZWVkIGF0IGVhY2ggc3VibGF5ZXIgCiAgY29ycmVzcG9uZGVkPEJSPnRvIHRoZSByYXRl IGF0IHdoaWNoIHRoYXQgc3VibGF5ZXIgdHJhbnNtaXR0ZWQgYml0IHRvIAogIGFuZC9vcjxCUj5y ZWNlaXZlZCBiaXRzIGZyb20gdGhlIHN1YmxheWVyIGJlbG93LiZuYnNwOyBUaGUgaWZTcGVlZCB2 YWx1ZXMgZm9yIAogIHRoZTxCUj5pZlRhYmxlIGVudHJpZXMgcmVwcmVzZW50aW5nIHRoZSBTT05F VCBzdWJsYXllcnMgd2VyZSBzcGVjaWZpZWQgCiAgaW48QlI+UkZDIDM2MzcgU2VjdGlvbiAzLjQs IGFuZCB0aGUgaWZTcGVlZCB2YWx1ZSBmb3IgdGhlIAogIGlmRW50cnk8QlI+cmVwcmVzZW50aW5n IHRoZSBQQ1MvUlMvTUFDL0xMQyBzdWJsYXllcnMgd2FzIHNwZWNpZmllZCBpbiBSRkMgCiAgMzYz NTxCUj5TZWN0aW9uIDMuMi44LjxCUj48QlI+SG9wZSB0aGlzIGhlbHBzLjxCUj48QlI+TWlrZSBI ZWFyZDxCUj5XSVMgTUlCIAogIGVkaXRvcjxCUj48QlI+UC5TLiBJdCB3b3VsZCBwcm9iYWJseSBi ZSBhIEdvb2QgVGhpbmcgKHRtKSB0byBoYXZlIGEgc3RhY2sgCiAgdGFibGU8QlI+ZGlhZ3JhbSBp biB0aGUgbmV4dCByZXYgb2YgCiAgZHJhZnQtaWV0Zi1odWJtaWItZWZtLWN1LW1pYjxCUj48QlI+ PC9GT05UPjwvUD48L0JMT0NLUVVPVEU+Cgo8L0JPRFk+CjwvSFRNTD4= ------_=_NextPart_001_01C479CE.8964643C-- --===============1657312143== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============1657312143==-- From hubmib-bounces@ietf.org Wed Aug 4 11:28:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11550 for ; Wed, 4 Aug 2004 11:28:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsNbf-0006N1-9m; Wed, 04 Aug 2004 11:23:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsNXL-0005tZ-8x for hubmib@megatron.ietf.org; Wed, 04 Aug 2004 11:18:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11165 for ; Wed, 4 Aug 2004 11:18:34 -0400 (EDT) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsNaa-0001UX-Hs for hubmib@ietf.org; Wed, 04 Aug 2004 11:22:02 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i74FH3Ga009817 for ; Wed, 4 Aug 2004 11:17:03 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i74FGXGa008870 for ; Wed, 4 Aug 2004 11:16:42 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hubmib] ifSpeed & 2BASE-TL/10PASS-TS Date: Wed, 4 Aug 2004 18:18:00 +0300 Message-ID: Thread-Topic: [Hubmib] ifSpeed & 2BASE-TL/10PASS-TS Thread-Index: AcR5iP7/TK+J419WQlGK3KDr/ocSdgAm7ADg From: "Romascanu, Dan (Dan)" To: "C. M. Heard" , "Matt Squire" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: "Edward Beili \(E-mail\)" , hubmib@ietf.org, stds-802-3-efm@ieee.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Yes! Can we please consider this as a Last Call comment.=20 (of course Mike, it would be great if you can have a look at the current = set of Internet-Drafts now in WG Last Call and submit a full set = comments). Thanks and Regards, Dan >=20 > P.S. It would probably be a Good Thing (tm) to have a stack table > diagram in the next rev of draft-ietf-hubmib-efm-cu-mib >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Wed Aug 4 12:50:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18075 for ; Wed, 4 Aug 2004 12:50:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsOiW-0000bv-Ci; Wed, 04 Aug 2004 12:34:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsOaI-0003qO-Lg for hubmib@megatron.ietf.org; Wed, 04 Aug 2004 12:25:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15362 for ; Wed, 4 Aug 2004 12:25:43 -0400 (EDT) Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsOda-0002d7-V9 for hubmib@ietf.org; Wed, 04 Aug 2004 12:29:12 -0400 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id i74GPbNQ014589; Wed, 4 Aug 2004 09:25:37 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id i74GPaAh014585; Wed, 4 Aug 2004 09:25:37 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 4 Aug 2004 09:25:36 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Hub Mib In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Subject: [Hubmib] IANA Maintained TC for MAU types X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org On Tue, 3 Aug 2004, Romascanu, Dan (Dan) wrote: > The Ethernet interfaces and hub MIB WG (hubmib) met for one > session at the 60th IETF. The WG discussed the latest changes, > comments and open issues for the three chartered WG > Internet-Drafts related to the Ethernet First Mile (EFM) > technology. The participants in the meeting recommended that > the MAU MIB be re-written to refer to a IANA-maintained Textual > Convention, which would ease the support for new MAUs in the > future, without requiring opening of the MAU MIB documents. I'd like to make a few comments about this idea. The first point is that what needs to be extended in the MAU-MIB is not just a single BITS type definition but rather a BITS type definition that is lined up with a matched set of OBJECT-IDENTITY definitions. The affected definitions in the MAU-MIB are these OBJECT-IDENTITY definitions: dot3MauType OBJECT IDENTIFIER ::= { snmpDot3MauMgt 4 } dot3MauTypeAUI OBJECT-IDENTITY STATUS current DESCRIPTION "no internal MAU, view from AUI" REFERENCE "[IEEE 802.3 Std.], Section 7" ::= { dot3MauType 1 } [ ... ] dot3MauType10GigBaseSW OBJECT-IDENTITY STATUS current DESCRIPTION "W fiber over 850 nm optics" REFERENCE "[IEEE 802.3 Std.], Section 52" ::= { dot3MauType 40 } and the BITS type in the following OBJECT-TYPE definition: ifMauTypeListBits OBJECT-TYPE SYNTAX BITS { bOther(0), -- other or unknown bAUI(1), -- AUI [ ... ] b10GbaseSW(40) -- 10GBASE-SW } MAX-ACCESS read-only STATUS current DESCRIPTION "A value that uniquely identifies the set of possible IEEE 802.3 types that the MAU could be. If auto-negotiation is present on this MAU, this object will map to ifMauAutoNegCapabilityBits. Note that this MAU may be capable of operating as a MAU type that is beyond the scope of this MIB. This is indicated by returning the bit value bOther in addition to any bit values for capabilities that are listed above." ::= { ifMauEntry 13 } The IANA-maintained MIB module would need to contain the dot3MauType* OBJECT-IDENTITY definitions along with a TC (which might be called IANAifMauTypeListBits) that whose SYNTAX clause is what is presently in ifMauTypeListBits. That, of course, is because these items have to remain in sync and so have to be maintained in parallel. The IANA-maintained module would, of course, import the base OID descriptor dot3MauType from the MAU-MIB. One minor backward-compatibility issue is that migrating the OBJECT-IDENTITY definitions in this way could cause problems if any existing MIB modules have imported those descriptors from MAU-MIB. This could be addressed by keeping the existing list of dot3MauType* descriptors in the MAU-MIB as object identifier value assignments; while RFC 2578 does not permit two "registrations" of the same OID value, it does allow a descriptor to be associated with both a registration and an object identifier value assignment, providing both are associated with the same OBJECT IDENTIFIER value and semantics (cf. Section 3.6). Another issue that needs to be addressed is what rules apply to new MAU types. My thinking is that this should be allowed ONLY by a Standards Action (as defined in RFC 2434) -- or at least IETF Consensus -- so that any prospective assignments are documented in an RFC. Any document that proposes such an assignment should also be required to note any special properties of the MAU types that it defines -- for example, side effects on the ifStackTable such as are noted in RFC 3636 Section 3.4.1 for 10GBASE-W MAUs. Also to be noted is that the MAU-MIB itself will need some minor modifications beyond those discussed above, such as the DESCRIPTION clauses for rpMauType and ifMauType. A good editor is needed to ferret all those things out. One final point: in his reply to Dan Romascanu's comments on draft-ietf-hubmib-efm-epon-mib-01.txt, Lior Khermosh said: > Sorry for being not clear but my intention is that MAU type > objects in the MAU section should be added to the MAUMIBs as > with the efm-cu document. If it is not done there then the MAU > section in the efm-epon mib should contain them (as now). My position would be that we MUST modify the MAU-MIB -- either directly or by putting the MAU types into an IANA-maintained module -- to contain the new MAU type definitions. It invites catastrophe (i.e., conflicting OID/bit position assignments) if the values assigned to MAU types are scattered over several documents. I do agree that it is OK to split off MAU-specific stats counters and so on and put those in a separate module; in fact there is no practical alternative to doing so if we don't want to change the MAU-MIB every time we add an MAU type that requires such things. Regards, Mike Heard _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Wed Aug 4 14:43:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27731 for ; Wed, 4 Aug 2004 14:43:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsQQQ-0005W1-88; Wed, 04 Aug 2004 14:23:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsQLV-0004Rz-A8 for hubmib@megatron.ietf.org; Wed, 04 Aug 2004 14:18:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25647 for ; Wed, 4 Aug 2004 14:18:34 -0400 (EDT) Received: from [62.90.13.193] (helo=il-mail.actelis.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsQOo-0005IU-4j for hubmib@ietf.org; Wed, 04 Aug 2004 14:22:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Hubmib] IANA Maintained TC for MAU types Date: Wed, 4 Aug 2004 21:17:52 +0300 Message-ID: <9C1CAB2B65E62D49A10E49DFCD68EF3E03BE83@il-mail.actelis.net> Thread-Topic: [Hubmib] IANA Maintained TC for MAU types Thread-Index: AcR6Qx5z03yZP0HBQpiXeJSF60JWNAABN0/C From: "Edward Beili" To: "C. M. Heard" , "Hub Mib" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0487430227==" Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============0487430227== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47A4F.5B15D584" This is a multi-part message in MIME format. ------_=_NextPart_001_01C47A4F.5B15D584 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWlrZSwNCiANCkl0IGxvb2tzIGxpa2UgeW91J3ZlIGFscmVhZHkgdGhvdWdodCBhYm91dCBpdC4g V291bGQgeW91IGxpa2UgdG8gZG8gdGhlIGVkaXRpbmcgb2YgdGhlIE1BVSBNSUI/DQogDQpXaGls ZSB3ZSBhcmUgb24gdGhlIHN1YmplY3Qgb2YgTUFVIE1JQiBJIHdvdWxkIGxpa2UgdG8gc2hhcmUg YSBsaXR0bGUgcHJvYmxlbSBJJ20gaGF2aW5nIGluIEVGTS1DVS1NSUI6DQpBcyBvZiB0b2RheSB0 aGUgSUVFRSBQODAyLjNhZi9EMy4zIHNwZWNpZmllcyBvTUFVIGJlaW5nIGEgc2libGluZyBvZiB0 aGUgb1BBRiB1bmRlciBhIGNvbW1vbiBvUEhZRW50aXR5IChzZWUgRmlndXJlIDMtMyBvbiBwYWdl IDY5MiksIHdoaWNoIGNyZWF0ZXMgYW4gaW1wcmVzc2lvbiB0aGF0IGlmTWF1VHlwZSBpcyBhbiBh dHRyaWJ1dGUgb2YgdGhlIFBIWSAoUENTKSBsYXllci4gVHJhZGl0aW9uYWxseSBNQVUgaXMgYXNz b2NpYXRlZCB3aXRoIFBNQSAoc2VlIGZpZ3VyZSA0LTEgb24gcGFnZSA3MCBvZiA4MDIuMy0yMDAy KSwgd2hpY2ggaXMgYWN0dWFsbHkgYSBwYXJ0IG9mIFBNRSBpbiBFRk1DdSBQSFlzLg0KIA0KU28s IEkgc2VlIDIgbWFpbiBhbHRlcm5hdGl2ZXMgZm9yIEVGTUN1IFBIWXM6DQogDQoxLiBOb3QgdG8g dXNlIE1BVSBNSUIgYXQgYWxsIGFuZCBpbnN0ZWFkIHVzZSBhcHByb3ByaWF0ZSBpZlR5cGUgdmFs dWVzIChzaG91bGQgYmUgZGVmaW5lZCBpbiBJQU5BaWZUeXBlLU1JQikgZm9yIGJvdGggUENTIGFu ZCBQTUUgcG9ydHMuIE5vdGUgYWxzbyB0aGF0IEVGTUN1IHBvcnRzIGRvbid0IHVzZSBNQVUgYXV0 by1uZWdvdGlhdGlvbiwgbWVkaWEgYXZhaWxhYmxlLCBmYWxzZSBjYXJyaWVycyBvciBqYWJiZXIs IHNvIHRoZXJlIHJlYWxseSBubyByZWFzb24gZm9yIHVzaW5nIE1BVS1NSUIgYXBhcnQgZnJvbSB0 aGUgZmFjdCB0aGF0IGFsbCBFdGhlckxpa2UgaW50ZXJmYWNlcyBhcmUgcmVxdWlyZWQgdG8gdXNl IGl0Lg0KIA0KMi4gVXNlIGlmTWF1VHlwZSBmb3IgUE1FcyBvbmx5ICh0aGVvcmV0aWNhbGx5IFBN RXMgY2FuIHN1cHBvcnQgYSBudW1iZXIgb2YgdHlwZXMgc28gaWZNYXVUeXBlTGlzdCBjYW4gYmUg aGFuZHkgaGVyZSkuIFRoZSBQQ1MgaWZUeXBlIHdvdWxkIHN0YXkgZXRoZXJuZXRDc21hY2QgYW5k IHRoZSByZWFsIHR5cGUgd291bGQgYmUgcmV0dXJuZWQgaW4gZWZtQ3VUeXBlIGFuZCBlZm1DdVBv cnRTaWRlLg0KIA0KWW91ciBjb21tZW50cyBhcmUgYXBwcmVjaWF0ZWQuDQogDQpSZWdhcmRzLA0K LUUuDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBodWJtaWItYm91bmNl c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgQy4gTS4gSGVhcmQgDQoJU2VudDogV2VkIDgvNC8yMDA0 IDc6MjUgUE0gDQoJVG86IEh1YiBNaWIgDQoJQ2M6IA0KCVN1YmplY3Q6IFtIdWJtaWJdIElBTkEg TWFpbnRhaW5lZCBUQyBmb3IgTUFVIHR5cGVzDQoJDQoJDQoNCglPbiBUdWUsIDMgQXVnIDIwMDQs IFJvbWFzY2FudSwgRGFuIChEYW4pIHdyb3RlOg0KCT4gVGhlIEV0aGVybmV0IGludGVyZmFjZXMg YW5kIGh1YiBNSUIgV0cgKGh1Ym1pYikgbWV0IGZvciBvbmUNCgk+IHNlc3Npb24gYXQgdGhlIDYw dGggSUVURi4gVGhlIFdHIGRpc2N1c3NlZCB0aGUgbGF0ZXN0IGNoYW5nZXMsDQoJPiBjb21tZW50 cyBhbmQgb3BlbiBpc3N1ZXMgZm9yIHRoZSB0aHJlZSBjaGFydGVyZWQgV0cNCgk+IEludGVybmV0 LURyYWZ0cyByZWxhdGVkIHRvIHRoZSBFdGhlcm5ldCBGaXJzdCBNaWxlIChFRk0pDQoJPiB0ZWNo bm9sb2d5LiAgVGhlIHBhcnRpY2lwYW50cyBpbiB0aGUgbWVldGluZyByZWNvbW1lbmRlZCB0aGF0 DQoJPiB0aGUgTUFVIE1JQiBiZSByZS13cml0dGVuIHRvIHJlZmVyIHRvIGEgSUFOQS1tYWludGFp bmVkIFRleHR1YWwNCgk+IENvbnZlbnRpb24sIHdoaWNoIHdvdWxkIGVhc2UgdGhlIHN1cHBvcnQg Zm9yIG5ldyBNQVVzIGluIHRoZQ0KCT4gZnV0dXJlLCB3aXRob3V0IHJlcXVpcmluZyBvcGVuaW5n IG9mIHRoZSBNQVUgTUlCIGRvY3VtZW50cy4NCgkNCglJJ2QgbGlrZSB0byBtYWtlIGEgZmV3IGNv bW1lbnRzIGFib3V0IHRoaXMgaWRlYS4gIFRoZSBmaXJzdCBwb2ludCBpcw0KCXRoYXQgd2hhdCBu ZWVkcyB0byBiZSBleHRlbmRlZCBpbiB0aGUgTUFVLU1JQiBpcyBub3QganVzdCBhIHNpbmdsZQ0K CUJJVFMgdHlwZSBkZWZpbml0aW9uIGJ1dCByYXRoZXIgYSBCSVRTIHR5cGUgZGVmaW5pdGlvbiB0 aGF0IGlzIGxpbmVkDQoJdXAgd2l0aCBhIG1hdGNoZWQgc2V0IG9mIE9CSkVDVC1JREVOVElUWSBk ZWZpbml0aW9ucy4gIFRoZSBhZmZlY3RlZA0KCWRlZmluaXRpb25zIGluIHRoZSBNQVUtTUlCIGFy ZSB0aGVzZSBPQkpFQ1QtSURFTlRJVFkgZGVmaW5pdGlvbnM6DQoJDQoJICAgICAgIGRvdDNNYXVU eXBlDQoJICAgICAgICAgICBPQkpFQ1QgSURFTlRJRklFUiA6Oj0geyBzbm1wRG90M01hdU1ndCA0 IH0NCgkNCgkgICAgICAgZG90M01hdVR5cGVBVUkgT0JKRUNULUlERU5USVRZDQoJICAgICAgICAg ICBTVEFUVVMgICAgICBjdXJyZW50DQoJICAgICAgICAgICBERVNDUklQVElPTiAibm8gaW50ZXJu YWwgTUFVLCB2aWV3IGZyb20gQVVJIg0KCSAgICAgICAgICAgUkVGRVJFTkNFICAgIltJRUVFIDgw Mi4zIFN0ZC5dLCBTZWN0aW9uIDciDQoJICAgICAgICAgICA6Oj0geyBkb3QzTWF1VHlwZSAxIH0N CgkNCgkgICAgICAgWyAuLi4gXQ0KCQ0KCSAgICAgICBkb3QzTWF1VHlwZTEwR2lnQmFzZVNXIE9C SkVDVC1JREVOVElUWQ0KCSAgICAgICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KCSAgICAgICAg ICAgREVTQ1JJUFRJT04gIlcgZmliZXIgb3ZlciA4NTAgbm0gb3B0aWNzIg0KCSAgICAgICAgICAg UkVGRVJFTkNFICAgIltJRUVFIDgwMi4zIFN0ZC5dLCBTZWN0aW9uIDUyIg0KCSAgICAgICAgICAg Ojo9IHsgZG90M01hdVR5cGUgNDAgfQ0KCQ0KCWFuZCB0aGUgQklUUyB0eXBlIGluIHRoZSBmb2xs b3dpbmcgT0JKRUNULVRZUEUgZGVmaW5pdGlvbjoNCgkNCgkgICAgICAgaWZNYXVUeXBlTGlzdEJp dHMgT0JKRUNULVRZUEUNCgkgICAgICAgICAgIFNZTlRBWCAgICAgIEJJVFMgew0KCSAgICAgICAg ICAgICAgIGJPdGhlcigwKSwgICAgICAgICAtLSBvdGhlciBvciB1bmtub3duDQoJICAgICAgICAg ICAgICAgYkFVSSgxKSwgICAgICAgICAgIC0tIEFVSQ0KCSAgICAgICAgICAgICAgIFsgLi4uIF0N CgkgICAgICAgICAgICAgICBiMTBHYmFzZVNXKDQwKSAgICAgLS0gMTBHQkFTRS1TVw0KCSAgICAg ICAgICAgfQ0KCSAgICAgICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQoJICAgICAgICAgICBT VEFUVVMgICAgICBjdXJyZW50DQoJICAgICAgICAgICBERVNDUklQVElPTiAiQSB2YWx1ZSB0aGF0 IHVuaXF1ZWx5IGlkZW50aWZpZXMgdGhlIHNldCBvZg0KCSAgICAgICAgICAgICAgICAgICAgICAg cG9zc2libGUgSUVFRSA4MDIuMyB0eXBlcyB0aGF0IHRoZSBNQVUgY291bGQgYmUuDQoJICAgICAg ICAgICAgICAgICAgICAgICBJZiBhdXRvLW5lZ290aWF0aW9uIGlzIHByZXNlbnQgb24gdGhpcyBN QVUsIHRoaXMNCgkgICAgICAgICAgICAgICAgICAgICAgIG9iamVjdCB3aWxsIG1hcCB0byBpZk1h dUF1dG9OZWdDYXBhYmlsaXR5Qml0cy4NCgkNCgkgICAgICAgICAgICAgICAgICAgICAgIE5vdGUg dGhhdCB0aGlzIE1BVSBtYXkgYmUgY2FwYWJsZSBvZiBvcGVyYXRpbmcNCgkgICAgICAgICAgICAg ICAgICAgICAgIGFzIGEgTUFVIHR5cGUgdGhhdCBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMN CgkgICAgICAgICAgICAgICAgICAgICAgIE1JQi4gIFRoaXMgaXMgaW5kaWNhdGVkIGJ5IHJldHVy bmluZyB0aGUNCgkgICAgICAgICAgICAgICAgICAgICAgIGJpdCB2YWx1ZSBiT3RoZXIgaW4gYWRk aXRpb24gdG8gYW55IGJpdCB2YWx1ZXMNCgkgICAgICAgICAgICAgICAgICAgICAgIGZvciBjYXBh YmlsaXRpZXMgdGhhdCBhcmUgbGlzdGVkIGFib3ZlLiINCgkgICAgICAgICAgIDo6PSB7IGlmTWF1 RW50cnkgMTMgfQ0KCQ0KCVRoZSBJQU5BLW1haW50YWluZWQgTUlCIG1vZHVsZSB3b3VsZCBuZWVk IHRvIGNvbnRhaW4gdGhlDQoJZG90M01hdVR5cGUqIE9CSkVDVC1JREVOVElUWSBkZWZpbml0aW9u cyBhbG9uZyB3aXRoIGEgVEMgKHdoaWNoDQoJbWlnaHQgYmUgY2FsbGVkIElBTkFpZk1hdVR5cGVM aXN0Qml0cykgdGhhdCB3aG9zZSBTWU5UQVggY2xhdXNlIGlzDQoJd2hhdCBpcyBwcmVzZW50bHkg aW4gaWZNYXVUeXBlTGlzdEJpdHMuICBUaGF0LCBvZiBjb3Vyc2UsIGlzIGJlY2F1c2UNCgl0aGVz ZSBpdGVtcyBoYXZlIHRvIHJlbWFpbiBpbiBzeW5jIGFuZCBzbyBoYXZlIHRvIGJlIG1haW50YWlu ZWQgaW4NCglwYXJhbGxlbC4gIFRoZSBJQU5BLW1haW50YWluZWQgbW9kdWxlIHdvdWxkLCBvZiBj b3Vyc2UsIGltcG9ydCB0aGUNCgliYXNlIE9JRCBkZXNjcmlwdG9yIGRvdDNNYXVUeXBlIGZyb20g dGhlIE1BVS1NSUIuDQoJDQoJT25lIG1pbm9yIGJhY2t3YXJkLWNvbXBhdGliaWxpdHkgaXNzdWUg aXMgdGhhdCBtaWdyYXRpbmcgdGhlDQoJT0JKRUNULUlERU5USVRZIGRlZmluaXRpb25zIGluIHRo aXMgd2F5IGNvdWxkIGNhdXNlIHByb2JsZW1zIGlmIGFueQ0KCWV4aXN0aW5nIE1JQiBtb2R1bGVz IGhhdmUgaW1wb3J0ZWQgdGhvc2UgZGVzY3JpcHRvcnMgZnJvbSBNQVUtTUlCLg0KCVRoaXMgY291 bGQgYmUgYWRkcmVzc2VkIGJ5IGtlZXBpbmcgdGhlIGV4aXN0aW5nIGxpc3Qgb2YgZG90M01hdVR5 cGUqDQoJZGVzY3JpcHRvcnMgaW4gdGhlIE1BVS1NSUIgYXMgb2JqZWN0IGlkZW50aWZpZXIgdmFs dWUgYXNzaWdubWVudHM7DQoJd2hpbGUgUkZDIDI1NzggZG9lcyBub3QgcGVybWl0IHR3byAicmVn aXN0cmF0aW9ucyIgb2YgdGhlIHNhbWUgT0lEDQoJdmFsdWUsIGl0IGRvZXMgYWxsb3cgYSBkZXNj cmlwdG9yIHRvIGJlIGFzc29jaWF0ZWQgd2l0aCBib3RoIGENCglyZWdpc3RyYXRpb24gYW5kIGFu IG9iamVjdCBpZGVudGlmaWVyIHZhbHVlIGFzc2lnbm1lbnQsIHByb3ZpZGluZw0KCWJvdGggYXJl IGFzc29jaWF0ZWQgd2l0aCB0aGUgc2FtZSBPQkpFQ1QgSURFTlRJRklFUiB2YWx1ZSBhbmQNCglz ZW1hbnRpY3MgKGNmLiBTZWN0aW9uIDMuNikuDQoJDQoJQW5vdGhlciBpc3N1ZSB0aGF0IG5lZWRz IHRvIGJlIGFkZHJlc3NlZCBpcyB3aGF0IHJ1bGVzIGFwcGx5IHRvIG5ldw0KCU1BVSB0eXBlcy4g IE15IHRoaW5raW5nIGlzIHRoYXQgdGhpcyBzaG91bGQgYmUgYWxsb3dlZCBPTkxZIGJ5IGENCglT dGFuZGFyZHMgQWN0aW9uIChhcyBkZWZpbmVkIGluIFJGQyAyNDM0KSAtLSBvciBhdCBsZWFzdCBJ RVRGDQoJQ29uc2Vuc3VzIC0tIHNvIHRoYXQgYW55IHByb3NwZWN0aXZlIGFzc2lnbm1lbnRzIGFy ZSBkb2N1bWVudGVkIGluDQoJYW4gUkZDLiAgQW55IGRvY3VtZW50IHRoYXQgcHJvcG9zZXMgc3Vj aCBhbiBhc3NpZ25tZW50IHNob3VsZCBhbHNvDQoJYmUgcmVxdWlyZWQgdG8gbm90ZSBhbnkgc3Bl Y2lhbCBwcm9wZXJ0aWVzIG9mIHRoZSBNQVUgdHlwZXMgdGhhdCBpdA0KCWRlZmluZXMgLS0gZm9y IGV4YW1wbGUsIHNpZGUgZWZmZWN0cyBvbiB0aGUgaWZTdGFja1RhYmxlIHN1Y2ggYXMgYXJlDQoJ bm90ZWQgaW4gUkZDIDM2MzYgU2VjdGlvbiAzLjQuMSBmb3IgMTBHQkFTRS1XIE1BVXMuDQoJDQoJ QWxzbyB0byBiZSBub3RlZCBpcyB0aGF0IHRoZSBNQVUtTUlCIGl0c2VsZiB3aWxsIG5lZWQgc29t ZSBtaW5vcg0KCW1vZGlmaWNhdGlvbnMgYmV5b25kIHRob3NlIGRpc2N1c3NlZCBhYm92ZSwgc3Vj aCBhcyB0aGUgREVTQ1JJUFRJT04NCgljbGF1c2VzIGZvciBycE1hdVR5cGUgYW5kIGlmTWF1VHlw ZS4gICBBIGdvb2QgZWRpdG9yIGlzIG5lZWRlZCB0bw0KCWZlcnJldCBhbGwgdGhvc2UgdGhpbmdz IG91dC4NCgkNCglPbmUgZmluYWwgcG9pbnQ6ICBpbiBoaXMgcmVwbHkgdG8gRGFuIFJvbWFzY2Fu dSdzIGNvbW1lbnRzIG9uDQoJZHJhZnQtaWV0Zi1odWJtaWItZWZtLWVwb24tbWliLTAxLnR4dCwg TGlvciBLaGVybW9zaCBzYWlkOg0KCQ0KCT4gU29ycnkgZm9yIGJlaW5nIG5vdCBjbGVhciBidXQg bXkgaW50ZW50aW9uIGlzIHRoYXQgTUFVIHR5cGUNCgk+IG9iamVjdHMgaW4gdGhlIE1BVSBzZWN0 aW9uIHNob3VsZCBiZSBhZGRlZCB0byB0aGUgTUFVTUlCcyBhcw0KCT4gd2l0aCB0aGUgZWZtLWN1 IGRvY3VtZW50LiBJZiBpdCBpcyBub3QgZG9uZSB0aGVyZSB0aGVuIHRoZSBNQVUNCgk+IHNlY3Rp b24gaW4gdGhlIGVmbS1lcG9uIG1pYiBzaG91bGQgY29udGFpbiB0aGVtIChhcyBub3cpLg0KCQ0K CU15IHBvc2l0aW9uIHdvdWxkIGJlIHRoYXQgd2UgTVVTVCBtb2RpZnkgdGhlIE1BVS1NSUIgLS0g ZWl0aGVyDQoJZGlyZWN0bHkgb3IgYnkgcHV0dGluZyB0aGUgTUFVIHR5cGVzIGludG8gYW4gSUFO QS1tYWludGFpbmVkIG1vZHVsZQ0KCS0tIHRvIGNvbnRhaW4gdGhlIG5ldyBNQVUgdHlwZSBkZWZp bml0aW9ucy4gIEl0IGludml0ZXMgY2F0YXN0cm9waGUNCgkoaS5lLiwgY29uZmxpY3RpbmcgT0lE L2JpdCBwb3NpdGlvbiBhc3NpZ25tZW50cykgaWYgdGhlIHZhbHVlcw0KCWFzc2lnbmVkIHRvIE1B VSB0eXBlcyBhcmUgc2NhdHRlcmVkIG92ZXIgc2V2ZXJhbCBkb2N1bWVudHMuICBJIGRvDQoJYWdy ZWUgdGhhdCBpdCBpcyBPSyB0byBzcGxpdCBvZmYgTUFVLXNwZWNpZmljIHN0YXRzIGNvdW50ZXJz IGFuZCBzbw0KCW9uIGFuZCBwdXQgdGhvc2UgaW4gYSBzZXBhcmF0ZSBtb2R1bGU7ICBpbiBmYWN0 IHRoZXJlIGlzIG5vDQoJcHJhY3RpY2FsIGFsdGVybmF0aXZlIHRvIGRvaW5nIHNvIGlmIHdlIGRv bid0IHdhbnQgdG8gY2hhbmdlIHRoZQ0KCU1BVS1NSUIgZXZlcnkgdGltZSB3ZSBhZGQgYW4gTUFV IHR5cGUgdGhhdCByZXF1aXJlcyBzdWNoIHRoaW5ncy4NCgkNCglSZWdhcmRzLA0KCQ0KCU1pa2Ug SGVhcmQNCgkNCgkNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KCUh1Ym1pYiBtYWlsaW5nIGxpc3QNCglIdWJtaWJAaWV0Zi5vcmcNCglodHRwczovL3d3 dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9odWJtaWINCgkNCg0K ------_=_NextPart_001_01C47A4F.5B15D584 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjY1NTYuMCI+CjxUSVRMRT5bSHVibWliXSBJQU5BIE1h aW50YWluZWQgVEMgZm9yIE1BVSB0eXBlczwvVElUTEU+CjwvSEVBRD4KPEJPRFkgZGlyPWx0cj4K PERJVj5NaWtlLDwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPkl0IGxvb2tzIGxpa2UgeW91 J3ZlIGFscmVhZHkgdGhvdWdodCBhYm91dCBpdC4gV291bGQgeW91IGxpa2UgdG8gZG8gdGhlIApl ZGl0aW5nIG9mIHRoZSBNQVUgTUlCPzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPldoaWxl IHdlIGFyZSBvbiB0aGUgc3ViamVjdCBvZiBNQVUgTUlCIEkgd291bGQgbGlrZSB0byBzaGFyZSBh IGxpdHRsZSAKcHJvYmxlbSBJJ20gaGF2aW5nIGluIEVGTS1DVS1NSUI6PC9ESVY+CjxESVY+QXMg b2YgdG9kYXkgdGhlIElFRUUgUDgwMi4zYWYvRDMuMyBzcGVjaWZpZXMgb01BVSBiZWluZyBhIHNp Ymxpbmcgb2YgdGhlIApvUEFGIHVuZGVyIGEgY29tbW9uIG9QSFlFbnRpdHkgKHNlZSBGaWd1cmUg My0zIG9uIHBhZ2UgNjkyKSwgd2hpY2ggY3JlYXRlcyBhbiAKaW1wcmVzc2lvbiB0aGF0IGlmTWF1 VHlwZSBpcyBhbiBhdHRyaWJ1dGUgb2YgdGhlIFBIWSAoUENTKSBsYXllci4gVHJhZGl0aW9uYWxs eSAKTUFVIGlzIGFzc29jaWF0ZWQgd2l0aCBQTUEgKHNlZSBmaWd1cmUgNC0xIG9uIHBhZ2UgNzAg b2YgODAyLjMtMjAwMiksIHdoaWNoIGlzIAphY3R1YWxseSBhIHBhcnQgb2YgUE1FIGluIEVGTUN1 IFBIWXMuPC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+U28sIEkgc2VlIDIgbWFpbiBhbHRl cm5hdGl2ZXMgZm9yIEVGTUN1IFBIWXM6PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+MS4g Tm90IHRvIHVzZSBNQVUgTUlCIGF0IGFsbCBhbmQgaW5zdGVhZCB1c2UgYXBwcm9wcmlhdGUgaWZU eXBlIHZhbHVlcyAKKHNob3VsZCBiZSBkZWZpbmVkIGluIElBTkFpZlR5cGUtTUlCKSBmb3IgYm90 aCBQQ1MgYW5kIFBNRSBwb3J0cy4gTm90ZSBhbHNvIHRoYXQgCkVGTUN1IHBvcnRzIGRvbid0IHVz ZSBNQVUgYXV0by1uZWdvdGlhdGlvbiwgbWVkaWEgYXZhaWxhYmxlLCBmYWxzZSBjYXJyaWVycyBv ciAKamFiYmVyLCBzbyB0aGVyZSByZWFsbHkgbm8mbmJzcDtyZWFzb24gZm9yIHVzaW5nIE1BVS1N SUImbmJzcDthcGFydCBmcm9tIHRoZSAKZmFjdCB0aGF0IGFsbCBFdGhlckxpa2UgaW50ZXJmYWNl cyBhcmUgcmVxdWlyZWQgdG8gdXNlIGl0LjwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPjIu IFVzZSBpZk1hdVR5cGUgZm9yIFBNRXMgb25seSAodGhlb3JldGljYWxseSBQTUVzIGNhbiBzdXBw b3J0IGEgbnVtYmVyIG9mIAp0eXBlcyBzbyBpZk1hdVR5cGVMaXN0IGNhbiBiZSBoYW5keSBoZXJl KS4gVGhlIFBDUyBpZlR5cGUgd291bGQgc3RheSAKZXRoZXJuZXRDc21hY2QgYW5kIHRoZSByZWFs IHR5cGUgd291bGQgYmUgcmV0dXJuZWQgaW4gZWZtQ3VUeXBlIGFuZCAKZWZtQ3VQb3J0U2lkZS48 L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5Zb3VyIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRl ZC48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5SZWdhcmRzLDwvRElWPgo8RElWPi1FLjwv RElWPgo8QkxPQ0tRVU9URSBkaXI9bHRyIHN0eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+CiAgPERJ Vj48Rk9OVCBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gPEJSPjxCPkZyb206PC9C PiAKICBodWJtaWItYm91bmNlc0BpZXRmLm9yZyZuYnNwO29uIGJlaGFsZiBvZiZuYnNwO0MuIE0u IEhlYXJkIDxCUj48Qj5TZW50OjwvQj4gCiAgV2VkIDgvNC8yMDA0IDc6MjUgUE0gPEJSPjxCPlRv OjwvQj4gSHViIE1pYiA8QlI+PEI+Q2M6PC9CPiA8QlI+PEI+U3ViamVjdDo8L0I+IAogIFtIdWJt aWJdIElBTkEgTWFpbnRhaW5lZCBUQyBmb3IgTUFVIHR5cGVzPEJSPjxCUj48L0ZPTlQ+PC9ESVY+ CiAgPFA+PEZPTlQgc2l6ZT0yPk9uIFR1ZSwgMyBBdWcgMjAwNCwgUm9tYXNjYW51LCBEYW4gKERh bikgd3JvdGU6PEJSPiZndDsgVGhlIAogIEV0aGVybmV0IGludGVyZmFjZXMgYW5kIGh1YiBNSUIg V0cgKGh1Ym1pYikgbWV0IGZvciBvbmU8QlI+Jmd0OyBzZXNzaW9uIGF0IHRoZSAKICA2MHRoIElF VEYuIFRoZSBXRyBkaXNjdXNzZWQgdGhlIGxhdGVzdCBjaGFuZ2VzLDxCUj4mZ3Q7IGNvbW1lbnRz IGFuZCBvcGVuIAogIGlzc3VlcyBmb3IgdGhlIHRocmVlIGNoYXJ0ZXJlZCBXRzxCUj4mZ3Q7IElu dGVybmV0LURyYWZ0cyByZWxhdGVkIHRvIHRoZSAKICBFdGhlcm5ldCBGaXJzdCBNaWxlIChFRk0p PEJSPiZndDsgdGVjaG5vbG9neS4mbmJzcDsgVGhlIHBhcnRpY2lwYW50cyBpbiB0aGUgCiAgbWVl dGluZyByZWNvbW1lbmRlZCB0aGF0PEJSPiZndDsgdGhlIE1BVSBNSUIgYmUgcmUtd3JpdHRlbiB0 byByZWZlciB0byBhIAogIElBTkEtbWFpbnRhaW5lZCBUZXh0dWFsPEJSPiZndDsgQ29udmVudGlv biwgd2hpY2ggd291bGQgZWFzZSB0aGUgc3VwcG9ydCBmb3IgCiAgbmV3IE1BVXMgaW4gdGhlPEJS PiZndDsgZnV0dXJlLCB3aXRob3V0IHJlcXVpcmluZyBvcGVuaW5nIG9mIHRoZSBNQVUgTUlCIAog IGRvY3VtZW50cy48QlI+PEJSPkknZCBsaWtlIHRvIG1ha2UgYSBmZXcgY29tbWVudHMgYWJvdXQg dGhpcyBpZGVhLiZuYnNwOyBUaGUgCiAgZmlyc3QgcG9pbnQgaXM8QlI+dGhhdCB3aGF0IG5lZWRz IHRvIGJlIGV4dGVuZGVkIGluIHRoZSBNQVUtTUlCIGlzIG5vdCBqdXN0IGEgCiAgc2luZ2xlPEJS PkJJVFMgdHlwZSBkZWZpbml0aW9uIGJ1dCByYXRoZXIgYSBCSVRTIHR5cGUgZGVmaW5pdGlvbiB0 aGF0IGlzIAogIGxpbmVkPEJSPnVwIHdpdGggYSBtYXRjaGVkIHNldCBvZiBPQkpFQ1QtSURFTlRJ VFkgZGVmaW5pdGlvbnMuJm5ic3A7IFRoZSAKICBhZmZlY3RlZDxCUj5kZWZpbml0aW9ucyBpbiB0 aGUgTUFVLU1JQiBhcmUgdGhlc2UgT0JKRUNULUlERU5USVRZIAogIGRlZmluaXRpb25zOjxCUj48 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIGRvdDNNYXVUeXBlPEJS PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAKICBPQkpFQ1QgSURFTlRJRklFUiA6Oj0geyBzbm1wRG90M01hdU1ndCA0IAogIH08QlI+ PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkb3QzTWF1VHlwZUFVSSAK ICBPQkpFQ1QtSURFTlRJVFk8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIFNUQVRVUyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAKICBjdXJyZW50PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICBERVNDUklQVElPTiAibm8gaW50ZXJuYWwgTUFV LCB2aWV3IGZyb20gCiAgQVVJIjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgUkVGRVJFTkNFJm5ic3A7Jm5ic3A7ICJbSUVF RSA4MDIuMyBTdGQuXSwgU2VjdGlvbiAKICA3IjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOjo9IHsgCiAgZG90M01hdVR5cGUg MSB9PEJSPjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWyAuLi4gCiAg XTxCUj48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRvdDNNYXVUeXBl MTBHaWdCYXNlU1cgCiAgT0JKRUNULUlERU5USVRZPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICBTVEFUVVMmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgY3VycmVudDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgREVTQ1JJUFRJT04gIlcg ZmliZXIgb3ZlciA4NTAgbm0gCiAgb3B0aWNzIjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgUkVGRVJFTkNFJm5ic3A7Jm5i c3A7ICJbSUVFRSA4MDIuMyBTdGQuXSwgU2VjdGlvbiAKICA1MiI8QlI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDo6PSB7IAogIGRv dDNNYXVUeXBlIDQwIH08QlI+PEJSPmFuZCB0aGUgQklUUyB0eXBlIGluIHRoZSBmb2xsb3dpbmcg T0JKRUNULVRZUEUgCiAgZGVmaW5pdGlvbjo8QlI+PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBpZk1hdVR5cGVMaXN0Qml0cyAKICBPQkpFQ1QtVFlQRTxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAg U1lOVEFYJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJJVFMgCiAgezxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgYk90aGVyKDApLCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBvdGhlciBvciAKICB1bmtub3duPEJSPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICBiQVVJKDEpLCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSAKICBBVUk8QlI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIFsgLi4uIAogIF08QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IAogIGIxMEdiYXNlU1coNDApJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIAog IDEwR0JBU0UtU1c8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIH08QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIE1BWC1BQ0NFU1MmbmJzcDsgCiAgcmVh ZC1vbmx5PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAKICBTVEFUVVMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAg Y3VycmVudDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgCiAgREVTQ1JJUFRJT04gIkEgdmFsdWUgdGhhdCB1bmlxdWVseSBpZGVu dGlmaWVzIHRoZSBzZXQgCiAgb2Y8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIHBvc3NpYmxlIElF RUUgODAyLjMgdHlwZXMgdGhhdCB0aGUgTUFVIGNvdWxkIAogIGJlLjxCUj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgCiAgSWYgYXV0by1uZWdvdGlhdGlvbiBpcyBwcmVzZW50IG9uIHRoaXMgTUFVLCAKICB0 aGlzPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICBvYmplY3Qgd2lsbCBtYXAgdG8gCiAgaWZNYXVB dXRvTmVnQ2FwYWJpbGl0eUJpdHMuPEJSPjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgTm90ZSB0 aGF0IHRoaXMgTUFVIG1heSBiZSBjYXBhYmxlIG9mIAogIG9wZXJhdGluZzxCUj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgCiAgYXMgYSBNQVUgdHlwZSB0aGF0IGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgCiAg dGhpczxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgTUlCLiZuYnNwOyBUaGlzIGlzIGluZGljYXRl ZCBieSByZXR1cm5pbmcgCiAgdGhlPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICBiaXQgdmFsdWUg Yk90aGVyIGluIGFkZGl0aW9uIHRvIGFueSBiaXQgCiAgdmFsdWVzPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAKICBmb3IgY2FwYWJpbGl0aWVzIHRoYXQgYXJlIGxpc3RlZCAKICBhYm92ZS4iPEJSPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA6Oj0geyAKICBpZk1hdUVudHJ5IDEzIH08QlI+PEJSPlRoZSBJQU5BLW1haW50YWluZWQgTUlC IG1vZHVsZSB3b3VsZCBuZWVkIHRvIGNvbnRhaW4gCiAgdGhlPEJSPmRvdDNNYXVUeXBlKiBPQkpF Q1QtSURFTlRJVFkgZGVmaW5pdGlvbnMgYWxvbmcgd2l0aCBhIFRDIAogICh3aGljaDxCUj5taWdo dCBiZSBjYWxsZWQgSUFOQWlmTWF1VHlwZUxpc3RCaXRzKSB0aGF0IHdob3NlIFNZTlRBWCBjbGF1 c2UgCiAgaXM8QlI+d2hhdCBpcyBwcmVzZW50bHkgaW4gaWZNYXVUeXBlTGlzdEJpdHMuJm5ic3A7 IFRoYXQsIG9mIGNvdXJzZSwgaXMgCiAgYmVjYXVzZTxCUj50aGVzZSBpdGVtcyBoYXZlIHRvIHJl bWFpbiBpbiBzeW5jIGFuZCBzbyBoYXZlIHRvIGJlIG1haW50YWluZWQgCiAgaW48QlI+cGFyYWxs ZWwuJm5ic3A7IFRoZSBJQU5BLW1haW50YWluZWQgbW9kdWxlIHdvdWxkLCBvZiBjb3Vyc2UsIGlt cG9ydCAKICB0aGU8QlI+YmFzZSBPSUQgZGVzY3JpcHRvciBkb3QzTWF1VHlwZSBmcm9tIHRoZSBN QVUtTUlCLjxCUj48QlI+T25lIG1pbm9yIAogIGJhY2t3YXJkLWNvbXBhdGliaWxpdHkgaXNzdWUg aXMgdGhhdCBtaWdyYXRpbmcgdGhlPEJSPk9CSkVDVC1JREVOVElUWSAKICBkZWZpbml0aW9ucyBp biB0aGlzIHdheSBjb3VsZCBjYXVzZSBwcm9ibGVtcyBpZiBhbnk8QlI+ZXhpc3RpbmcgTUlCIG1v ZHVsZXMgCiAgaGF2ZSBpbXBvcnRlZCB0aG9zZSBkZXNjcmlwdG9ycyBmcm9tIE1BVS1NSUIuPEJS PlRoaXMgY291bGQgYmUgYWRkcmVzc2VkIGJ5IAogIGtlZXBpbmcgdGhlIGV4aXN0aW5nIGxpc3Qg b2YgZG90M01hdVR5cGUqPEJSPmRlc2NyaXB0b3JzIGluIHRoZSBNQVUtTUlCIGFzIAogIG9iamVj dCBpZGVudGlmaWVyIHZhbHVlIGFzc2lnbm1lbnRzOzxCUj53aGlsZSBSRkMgMjU3OCBkb2VzIG5v dCBwZXJtaXQgdHdvIAogICJyZWdpc3RyYXRpb25zIiBvZiB0aGUgc2FtZSBPSUQ8QlI+dmFsdWUs IGl0IGRvZXMgYWxsb3cgYSBkZXNjcmlwdG9yIHRvIGJlIAogIGFzc29jaWF0ZWQgd2l0aCBib3Ro IGE8QlI+cmVnaXN0cmF0aW9uIGFuZCBhbiBvYmplY3QgaWRlbnRpZmllciB2YWx1ZSAKICBhc3Np Z25tZW50LCBwcm92aWRpbmc8QlI+Ym90aCBhcmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBzYW1lIE9C SkVDVCBJREVOVElGSUVSIAogIHZhbHVlIGFuZDxCUj5zZW1hbnRpY3MgKGNmLiBTZWN0aW9uIDMu NikuPEJSPjxCUj5Bbm90aGVyIGlzc3VlIHRoYXQgbmVlZHMgdG8gCiAgYmUgYWRkcmVzc2VkIGlz IHdoYXQgcnVsZXMgYXBwbHkgdG8gbmV3PEJSPk1BVSB0eXBlcy4mbmJzcDsgTXkgdGhpbmtpbmcg aXMgCiAgdGhhdCB0aGlzIHNob3VsZCBiZSBhbGxvd2VkIE9OTFkgYnkgYTxCUj5TdGFuZGFyZHMg QWN0aW9uIChhcyBkZWZpbmVkIGluIFJGQyAKICAyNDM0KSAtLSBvciBhdCBsZWFzdCBJRVRGPEJS PkNvbnNlbnN1cyAtLSBzbyB0aGF0IGFueSBwcm9zcGVjdGl2ZSBhc3NpZ25tZW50cyAKICBhcmUg ZG9jdW1lbnRlZCBpbjxCUj5hbiBSRkMuJm5ic3A7IEFueSBkb2N1bWVudCB0aGF0IHByb3Bvc2Vz IHN1Y2ggYW4gCiAgYXNzaWdubWVudCBzaG91bGQgYWxzbzxCUj5iZSByZXF1aXJlZCB0byBub3Rl IGFueSBzcGVjaWFsIHByb3BlcnRpZXMgb2YgdGhlIAogIE1BVSB0eXBlcyB0aGF0IGl0PEJSPmRl ZmluZXMgLS0gZm9yIGV4YW1wbGUsIHNpZGUgZWZmZWN0cyBvbiB0aGUgaWZTdGFja1RhYmxlIAog IHN1Y2ggYXMgYXJlPEJSPm5vdGVkIGluIFJGQyAzNjM2IFNlY3Rpb24gMy40LjEgZm9yIDEwR0JB U0UtVyBNQVVzLjxCUj48QlI+QWxzbyAKICB0byBiZSBub3RlZCBpcyB0aGF0IHRoZSBNQVUtTUlC IGl0c2VsZiB3aWxsIG5lZWQgc29tZSBtaW5vcjxCUj5tb2RpZmljYXRpb25zIAogIGJleW9uZCB0 aG9zZSBkaXNjdXNzZWQgYWJvdmUsIHN1Y2ggYXMgdGhlIERFU0NSSVBUSU9OPEJSPmNsYXVzZXMg Zm9yIHJwTWF1VHlwZSAKICBhbmQgaWZNYXVUeXBlLiZuYnNwOyZuYnNwOyBBIGdvb2QgZWRpdG9y IGlzIG5lZWRlZCB0bzxCUj5mZXJyZXQgYWxsIHRob3NlIAogIHRoaW5ncyBvdXQuPEJSPjxCUj5P bmUgZmluYWwgcG9pbnQ6Jm5ic3A7IGluIGhpcyByZXBseSB0byBEYW4gUm9tYXNjYW51J3MgCiAg Y29tbWVudHMgb248QlI+ZHJhZnQtaWV0Zi1odWJtaWItZWZtLWVwb24tbWliLTAxLnR4dCwgTGlv ciBLaGVybW9zaCAKICBzYWlkOjxCUj48QlI+Jmd0OyBTb3JyeSBmb3IgYmVpbmcgbm90IGNsZWFy IGJ1dCBteSBpbnRlbnRpb24gaXMgdGhhdCBNQVUgCiAgdHlwZTxCUj4mZ3Q7IG9iamVjdHMgaW4g dGhlIE1BVSBzZWN0aW9uIHNob3VsZCBiZSBhZGRlZCB0byB0aGUgTUFVTUlCcyAKICBhczxCUj4m Z3Q7IHdpdGggdGhlIGVmbS1jdSBkb2N1bWVudC4gSWYgaXQgaXMgbm90IGRvbmUgdGhlcmUgdGhl biB0aGUgCiAgTUFVPEJSPiZndDsgc2VjdGlvbiBpbiB0aGUgZWZtLWVwb24gbWliIHNob3VsZCBj b250YWluIHRoZW0gKGFzIAogIG5vdykuPEJSPjxCUj5NeSBwb3NpdGlvbiB3b3VsZCBiZSB0aGF0 IHdlIE1VU1QgbW9kaWZ5IHRoZSBNQVUtTUlCIC0tIAogIGVpdGhlcjxCUj5kaXJlY3RseSBvciBi eSBwdXR0aW5nIHRoZSBNQVUgdHlwZXMgaW50byBhbiBJQU5BLW1haW50YWluZWQgCiAgbW9kdWxl PEJSPi0tIHRvIGNvbnRhaW4gdGhlIG5ldyBNQVUgdHlwZSBkZWZpbml0aW9ucy4mbmJzcDsgSXQg aW52aXRlcyAKICBjYXRhc3Ryb3BoZTxCUj4oaS5lLiwgY29uZmxpY3RpbmcgT0lEL2JpdCBwb3Np dGlvbiBhc3NpZ25tZW50cykgaWYgdGhlIAogIHZhbHVlczxCUj5hc3NpZ25lZCB0byBNQVUgdHlw ZXMgYXJlIHNjYXR0ZXJlZCBvdmVyIHNldmVyYWwgZG9jdW1lbnRzLiZuYnNwOyBJIAogIGRvPEJS PmFncmVlIHRoYXQgaXQgaXMgT0sgdG8gc3BsaXQgb2ZmIE1BVS1zcGVjaWZpYyBzdGF0cyBjb3Vu dGVycyBhbmQgCiAgc288QlI+b24gYW5kIHB1dCB0aG9zZSBpbiBhIHNlcGFyYXRlIG1vZHVsZTsm bmJzcDsgaW4gZmFjdCB0aGVyZSBpcyAKICBubzxCUj5wcmFjdGljYWwgYWx0ZXJuYXRpdmUgdG8g ZG9pbmcgc28gaWYgd2UgZG9uJ3Qgd2FudCB0byBjaGFuZ2UgCiAgdGhlPEJSPk1BVS1NSUIgZXZl cnkgdGltZSB3ZSBhZGQgYW4gTUFVIHR5cGUgdGhhdCByZXF1aXJlcyBzdWNoIAogIHRoaW5ncy48 QlI+PEJSPlJlZ2FyZHMsPEJSPjxCUj5NaWtlIAogIEhlYXJkPEJSPjxCUj48QlI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+SHVibWliIAogIG1haWxp bmcgbGlzdDxCUj5IdWJtaWJAaWV0Zi5vcmc8QlI+PEEgCiAgaHJlZj0iaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaHVibWliIj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9odWJtaWI8L0E+PEJSPjwvRk9OVD48L1A+PC9CTE9DS1FVT1RFPgoKPC9C T0RZPgo8L0hUTUw+ ------_=_NextPart_001_01C47A4F.5B15D584-- --===============0487430227== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============0487430227==-- From hubmib-bounces@ietf.org Thu Aug 12 10:14:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03980 for ; Thu, 12 Aug 2004 10:14:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvG6S-0004i8-9r; Thu, 12 Aug 2004 09:58:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvG2b-0003qB-RB for hubmib@megatron.ietf.org; Thu, 12 Aug 2004 09:54:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02312 for ; Thu, 12 Aug 2004 09:54:48 -0400 (EDT) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvG7Y-0004NU-Mj for hubmib@ietf.org; Thu, 12 Aug 2004 09:59:58 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i7CDlv9N025001 for ; Thu, 12 Aug 2004 08:47:57 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i7CDlq9N024912 for ; Thu, 12 Aug 2004 08:47:53 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C48073.E626E8B4" Subject: FW: [Hubmib] WG Last Call Date: Thu, 12 Aug 2004 16:54:34 +0300 Message-ID: Thread-Topic: WG Last Call Thread-Index: AcRt09BCFQpE3GhdR1CZ7VXOuDJXyQSn8uCw From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 3.6 (+++) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C48073.E626E8B4 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C48073.E626E8B4" ------_=_NextPart_002_01C48073.E626E8B4 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable There is one more week until the WG Last Call completes. We received too = few comments to my taste. Please read the documents, and send your = comments to the WG list hubmib@ietf.org, if you want this work to be = completed at the appropriate quality level. Even comments like - 'I do = not really have time to review the MIB modules in detail, but the = technical approach seems OK from an EFM and Ethernet management = perspective' are welcome. Of course, if you think that something is = broken, you should make a more explicit argument. =20 Thanks and Regards, Dan -----Original Message----- From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org]On Behalf = Of Romascanu, Dan (Dan) Sent: 20 July, 2004 12:03 AM To: hubmib@ietf.org Subject: [Hubmib] WG Last Call My previous message contained an erroneous reference. Please disregard = it, and replace it with this one. This is an Ethernet Interfaces and Hub MIB WG Last Call for the EFM MIB = Internet-Drafts. The documents can be found at:=20 * = http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-m= ib-01.txt * = http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-e= pon-mib-01.txt * = http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-c= u-mib-01.txt All comments must be sent to the WG e-mail list hubmib@ietf.org, until = Wednesday August 18, 2004. Although a 30 days Last Call period is being granted, it is strongly = suggested to the WG participants to submit their comments before the = face to face WG meeting, which will be hold on Monday, August 2nd - so = that their inputs can be discussed during the meeting in San Diego. Regards, Dan ------_=_NextPart_002_01C48073.E626E8B4 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable WG Last Call
There is one more week until the WG Last Call = completes. We received too few comments to my taste. Please read the = documents,=20 and send your comments to the WG list hubmib@ietf.org, if you want this = work to be=20 completed at the appropriate quality level. Even comments = like - 'I do=20 not really have time to review the MIB modules in detail, but the = technical=20 approach seems OK from an EFM and Ethernet management perspective' are = welcome.=20 Of course, if you think that something is broken, you should make a more = explicit = argument.
 

Thanks and=20 Regards,

Dan

-----Original Message-----
From: = hubmib-bounces@ietf.org=20 [mailto:hubmib-bounces@ietf.org]On Behalf Of Romascanu, Dan=20 (Dan)
Sent: 20 July, 2004 12:03 AM
To:=20 hubmib@ietf.org
Subject: [Hubmib] WG Last = Call

My previous = message=20 contained an erroneous reference. Please disregard it, and replace it = with this=20 one.

This is an = Ethernet=20 Interfaces and Hub MIB WG Last Call for the EFM MIB Internet-Drafts. The = documents can be found at:

  • http://www.ietf.cnri.reston.va.us/internet-drafts/draf= t-ietf-hubmib-efm-mib-01.txt
  • http://www.ietf.cnri.reston.va.us/internet-drafts= /draft-ietf-hubmib-efm-epon-mib-01.txt
  • http://www.ietf.cnri.reston.va.us/internet-drafts/d= raft-ietf-hubmib-efm-cu-mib-01.txt

All comments = must be sent to=20 the WG e-mail list hubmib@ietf.org, until Wednesday August 18,=20 2004.

Although a = 30 days Last Call=20 period is being granted, it is strongly suggested to the WG participants = to=20 submit their comments before the face to face WG meeting, which will be = hold on=20 Monday, August 2nd - so that their inputs can be discussed during the = meeting in=20 San Diego.


Regards,

Dan

------_=_NextPart_002_01C48073.E626E8B4-- ------_=_NextPart_001_01C48073.E626E8B4 Content-Type: text/plain; name="ATT109898.txt" Content-Transfer-Encoding: base64 Content-Description: ATT109898.txt Content-Disposition: inline; filename="ATT109898.txt" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkh1Ym1pYiBt YWlsaW5nIGxpc3QNCkh1Ym1pYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaHVibWliDQo= ------_=_NextPart_001_01C48073.E626E8B4 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib ------_=_NextPart_001_01C48073.E626E8B4-- From hubmib-bounces@ietf.org Thu Aug 12 13:03:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15622 for ; Thu, 12 Aug 2004 13:03:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvIhR-0005sU-A7; Thu, 12 Aug 2004 12:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvIUY-0002mA-4R for hubmib@megatron.ietf.org; Thu, 12 Aug 2004 12:31:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13038 for ; Thu, 12 Aug 2004 12:31:47 -0400 (EDT) Received: from [213.70.90.131] (helo=mail.advaoptical.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvIZT-0007Jj-8L for hubmib@ietf.org; Thu, 12 Aug 2004 12:37:00 -0400 Received: from muc-srv-exch3.advaoptical.com (unverified) by mail.advaoptical.de (Content Technologies SMTPRS 4.3.1) with ESMTP id for ; Thu, 12 Aug 2004 18:31:30 +0200 Received: by muc-srv-exch3.advaoptical.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Aug 2004 18:31:34 +0200 Message-ID: <149127BC7EEE5A48B1F550A57086C1EB0457FB@yrk-srv-mail.yrk.advaoptical.com> From: John Messenger To: hubmib@ietf.org Subject: RE: [Hubmib] WG Last Call Date: Thu, 12 Aug 2004 18:30:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message X-Spam-Score: 1.2 (+) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1572520870==" Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1572520870== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48089.C065FA00" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C48089.C065FA00 Content-Type: text/plain; charset="windows-1255" Hi, I have not reviewed the EPON or CU MIBs, but we have reviewed and implemented the EFM MIB. We agreed with one issue that has already been raised: as creation is automatic we couldn't see the need for the rowStatus object. Why is there no trap on receipt of OAMPDUs with the special EFM alarm bits set in the flags field? Assuming one was reflecting the status of a remote system in a local system's MIB, I can see some value sending such a trap. In principle, if there were suitable traps defined in other MIBs, I think those should be used. For the "link fault" event, I can imagine using a trap in IF-MIB for example, but for a "dying gasp" or "critical" event, there doesn't seem to be a suitable trap elsewhere. Arguably, the general-purpose "critical" event is too generic to be useful, but there's real information in "dying gasp" that hasn't been available from remote Ethernet devices before. We have chosen to include such events in traps defined in an enterprise-specific MIB. Best regards, -- John -----Original Message----- From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org]On Behalf Of Romascanu, Dan (Dan) Sent: 12 August 2004 14:55 To: hubmib@ietf.org Subject: FW: [Hubmib] WG Last Call There is one more week until the WG Last Call completes. We received too few comments to my taste. Please read the documents, and send your comments to the WG list hubmib@ietf.org , if you want this work to be completed at the appropriate quality level. Even comments like - 'I do not really have time to review the MIB modules in detail, but the technical approach seems OK from an EFM and Ethernet management perspective' are welcome. Of course, if you think that something is broken, you should make a more explicit argument. Thanks and Regards, Dan -----Original Message----- From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org]On Behalf Of Romascanu, Dan (Dan) Sent: 20 July, 2004 12:03 AM To: hubmib@ietf.org Subject: [Hubmib] WG Last Call My previous message contained an erroneous reference. Please disregard it, and replace it with this one. This is an Ethernet Interfaces and Hub MIB WG Last Call for the EFM MIB Internet-Drafts. The documents can be found at: * http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-mib- 01.txt * http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-epon -mib-01.txt * http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-cu-m ib-01.txt All comments must be sent to the WG e-mail list hubmib@ietf.org, until Wednesday August 18, 2004. Although a 30 days Last Call period is being granted, it is strongly suggested to the WG participants to submit their comments before the face to face WG meeting, which will be hold on Monday, August 2nd - so that their inputs can be discussed during the meeting in San Diego. Regards, Dan ------_=_NextPart_001_01C48089.C065FA00 Content-Type: text/html; charset="windows-1255" WG Last Call
Hi,
 
I have not reviewed the EPON or CU MIBs, but we have reviewed and implemented the EFM MIB.  We agreed with one issue that has already been raised:  as creation is automatic we couldn't see the need for the rowStatus object.
 
Why is there no trap on receipt of OAMPDUs with the special EFM alarm bits set in the flags field?  Assuming one was reflecting the status of a remote system in a local system's MIB, I can see some value sending such a trap.  In principle, if there were suitable traps defined in other MIBs, I think those should be used.  For the "link fault" event, I can imagine using a trap in IF-MIB for example, but for a "dying gasp" or "critical" event, there doesn't seem to be a suitable trap elsewhere.  Arguably, the general-purpose "critical" event is too generic to be useful, but there's real information in "dying gasp" that hasn't been available from remote Ethernet devices before.  We have chosen to include such events in traps defined in an enterprise-specific MIB.
 
Best regards,
    -- John
 
-----Original Message-----
From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org]On Behalf Of Romascanu, Dan (Dan)
Sent: 12 August 2004 14:55
To: hubmib@ietf.org
Subject: FW: [Hubmib] WG Last Call

There is one more week until the WG Last Call completes. We received too few comments to my taste. Please read the documents, and send your comments to the WG list hubmib@ietf.org, if you want this work to be completed at the appropriate quality level. Even comments like - 'I do not really have time to review the MIB modules in detail, but the technical approach seems OK from an EFM and Ethernet management perspective' are welcome. Of course, if you think that something is broken, you should make a more explicit argument.
 

Thanks and Regards,

Dan

-----Original Message-----
From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org]On Behalf Of Romascanu, Dan (Dan)
Sent: 20 July, 2004 12:03 AM
To: hubmib@ietf.org
Subject: [Hubmib] WG Last Call

My previous message contained an erroneous reference. Please disregard it, and replace it with this one.

This is an Ethernet Interfaces and Hub MIB WG Last Call for the EFM MIB Internet-Drafts. The documents can be found at:

All comments must be sent to the WG e-mail list hubmib@ietf.org, until Wednesday August 18, 2004.

Although a 30 days Last Call period is being granted, it is strongly suggested to the WG participants to submit their comments before the face to face WG meeting, which will be hold on Monday, August 2nd - so that their inputs can be discussed during the meeting in San Diego.


Regards,

Dan

------_=_NextPart_001_01C48089.C065FA00-- --===============1572520870== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============1572520870==-- From hubmib-bounces@ietf.org Sun Aug 15 15:40:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16126 for ; Sun, 15 Aug 2004 15:40:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwQnZ-0004lY-Tr; Sun, 15 Aug 2004 15:36:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwQmv-0004Nn-AX for hubmib@megatron.ietf.org; Sun, 15 Aug 2004 15:35:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15852 for ; Sun, 15 Aug 2004 15:35:24 -0400 (EDT) Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwQsW-0000tO-Hu for hubmib@ietf.org; Sun, 15 Aug 2004 15:41:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hubmib] WG Last Call Date: Sun, 15 Aug 2004 15:34:51 -0400 Message-ID: <8052E2EA753D144EB906B7A7AA399714026F3DAB@mailserv.hatteras.com> Thread-Topic: [Hubmib] WG Last Call Thread-Index: AcSAjlyR0IQ5Q2XzQ7mRmWm6cipjxwCb6bVg From: "Matt Squire" To: "John Messenger" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi John -=20 Thanks for the comments. Some replies below: - Matt > I have not reviewed the EPON or CU MIBs, but we have reviewed=20 > and implemented the EFM MIB. We agreed with one issue that=20 > has already been raised: as creation is automatic we couldn't=20 > see the need for the rowStatus object. Will be taken care of. > Why is there no trap on receipt of OAMPDUs with the special=20 > EFM alarm bits set in the flags field? Assuming one was=20 > reflecting the status of a remote system in a local system's=20 > MIB, I can see some value sending such a trap. In principle,=20 > if there were suitable traps defined in other MIBs, I think=20 > those should be used. For the "link fault" event, I can=20 > imagine using a trap in IF-MIB for example, but for a=20 > "dying gasp" or "critical" event, there doesn't seem to be a=20 > suitable trap elsewhere. Arguably, the general-purpose "critical"=20 > event is too generic to be useful, but there's real information in=20 > "dying gasp" that hasn't been available from remote Ethernet=20 > devices before. We have chosen to include such events in traps=20 > defined in an enterprise-specific MIB. I tried to cover reflecting the flags in SNMP notifications using the = notifications dot3OamRmtErrEventFlags and dot3OamLclErrEventFlags. = These notifications are supposed to be sent whenever the flags field = changes (which covers critical, dying gasp, link fault, both setting and = clearing). We could certainly pull those events out individually into = their own notifications, but I just threw it in as one for now. =20 Do you think those notifications are sufficient, or that we should = define new notifications for each of the three flags, or do you have a = different suggestion? =20 - Matt -----Original Message----- From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org]On Behalf = Of Romascanu, Dan (Dan) Sent: 12 August 2004 14:55 To: hubmib@ietf.org Subject: FW: [Hubmib] WG Last Call There is one more week until the WG Last Call completes. We received too = few comments to my taste. Please read the documents, and send your = comments to the WG list hubmib@ietf.org, if you want this work to be = completed at the appropriate quality level. Even comments like - 'I do = not really have time to review the MIB modules in detail, but the = technical approach seems OK from an EFM and Ethernet management = perspective' are welcome. Of course, if you think that something is = broken, you should make a more explicit argument. Thanks and Regards, Dan -----Original Message----- From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org]On Behalf = Of Romascanu, Dan (Dan) Sent: 20 July, 2004 12:03 AM To: hubmib@ietf.org Subject: [Hubmib] WG Last Call My previous message contained an erroneous reference. Please disregard = it, and replace it with this one. This is an Ethernet Interfaces and Hub MIB WG Last Call for the EFM MIB = Internet-Drafts. The documents can be found at:=20 http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-m= ib-01.txt http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-e= pon-mib-01.txt http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-c= u-mib-01.txt All comments must be sent to the WG e-mail list hubmib@ietf.org, until = Wednesday August 18, 2004. Although a 30 days Last Call period is being granted, it is strongly = suggested to the WG participants to submit their comments before the = face to face WG meeting, which will be hold on Monday, August 2nd - so = that their inputs can be discussed during the meeting in San Diego. Regards, Dan _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Sun Aug 15 18:23:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24127 for ; Sun, 15 Aug 2004 18:23:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwTMl-0002Ef-Ii; Sun, 15 Aug 2004 18:20:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwTH0-0008Ev-Fo for hubmib@megatron.ietf.org; Sun, 15 Aug 2004 18:14:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23345 for ; Sun, 15 Aug 2004 18:14:39 -0400 (EDT) Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwTMg-0003Nh-91 for hubmib@ietf.org; Sun, 15 Aug 2004 18:20:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Aug 2004 18:14:11 -0400 Message-ID: <8052E2EA753D144EB906B7A7AA39971402A3B70F@mailserv.hatteras.com> Thread-Topic: San Diego OAM MIB summary Thread-Index: AcSDFTDL0o5KfM11Q7q624zbL1XXew== From: "Matt Squire" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] San Diego OAM MIB summary X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable For those who weren't at the IETF meeting in San Diego, here are my = notes received on the EFM OAM MIB. 1) Relationship to other MIBs. There was a comment to add more verbage = on the entirety of the EFM project to this MIB. After a little = discussion, it seemed like the consensus would be to add some text in = the overview/background sections, but do not include anything in the = actual MIB itself.=20 2) Row status. There were several tables with row status (dot3OamTable, = dot3OamPeerTable). This was commented as unnecessary and will be = removed. 3) Special stuff for EPON. A question was asked if anything special is = needed for using OAM on EPON. In general, EPON looks like a collection = of p2p links to higher layer applications, OAM included but not special = in that regard. The suggestion at the end was to add a brief sentence = somewhere that indicates EPON has an architecture for higher layer = applications like OAM, reference the EPON MIB, but not go into any = detail here. 4) Loopback control. A comment was made that the OAM loopback control = isn't secure. In the end, the commentor misunderstood the = intent/workings of the OAM loopback control objects and withdrew the = comment after some discussion. It was decided that OAM should not allow = loopback commands from the peer by default = (dot3OamLoopbackIgnoreRx=3Dtrue by default). =20 5) Event configuration. A question was raised as to whether OAM should = have a configurable number of re-tries for the event replication. The = idea would be to allow the administrator to configure whether an event = should be sent once, twice, etc., in order to control the tradeoff = between utilization and reliability (as OAM events are not confirmed or = guaranteed). Some discussion but no consensus, so if you have an = opinion, pass it on. 6) Event status table. Currently, event information is stored as a TLV = (e.g. an octet array). The individual field are not pulled out and = exposed. A question was raised as to whether this is good or bad. The = positive aspects are that it results in fewer fields, but on the other = side, the fields are probably useful and need to be exposed for a = manager. There seemed to be consensus that the fields should be pulled = out of the TLV. And that we might be able to create a generic event = table rather than one row per event type. 7) Event compliance. There was a question as to whether the compliance = table should require implementation of all events, or if each event can = be its own compliance group. The justification for individual = compliance groups for different events are that some can be implemented = easier than others (e.g. remote fault may requrie hardware changes, = frame error thresholds would not). So the general feeling seemed to be = that we can keep the individual event compliance groups.=20 If anyone has a different recollection or additional opinionis, pass 'em = on. - Matt _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Mon Aug 16 13:57:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18122 for ; Mon, 16 Aug 2004 13:57:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwlZi-00078H-Rx; Mon, 16 Aug 2004 13:47:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BwlQN-0005OD-NZ for hubmib@megatron.ietf.org; Mon, 16 Aug 2004 13:37:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16924 for ; Mon, 16 Aug 2004 13:37:34 -0400 (EDT) Received: from falcon.mrv.com ([66.43.110.200] helo=mailsrv.chats.int.mrv.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwlWD-0005DW-Lu for hubmib@ietf.org; Mon, 16 Aug 2004 13:43:38 -0400 Received: by mailsrv.chats.int.mrv.com with Internet Mail Service (5.5.2657.72) id ; Mon, 16 Aug 2004 10:36:49 -0700 Message-ID: <30C8EC18FA0B92458918317E864AABCE01CE1F1B@mailsrv.chats.int.mrv.com> From: Grant Schnebly To: "'Matt Squire'" Subject: RE: [Hubmib] WG Last Call Date: Mon, 16 Aug 2004 10:35:18 -0700 Deferred-Delivery: Mon, 16 Aug 2004 10:36:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="windows-1255" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: "'hubmib@ietf.org'" X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Matt, > Do you think those notifications are sufficient ... or do you have a different suggestion? Please define a Notification for each distinct event. -Grant -----Original Message----- From: Matt Squire [mailto:MSquire@HatterasNetworks.com] Sent: Sunday, August 15, 2004 12:35 PM To: John Messenger; hubmib@ietf.org Subject: RE: [Hubmib] WG Last Call Hi John - Thanks for the comments. Some replies below: - Matt > I have not reviewed the EPON or CU MIBs, but we have reviewed > and implemented the EFM MIB. We agreed with one issue that > has already been raised: as creation is automatic we couldn't > see the need for the rowStatus object. Will be taken care of. > Why is there no trap on receipt of OAMPDUs with the special > EFM alarm bits set in the flags field? Assuming one was > reflecting the status of a remote system in a local system's > MIB, I can see some value sending such a trap. In principle, > if there were suitable traps defined in other MIBs, I think > those should be used. For the "link fault" event, I can > imagine using a trap in IF-MIB for example, but for a > "dying gasp" or "critical" event, there doesn't seem to be a > suitable trap elsewhere. Arguably, the general-purpose "critical" > event is too generic to be useful, but there's real information in > "dying gasp" that hasn't been available from remote Ethernet > devices before. We have chosen to include such events in traps > defined in an enterprise-specific MIB. I tried to cover reflecting the flags in SNMP notifications using the notifications dot3OamRmtErrEventFlags and dot3OamLclErrEventFlags. These notifications are supposed to be sent whenever the flags field changes (which covers critical, dying gasp, link fault, both setting and clearing). We could certainly pull those events out individually into their own notifications, but I just threw it in as one for now. Do you think those notifications are sufficient, or that we should define new notifications for each of the three flags, or do you have a different suggestion? - Matt -----Original Message----- From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org]On Behalf Of Romascanu, Dan (Dan) Sent: 12 August 2004 14:55 To: hubmib@ietf.org Subject: FW: [Hubmib] WG Last Call There is one more week until the WG Last Call completes. We received too few comments to my taste. Please read the documents, and send your comments to the WG list hubmib@ietf.org, if you want this work to be completed at the appropriate quality level. Even comments like - 'I do not really have time to review the MIB modules in detail, but the technical approach seems OK from an EFM and Ethernet management perspective' are welcome. Of course, if you think that something is broken, you should make a more explicit argument. Thanks and Regards, Dan -----Original Message----- From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org]On Behalf Of Romascanu, Dan (Dan) Sent: 20 July, 2004 12:03 AM To: hubmib@ietf.org Subject: [Hubmib] WG Last Call My previous message contained an erroneous reference. Please disregard it, and replace it with this one. This is an Ethernet Interfaces and Hub MIB WG Last Call for the EFM MIB Internet-Drafts. The documents can be found at: http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-mib- 01.txt http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-epon -mib-01.txt http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-cu-m ib-01.txt All comments must be sent to the WG e-mail list hubmib@ietf.org, until Wednesday August 18, 2004. Although a 30 days Last Call period is being granted, it is strongly suggested to the WG participants to submit their comments before the face to face WG meeting, which will be hold on Monday, August 2nd - so that their inputs can be discussed during the meeting in San Diego. Regards, Dan _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Fri Aug 20 08:48:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10066 for ; Fri, 20 Aug 2004 08:48:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By8Qe-0001PK-Uo; Fri, 20 Aug 2004 08:23:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By82J-00066p-KZ for hubmib@megatron.ietf.org; Fri, 20 Aug 2004 07:58:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07123 for ; Fri, 20 Aug 2004 07:58:17 -0400 (EDT) Received: from [213.70.90.131] (helo=mail.advaoptical.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1By88o-0005mT-G6 for hubmib@ietf.org; Fri, 20 Aug 2004 08:05:09 -0400 Received: from muc-srv-exch3.advaoptical.com (unverified) by mail.advaoptical.de (Content Technologies SMTPRS 4.3.1) with ESMTP id ; Fri, 20 Aug 2004 13:57:59 +0200 Received: by muc-srv-exch3.advaoptical.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Aug 2004 13:58:10 +0200 Message-ID: <149127BC7EEE5A48B1F550A57086C1EB045820@yrk-srv-mail.yrk.advaoptical.com> From: John Messenger To: Grant Schnebly , Matt Squire Subject: RE: [Hubmib] WG Last Call Date: Fri, 20 Aug 2004 13:58:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="windows-1255" X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Hi, I agree that separate notifications are best. The reason is that some management systems like to differentiate between different events via the top-level event definition rather than a varbind within it. Also my gut feeling is that "link fault" is a very important message, "dying gasp" could be useful (but why isn't there a standardised "I'm dying" trap similar to coldStart?) and "critical" is too vague to be usefully standardised. Best regards, -- John -----Original Message----- From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org]On Behalf Of Grant Schnebly Sent: 16 August 2004 18:35 To: 'Matt Squire' Cc: 'hubmib@ietf.org' Subject: RE: [Hubmib] WG Last Call Matt, > Do you think those notifications are sufficient ... or do you have a different suggestion? Please define a Notification for each distinct event. -Grant -----Original Message----- From: Matt Squire [mailto:MSquire@HatterasNetworks.com] Sent: Sunday, August 15, 2004 12:35 PM To: John Messenger; hubmib@ietf.org Subject: RE: [Hubmib] WG Last Call Hi John - Thanks for the comments. Some replies below: - Matt > I have not reviewed the EPON or CU MIBs, but we have reviewed > and implemented the EFM MIB. We agreed with one issue that > has already been raised: as creation is automatic we couldn't > see the need for the rowStatus object. Will be taken care of. > Why is there no trap on receipt of OAMPDUs with the special > EFM alarm bits set in the flags field? Assuming one was > reflecting the status of a remote system in a local system's > MIB, I can see some value sending such a trap. In principle, > if there were suitable traps defined in other MIBs, I think > those should be used. For the "link fault" event, I can > imagine using a trap in IF-MIB for example, but for a > "dying gasp" or "critical" event, there doesn't seem to be a > suitable trap elsewhere. Arguably, the general-purpose "critical" > event is too generic to be useful, but there's real information in > "dying gasp" that hasn't been available from remote Ethernet > devices before. We have chosen to include such events in traps > defined in an enterprise-specific MIB. I tried to cover reflecting the flags in SNMP notifications using the notifications dot3OamRmtErrEventFlags and dot3OamLclErrEventFlags. These notifications are supposed to be sent whenever the flags field changes (which covers critical, dying gasp, link fault, both setting and clearing). We could certainly pull those events out individually into their own notifications, but I just threw it in as one for now. Do you think those notifications are sufficient, or that we should define new notifications for each of the three flags, or do you have a different suggestion? - Matt -----Original Message----- From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org]On Behalf Of Romascanu, Dan (Dan) Sent: 12 August 2004 14:55 To: hubmib@ietf.org Subject: FW: [Hubmib] WG Last Call There is one more week until the WG Last Call completes. We received too few comments to my taste. Please read the documents, and send your comments to the WG list hubmib@ietf.org, if you want this work to be completed at the appropriate quality level. Even comments like - 'I do not really have time to review the MIB modules in detail, but the technical approach seems OK from an EFM and Ethernet management perspective' are welcome. Of course, if you think that something is broken, you should make a more explicit argument. Thanks and Regards, Dan -----Original Message----- From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org]On Behalf Of Romascanu, Dan (Dan) Sent: 20 July, 2004 12:03 AM To: hubmib@ietf.org Subject: [Hubmib] WG Last Call My previous message contained an erroneous reference. Please disregard it, and replace it with this one. This is an Ethernet Interfaces and Hub MIB WG Last Call for the EFM MIB Internet-Drafts. The documents can be found at: http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-mib- 01.txt http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-epon -mib-01.txt http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-cu-m ib-01.txt All comments must be sent to the WG e-mail list hubmib@ietf.org, until Wednesday August 18, 2004. Although a 30 days Last Call period is being granted, it is strongly suggested to the WG participants to submit their comments before the face to face WG meeting, which will be hold on Monday, August 2nd - so that their inputs can be discussed during the meeting in San Diego. Regards, Dan _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Fri Aug 20 10:51:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18041 for ; Fri, 20 Aug 2004 10:51:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByAOX-00068o-6E; Fri, 20 Aug 2004 10:29:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1By9yG-00058z-I2 for hubmib@megatron.ietf.org; Fri, 20 Aug 2004 10:02:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13928 for ; Fri, 20 Aug 2004 10:02:18 -0400 (EDT) Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByA4s-0007zo-M0 for hubmib@ietf.org; Fri, 20 Aug 2004 10:09:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hubmib] WG Last Call Date: Fri, 20 Aug 2004 10:01:46 -0400 Message-ID: <8052E2EA753D144EB906B7A7AA399714026F3E4A@mailserv.hatteras.com> Thread-Topic: [Hubmib] WG Last Call Thread-Index: AcSGrPk8iC74FrXiQKmQSf4MMUAUjwAETsBg From: "Matt Squire" To: "John Messenger" , "Grant Schnebly" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: quoted-printable Cc: hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Understood. Working on it for next rev. - Matt > -----Original Message----- > From: John Messenger [mailto:jmessenger@advaoptical.com] > Sent: Friday, August 20, 2004 7:58 AM > To: Grant Schnebly; Matt Squire > Cc: hubmib@ietf.org > Subject: RE: [Hubmib] WG Last Call >=20 >=20 > Hi, >=20 > I agree that separate notifications are best. The reason is that some > management systems like to differentiate between different=20 > events via the > top-level event definition rather than a varbind within it. =20 > Also my gut > feeling is that "link fault" is a very important message,=20 > "dying gasp" could > be useful (but why isn't there a standardised "I'm dying"=20 > trap similar to > coldStart?) and "critical" is too vague to be usefully standardised. >=20 > Best regards, > -- John >=20 > -----Original Message----- > From: hubmib-bounces@ietf.org=20 > [mailto:hubmib-bounces@ietf.org]On Behalf Of > Grant Schnebly > Sent: 16 August 2004 18:35 > To: 'Matt Squire' > Cc: 'hubmib@ietf.org' > Subject: RE: [Hubmib] WG Last Call >=20 >=20 > Matt, >=20 > > Do you think those notifications are sufficient ... or do=20 > you have a > different suggestion? >=20 > Please define a Notification for each distinct event. >=20 > -Grant >=20 >=20 >=20 > -----Original Message----- > From: Matt Squire [mailto:MSquire@HatterasNetworks.com] > Sent: Sunday, August 15, 2004 12:35 PM > To: John Messenger; hubmib@ietf.org > Subject: RE: [Hubmib] WG Last Call >=20 >=20 >=20 > Hi John -=20 >=20 > Thanks for the comments. Some replies below: >=20 > - Matt >=20 >=20 >=20 > > I have not reviewed the EPON or CU MIBs, but we have reviewed=20 > > and implemented the EFM MIB. We agreed with one issue that=20 > > has already been raised: as creation is automatic we couldn't=20 > > see the need for the rowStatus object. >=20 > Will be taken care of. >=20 > > Why is there no trap on receipt of OAMPDUs with the special=20 > > EFM alarm bits set in the flags field? Assuming one was=20 > > reflecting the status of a remote system in a local system's=20 > > MIB, I can see some value sending such a trap. In principle,=20 > > if there were suitable traps defined in other MIBs, I think=20 > > those should be used. For the "link fault" event, I can=20 > > imagine using a trap in IF-MIB for example, but for a=20 > > "dying gasp" or "critical" event, there doesn't seem to be a=20 > > suitable trap elsewhere. Arguably, the general-purpose "critical"=20 > > event is too generic to be useful, but there's real information in=20 > > "dying gasp" that hasn't been available from remote Ethernet=20 > > devices before. We have chosen to include such events in traps=20 > > defined in an enterprise-specific MIB. >=20 > I tried to cover reflecting the flags in SNMP notifications using the > notifications dot3OamRmtErrEventFlags and=20 > dot3OamLclErrEventFlags. These > notifications are supposed to be sent whenever the flags field changes > (which covers critical, dying gasp, link fault, both setting=20 > and clearing). > We could certainly pull those events out individually into their own > notifications, but I just threw it in as one for now. =20 >=20 > Do you think those notifications are sufficient, or that we=20 > should define > new notifications for each of the three flags, or do you have=20 > a different > suggestion? =20 >=20 > - Matt >=20 > -----Original Message----- > From: hubmib-bounces@ietf.org=20 > [mailto:hubmib-bounces@ietf.org]On Behalf Of > Romascanu, Dan (Dan) > Sent: 12 August 2004 14:55 > To: hubmib@ietf.org > Subject: FW: [Hubmib] WG Last Call >=20 >=20 > There is one more week until the WG Last Call completes. We=20 > received too few > comments to my taste. Please read the documents, and send=20 > your comments to > the WG list hubmib@ietf.org, if you want this work to be=20 > completed at the > appropriate quality level. Even comments like - 'I do not=20 > really have time > to review the MIB modules in detail, but the technical=20 > approach seems OK > from an EFM and Ethernet management perspective' are welcome.=20 > Of course, if > you think that something is broken, you should make a more explicit > argument. >=20 > Thanks and Regards, > Dan > -----Original Message----- > From: hubmib-bounces@ietf.org=20 > [mailto:hubmib-bounces@ietf.org]On Behalf Of > Romascanu, Dan (Dan) > Sent: 20 July, 2004 12:03 AM > To: hubmib@ietf.org > Subject: [Hubmib] WG Last Call >=20 >=20 > My previous message contained an erroneous reference. Please=20 > disregard it, > and replace it with this one. > This is an Ethernet Interfaces and Hub MIB WG Last Call for=20 > the EFM MIB > Internet-Drafts. The documents can be found at:=20 > http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-h ubmib-efm-mib- 01.txt http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-e= pon -mib-01.txt http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-c= u-m ib-01.txt All comments must be sent to the WG e-mail list hubmib@ietf.org, until Wednesday August 18, 2004. Although a 30 days Last Call period is being granted, it is strongly suggested to the WG participants to submit their comments before the = face to face WG meeting, which will be hold on Monday, August 2nd - so that = their inputs can be discussed during the meeting in San Diego. Regards, Dan _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Mon Aug 23 13:42:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25433 for ; Mon, 23 Aug 2004 13:42:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzIVM-0005Je-8i; Mon, 23 Aug 2004 13:21:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzIAo-0002zZ-5Z for hubmib@megatron.ietf.org; Mon, 23 Aug 2004 12:59:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23132 for ; Mon, 23 Aug 2004 12:59:45 -0400 (EDT) Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzIAy-0000ro-RV for hubmib@ietf.org; Mon, 23 Aug 2004 13:00:10 -0400 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id i7NGxhPv020029 for ; Mon, 23 Aug 2004 09:59:43 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id i7NGxgSN020017 for ; Mon, 23 Aug 2004 09:59:43 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Mon, 23 Aug 2004 09:59:42 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Hub Mib In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Hubmib] Desultory comments on draft-ietf-hubmib-efm-cu-01 X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org On Wed, 4 Aug 2004, Romascanu, Dan (Dan) wrote: > (of course Mike, it would be great if you can have a look at the > current set of Internet-Drafts now in WG Last Call and submit a > full set comments). Some comments on the ifSpeed, ifStackTable diagram, and MAU-MIB usage issues that have already been discussed on this list to some extent will appear in a forthcoming message. In the meantime here are some things that caught my eye when when looking at the docment this weekend. - On page 6 there is a typo: The SNMP Agent builds efmCuStackTable according to the information contained in the Clause 45 PME_Available_register (see [802.3ah] 61.1.5.3 and 45.2.3.20). The text should read: The SNMP Agent builds efmCuAvailableStackTable according to the information contained in the Clause 45 PME_Available_register (see [802.3ah] 61.1.5.3 and 45.2.3.20). - On page 16, the DESCRIPTION clause of efmCuPAFAdminState says: PCS ports incapable of supporting PAF SHALL return a value of 'disabled'. Attempts to 'enable' such ports SHALL be ignored. ________________________________________________________^^^^^^^ This will almost certainly raise a red flag during MIB Doctor review, since the usual behaviour is to reject unacceptable values with an SNMP error, not to ignore them. I would recommend changing "ignored" to "rejected". There are other places where this is done, and they should be changed, too. I would also recommend that the compliance statement include an OBJECT clause for this object with a WRITE-SYNTAX clause specifying that values other than disabled need not be accepted. - I see several places with Editor's Notes indicating that there are open issues (e.g., text to be added, technical decisions to be made, etc.) These need to be closed off before we make a publication request. Mike _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Mon Aug 23 19:17:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25829 for ; Mon, 23 Aug 2004 19:17:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzMyU-0000k1-QG; Mon, 23 Aug 2004 18:07:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzMEw-0001dC-9i for hubmib@megatron.ietf.org; Mon, 23 Aug 2004 17:20:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15621 for ; Mon, 23 Aug 2004 17:20:17 -0400 (EDT) Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzMFA-0007Si-5b for hubmib@ietf.org; Mon, 23 Aug 2004 17:20:44 -0400 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id i7NLIVCJ031163; Mon, 23 Aug 2004 14:18:31 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id i7NLIUmk031158; Mon, 23 Aug 2004 14:18:31 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Mon, 23 Aug 2004 14:18:30 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Edward Beili Subject: RE: [Hubmib] ifSpeed & 2BASE-TL/10PASS-TS In-Reply-To: <9C1CAB2B65E62D49A10E49DFCD68EF3E03BE6C@il-mail.actelis.net> <9C1CAB2B65E62D49A10E49DFCD68EF3E03BE83@il-mail.actelis.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: hubmib@ietf.org, Matt Squire , stds-802-3-efm@ieee.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org >>>>> On Wed, 4 Aug 2004, Edward Beili wrote: EB> I agree that it would probably be a good idea to include the EB> layering diagram into the efm-cu-mib. >>>>> On Wed, 4 Aug 2004, Romascanu, Dan (Dan) wrote: DR> Can we please consider this as a Last Call comment. DR> DR> (of course Mike, it would be great if you can have a look at the DR> current set of Internet-Drafts now in WG Last Call and submit a DR> full set comments). Unfortunately I don't have the time to do that but I will try to address a couple of points that I previously agreed to comment on. Regarding the layering diagram, what I have inferred from the document is something like the following; please advise whether or not it is correct. _______________________________ _ | LLC Layer | | +-------------------------------+ | | MAC Layer | | +-------------------------------+ > 1 ifEntry | Reconciliation Sublayer | | ifType: ethernetCsmacd(6) +-------------------------------+ | | Physical Coding Sublayer | | +-------+-------+-------+-------+ + N ifEntries | PME 1 | PME 2 | ... | PME N | | ifType: shdsl(169) for 2Base-TL +-------+-------+-------+-------+ - vdsl(97) for 10Pass-TS EB> The PCS in the EFMCu ports performs rate matching using flow EB> control, while the MAC is running at 100Mbps. Since EFMCu EB> interface speeds may vary depending on the copper conditions, EB> configuration parameters and amount of PMEs aggregated, EB> reporting the ifSpeed of the PCS as 100Mbps wouldn't really EB> help. Reporting the ifSpeed of the PCS as the sum of the PME EB> speeds is also incorrect as there's 64/65B encapsulation EB> overhead with optional PAF overhead. What we did for 10GBASE ethernetCsmacd(6) variants was to report the "the current operational speed of the interface" (words from RFC 3635) _excluding_ 64B/66B overhead. That comes out to 10000 Mb/sec for 10GBASE-R (LAN) variants and 9294 Mb/sec for 10GBASE-W variants. I would say that either Matt Squire's option #2 or option #3 would be consistent with that precedent: >>>>> On Mon, 2 Aug 2004, Matt Squire wrote: MS> 2) Use the rate of "goodput" on the PHYs (e.g. how much data can MS> ge thru). This would ignore any overhead of the PHY (PAF, MS> 64/65) and overhead of the MAC (preamble, IPG). This most MS> accurately reflects how much data can get thru. MS> MS> 3) Use the rate at the MAC/MII. E.g. include preamble/IPG (even MS> though its not transmitted), but not PHY overhead (PAF, 64/65). MS> This seems consistent with other PHYs, but is kinda weird in MS> that we're not actually transmitting preamble/ipg. In the 10GBASE cases the reported ifSpeed is the _effective_ rate at which bits are transferred across the XGMII between the RS and PCS. The "bits transferred" always includes the preamble and sfd. It includes all idle characters for 10GBASE-R PHYs, but for 10GBASE-W PHYs it _omits_ the idle characters that are added or removed to adapt the 10GB/s MAC data rate to the 9294 Mb/s "effectve" data rate at the PCS/RS boundary. In other words, it inclues the stuff that actually gets transmitted over the physical medium, but it omits stuff that is just used internally for adaptation but isn't sent over the wire. Based on that, I would be inclined to recommend option #2. If the EFMcu does not actually send preamble and IPG over the wire, then those bits should probably not be included in the effective data rate. >>>>> On Wed, 4 Aug 2004, Edward Beili wrote (in a different thread): EB> While we are on the subject of MAU MIB I would like to share a EB> little problem I'm having in EFM-CU-MIB: EB> EB> As of today the IEEE P802.3af/D3.3 specifies oMAU being a EB> sibling of the oPAF under a common oPHYEntity (see Figure 3-3 on EB> page 692), which creates an impression that ifMauType is an EB> attribute of the PHY (PCS) layer. Traditionally MAU is EB> associated with PMA (see figure 4-1 on page 70 of 802.3-2002), EB> which is actually a part of PME in EFMCu PHYs. EB> EB> So, I see 2 main alternatives for EFMCu PHYs: EB> EB> 1. Not to use MAU MIB at all and instead use appropriate ifType EB> values (should be defined in IANAifType-MIB) for both PCS and EB> PME ports. Note also that EFMCu ports don't use MAU EB> auto-negotiation, media available, false carriers or jabber, so EB> there really no reason for using MAU-MIB apart from the fact EB> that all EtherLike interfaces are required to use it. EB> EB> 2. Use ifMauType for PMEs only (theoretically PMEs can support a EB> number of types so ifMauTypeList can be handy here). The PCS EB> ifType would stay ethernetCsmacd and the real type would be EB> returned in efmCuType and efmCuPortSide. Note that every Ethernet-Like interface is required to use the ifType = ethernetCsmacd(6), and up to now every ifEntry with ifType = ethernetCsmacd(6) has been a consolidated representation of (at least) the LLC, MAC, and PCS (sub)layers. As a result, management software has come to rely on the associated ifMauType to distinguish between the various Ethernet flavors. So, even though you don't do autonegotiation and don't have any PCS status conditions or statistics for the existing MAU MIB to report, you still need an appropriate ifMauType to tell management software to look in the EFM-CU-MIB for the desired information. As for using the MAU-MIB for PMEs, that is not appropriate, since these devices are not Ethernet-Like interfaces, and instantiation of interface MAU objects is allowed only for Ethernet-Like interfaces, as stated in the following excerpt from RFC 3636: It is REQUIRED that an agent implementing the interface-MAU related objects in this MIB will also fully comply with the dot3Compliance2 MODULE-COMPLIANCE statement of the Ethernet-like Interfaces MIB, So, if you use the layering model I depicted above, you will need to instantiate the applicable interface MAU objects (in particular, ifMauType) for each PCS, but you must not do so for the PMEs. Note that this would agree with what was done for 10GBASE-W interfaces. For the 10GBASE-W interfaces we also used the counters from the existing SONET-MIB (RFC 3592) for the WIS, which I suppose would be a precedent in favor of using the existing VDSL and SHDSL MIB modules for EFMcu. Mike _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Thu Aug 26 01:12:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23601 for ; Thu, 26 Aug 2004 01:12:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0C9w-0001lx-P1; Thu, 26 Aug 2004 00:46:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0C1E-00077d-UL for hubmib@megatron.ietf.org; Thu, 26 Aug 2004 00:37:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21816 for ; Thu, 26 Aug 2004 00:37:10 -0400 (EDT) Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0C1X-0003hJ-EL for hubmib@ietf.org; Thu, 26 Aug 2004 00:38:07 -0400 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id i7Q4PLex027046 for ; Wed, 25 Aug 2004 21:25:21 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id i7Q4PKYa027041 for ; Wed, 25 Aug 2004 21:25:20 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 25 Aug 2004 21:25:20 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Hub MIB Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [Hubmib] 10GBASE-CX4 and MAU-MIB X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hubmib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Hub MIB colleagues, According to information on the IEEE 802.3 web site, the work of the IEEE P802.3ak 10GBASE-CX4 Task Force was completed with the approval on 9th February 2004 of IEEE Std 802.3ak-2004 by the IEEE Standards Board. It would therefore beehove us to add support for 10GBASE-CX4 to the MAU-MIB when it is next opened up for revisions. As discussed recently, this will be happening "soon" anyway in order to add the MAU types required for the EFM work. At the present time IEEE Std. 802.3ak-2004 is available from the IEEE only by purchase, not via the getIEEE program, and I have not actually gotten a copy of the published standard. But my understanding from early drafts is that the changes to the MAU-MIB required to support 10GBASE-CX4 will be quite small. I've attached below an e-mail I sent out in early 2003 detailing what appeared to be necessary at that time. We also need to be aware that 10GBASE-T and 10GBASE-LRM are on the horizon. That certainly bolsters the case for moving the MAU type list into an IANA-maintained MIB module. Regards, Mike Heard ---------- Forwarded message ---------- Date: Tue, 14 Jan 2003 12:03:41 -0800 (PST) From: C. M. Heard To: Hub MIB Subject: [Hubmib] 10GBASE-CX4 and 10GBASE-T Hub MIB folks, For those who aren't already aware, I'd like to bring your attention to the fact that there are two IEEE study groups at work on new PMDs for 10 Gb/s Ethernet. The 10GBASE-CX4 group is working on a 15 m shielded copper solution that will use the same PCS as does 10GBASE-LX4. The 10GBASE-T group is working on a 100 m UTP solution. Those who are interested can find more information on the 802.3 web site http://grouper.ieee.org/groups/802/3/ The 10GBASE-CX4 effort has, I believe, the much shorter timeline, and it appears that the impact on our documents will be minimal. In fact as far as I can tell, the only document that will be affected is the MAU-MIB document, and the changes to it will be confined to the following additions: [ ... ] dot3MauType10GigBaseCX4 OBJECT-IDENTITY STATUS current DESCRIPTION "X fiber over copper (per 802.3 section 54)" ::= { dot3MauType XX } -- NOTE: next unassigned value is 41 [ ... ] ifMauTypeListBits OBJECT-TYPE SYNTAX BITS { [ ... ] b10GbaseCX4(XX), -- 10GBASE-CX4 (see NOTE above) [ ... ] } [ ... ] These would mirror the proposed changes to Clause 30, which you can find here: http://grouper.ieee.org/groups/802/3/10GBCX4/public/jan03/WP2p0_cls30_annex30B.pdf While it is probably not be appropriate to include this stuff in the next MAU-MIB draft that includes the 802.3ae stuff, the changes are small enough that they should be able to go into a maintenance update without affecting time-in-grade, or else when then the document advances Draft Standard. The impact of 10GBASE-T is harder to gauge. Mike Heard _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib