From mailman-bounces@ietf.org Mon Nov 1 06:04:39 2004 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 GAA16736 for ; Mon, 1 Nov 2004 06:04:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COaEG-0004PI-95 for bridge-mib-archive@ietf.org; Mon, 01 Nov 2004 06:20:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZK3-0004iO-3D for bridge-mib-archive@ietf.org; Mon, 01 Nov 2004 05:21:59 -0500 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: bridge-mib-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:07:06 -0500 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 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 bridge-mib-archive@ietf.org: List Password // URL ---- -------- bridge-mib@ietf.org zopaeb https://www1.ietf.org/mailman/options/bridge-mib/bridge-mib-archive%40ietf.org From bridge-mib-bounces@ietf.org Mon Nov 1 14:10:26 2004 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 OAA18883 for ; Mon, 1 Nov 2004 14:10:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COhoQ-00008x-GL for bridge-mib-archive@ietf.org; Mon, 01 Nov 2004 14:25:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COhBA-0001GS-9P; Mon, 01 Nov 2004 13:45:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COh28-0004BT-L2 for bridge-mib@megatron.ietf.org; Mon, 01 Nov 2004 13:36:00 -0500 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 NAA15856 for ; Mon, 1 Nov 2004 13:35:58 -0500 (EST) Message-Id: <200411011835.NAA15856@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COhH4-0007iz-VE for bridge-mib@ietf.org; Mon, 01 Nov 2004 13:51:28 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc12) with SMTP id <2004110118352801200a02hte>; Mon, 1 Nov 2004 18:35:28 +0000 From: "David B Harrington" To: Date: Mon, 1 Nov 2004 13:35:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTAQZGAaUy7JQVsTh6QOz0TCU78HA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] MSTP MIB proposals X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Hi, A number of people have asked about MSTP (802.1s) MIB work, and offered a starting document. The Bridge WG will not be developing a mib module for MSTP. MSTP mib work will be done by the IEEE 802.1 WG. The IEEE 802.1 WG will meet the week following IETF61, and the co-chair is planning to schedule time to discuss an 802.1s mib PAR. For those who are not acquainted with IEEE, a PAR discussion is something like a BOF or a re-charter discussion. This is the point at which they decide whether to ask the to approve work on a new document. One proposal has been submitted, and it will be reviewed by the 802.1 WG next week, as part of the PAR discussions. If you want your proposal considered as a basis for the effort, then now is the time to submit it. If you don't, it is likely the effort will be based on somebody else's proposal. You can submit your proposal to Paul Congdon [paul.congdon@hp.com]. You can send your proposal in a format consistent with IETF internet draft requirements. You do not have to have it published by the I-D editor, since it will be published on the IEEE web site. David Harrington dbharrington@comcast.net p.s. Please do NOT name your draft draft-ietf-bridge-XXXXX.txt, since that is reserved for the Bridge WG. _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Tue Nov 2 05:08:24 2004 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 FAA03063 for ; Tue, 2 Nov 2004 05:08:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COvpa-0005Ty-7q for bridge-mib-archive@ietf.org; Tue, 02 Nov 2004 05:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COvQI-0000nH-Ga; Tue, 02 Nov 2004 04:57:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COvJc-0007C5-4w for bridge-mib@megatron.ietf.org; Tue, 02 Nov 2004 04:51:00 -0500 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 EAA02271 for ; Tue, 2 Nov 2004 04:50:53 -0500 (EST) Received: from columba.eur.3com.com ([161.71.171.238]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COvYc-0005Cj-0x for bridge-mib@ietf.org; Tue, 02 Nov 2004 05:06:30 -0500 Received: from toucana.eur.3com.com (eurelay.eur.3com.com [140.204.220.50]) by columba.eur.3com.com with ESMTP id iA29qQuQ026388; Tue, 2 Nov 2004 09:52:26 GMT Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id iA29t8AI009097; Tue, 2 Nov 2004 09:55:09 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256F40.00361844 ; Tue, 2 Nov 2004 09:50:51 +0000 X-Lotus-FromDomain: 3COM From: "Les Bell" To: j.schoenwaelder@iu-bremen.de Message-ID: <80256F40.003616A1.00@notesmta.eur.3com.com> Date: Tue, 2 Nov 2004 09:50:14 +0000 Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Use of the 32-bit path cost was defined in both 802.1w (RSTP) and 802.1t. 802.1t was a collection of enhacements to Bridges, including those that support legacy STP. So the 32-bit path costs do not just apply to RSTP. I think you are right that dot1dStpPortPathCost32 should be conditionally mandatory, but for any Spanning Tree implementation that supports 32-bit path costs, not just for RSTP. Implementations that support 32-bit path costs should not use the 16-bit path cost object, dot1dStpPortPathCost, but I am not sure what is the best way to deal with this. Are we allowed to allocate a special value to indicate it is not in use? I think it would be safer to return an SNMP error indicating the old object is not supported. Les... Juergen Schoenwaelder @ietf.org on 22/10/2004 12:05:23 Please respond to j.schoenwaelder@iu-bremen.de Sent by: bridge-mib-bounces@ietf.org To: bridge-mib@ietf.org cc: Subject: [Bridge-mib] dot1dStpPortPathCost32 The revised BRIDGE-MIB adds dot1dStpPortPathCost32 and makes it mandatory. I think this is broken since existing deployed implementations won't support that object and thus are not compliant. Can someone please explain in which situations the increased range of dot1dStpPortPathCost32 is actually needed? Is this only relevant for rapid spanning tree? In that case, I think the object should be conditionally mandatory for boxes that do rapid spanning tree and the old one stays current, probably with a special value to use in case dot1dStpPortPathCost32 actually has the larger path cost. Please give advise. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Tue Nov 2 11:22:14 2004 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 LAA05766 for ; Tue, 2 Nov 2004 11:22:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1fM-0005Zc-96 for bridge-mib-archive@ietf.org; Tue, 02 Nov 2004 11:37:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1Bc-0003sb-E3; Tue, 02 Nov 2004 11:07:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COxS3-0001J3-S8 for bridge-mib@megatron.ietf.org; Tue, 02 Nov 2004 07:07:52 -0500 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 HAA11058 for ; Tue, 2 Nov 2004 07:07:49 -0500 (EST) Received: from apollo.nbase.co.il ([194.90.137.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COxh8-0007rn-5N for bridge-mib@ietf.org; Tue, 02 Nov 2004 07:23:28 -0500 Received: from Alexr ([194.90.136.135]) by apollo.nbase.co.il (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-44418U200L2S100) with SMTP id AAA2633; Tue, 2 Nov 2004 14:05:55 +0200 From: arozin@mrv.com (Alex Ruzin) To: , , Subject: RE: [Bridge-mib] MSTP MIB proposals Date: Tue, 2 Nov 2004 14:06:55 +0200 Message-ID: <016501c4c0d4$73be0810$87885ac2@Alexr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0166_01C4C0E5.37485EB0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200411011835.NAA15856@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.3 (/) X-Scan-Signature: b82a343a837540fddd003340b02c7b43 X-Mailman-Approved-At: Tue, 02 Nov 2004 11:07:06 -0500 X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arozin@mrv.com List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3eec21359cc773323f0aab45cb0596af This is a multi-part message in MIME format. ------=_NextPart_000_0166_01C4C0E5.37485EB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I dare make a number of comments, regarding the proposed draft-ietf-bridge-mstpmib-01.txt draft, that Paul Congdon had uploaded on http://www.ieee802.org/1/files/public/docs2004/malhotra-mstpmib-01.txt 1. dot1sStpEnable. It is not clear, what does it mean and how it corresponds with .1s 2. dot1sStpBridgeForwardDelay. It must a pair of objects like in RFC1493 - dot1dStpForwardDelay & dot1dStpBridgeForwardDelay: dot1dStpForwardDelay is one that this bridge is currently using, in contrast to dot1dStpBridgeForwardDelay which is the value that this bridge and all others would start using if/when this bridge were to become the root". The same remark is true also for dot1sStpBridgeHelloTime and dot1sStpBridgeMaxAge. 3. dot1sStpProtocolSpecification. The question is - can a Bridge run in several modes depending on configuration? In other words, are we sure, that this object is "read-only"? 4. dot1sStpInstForwardDelay. I am not sure, that we have this object per instance. The same remark is true also for dot1sStpInstHelloTime, dot1sStpInstMaxAge. 5. dot1sStpInstAdminEnable and dot1sStpInstOperEnable: what do they mean. What is "disabled" instance, does it has ports, does it participate in MST Configuration Identifier and in MSTI Configuration Messages? 6. dot1sStpPortTable. Objects dot1sPortAdminExternalPathCost and dot1sPortOperExternalPathCost are absent. The same: dot1sPortAutoEdge, dot1sPortHelloTime, dot1sPortProtocolMigration. 7. dot1sStpInstPortPathCost should be renamed to dot1sStpInstInternalPortPathCost. Better: to have to objects dot1sStpInstAdminInternalPortPathCost and dot1sStpInstAdminInternalPortPathCost. 8. dot1sStpInstPortRole (if it must be...) should distinguish between 'alternate' and 'backup' values. 9. dot1sStpVlanTable. It looks better, than my dot1sMapTable 10. Trap section is absent (see traps in my proposition in attachment). 11. Conformance/Compliances are absent (while my mib doesn't have them too). Attached is my version of proposition, please consider it as a start template for further development. With regards, Alex On Monday, November 01, 2004 8:36 PM David B Harrington wrote: > Hi, > > A number of people have asked about MSTP (802.1s) MIB work, and > offered a starting document. > > The Bridge WG will not be developing a mib module for MSTP. MSTP mib > work will be done by the IEEE 802.1 WG. > > The IEEE 802.1 WG will meet the week following IETF61, and the > co-chair is planning to schedule time to discuss an 802.1s mib PAR. > For those who are not acquainted with IEEE, a PAR discussion is > something like a BOF or a re-charter discussion. This is the point at > which they decide whether to ask the to > approve work on a new document. > > One proposal has been submitted, and it will be reviewed by the 802.1 > WG next week, as part of the PAR discussions. If you want your > proposal considered as a basis for the effort, then now is the time to > submit it. If you don't, it is likely the effort will be based on > somebody else's proposal. You can submit your proposal to Paul Congdon > [paul.congdon@hp.com]. > > You can send your proposal in a format consistent with IETF internet > draft requirements. You do not have to have it published by the I-D > editor, since it will be published on the IEEE web site. > > David Harrington > dbharrington@comcast.net > > p.s. Please do NOT name your draft draft-ietf-bridge-XXXXX.txt, since > that is reserved for the Bridge WG. > > ------=_NextPart_000_0166_01C4C0E5.37485EB0 Content-Type: text/plain; name="draft-mstp-mib-00.txt" Content-Disposition: attachment; filename="draft-mstp-mib-00.txt" Content-Transfer-Encoding: quoted-printable Internet Draft = =20 draft-mstp-mib-00.txt = Alex Rozin MRV = International = T.B.D. =20 = Oct 2004 Definitions of Managed Objects for Bridges with Multiple Spanning Tree Protocol Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines a MIB module for managing the Multiple Spanning Tree capability defined by the IEEE Std 802.1s amendment to IEEE Std 802.1D-1998 for bridging between Local Area Network (LAN) = segments. This memo gives a MIB module for managing the MSTP protocol in a = manner that is compliant to SMIv2 [RFC2578]. Table of Contents 1 The SNMP Management Framework ................................ =20 2 Overview ..................................................... =20 2.1 Scope ...................................................... =20 3 Structure of MSTP-MIB......................................... =20 4 Relation to Original Bridge MIB............................... =20 5 Definition for MSTP-MIB ...................................... =20 6 Acknowledgments .............................................. =20 7 Security consideration ....................................... =20 8 References ................................................... =20 9 Authors' Addresses ........................................... =20 10 Full Copyright .............................................. =20 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. Overview A common device present in many networks is the Bridge. This device is used to connect Local Area Network segments below the network layer. These devices are often known as 'layer 2 switches'. There are two major modes defined for this bridging: Source-Route and transparent. Management of Source-Route bridging is not discussed=20 in this document. MSTP is defined by IEEE 802.1s. MST is defined as one or more logical topologies on a common physical interface. Typically one or more = VLANs are mapped to a logical topology. 2.1. Scope This MIB includes a comprehensive set of managed objects which attempts to match the set defined in IEEE 802.1s. 3. Structure of MSTP-MIB MSTP-MIB Name IEEE 802.1s Name/Purpose dot1s T.B.D. 4. Relation to Original Bridge MIB =20 The interpretation of all the existing groups in the original Bridge = MIB [BRIDGEMIB] remains unchanged. In addition to the objects in the = original=20 Bridge MIB [BRIDGEMIB], this document adds dot1sStp group with the = following=20 OID to manage the Multiple Spanning Tree Protocol: dot1sStp 7 MSTP-MIB DEFINITIONS ::=3D BEGIN=0A= -- draft !=0A= =0A= IMPORTS=0A= MODULE-IDENTITY, OBJECT-TYPE, Counter32, TimeTicks=0A= FROM SNMPv2-SMI=0A= TEXTUAL-CONVENTION, DisplayString, TruthValue=0A= FROM SNMPv2-TC=0A= mib-2=0A= FROM RFC1213-MIB=0A= Timeout, BridgeId=0A= FROM BRIDGE-MIB=0A= enterprises=0A= FROM RFC1155-SMI;=0A= =0A= dot1s MODULE-IDENTITY=0A= LAST-UPDATED "200107130000Z"=0A= ORGANIZATION "MRV Communications, Inc."=0A= CONTACT-INFO=0A= "Alex Rozin=0A= MRV Communication, Inc=0A= http://www.mrv.com=0A= Email: ARozin@mrv.com"=0A= =0A= DESCRIPTION=0A= "The MIB module for managing Multiple & Rapid = Spanning Treescw=0A= Protocol and algorith. It is dedicated to reflect = IEEE 802.1s."=0A= ::=3D { dot1dBridge XX }=0A= =0A= --=0A= -- Textual Conventions=0A= --=0A= =0A= PortIndex ::=3D TEXTUAL-CONVENTION=0A= DISPLAY-HINT "d"=0A= STATUS current=0A= DESCRIPTION=0A= "A unique value, greater than zero, for each Port=0A= in the managed Bridge.=0A= The value for each PortIndex remain=0A= constant at least from one re-initialization of the entity's=0A= network management system to the next re-initialization."=0A= SYNTAX Integer32 (1..2147483647)=0A= =0A= PortIndexOrZero ::=3D TEXTUAL-CONVENTION=0A= DISPLAY-HINT "d"=0A= STATUS current=0A= DESCRIPTION=0A= "This textual convention is an extension of the=0A= PortIndex convention. The latter defines a greater=0A= than zero value used to identify a Port=0A= in the managed Bridge. This extension permits the=0A= additional value of zero. the value zero is object-specific=0A= and must therefore be defined as part of the description of=0A= any object which uses this syntax. Examples of the usage of=0A= zero might include situations where Port was unknown,=0A= or when none or all Ports need to be referenced."=0A= SYNTAX Integer32 (0..2147483647)=0A= =0A= MstiInstanceIndex ::=3D TEXTUAL-CONVENTION=0A= DISPLAY-HINT "d"=0A= STATUS current=0A= DESCRIPTION=0A= "A unique value, greater than zero, for each Multiple = Spanning=0A= Tree Instance (MSTI) in the managed Bridge.=0A= The value for each MstiInstanceIndex remains=0A= constant for the instance,"=0A= SYNTAX Integer32 (1..64)=0A= =0A= MstiOrCistInstanceIndex ::=3D TEXTUAL-CONVENTION=0A= DISPLAY-HINT "d"=0A= STATUS current=0A= DESCRIPTION=0A= "This textual convention is an extension of the=0A= MstiInstanceIndex convention. This extension permits the=0A= additional value of zero, which means Common and Internal=0A= Spanning Tree (CIST)."=0A= SYNTAX Integer32 (0..64)=0A= =0A= PortId ::=3D TEXTUAL-CONVENTION=0A= DISPLAY-HINT "d"=0A= STATUS current=0A= DESCRIPTION=0A= "The Port Identifier of the Port, see IEEE 802.1s clause = 12.8.2.1.3.c)."=0A= SYNTAX OCTET STRING (SIZE (2))=0A= =0A= dot1sGen OBJECT IDENTIFIER ::=3D { dot1s 10 }=0A= -- dot1sGen group reflects configurations/statuses=0A= -- the Bridge as a unit=0A= =0A= dot1sGenBridgeMaxAge OBJECT-TYPE=0A= SYNTAX Timeout (600..4000)=0A= ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "12.8.1.3.a)"=0A= ::=3D { dot1sGen 2 }=0A= =0A= dot1sGenBridgeHelloTime OBJECT-TYPE=0A= SYNTAX Timeout (100..1000)=0A= ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "12.8.1.3.b)"=0A= ::=3D { dot1sGen 3 }=0A= =0A= dot1sGenBridgeForwardDelay OBJECT-TYPE=0A= SYNTAX Timeout (400..3000)=0A= ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "12.8.1.3.c)"=0A= ::=3D { dot1sGen 4 }=0A= =0A= dot1sGenMaxAge OBJECT-TYPE=0A= SYNTAX Timeout (600..4000)=0A= ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "12.8.1.3.a)"=0A= ::=3D { dot1sGen 8 }=0A= =0A= dot1sGenHelloTime OBJECT-TYPE=0A= SYNTAX Timeout (100..1000)=0A= ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "12.8.1.3.b)"=0A= ::=3D { dot1sGen 9 }=0A= =0A= dot1sGenForwardDelay OBJECT-TYPE=0A= SYNTAX Timeout (400..3000)=0A= ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "12.8.1.3.c)"=0A= ::=3D { dot1sGen 10 }=0A= =0A= dot1sGenMaxHops OBJECT-TYPE=0A= SYNTAX Integer32 (4..30)=0A= ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "13.22.f)"=0A= ::=3D { dot1sGen 14 }=0A= =0A= dot1sGenHoldTime OBJECT-TYPE=0A= SYNTAX Timeout (100..1000)=0A= ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sGen 15 }=0A= =0A= dot1sGenMigrateTime OBJECT-TYPE=0A= SYNTAX Timeout (100..1000)=0A= ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "13.22.d)"=0A= ::=3D { dot1sGen 16 }=0A= =0A= dot1sGenPathCostDefault OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= pathCostDefault8021d1998(1),=0A= pathCostDefault8021t2001(2)=0A= }=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "(Copied from = draft-ietf-bridge-rstpmib-02.txt).=0A= The version of the Spanning Tree default Path = Costs that=0A= are to be used by this Bridge. A value of = pathCostDefault8021d1998(1)=0A= uses the 16-bit default Path Costs from IEEE = Std. 802.1D-1998.=0A= A value of pathCostDefault8021t2001(2) uses = the 32-bit default Path=0A= Costs from IEEE Std. 802.1t."=0A= REFERENCE=0A= "IEEE 802.1D & 802.1t Table 8-5"=0A= ::=3D { dot1sGen 18 }=0A= =0A= dot1sGenCapable OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= nonStp(0),=0A= dot1d1998(1),=0A= dot1w(2),=0A= dot1d2004(3),=0A= dot1s(4),=0A= unknown(5)=0A= }=0A= ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "An indication of wheter the Bridge supports=0A= 'maximum' level Spanning Tree Protocol.=0A= The value nonStp(0) indicates, the Bridge doesn't=0A= support any Spanning Tree Protocol.=0A= The value 'dot1d1998(1)' indicates the Spanning Tree = Protocol=0A= specified in EEE 802.1D-1998, 'dot1w(2)' indicates = the Rapid=0A= Spanning Tree Protocol specified in IEEE 802.1w,=0A= 'dot1d2004' indicates IEEE 802.1D-2004 and=0A= 'dot1s(3)means MSTP IEEE 802.1s."=0A= ::=3D { dot1sGen 19 }=0A= =0A= =0A= dot1sGenForceVersion OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= forceNonStp(0),=0A= forceLegacyDot1d(1),=0A= forceDot1w(2),=0A= autoDot1s(3),=0A= unknown(4)=0A= }=0A= ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "The value forceNonStp(0) indicates, the Spanning Tree = Protocol=0A= is disabled on the Bridge (or the Spanning Tree = Protocol=0A= Emulation operates). Other possible values are = described=0A= in IEEE 802.1s clause 12.8.1.3.e)"=0A= DEFVAL { autoDot1s }=0A= ::=3D { dot1sGen 20 }=0A= =0A= dot1sGenCfgName OBJECT-TYPE=0A= SYNTAX DisplayString (SIZE (32))=0A= ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "12.12.3.4.2.b)"=0A= ::=3D { dot1sGen 21 }=0A= =0A= dot1sGenRevLevel OBJECT-TYPE=0A= SYNTAX Integer32=0A= ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "12.12.3.4.2.c)"=0A= ::=3D { dot1sGen 22 }=0A= =0A= dot1sGenBridgeId OBJECT-TYPE=0A= SYNTAX BridgeId=0A= ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sGen 25 }=0A= =0A= dot1sGenReginalRoot OBJECT-TYPE=0A= SYNTAX BridgeId=0A= ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sGen 26 }=0A= =0A= dot1sGenExternalRootCost OBJECT-TYPE=0A= SYNTAX Integer32=0A= ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sGen 27 }=0A= =0A= =0A= dot1sPortTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF Dot1sPortEntry=0A= ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "A table that contains generic information about=0A= every port that is associated with this bridge.=0A= Transparent, source-route, and srt ports are=0A= included."=0A= ::=3D { dot1s 11 }=0A= =0A= dot1sPortEntry OBJECT-TYPE=0A= SYNTAX Dot1sPortEntry=0A= ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "A list of information for each port of the=0A= bridge."=0A= INDEX { dot1sPortIndex }=0A= ::=3D { dot1sPortTable 1 }=0A= =0A= Dot1sPortEntry ::=3D SEQUENCE {=0A= dot1sPortIndex PortIndex,=0A= dot1sPortAdminMACEnable TruthValue,=0A= dot1sPortOperMACEnable TruthValue,=0A= dot1sPortUpTime TimeTicks,=0A= dot1sPortAdminExternalPathCost Integer32,=0A= dot1sPortOperExternalPathCost Integer32,=0A= dot1sPortAdminEdge TruthValue,=0A= dot1sPortOperEdge TruthValue,=0A= dot1sPortAutoEdge TruthValue,=0A= dot1sPortAdminPointToPoint INTEGER,=0A= dot1sPortOperPointToPoint TruthValue,=0A= dot1sPortHelloTime Timeout,=0A= dot1sPortAdminNonStp TruthValue,=0A= dot1sPortProtocolMigration TruthValue,=0A= dot1sPortRxTcnBpduCounter Counter32,=0A= dot1sPortRxCfgBpduCounter Counter32,=0A= dot1sPortRxRstBpduCounter Counter32,=0A= dot1sPortTxMstBpduCounter Counter32,=0A= dot1sPortTxTcnBpduCounter Counter32,=0A= dot1sPortTxCfgBpduCounter Counter32,=0A= dot1sPortTxRstBpduCounter Counter32,=0A= dot1sPortTxMstBpduCounter Counter32=0A= }=0A= =0A= =0A= dot1sPortIndex OBJECT-TYPE=0A= SYNTAX PortIndex=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "A unique value, greater than zero, for = each Port.=0A= The value for each interface sub-layer=0A= must remain constant at least from one = re-initialization=0A= of the entity's network management = system to the next re-=0A= initialization."=0A= ::=3D { dot1sPortEntry 1 }=0A= =0A= dot1sPortAdminMACEnable OBJECT-TYPE =0A= SYNTAX TruthValue=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause = 12.8.2.5.2"=0A= ::=3D { dot1sPortEntry 2 }=0A= =0A= dot1sPortOperMACEnable OBJECT-TYPE =0A= SYNTAX TruthValue=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause = 12.8.2.5.2"=0A= ::=3D { dot1sPortEntry 3 }=0A= =0A= dot1sPortUpTime OBJECT-TYPE =0A= SYNTAX TimeTicks=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "The value of sysUpTime at the time = when the Port=0A= has been enabled by = dot1sPortAdminMACEnable or linked=0A= last time."=0A= ::=3D { dot1sPortEntry 4 }=0A= =0A= dot1sPortAdminExternalPathCost OBJECT-TYPE=0A= SYNTAX Integer32 (0..200000000)=0A= MAX-ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "The administrative value of the = External Port Cost parameter.=0A= The value 0 means, that Port Cost will = be selected=0A= automatically in correspondence with = the speed of=0A= the attached LAN."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 5 }=0A= =0A= dot1sPortOperExternalPathCost OBJECT-TYPE=0A= SYNTAX Integer32=0A= MAX-ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 6 }=0A= =0A= dot1sPortAdminEdge OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 7 }=0A= =0A= dot1sPortOperEdge OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 8 }=0A= =0A= dot1sPortAutoEdge OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 9 }=0A= =0A= dot1sPortAdminPointToPoint OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= forceTrue(0),=0A= forceFalse(1),=0A= auto(2)=0A= }=0A= MAX-ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 10 }=0A= =0A= dot1sPortOperPointToPoint OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 11 }=0A= =0A= dot1sPortHelloTime OBJECT-TYPE=0A= SYNTAX Timeout (100..1000)=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 12 }=0A= =0A= dot1sPortAdminNonStp OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 13 }=0A= =0A= dot1sPortProtocolMigration OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 14 }=0A= =0A= dot1sPortRxTcnBpduCounter OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 15 }=0A= =0A= dot1sPortRxCfgBpduCounter OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 16 }=0A= =0A= dot1sPortRxRstBpduCounter OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 17 }=0A= =0A= dot1sPortTxMstBpduCounter OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 18 }=0A= =0A= dot1sPortTxTcnBpduCounter OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 19 }=0A= =0A= dot1sPortTxCfgBpduCounter OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 20 }=0A= =0A= dot1sPortTxRstBpduCounter OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 21 }=0A= =0A= dot1sPortTxMstBpduCounter OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= REFERENCE "IEEE 802.1s Clause "=0A= ::=3D { dot1sPortEntry 22 }=0A= =0A= =0A= dot1sMapTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF Dot1sMapEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION=0A= "MST Configuration table (VID=3D>MSTID translation): = allocates=0A= each and every possible VLAN to CST or a specific MSTI."=0A= ::=3D { dot1s 12 }=0A= =0A= dot1sMapEntry OBJECT-TYPE=0A= SYNTAX Dot1sMapEntry=0A= MAX-ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "MST Configuration table (VID=3D>MSTID translation): = allocates=0A= each and every possible VLAN to CST or a specific MSTI."=0A= INDEX { dot1sMapMSTiID, dot1sMapVlanId }=0A= ::=3D { dot1sMapTable 1 }=0A= =0A= Dot1sMapEntry ::=3D SEQUENCE {=0A= dot1sMapMSTiID MstiInstanceIndex,=0A= dot1sMapVlanId Integer32,=0A= dot1sMapRowStatus INTEGER=0A= }=0A= =0A= dot1sMapMSTiID OBJECT-TYPE=0A= SYNTAX MstiInstanceIndex=0A= MAX-ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "GETNEXT opration shows only entries, which have = non-zero=0A= dot1sMapVlanId."=0A= ::=3D { dot1sMapEntry 1 }=0A= =0A= dot1sMapVlanId OBJECT-TYPE=0A= SYNTAX Integer32 (0..4095)=0A= MAX-ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sMapEntry 2 }=0A= =0A= dot1sMapRowStatus OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= create(1),=0A= delete(2),=0A= exists(3),=0A= isAbsent(4)=0A= }=0A= MAX-ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sMapEntry 3 }=0A= =0A= dot1sXstTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF Dot1sXstEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1s 13 }=0A= =0A= dot1sXstEntry OBJECT-TYPE=0A= SYNTAX Dot1sXstEntry=0A= MAX-ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= INDEX { dot1sXstId }=0A= ::=3D { dot1sXstTable 1 }=0A= =0A= Dot1sXstEntry ::=3D SEQUENCE {=0A= dot1sXstId MstiOrCistInstanceIndex,=0A= dot1sXstBridgePriority Integer32,=0A= dot1sXstBridgeId BridgeId,=0A= dot1sXstDesignatedRoot BridgeId,=0A= dot1sXstDesignatedBridge BridgeId,=0A= dot1sXstInternalRootCost Integer32,=0A= dot1sXstRootPort dot1sXstRootPort,=0A= dot1sXstTimeSinceTopologyChange TimeTicks,=0A= dot1sXstTopologyChangesCount Counter32,=0A= dot1sXstTopologyChangeFlag TruthValue=0A= }=0A= =0A= dot1sXstId OBJECT-TYPE=0A= SYNTAX MstiOrCistInstanceIndex=0A= MAX-ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "0 means CIST."=0A= ::=3D { dot1sXstEntry 1 }=0A= =0A= =0A= dot1sXstBridgePriority OBJECT-TYPE=0A= SYNTAX Integer32 (0..61440)=0A= MAX-ACCESS read-write=0A= STATUS mandatory=0A= DESCRIPTION=0A= "Bridge priority, in steps of 4096."=0A= DEFVAL { 32768 }=0A= ::=3D { dot1sXstEntry 2 }=0A= =0A= dot1sXstBridgeId OBJECT-TYPE=0A= SYNTAX BridgeId=0A= MAX-ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstEntry 3 }=0A= =0A= dot1sXstDesignatedRoot OBJECT-TYPE=0A= SYNTAX BridgeId=0A= MAX-ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstEntry 4 }=0A= =0A= dot1sXstDesignatedBridge OBJECT-TYPE=0A= SYNTAX BridgeId=0A= MAX-ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstEntry 5 }=0A= =0A= dot1sXstInternalRootCost OBJECT-TYPE=0A= SYNTAX Integer32=0A= MAX-ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstEntry 6 }=0A= =0A= dot1sXstRootPort OBJECT-TYPE=0A= SYNTAX PortIndexOrZero=0A= MAX-ACCESS read-only=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstEntry 7 }=0A= =0A= dot1sXstTimeSinceTopologyChange OBJECT-TYPE=0A= SYNTAX TimeTicks=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstEntry 11 }=0A= =0A= dot1sXstTopologyChangesCount OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstEntry 12 }=0A= =0A= dot1sXstTopologyChangeFlag OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstEntry 13 }=0A= =0A= =0A= dot1sXstPortTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF Dot1sXstPortEntry=0A= ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1s 14 }=0A= =0A= dot1sXstPortEntry OBJECT-TYPE=0A= SYNTAX Dot1sXstPortEntry=0A= ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "."=0A= REFERENCE=0A= "."=0A= INDEX { dot1sXstPortXstId, dot1sXstPortIndex }=0A= ::=3D { dot1sXstPortTable 1 }=0A= =0A= =0A= Dot1sXstPortEntry ::=3D=0A= SEQUENCE {=0A= dot1sXstPortXstId = MstiOrCistInstanceIndex,=0A= dot1sXstPortIndex PortIndex,=0A= dot1sXstPortState INTEGER, =0A= dot1sXstPortRole INTEGER, =0A= dot1sXstPortDesignatedRoot BridgeId,=0A= dot1sXstPortExternalRootCost Integer32,=0A= dot1sXstPortRegionalBridge BridgeId,=0A= dot1sXstPortInternalRootCost Integer32,=0A= dot1sXstPortDesignatedBridge BridgeId,=0A= dot1sXstPortDesignatedPort PortId,=0A= dot1sXstPortPriority Integer32,=0A= dot1sXstPortAdminInternalPathCost Integer32,=0A= dot1sXstPortOperInternalPathCost Integer32=0A= }=0A= =0A= dot1sXstPortXstId OBJECT-TYPE=0A= SYNTAX MstiOrCistInstanceIndex=0A= MAX-ACCESS not-accessible=0A= STATUS mandatory=0A= DESCRIPTION=0A= "0 means CIST."=0A= ::=3D { dot1sXstPortEntry 1 }=0A= =0A= dot1sXstPortIndex OBJECT-TYPE=0A= SYNTAX PortIndex=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "The value of dot1sPortIndex of the = Port=0A= in dot1sPortTable."=0A= ::=3D { dot1sXstPortEntry 2 }=0A= =0A= dot1sXstPortState OBJECT-TYPE =0A= SYNTAX INTEGER {=0A= disabled(1),=0A= discarding(1),=0A= learning(2),=0A= forwarding(3),=0A= unknown(4)=0A= }=0A= =0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstPortEntry 3 }=0A= =0A= dot1sXstPortRole OBJECT-TYPE =0A= SYNTAX INTEGER {=0A= disabled(1),=0A= alternate(2),=0A= backup(3), =0A= root(4),=0A= designated(5),=0A= master(6),=0A= nonStp(7),=0A= unknown(8)=0A= }=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstPortEntry 4 }=0A= =0A= dot1sXstPortDesignatedRoot OBJECT-TYPE =0A= SYNTAX BridgeId=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstPortEntry 6 }=0A= =0A= dot1sXstPortExternalRootCost OBJECT-TYPE =0A= SYNTAX Integer32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstPortEntry 7 }=0A= =0A= dot1sXstPortRegionalBridge OBJECT-TYPE =0A= SYNTAX BridgeId=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstPortEntry 8 }=0A= =0A= dot1sXstPortInternalRootCost OBJECT-TYPE =0A= SYNTAX Integer32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstPortEntry 9 }=0A= =0A= dot1sXstPortDesignatedBridge OBJECT-TYPE =0A= SYNTAX BridgeId=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstPortEntry 10 }=0A= =0A= dot1sXstPortDesignatedPort OBJECT-TYPE =0A= SYNTAX PortId=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstPortEntry 14 }=0A= =0A= dot1sXstPortPriority OBJECT-TYPE =0A= SYNTAX Integer32 (0..255)=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "Port priority, in steps of 16."=0A= DEFVAL { 128 }=0A= ::=3D { dot1sXstPortEntry 15 }=0A= =0A= dot1sXstPortAdminInternalPathCost OBJECT-TYPE =0A= SYNTAX Integer32 (0..200000000)=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "The value 0 means, that the cost = will be selected=0A= automatically."=0A= ::=3D { dot1sXstPortEntry 16 }=0A= =0A= dot1sXstPortOperInternalPathCost OBJECT-TYPE=0A= SYNTAX Integer32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "."=0A= ::=3D { dot1sXstPortEntry 17 }=0A= =0A= -- Traps=0A= =0A= dot1sTraps OBJECT IDENTIFIER ::=3D { dot1s 0 }=0A= =0A= dos1sNewRootBridge NOTIFICATION-TYPE=0A= OBJECTS { dot1sXstId }=0A= STATUS current=0A= DESCRIPTION=0A= "The dos1sNewRootBridge trap indicates that the=0A= sending agent has become the new root of the=0A= Spanning Tree in the CIST or in any MSTI; the=0A= trap is sent by a bridge soon after its election=0A= as the new root, e.g., upon expiration of the=0A= Topology Change Timer immediately subsequent to=0A= its election. Implementation of this trap is=0A= optional."=0A= ::=3D { dot1sTraps 1 }=0A= =0A= dos1sNewRootPort NOTIFICATION-TYPE=0A= OBJECTS { dot1sXstId, dot1sXstPortIndex }=0A= STATUS current=0A= DESCRIPTION=0A= "The dos1sNewRootPort trap indicates that the=0A= sending agent has changed the root Port of the=0A= Spanning Tree in the CIST or in any MSTI. If the = instance=0A= has become a root one, the sending value of the=0A= parameter dot1sXstPortIndex is equal to zero. The=0A= trap is sent by a bridge soon after its election=0A= as the new root Port, e.g., upon expiration of the=0A= Topology Change Timer immediately subsequent to=0A= its election. Implementation of this trap is=0A= optional."=0A= ::=3D { dot1sTraps 2 }=0A= =0A= dos1sTopologyChange NOTIFICATION-TYPE=0A= OBJECTS { dot1sXstId, dot1sXstPortIndex, dot1sXstPortState }=0A= STATUS current=0A= DESCRIPTION=0A= "A dos1sTopologyChange trap is sent by a bridge = when=0A= any of its configured ports n any instance (CIST = or MSTI)=0A= transitions from the=0A= Learning state to the Forwarding state, or from=0A= the Forwarding state to the Blocking state. The=0A= trap is not sent if a dos1sNewRootBridge trap is = sent for the=0A= same transition. Implementation of this trap is=0A= optional."=0A= ::=3D { dot1sTraps 3 }=0A= =0A= END=0A= =0A= 5. Acknowledgments This document was produced on behalf of the Bridge MIB Working Group in the Operations and Management area of the Internet Engineering Task Force. 6. Security Considerations Security Issues are not discussed in this memo. 7. References [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, An Architecture for Describing SNMP Management Frameworks, RFC 2571, April 1999. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, Structure of Management Information Version 2 (SMIv2), STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, Textual Conventions for SMIv2, STD 58, RFC 2579, April 1999. [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2), RFC 1905, January 1996. [RFC1493] Decker, E., Langille, P., Rijsinghani, A. and K. McCloghrie, "Definitions of Managed Objects for Bridges", RFC 1493, July 1993. [802.1d] IEEE 802.1d-1998, "IEEE Standard for Information technology Telecommunications and information exchange between systems Local and metropolitan area networks - Common = Specifications Part 3: Media Access Control (MAC) Bridges". [802.1w] IEEE 802.1w-2001, "(Amendment to IEEE Standard 802.1D) IEEE Standard for Information technology - Telecommunications = and information exchange between systems - Local and metropolitan area networks--Common Specifications - Part 3: Media Access Control (MAC) Bridges: Rapid Reconfiguation". [802.1s] IEEE 802.1s-2002, "(Amendment to IEEE Standard 802.1Q) IEEE Standard for Local and metropolitan area networks-Virtual Bridged Local Area Networks-Amendment 3: Multiple Spanning=20 Trees. 8. Authors' Addresses T.B.D. 9. Full Copyright Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, = copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. =0A= ------=_NextPart_000_0166_01C4C0E5.37485EB0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib ------=_NextPart_000_0166_01C4C0E5.37485EB0-- From bridge-mib-bounces@ietf.org Tue Nov 2 12:01:38 2004 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 MAA11782 for ; Tue, 2 Nov 2004 12:01:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2HW-000702-Ek for bridge-mib-archive@ietf.org; Tue, 02 Nov 2004 12:17:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1nC-00060R-EP; Tue, 02 Nov 2004 11:45:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1TM-0002oo-L1 for bridge-mib@megatron.ietf.org; Tue, 02 Nov 2004 11:25:28 -0500 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 LAA06220 for ; Tue, 2 Nov 2004 11:25:26 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1iU-0005gr-Qr for bridge-mib@ietf.org; Tue, 02 Nov 2004 11:41:07 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 1BAFF2F6C; Tue, 2 Nov 2004 17:24:55 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 29791-08; Tue, 2 Nov 2004 17:24:54 +0100 (CET) Received: from james (james.public.iu-bremen.de [212.201.46.187]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 133EC2F60; Tue, 2 Nov 2004 17:24:54 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CP1So-00016f-L2; Tue, 02 Nov 2004 17:24:54 +0100 Date: Tue, 2 Nov 2004 17:24:54 +0100 From: Juergen Schoenwaelder To: Les Bell Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 Message-ID: <20041102162454.GA4231@james> Mail-Followup-To: Les Bell , bridge-mib@ietf.org References: <80256F40.003616A1.00@notesmta.eur.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80256F40.003616A1.00@notesmta.eur.3com.com> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca On Tue, Nov 02, 2004 at 09:50:14AM +0000, Les Bell wrote: > Use of the 32-bit path cost was defined in both 802.1w (RSTP) and 802.1t. > 802.1t was a collection of enhacements to Bridges, including those that support > legacy STP. So the 32-bit path costs do not just apply to RSTP. > > I think you are right that dot1dStpPortPathCost32 should be conditionally > mandatory, but for any Spanning Tree implementation that supports 32-bit path > costs, not just for RSTP. OK, that language makes sense. > Implementations that support 32-bit path costs should not use the 16-bit path > cost object, dot1dStpPortPathCost, but I am not sure what is the best way to > deal with this. Are we allowed to allocate a special value to indicate it is > not in use? I think it would be safer to return an SNMP error indicating the > old object is not supported. I guess we need to discuss this next week. I know that this issue was discussed before, but we have to make a real engineering decision here. There are several issues involved as far as I can tell: a) Formally, we are not expected (or even allowed?) to add objects while moving from Draft to Standard. So this needs careful consideration from the IETF procedures perspective and support by the AD. b) According to the SMIv2 rules, we can't change the range of the original 16 bit object and have to introduce the new object as done in the current ID. Your question what implementations should do that support 32-bit path costs with the old object requires consideration. Not sure there is a path cost which can be used as a special value (and doing so would most likely change existing semantics) so the requirement might indeed be not to support that object (at least if the value is outside the range). c) It would be nice to know what existing implementations do. I guess that implementation wise simply removing the range restriction is probably the easiest thing to do on the agent. It is hard to judge whether this seriously impacts real-world managers interoperability. If there are implementations which did follow this approach, then this might be important information to consider. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Tue Nov 2 12:48:40 2004 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 MAA16877 for ; Tue, 2 Nov 2004 12:48:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP315-0008Kr-3V for bridge-mib-archive@ietf.org; Tue, 02 Nov 2004 13:04:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2Wd-0006RI-ET; Tue, 02 Nov 2004 12:32:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP23m-00074z-AJ for bridge-mib@megatron.ietf.org; Tue, 02 Nov 2004 12:03:06 -0500 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 MAA11949 for ; Tue, 2 Nov 2004 12:03:04 -0500 (EST) Message-Id: <200411021703.MAA11949@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2Is-00071z-CE for bridge-mib@ietf.org; Tue, 02 Nov 2004 12:18:45 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <20041102170227015007mp8pe>; Tue, 2 Nov 2004 17:02:28 +0000 From: "David B Harrington" To: "'Les Bell'" , Subject: RE: [Bridge-mib] dot1dStpPortPathCost32 Date: Tue, 2 Nov 2004 12:02:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTAw+SfYolvJfVPQL29CMWqKf+QbgAOXZBA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <80256F40.003616A1.00@notesmta.eur.3com.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit I'm not very knowledgeable about the new object, but I think the support should be conditionally mandatory, and the condition should spell out that one or the other should be used. An alternative would be to have different compliance caluses, one to support the older compliance rules and another to support the new compliance rules, but if there's only one object that would be mandatory in the new clause, that doesn't seem worth it. dbh -----Original Message----- From: bridge-mib-bounces@ietf.org [mailto:bridge-mib-bounces@ietf.org] On Behalf Of Les Bell Sent: Tuesday, November 02, 2004 4:50 AM To: j.schoenwaelder@iu-bremen.de Cc: bridge-mib@ietf.org Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 Use of the 32-bit path cost was defined in both 802.1w (RSTP) and 802.1t. 802.1t was a collection of enhacements to Bridges, including those that support legacy STP. So the 32-bit path costs do not just apply to RSTP. I think you are right that dot1dStpPortPathCost32 should be conditionally mandatory, but for any Spanning Tree implementation that supports 32-bit path costs, not just for RSTP. Implementations that support 32-bit path costs should not use the 16-bit path cost object, dot1dStpPortPathCost, but I am not sure what is the best way to deal with this. Are we allowed to allocate a special value to indicate it is not in use? I think it would be safer to return an SNMP error indicating the old object is not supported. Les... Juergen Schoenwaelder @ietf.org on 22/10/2004 12:05:23 Please respond to j.schoenwaelder@iu-bremen.de Sent by: bridge-mib-bounces@ietf.org To: bridge-mib@ietf.org cc: Subject: [Bridge-mib] dot1dStpPortPathCost32 The revised BRIDGE-MIB adds dot1dStpPortPathCost32 and makes it mandatory. I think this is broken since existing deployed implementations won't support that object and thus are not compliant. Can someone please explain in which situations the increased range of dot1dStpPortPathCost32 is actually needed? Is this only relevant for rapid spanning tree? In that case, I think the object should be conditionally mandatory for boxes that do rapid spanning tree and the old one stays current, probably with a special value to use in case dot1dStpPortPathCost32 actually has the larger path cost. Please give advise. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Tue Nov 2 12:51:59 2004 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 MAA17200 for ; Tue, 2 Nov 2004 12:51:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP34H-0008Qf-9X for bridge-mib-archive@ietf.org; Tue, 02 Nov 2004 13:07:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2Wf-0006Uv-EB; Tue, 02 Nov 2004 12:32:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP25o-0007X9-7R for bridge-mib@megatron.ietf.org; Tue, 02 Nov 2004 12:05:12 -0500 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 MAA12167 for ; Tue, 2 Nov 2004 12:05:09 -0500 (EST) Message-Id: <200411021705.MAA12167@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2Kw-00075d-8U for bridge-mib@ietf.org; Tue, 02 Nov 2004 12:20:51 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <2004110217043601400sc25pe>; Tue, 2 Nov 2004 17:04:37 +0000 From: "David B Harrington" To: Date: Tue, 2 Nov 2004 12:04:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTA/gXbDlcp0SI6Qf6eOZYLoOiBng== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] Note takers X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Hi, I am looking for volunteers to be notetakers and jabber scribes at the bridge WG session at IETF61. Please respond off-list. Thanks, David Harrington dbharrington@comcast.net _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Tue Nov 2 13:00:33 2004 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 NAA18422 for ; Tue, 2 Nov 2004 13:00:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP3CY-0000Hd-Pd for bridge-mib-archive@ietf.org; Tue, 02 Nov 2004 13:16:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2ja-0003uQ-Al; Tue, 02 Nov 2004 12:46:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2Vz-0005wE-7H for bridge-mib@megatron.ietf.org; Tue, 02 Nov 2004 12:32:15 -0500 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 MAA15305 for ; Tue, 2 Nov 2004 12:32:12 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2l8-0007uf-Gi for bridge-mib@ietf.org; Tue, 02 Nov 2004 12:47:55 -0500 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 iA2HO6qn006599 for ; Tue, 2 Nov 2004 12:24:06 -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 iA2HMeqn005392 for ; Tue, 2 Nov 2004 12:23:03 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Bridge-mib] dot1dStpPortPathCost32 Date: Tue, 2 Nov 2004 19:30:11 +0200 Message-ID: Thread-Topic: [Bridge-mib] dot1dStpPortPathCost32 Thread-Index: AcTA/sh+Y7VYDYa9TC6BaVk4pe3uEgAApJaQ From: "Romascanu, Dan \(Dan\)" To: , "Les Bell" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Unless I am missing something, I do not see how such a change would not = mandate returning to Proposed.=20 Regards, Dan >=20 > a) Formally, we are not expected (or even allowed?) to add=20 > objects while > moving from Draft to Standard. So this needs careful consideration > from the IETF procedures perspective and support by the AD. >=20 _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Tue Nov 2 15:06:12 2004 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 PAA04756 for ; Tue, 2 Nov 2004 15:06:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP5AA-0003tf-56 for bridge-mib-archive@ietf.org; Tue, 02 Nov 2004 15:21:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP4nT-0002IN-Rx; Tue, 02 Nov 2004 14:58:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP4dQ-0005zV-Lc for bridge-mib@megatron.ietf.org; Tue, 02 Nov 2004 14:48:04 -0500 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 OAA02919 for ; Tue, 2 Nov 2004 14:48:03 -0500 (EST) Message-Id: <200411021948.OAA02919@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP4sM-0003QO-47 for bridge-mib@ietf.org; Tue, 02 Nov 2004 15:03:33 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <2004110219471601400sdjj5e>; Tue, 2 Nov 2004 19:47:17 +0000 From: "David B Harrington" To: , "'Les Bell'" , Subject: RE: [Bridge-mib] dot1dStpPortPathCost32 Date: Tue, 2 Nov 2004 14:47:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTAw+SfYolvJfVPQL29CMWqKf+QbgAOXZBAAAW72SA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <200411021703.MAA11949@ietf.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit Cc: bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Hi, Can we resolve this (and any other issues) on the mailing list before IETF61, please? These mib modules are already three years behind the charter schedule. We want to start the WG last call before IETF61, not wait until IETF61 to start discussing possible solutions. dbh > -----Original Message----- > From: bridge-mib-bounces@ietf.org > [mailto:bridge-mib-bounces@ietf.org] On Behalf Of David B Harrington > Sent: Tuesday, November 02, 2004 12:02 PM > To: 'Les Bell'; j.schoenwaelder@iu-bremen.de > Cc: bridge-mib@ietf.org > Subject: RE: [Bridge-mib] dot1dStpPortPathCost32 > > I'm not very knowledgeable about the new object, but I think > the support should be conditionally mandatory, and the > condition should spell out that one or the other should be used. > > An alternative would be to have different compliance caluses, > one to support the older compliance rules and another to > support the new compliance rules, but if there's only one > object that would be mandatory in the new clause, that > doesn't seem worth it. > > dbh > > > -----Original Message----- > From: bridge-mib-bounces@ietf.org [mailto:bridge-mib-bounces@ietf.org] > On Behalf Of Les Bell > Sent: Tuesday, November 02, 2004 4:50 AM > To: j.schoenwaelder@iu-bremen.de > Cc: bridge-mib@ietf.org > Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 > > > > > Use of the 32-bit path cost was defined in both 802.1w (RSTP) > and 802.1t. > 802.1t was a collection of enhacements to Bridges, including > those that support legacy STP. So the 32-bit path costs do > not just apply to RSTP. > > I think you are right that dot1dStpPortPathCost32 should be > conditionally mandatory, but for any Spanning Tree > implementation that supports 32-bit path costs, not just for RSTP. > > Implementations that support 32-bit path costs should not use > the 16-bit path cost object, dot1dStpPortPathCost, but I am > not sure what is the best way to deal with this. Are we > allowed to allocate a special value to indicate it is not in > use? I think it would be safer to return an SNMP error > indicating the old object is not supported. > > Les... > > > > > > Juergen Schoenwaelder @ietf.org on > 22/10/2004 > 12:05:23 > > Please respond to j.schoenwaelder@iu-bremen.de > > Sent by: bridge-mib-bounces@ietf.org > > > To: bridge-mib@ietf.org > cc: > Subject: [Bridge-mib] dot1dStpPortPathCost32 > > > The revised BRIDGE-MIB adds dot1dStpPortPathCost32 and makes > it mandatory. I think this is broken since existing deployed > implementations won't support that object and thus are not compliant. > Can someone please explain in which situations the increased range of > dot1dStpPortPathCost32 is actually needed? > Is this only relevant for rapid spanning tree? In that case, > I think the object should be conditionally mandatory for > boxes that do rapid spanning tree and the old one stays > current, probably with a special value to use in case > dot1dStpPortPathCost32 actually has the larger path cost. > > Please give advise. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, > Germany > > _______________________________________________ > Bridge-mib mailing list > Bridge-mib@ietf.org > https://www1.ietf.org/mailman/listinfo/bridge-mib > > > > > > _______________________________________________ > Bridge-mib mailing list > Bridge-mib@ietf.org > https://www1.ietf.org/mailman/listinfo/bridge-mib > > > > _______________________________________________ > Bridge-mib mailing list > Bridge-mib@ietf.org > https://www1.ietf.org/mailman/listinfo/bridge-mib > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Tue Nov 2 15:48:44 2004 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 PAA10283 for ; Tue, 2 Nov 2004 15:48:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP5pK-0005KH-Ee for bridge-mib-archive@ietf.org; Tue, 02 Nov 2004 16:04:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP5My-0001nv-Jw; Tue, 02 Nov 2004 15:35:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP5C8-00013T-PG for bridge-mib@megatron.ietf.org; Tue, 02 Nov 2004 15:23:57 -0500 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 PAA07186 for ; Tue, 2 Nov 2004 15:23:55 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP5RG-0004Kt-HW for bridge-mib@ietf.org; Tue, 02 Nov 2004 15:39:38 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id B8A9E2F82; Tue, 2 Nov 2004 21:23:21 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 11692-06; Tue, 2 Nov 2004 21:23:20 +0100 (CET) Received: from james (Ib121.i.pppool.de [85.73.177.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 93EF02F87; Tue, 2 Nov 2004 21:23:18 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CP5BQ-0000eT-JF; Tue, 02 Nov 2004 21:23:12 +0100 Date: Tue, 2 Nov 2004 21:23:12 +0100 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 Message-ID: <20041102202312.GA2450@james> Mail-Followup-To: David B Harrington , ietfdbh@comcast.net, 'Les Bell' , bridge-mib@ietf.org References: <200411021703.MAA11949@ietf.org> <200411021948.OAA02919@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411021948.OAA02919@ietf.org> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "'Les Bell'" , ietfdbh@comcast.net, bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca On Tue, Nov 02, 2004 at 02:47:11PM -0500, David B Harrington wrote: > Can we resolve this (and any other issues) on the mailing list before > IETF61, please? Will be hard, but we can try. > These mib modules are already three years behind the charter schedule. Yes. But since the IETF meeting is next week, I would say that this week does not cause any significant delay. > We want to start the WG last call before IETF61, not wait until IETF61 > to start discussing possible solutions. Lets try to collect possible solutions: a) We remove the 32-bit path cost, move the BRIDGE-MIB to Standard and start a new MIB module which defines the new object. a') We remove the 32-bit path cost, move the BRIDGE-MIB to Standard and tell the IEEE or who cares that they have to address this issue. b) We agree to change the range restriction by declaring that an error or bug fix (even though it really is not, well yeah ...). We don't introduce a new object, stepping of course formally on SMIv2 rules. c) We do what the document currently does (introducing a new object) and move the whole MIB module back to Proposed. d) We do what the document currently does and move forward, looking for the IESG feedback. Note that RFC 2026 says that a Draft standard "is normally considered to be a final specification, and changes are likely to be made only to solve specific problems encountered." Perhaps this is a specific problem encountered... e) We drop the whole document and just stick to RFC 1493. Any options I did forget? Any ideas how to select the winner? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Wed Nov 3 12:47:33 2004 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 MAA02010 for ; Wed, 3 Nov 2004 12:47:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPPTj-0002hl-WC for bridge-mib-archive@ietf.org; Wed, 03 Nov 2004 13:03:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPP85-0002MW-OW; Wed, 03 Nov 2004 12:41:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPP2B-0000qq-Dq for bridge-mib@megatron.ietf.org; Wed, 03 Nov 2004 12:34:59 -0500 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 MAA00472 for ; Wed, 3 Nov 2004 12:34:56 -0500 (EST) Message-Id: <200411031734.MAA00472@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPPHX-0002Ir-7j for bridge-mib@ietf.org; Wed, 03 Nov 2004 12:50:51 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <20041103173418015007gv6ie>; Wed, 3 Nov 2004 17:34:18 +0000 From: "David B Harrington" To: Date: Wed, 3 Nov 2004 12:34:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTBy1VUODoviiRlT4m4H+uVOWNMQA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] WG Last Call:dratf-ietf-bridge-ext-v2-03.txt X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Hi, This starts the WG last call for the update to RFC2674. We missed the IETF61 publication deadline, so the document can be found at: http://www.ibr.cs.tu-bs.de/users/schoenw/draft-ietf-bridge-ext-v2-03.t xt The WG last call will end November 23. This date has been chosen to ensure that 1) IETF61 attendees have two weeks to perform reviews, 2) attendees of the IEEE meeting the following week have two weeks to perform reviews, 3) the ID publication lockout is lifted and the document becomes available in the normal repository If anybody has objection to this date, please post your concerns to bridge-mib@ietf.org. If anybody has comments on the draft, please post them to bridge-mib@ietf.org Thanks, David Harrington dbharrington@comcast.net Bridge-mib co-chair _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 4 10:48:11 2004 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 KAA02435 for ; Thu, 4 Nov 2004 10:48:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPk5y-0007Pl-08 for bridge-mib-archive@ietf.org; Thu, 04 Nov 2004 11:04:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPjhi-0000Wk-8K; Thu, 04 Nov 2004 10:39:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPjcV-0007sB-Dz for bridge-mib@megatron.ietf.org; Thu, 04 Nov 2004 10:33:52 -0500 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 KAA01397 for ; Thu, 4 Nov 2004 10:33:49 -0500 (EST) Message-Id: <200411041533.KAA01397@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPjrx-00075b-2u for bridge-mib@ietf.org; Thu, 04 Nov 2004 10:49:56 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <20041104153310015007cvbbe>; Thu, 4 Nov 2004 15:33:10 +0000 From: "David B Harrington" To: Date: Thu, 4 Nov 2004 10:33:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTBGdCFpISCcWJvQsifS9Kn3UEYBgBZV8EA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <20041102202312.GA2450@james> X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] Consensus Call X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit OK, Let me start a discussion here. This is important for a consensus check, so please read and respond. My experience has been working for an equipment vendor. I have worked in both the embedded system space and the pure vendor-neutral software solution space. Here is what I have learned from that experience. Mib module official status becomes important on the agent side first; once a mib hits PS it's a valid target for inclusion in project plans (for those products that include the managed functionality). While some mib modules get implemented from an I-D, the RFC publication finalizes the design and an RFC# is marketable. Advancement to DS or FS makes little difference - if the functionality is in the box, the mib module should be done fairly soon after the functionality is available, and if there is an RFC-level standard, that's good. The tweaking that occurs between PS and DS and between DS and FS makes little difference to an equipment vendor (except as non-marketable maintenance work). MIB modules become important to vendor-neutral software developers when enough equipment vendors support the MIB module to make it worthwhile directly supporting it, and there is customer demand for consistent management of the functionality. Most vendor-neutral software vendors use table-driven or model-driven designs that largely hide whether the implementation is the industry standard MIB module or a proprietary MIB module with similar capabilites. The status of a MIB module standard is largely irrelevant; the customer demand exists or it doesn't. So, we are now faced with a decision to publish the SMIv2 version of RFC1493 **with no semantic changes** or to publish an updated MIB module that reflects the current underlying IEEE standard better, by supporting 32-bit PathCost rather than only the 16-bit PathCost. How many people on this list actually care whether the standard status is at PS or DS or FS, and why? Will advancing the standards level have an **actual** impact on whether the implementation is done by your company? Would recycling the MIB module at PS have a negative effect on your company and its revenue stream? Would the benefit of having a MIB module that is more current with IEEE standards offset any negatives of recycling at PS? If you are not associated with a company, but rather a university or an open-source product or whatever, will the status level have a real impact on what you do? Ultimately the question to be answered is: Should we diminish the functionality in order to advance the document in the standards track, or should we add the 32-bit functionality even if we have to recycle at Proposed? Thanks, David Harrington dbharrington@comcast.net Bridge-mib co-chair > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, November 02, 2004 3:23 PM > To: David B Harrington > Cc: ietfdbh@comcast.net; 'Les Bell'; bridge-mib@ietf.org > Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 > > On Tue, Nov 02, 2004 at 02:47:11PM -0500, David B Harrington wrote: > > > Can we resolve this (and any other issues) on the mailing > list before > > IETF61, please? > > Will be hard, but we can try. > > > These mib modules are already three years behind the > charter schedule. > > Yes. But since the IETF meeting is next week, I would say > that this week does not cause any significant delay. > > > We want to start the WG last call before IETF61, not wait > until IETF61 > > to start discussing possible solutions. > > Lets try to collect possible solutions: > > a) We remove the 32-bit path cost, move the BRIDGE-MIB to Standard and > start a new MIB module which defines the new object. > > a') We remove the 32-bit path cost, move the BRIDGE-MIB to > Standard and > tell the IEEE or who cares that they have to address this issue. > > b) We agree to change the range restriction by declaring that an error > or bug fix (even though it really is not, well yeah ...). We don't > introduce a new object, stepping of course formally on SMIv2 rules. > > c) We do what the document currently does (introducing a new object) > and move the whole MIB module back to Proposed. > > d) We do what the document currently does and move forward, > looking for > the IESG feedback. Note that RFC 2026 says that a Draft > standard "is > normally considered to be a final specification, and changes are > likely to be made only to solve specific problems encountered." > Perhaps this is a specific problem encountered... > > e) We drop the whole document and just stick to RFC 1493. > > Any options I did forget? > > Any ideas how to select the winner? > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 4 11:35:51 2004 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 LAA07534 for ; Thu, 4 Nov 2004 11:35:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPkq6-00009q-I3 for bridge-mib-archive@ietf.org; Thu, 04 Nov 2004 11:51:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPkPo-0002W1-S8; Thu, 04 Nov 2004 11:24:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPkL2-0001RV-UX for bridge-mib@megatron.ietf.org; Thu, 04 Nov 2004 11:19:52 -0500 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 LAA06025 for ; Thu, 4 Nov 2004 11:19:51 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPkab-0008EH-OA for bridge-mib@ietf.org; Thu, 04 Nov 2004 11:35:58 -0500 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 iA4GBgbh019214 for ; Thu, 4 Nov 2004 11:11:43 -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 iA4G9fbh016423 for ; Thu, 4 Nov 2004 11:10:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Bridge-mib] Consensus Call Date: Thu, 4 Nov 2004 18:15:56 +0200 Message-ID: Thread-Topic: [Bridge-mib] Consensus Call Thread-Index: AcTBGdCFpISCcWJvQsifS9Kn3UEYBgBZV8EAAAJBINA= From: "Romascanu, Dan \(Dan\)" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: quoted-printable X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: quoted-printable Speaking as a contributor - I always favored the approach that we should = rather update the standard and recycle at Proposed, than progress MIB = modules on the standard track, while they are not exactly in synch with = the IEEE standard. This is the line they we also took in the Ethernet = MIB WG.=20 My employer is a mostly enterprise space vendor. I am not official = speaker for the company, but I could cautiously say that my impression = is that our customers do not care too much about the IETF Standards = Status. If a standard does its job and ensures interoperability between = vendors its fine with them.=20 Only a small category of customers would look at the standards status = before entering it in an RFP. However, my impression is that these = customers will first include the IEEE 802.1 standard, and only second = the MIB standard. What is the good of having a Full Standard with a MIB = that is not in synch with the IEEE specification?=20 In conclusion I personally favor option c in Bert's mail.=20 Regards, Dan > -----Original Message----- > From: bridge-mib-bounces@ietf.org=20 > [mailto:bridge-mib-bounces@ietf.org]On Behalf Of David B Harrington > Sent: 04 November, 2004 5:33 PM > To: bridge-mib@ietf.org > Subject: [Bridge-mib] Consensus Call >=20 >=20 > OK, Let me start a discussion here. This is important for a consensus > check, so please read and respond. >=20 > My experience has been working for an equipment vendor. I have worked > in both the embedded system space and the pure vendor-neutral software > solution space. Here is what I have learned from that experience. >=20 > Mib module official status becomes important on the agent side first; > once a mib hits PS it's a valid target for inclusion in project plans > (for those products that include the managed functionality). While > some mib modules get implemented from an I-D, the RFC publication > finalizes the design and an RFC# is marketable. Advancement to DS or > FS makes little difference - if the functionality is in the box, the > mib module should be done fairly soon after the functionality is > available, and if there is an RFC-level standard, that's good. The > tweaking that occurs between PS and DS and between DS and FS makes > little difference to an equipment vendor (except as non-marketable > maintenance work). >=20 > MIB modules become important to vendor-neutral software developers > when enough equipment vendors support the MIB module to make it > worthwhile directly supporting it, and there is customer demand for > consistent management of the functionality. Most vendor-neutral > software vendors use table-driven or model-driven designs that largely > hide whether the implementation is the industry standard MIB module or > a proprietary MIB module with similar capabilites. The status of a MIB > module standard is largely irrelevant; the customer demand exists or > it doesn't. >=20 > So, we are now faced with a decision to publish the SMIv2 version of > RFC1493 **with no semantic changes** or to publish an updated MIB > module that reflects the current underlying IEEE standard better, by > supporting 32-bit PathCost rather than only the 16-bit PathCost. >=20 > How many people on this list actually care whether the standard status > is at PS or DS or FS, and why? Will advancing the standards level have > an **actual** impact on whether the implementation is done by your > company? Would recycling the MIB module at PS have a negative effect > on your company and its revenue stream? Would the benefit of having a > MIB module that is more current with IEEE standards offset any > negatives of recycling at PS? >=20 > If you are not associated with a company, but rather a university or > an open-source product or whatever, will the status level have a real > impact on what you do? >=20 > Ultimately the question to be answered is: Should we diminish the > functionality in order to advance the document in the standards track, > or should we add the 32-bit functionality even if we have to recycle > at Proposed? >=20 > Thanks, > David Harrington > dbharrington@comcast.net > Bridge-mib co-chair > =20 >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On=20 > > Behalf Of Juergen Schoenwaelder > > Sent: Tuesday, November 02, 2004 3:23 PM > > To: David B Harrington > > Cc: ietfdbh@comcast.net; 'Les Bell'; bridge-mib@ietf.org > > Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 > >=20 > > On Tue, Nov 02, 2004 at 02:47:11PM -0500, David B Harrington wrote: > > =20 > > > Can we resolve this (and any other issues) on the mailing=20 > > list before=20 > > > IETF61, please? > >=20 > > Will be hard, but we can try. > > =20 > > > These mib modules are already three years behind the=20 > > charter schedule. > >=20 > > Yes. But since the IETF meeting is next week, I would say=20 > > that this week does not cause any significant delay. > > =20 > > > We want to start the WG last call before IETF61, not wait=20 > > until IETF61=20 > > > to start discussing possible solutions. > >=20 > > Lets try to collect possible solutions: > >=20 > > a) We remove the 32-bit path cost, move the BRIDGE-MIB to Standard > and > > start a new MIB module which defines the new object. > >=20 > > a') We remove the 32-bit path cost, move the BRIDGE-MIB to=20 > > Standard and > > tell the IEEE or who cares that they have to address this issue. > >=20 > > b) We agree to change the range restriction by declaring that an > error > > or bug fix (even though it really is not, well yeah ...). We > don't > > introduce a new object, stepping of course formally on SMIv2 > rules. > >=20 > > c) We do what the document currently does (introducing a new object) >=20 > > and move the whole MIB module back to Proposed. > >=20 > > d) We do what the document currently does and move forward,=20 > > looking for=20 > > the IESG feedback. Note that RFC 2026 says that a Draft=20 > > standard "is=20 > > normally considered to be a final specification, and changes are=20 > > likely to be made only to solve specific problems encountered."=20 > > Perhaps this is a specific problem encountered... > >=20 > > e) We drop the whole document and just stick to RFC 1493. > >=20 > > Any options I did forget? > >=20 > > Any ideas how to select the winner? > >=20 > > /js > >=20 > > --=20 > > Juergen Schoenwaelder International=20 > University Bremen > > P.O. Box 750 561,=20 > > 28725 Bremen, Germany > >=20 >=20 >=20 >=20 > _______________________________________________ > Bridge-mib mailing list > Bridge-mib@ietf.org > https://www1.ietf.org/mailman/listinfo/bridge-mib >=20 _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 4 12:42:53 2004 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 MAA14968 for ; Thu, 4 Nov 2004 12:42:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPlsz-00029H-AD for bridge-mib-archive@ietf.org; Thu, 04 Nov 2004 12:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPlRZ-0005fW-DI; Thu, 04 Nov 2004 12:30:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPlH7-0002Lz-1m for bridge-mib@megatron.ietf.org; Thu, 04 Nov 2004 12:19:53 -0500 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 MAA12988 for ; Thu, 4 Nov 2004 12:19:50 -0500 (EST) Message-Id: <200411041719.MAA12988@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPlWf-0001XA-Dm for bridge-mib@ietf.org; Thu, 04 Nov 2004 12:35:58 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2004110417191901300c0vmfe>; Thu, 4 Nov 2004 17:19:20 +0000 From: "David B Harrington" To: "'Romascanu, Dan \(Dan\)'" , Subject: RE: [Bridge-mib] Consensus Call Date: Thu, 4 Nov 2004 12:19:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTBGdCFpISCcWJvQsifS9Kn3UEYBgBZV8EAAAJBINAAAoIWAA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Content-Transfer-Encoding: 7bit X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Content-Transfer-Encoding: 7bit Just to be clear, that was Juergen's mail, not Bert's. dbh > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Thursday, November 04, 2004 11:16 AM > To: dbharrington@comcast.net; bridge-mib@ietf.org > Subject: RE: [Bridge-mib] Consensus Call > > Speaking as a contributor - I always favored the approach > that we should rather update the standard and recycle at > Proposed, than progress MIB modules on the standard track, > while they are not exactly in synch with the IEEE standard. > This is the line they we also took in the Ethernet MIB WG. > > My employer is a mostly enterprise space vendor. I am not > official speaker for the company, but I could cautiously say > that my impression is that our customers do not care too much > about the IETF Standards Status. If a standard does its job > and ensures interoperability between vendors its fine with them. > > Only a small category of customers would look at the > standards status before entering it in an RFP. However, my > impression is that these customers will first include the > IEEE 802.1 standard, and only second the MIB standard. What > is the good of having a Full Standard with a MIB that is not > in synch with the IEEE specification? > > In conclusion I personally favor option c in Bert's mail. > > Regards, > > Dan > > > > > -----Original Message----- > > From: bridge-mib-bounces@ietf.org > > [mailto:bridge-mib-bounces@ietf.org]On Behalf Of David B Harrington > > Sent: 04 November, 2004 5:33 PM > > To: bridge-mib@ietf.org > > Subject: [Bridge-mib] Consensus Call > > > > > > OK, Let me start a discussion here. This is important for a > consensus > > check, so please read and respond. > > > > My experience has been working for an equipment vendor. I > have worked > > in both the embedded system space and the pure > vendor-neutral software > > solution space. Here is what I have learned from that experience. > > > > Mib module official status becomes important on the agent > side first; > > once a mib hits PS it's a valid target for inclusion in > project plans > > (for those products that include the managed functionality). While > > some mib modules get implemented from an I-D, the RFC publication > > finalizes the design and an RFC# is marketable. Advancement > to DS or > > FS makes little difference - if the functionality is in the > box, the > > mib module should be done fairly soon after the functionality is > > available, and if there is an RFC-level standard, that's good. The > > tweaking that occurs between PS and DS and between DS and FS makes > > little difference to an equipment vendor (except as non-marketable > > maintenance work). > > > > MIB modules become important to vendor-neutral software developers > > when enough equipment vendors support the MIB module to make it > > worthwhile directly supporting it, and there is customer demand for > > consistent management of the functionality. Most vendor-neutral > > software vendors use table-driven or model-driven designs > that largely > > hide whether the implementation is the industry standard > MIB module or > > a proprietary MIB module with similar capabilites. The > status of a MIB > > module standard is largely irrelevant; the customer demand > exists or > > it doesn't. > > > > So, we are now faced with a decision to publish the SMIv2 version of > > RFC1493 **with no semantic changes** or to publish an updated MIB > > module that reflects the current underlying IEEE standard > better, by > > supporting 32-bit PathCost rather than only the 16-bit PathCost. > > > > How many people on this list actually care whether the > standard status > > is at PS or DS or FS, and why? Will advancing the standards > level have > > an **actual** impact on whether the implementation is done by your > > company? Would recycling the MIB module at PS have a > negative effect > > on your company and its revenue stream? Would the benefit > of having a > > MIB module that is more current with IEEE standards offset any > > negatives of recycling at PS? > > > > If you are not associated with a company, but rather a > university or > > an open-source product or whatever, will the status level > have a real > > impact on what you do? > > > > Ultimately the question to be answered is: Should we diminish the > > functionality in order to advance the document in the > standards track, > > or should we add the 32-bit functionality even if we have > to recycle > > at Proposed? > > > > Thanks, > > David Harrington > > dbharrington@comcast.net > > Bridge-mib co-chair > > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] > On Behalf > > > Of Juergen Schoenwaelder > > > Sent: Tuesday, November 02, 2004 3:23 PM > > > To: David B Harrington > > > Cc: ietfdbh@comcast.net; 'Les Bell'; bridge-mib@ietf.org > > > Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 > > > > > > On Tue, Nov 02, 2004 at 02:47:11PM -0500, David B > Harrington wrote: > > > > > > > Can we resolve this (and any other issues) on the mailing > > > list before > > > > IETF61, please? > > > > > > Will be hard, but we can try. > > > > > > > These mib modules are already three years behind the > > > charter schedule. > > > > > > Yes. But since the IETF meeting is next week, I would say > that this > > > week does not cause any significant delay. > > > > > > > We want to start the WG last call before IETF61, not wait > > > until IETF61 > > > > to start discussing possible solutions. > > > > > > Lets try to collect possible solutions: > > > > > > a) We remove the 32-bit path cost, move the BRIDGE-MIB to Standard > > and > > > start a new MIB module which defines the new object. > > > > > > a') We remove the 32-bit path cost, move the BRIDGE-MIB > to Standard > > > and > > > tell the IEEE or who cares that they have to address > this issue. > > > > > > b) We agree to change the range restriction by declaring that an > > error > > > or bug fix (even though it really is not, well yeah ...). We > > don't > > > introduce a new object, stepping of course formally on SMIv2 > > rules. > > > > > > c) We do what the document currently does (introducing a > new object) > > > > > and move the whole MIB module back to Proposed. > > > > > > d) We do what the document currently does and move > forward, looking > > > for > > > the IESG feedback. Note that RFC 2026 says that a > Draft standard > > > "is > > > normally considered to be a final specification, and > changes are > > > likely to be made only to solve specific problems > encountered." > > > Perhaps this is a specific problem encountered... > > > > > > e) We drop the whole document and just stick to RFC 1493. > > > > > > Any options I did forget? > > > > > > Any ideas how to select the winner? > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder International > > University Bremen > > > P.O. Box 750 561, > > > 28725 Bremen, Germany > > > > > > > > > > > _______________________________________________ > > Bridge-mib mailing list > > Bridge-mib@ietf.org > > https://www1.ietf.org/mailman/listinfo/bridge-mib > > > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 4 12:48:01 2004 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 MAA15638 for ; Thu, 4 Nov 2004 12:48:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPlxw-0002Nz-Ft for bridge-mib-archive@ietf.org; Thu, 04 Nov 2004 13:04:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPlcD-0007T1-Vv; Thu, 04 Nov 2004 12:41:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPlRR-0005WV-BR for bridge-mib@megatron.ietf.org; Thu, 04 Nov 2004 12:30:33 -0500 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 MAA14053 for ; Thu, 4 Nov 2004 12:30:30 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPlgz-0001r3-KD for bridge-mib@ietf.org; Thu, 04 Nov 2004 12:46:39 -0500 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 iA4HMMbh016320 for ; Thu, 4 Nov 2004 12:22:22 -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 iA4HKnbh014853 for ; Thu, 4 Nov 2004 12:21:29 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Bridge-mib] Consensus Call Date: Thu, 4 Nov 2004 19:28:22 +0200 Message-ID: Thread-Topic: [Bridge-mib] Consensus Call Thread-Index: AcTBGdCFpISCcWJvQsifS9Kn3UEYBgBZV8EAAAJBINAAAoIWAAAAUoWw From: "Romascanu, Dan \(Dan\)" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Ooops, my apologies.=20 Regards, Dan > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: 04 November, 2004 7:19 PM > To: Romascanu, Dan (Dan); bridge-mib@ietf.org > Subject: RE: [Bridge-mib] Consensus Call >=20 >=20 > Just to be clear, that was Juergen's mail, not Bert's. >=20 > dbh >=20 >=20 _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 4 13:03:02 2004 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 NAA16637 for ; Thu, 4 Nov 2004 13:03:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPmCU-0002f5-PC for bridge-mib-archive@ietf.org; Thu, 04 Nov 2004 13:19:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPlhl-0000Iq-QY; Thu, 04 Nov 2004 12:47:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPlRr-0005n8-V3 for bridge-mib@megatron.ietf.org; Thu, 04 Nov 2004 12:31:00 -0500 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 MAA14125 for ; Thu, 4 Nov 2004 12:30:57 -0500 (EST) Message-Id: <200411041730.MAA14125@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPlhQ-0001qq-9M for bridge-mib@ietf.org; Thu, 04 Nov 2004 12:47:05 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2004110417302701300bqf3ke>; Thu, 4 Nov 2004 17:30:27 +0000 From: "David B Harrington" To: Date: Thu, 4 Nov 2004 12:30:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTCk/ccn+sw5cWoTIO7OCdqCKVjbA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: STDS-802-1-L@LISTSERV.IEEE.ORG Subject: [Bridge-mib] Last Call: draft-ietf-bridge-bridgemib-smiv2-07.txt X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Hi, This starts the WG last call for the update to RFC1493. The document is available at ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-bridge-br idgemib-smiv2-07.txt The WG last call will end November 23. This date has been chosen to ensure that 1) IETF61 attendees have time to perform reviews, and 2) attendees of the IEEE meeting the following week have time to perform reviews. Please post your comments to bridge-mib@ietf.org Two points: 1) there have been two different -07- revisions published; please ensure that you review the one dated October 25, 2004. 2) I just started a discussion of advancement versus adding PathCost32; the current -07- draft will require recycling at PS; any discussion about recycling at PS will be included in the WG last call comments. Thanks, David Harrington dbharrington@comcast.net Bridge-mib co-chair _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 4 17:00:29 2004 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 RAA11051 for ; Thu, 4 Nov 2004 17:00:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPpuI-0008Te-GA for bridge-mib-archive@ietf.org; Thu, 04 Nov 2004 17:16:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpNW-00038s-8Y; Thu, 04 Nov 2004 16:42:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpFH-0000Ps-99 for bridge-mib@megatron.ietf.org; Thu, 04 Nov 2004 16:34:15 -0500 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 QAA08408 for ; Thu, 4 Nov 2004 16:34:13 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPpUs-0007in-GH for bridge-mib@ietf.org; Thu, 04 Nov 2004 16:50:23 -0500 Received: from tom3 (1Cust43.tnt30.lnd3.gbr.da.uu.net [62.188.122.43]) by blaster.systems.pipex.net (Postfix) with SMTP id 8C424E0000DE; Thu, 4 Nov 2004 21:33:38 +0000 (GMT) Message-ID: <044401c4c2b5$cd82ff80$0301a8c0@tom3> From: "Tom Petch" To: , Subject: Re: [Bridge-mib] Consensus Call Date: Thu, 4 Nov 2004 21:30:59 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit David I think you pose the wrong question. For me, the issue is more about how long do we go on doing this for with what end in view? I prefer option a' where we arrive at FS because I think anything else is, at least technically, an unstable state within the IETF. I do not believe that most MIB users/implementors comprehend the difference between the various ,S that the IETF has defined. And while it is technically satisfying to get 32 bit path cost right, this is just the current of what could be a never ending list of changes coming up in the future and we already decided that the future of this work belongs with IEEE not IETF. Tom Petch -----Original Message----- From: David B Harrington To: bridge-mib@ietf.org Date: 04 November 2004 15:48 Subject: [Bridge-mib] Consensus Call >OK, Let me start a discussion here. This is important for a consensus >check, so please read and respond. > > >Ultimately the question to be answered is: Should we diminish the >functionality in order to advance the document in the standards track, >or should we add the 32-bit functionality even if we have to recycle >at Proposed? > >Thanks, >David Harrington >dbharrington@comcast.net >Bridge-mib co-chair > > >> -----Original Message----- >> From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On >> Behalf Of Juergen Schoenwaelder >> Sent: Tuesday, November 02, 2004 3:23 PM >> To: David B Harrington >> Cc: ietfdbh@comcast.net; 'Les Bell'; bridge-mib@ietf.org >> Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 >> >> On Tue, Nov 02, 2004 at 02:47:11PM -0500, David B Harrington wrote: >> >> Lets try to collect possible solutions: >> >> a) We remove the 32-bit path cost, move the BRIDGE-MIB to Standard >and >> start a new MIB module which defines the new object. >> >> a') We remove the 32-bit path cost, move the BRIDGE-MIB to >> Standard and >> tell the IEEE or who cares that they have to address this issue. >> >> b) We agree to change the range restriction by declaring that an >error >> or bug fix (even though it really is not, well yeah ...). We >don't >> introduce a new object, stepping of course formally on SMIv2 >rules. >> >> c) We do what the document currently does (introducing a new object) > >> and move the whole MIB module back to Proposed. >> >> d) We do what the document currently does and move forward, >> looking for >> the IESG feedback. Note that RFC 2026 says that a Draft >> standard "is >> normally considered to be a final specification, and changes are >> likely to be made only to solve specific problems encountered." >> Perhaps this is a specific problem encountered... >> >> e) We drop the whole document and just stick to RFC 1493. >> >> Any ideas how to select the winner? Rough consensus? >> >> Juergen Schoenwaelder International University Bremen >> P.O. Box 750 561, >> 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 4 17:50:28 2004 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 RAA18031 for ; Thu, 4 Nov 2004 17:50:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPqgd-0001nW-DA for bridge-mib-archive@ietf.org; Thu, 04 Nov 2004 18:06:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPqDQ-0005J6-45; Thu, 04 Nov 2004 17:36:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPq39-0001Z8-U9 for bridge-mib@megatron.ietf.org; Thu, 04 Nov 2004 17:25:48 -0500 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 RAA14231 for ; Thu, 4 Nov 2004 17:25:45 -0500 (EST) Message-Id: <200411042225.RAA14231@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPqId-0000ov-MD for bridge-mib@ietf.org; Thu, 04 Nov 2004 17:41:55 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <2004110422250701400sdt9te>; Thu, 4 Nov 2004 22:25:07 +0000 From: "David B Harrington" To: "'Tom Petch'" , Subject: RE: [Bridge-mib] Consensus Call Date: Thu, 4 Nov 2004 17:25:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTCtfPlWi4GJdfvTEKNJPC3JEWYuQAAHbpA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <044401c4c2b5$cd82ff80$0301a8c0@tom3> X-Spam-Score: 0.1 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: 7bit X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: 7bit Hi Tom, My goal, to make it clear, is to get the documents finished. I don't want to have to re-edit the documents to remove the PathCost32 because that will take another four to six months to a year at the glacial rate of this working group. I would like to simply last call the three documents as they currently stand and be done. The documents will be published as RFCs, which are by definition stable **documents** within the IETF, even though -- technically -- they are in an unstable **state**. The only difference is that, with PathCost32 present, we would need to submit the documents at Proposed rather than FS, and "most MIB users/implementors [do not] comprehend the difference between the various ,S that the IETF has defined." I see no benefit to be gained from advancing three-year-old mib modules in the standards track and then having the IEEE immediately start to write new documents to replace them. The PAR for an 802.1Q-REV has already been granted, and it is well understood in both the IEEE and the IETF that the Bridge MIB modules are out-of-date relative to 802.1D-2004 and needs to be updated. It may not have been obvious, but I posed the question relative only to this editing cycle - the last planned editing cycle for this document in the IETF. There would be no more additions to the three documents currently in last call. Any further work would be done in the IEEE as part of their next update. I was not suggesting that we reopen the document for even more additions now, or ever. I think I did pose the correct question though. Given that the compliance statement for RFC1493 is still valid, so you only need to do an upodate if you want the PathCost32 in your implementation, if we publish the documents with the PathCost32 in them, and therefore have to start the updated document at Proposed, will that impact your company's implementation schedule? If we re-edit the documents and then advance them to FS and DS, will that change your company's implementation schedule and generate addition revenue for your company? Or does the advancement only impact its "technical" status within the IETF, and not **really** impact users and implementors of the MIB module? I think we are in agreement that the advancement has only a technical impact within the IETF, not a practical impact to the industry. dbh > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Thursday, November 04, 2004 4:31 PM > To: dbharrington@comcast.net; bridge-mib@ietf.org > Subject: Re: [Bridge-mib] Consensus Call > > David > > I think you pose the wrong question. For me, the issue is > more about how long do we go on doing this for with what end in view? > > I prefer option a' where we arrive at FS because I think > anything else is, at least technically, an unstable state > within the IETF. I do not believe that most MIB > users/implementors comprehend the difference between the > various ,S that the IETF has defined. > > And while it is technically satisfying to get 32 bit path > cost right, this is just the current of what could be a never > ending list of changes coming up in the future and we already > decided that the future of this work belongs with IEEE not IETF. > > Tom Petch > > -----Original Message----- > From: David B Harrington > To: bridge-mib@ietf.org > Date: 04 November 2004 15:48 > Subject: [Bridge-mib] Consensus Call > > > >OK, Let me start a discussion here. This is important for a > consensus > >check, so please read and respond. > > > > > > >Ultimately the question to be answered is: Should we diminish the > >functionality in order to advance the document in the > standards track, > >or should we add the 32-bit functionality even if we have to > recycle at > >Proposed? > > > >Thanks, > >David Harrington > >dbharrington@comcast.net > >Bridge-mib co-chair > > > > > >> -----Original Message----- > >> From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] > On Behalf > >> Of Juergen Schoenwaelder > >> Sent: Tuesday, November 02, 2004 3:23 PM > >> To: David B Harrington > >> Cc: ietfdbh@comcast.net; 'Les Bell'; bridge-mib@ietf.org > >> Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 > >> > >> On Tue, Nov 02, 2004 at 02:47:11PM -0500, David B Harrington wrote: > >> > >> Lets try to collect possible solutions: > >> > >> a) We remove the 32-bit path cost, move the BRIDGE-MIB to Standard > >and > >> start a new MIB module which defines the new object. > >> > >> a') We remove the 32-bit path cost, move the BRIDGE-MIB to > Standard > >> and > >> tell the IEEE or who cares that they have to address this issue. > >> > >> b) We agree to change the range restriction by declaring that an > >error > >> or bug fix (even though it really is not, well yeah ...). We > >don't > >> introduce a new object, stepping of course formally on SMIv2 > >rules. > >> > >> c) We do what the document currently does (introducing a > new object) > > > >> and move the whole MIB module back to Proposed. > >> > >> d) We do what the document currently does and move > forward, looking > >> for > >> the IESG feedback. Note that RFC 2026 says that a Draft > standard > >> "is > >> normally considered to be a final specification, and changes are > >> likely to be made only to solve specific problems encountered." > >> Perhaps this is a specific problem encountered... > >> > >> e) We drop the whole document and just stick to RFC 1493. > >> > >> Any ideas how to select the winner? > > Rough consensus? > > >> > >> Juergen Schoenwaelder International University Bremen > >> P.O. Box 750 561, > >> 28725 Bremen, Germany > > > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Fri Nov 5 03:01:07 2004 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 DAA14155 for ; Fri, 5 Nov 2004 03:01:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPzHU-0004GG-94 for bridge-mib-archive@ietf.org; Fri, 05 Nov 2004 03:17:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPz0f-0001oy-Ud; Fri, 05 Nov 2004 02:59:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPyzJ-0001Za-Vy for bridge-mib@megatron.ietf.org; Fri, 05 Nov 2004 02:58:26 -0500 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 CAA13924 for ; Fri, 5 Nov 2004 02:58:20 -0500 (EST) Received: from columba.eur.3com.com ([161.71.171.238]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPzEm-0004DH-9F for bridge-mib@ietf.org; Fri, 05 Nov 2004 03:14:35 -0500 Received: from toucana.eur.3com.com (eurelay.eur.3com.com [140.204.220.50]) by columba.eur.3com.com with ESMTP id iA57xVuQ025574 for ; Fri, 5 Nov 2004 07:59:32 GMT Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id iA582EAH007536 for ; Fri, 5 Nov 2004 08:02:15 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256F43.002BC571 ; Fri, 5 Nov 2004 07:58:05 +0000 X-Lotus-FromDomain: 3COM From: "Les Bell" To: bridge-mib@ietf.org Message-ID: <80256F43.002BC4E6.00@notesmta.eur.3com.com> Date: Fri, 5 Nov 2004 07:57:27 +0000 Subject: RE: [Bridge-mib] Consensus Call Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b I agree with Dan. Les... "Romascanu, Dan \(Dan\)" @ietf.org on 04/11/2004 16:15:56 Sent by: bridge-mib-bounces@ietf.org To: , cc: Subject: RE: [Bridge-mib] Consensus Call Speaking as a contributor - I always favored the approach that we should rather update the standard and recycle at Proposed, than progress MIB modules on the standard track, while they are not exactly in synch with the IEEE standard. This is the line they we also took in the Ethernet MIB WG. My employer is a mostly enterprise space vendor. I am not official speaker for the company, but I could cautiously say that my impression is that our customers do not care too much about the IETF Standards Status. If a standard does its job and ensures interoperability between vendors its fine with them. Only a small category of customers would look at the standards status before entering it in an RFP. However, my impression is that these customers will first include the IEEE 802.1 standard, and only second the MIB standard. What is the good of having a Full Standard with a MIB that is not in synch with the IEEE specification? In conclusion I personally favor option c in Bert's mail. Regards, Dan > -----Original Message----- > From: bridge-mib-bounces@ietf.org > [mailto:bridge-mib-bounces@ietf.org]On Behalf Of David B Harrington > Sent: 04 November, 2004 5:33 PM > To: bridge-mib@ietf.org > Subject: [Bridge-mib] Consensus Call > > > OK, Let me start a discussion here. This is important for a consensus > check, so please read and respond. > > My experience has been working for an equipment vendor. I have worked > in both the embedded system space and the pure vendor-neutral software > solution space. Here is what I have learned from that experience. > > Mib module official status becomes important on the agent side first; > once a mib hits PS it's a valid target for inclusion in project plans > (for those products that include the managed functionality). While > some mib modules get implemented from an I-D, the RFC publication > finalizes the design and an RFC# is marketable. Advancement to DS or > FS makes little difference - if the functionality is in the box, the > mib module should be done fairly soon after the functionality is > available, and if there is an RFC-level standard, that's good. The > tweaking that occurs between PS and DS and between DS and FS makes > little difference to an equipment vendor (except as non-marketable > maintenance work). > > MIB modules become important to vendor-neutral software developers > when enough equipment vendors support the MIB module to make it > worthwhile directly supporting it, and there is customer demand for > consistent management of the functionality. Most vendor-neutral > software vendors use table-driven or model-driven designs that largely > hide whether the implementation is the industry standard MIB module or > a proprietary MIB module with similar capabilites. The status of a MIB > module standard is largely irrelevant; the customer demand exists or > it doesn't. > > So, we are now faced with a decision to publish the SMIv2 version of > RFC1493 **with no semantic changes** or to publish an updated MIB > module that reflects the current underlying IEEE standard better, by > supporting 32-bit PathCost rather than only the 16-bit PathCost. > > How many people on this list actually care whether the standard status > is at PS or DS or FS, and why? Will advancing the standards level have > an **actual** impact on whether the implementation is done by your > company? Would recycling the MIB module at PS have a negative effect > on your company and its revenue stream? Would the benefit of having a > MIB module that is more current with IEEE standards offset any > negatives of recycling at PS? > > If you are not associated with a company, but rather a university or > an open-source product or whatever, will the status level have a real > impact on what you do? > > Ultimately the question to be answered is: Should we diminish the > functionality in order to advance the document in the standards track, > or should we add the 32-bit functionality even if we have to recycle > at Proposed? > > Thanks, > David Harrington > dbharrington@comcast.net > Bridge-mib co-chair > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On > > Behalf Of Juergen Schoenwaelder > > Sent: Tuesday, November 02, 2004 3:23 PM > > To: David B Harrington > > Cc: ietfdbh@comcast.net; 'Les Bell'; bridge-mib@ietf.org > > Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 > > > > On Tue, Nov 02, 2004 at 02:47:11PM -0500, David B Harrington wrote: > > > > > Can we resolve this (and any other issues) on the mailing > > list before > > > IETF61, please? > > > > Will be hard, but we can try. > > > > > These mib modules are already three years behind the > > charter schedule. > > > > Yes. But since the IETF meeting is next week, I would say > > that this week does not cause any significant delay. > > > > > We want to start the WG last call before IETF61, not wait > > until IETF61 > > > to start discussing possible solutions. > > > > Lets try to collect possible solutions: > > > > a) We remove the 32-bit path cost, move the BRIDGE-MIB to Standard > and > > start a new MIB module which defines the new object. > > > > a') We remove the 32-bit path cost, move the BRIDGE-MIB to > > Standard and > > tell the IEEE or who cares that they have to address this issue. > > > > b) We agree to change the range restriction by declaring that an > error > > or bug fix (even though it really is not, well yeah ...). We > don't > > introduce a new object, stepping of course formally on SMIv2 > rules. > > > > c) We do what the document currently does (introducing a new object) > > > and move the whole MIB module back to Proposed. > > > > d) We do what the document currently does and move forward, > > looking for > > the IESG feedback. Note that RFC 2026 says that a Draft > > standard "is > > normally considered to be a final specification, and changes are > > likely to be made only to solve specific problems encountered." > > Perhaps this is a specific problem encountered... > > > > e) We drop the whole document and just stick to RFC 1493. > > > > Any options I did forget? > > > > Any ideas how to select the winner? > > > > /js > > > > -- > > Juergen Schoenwaelder International > University Bremen > > P.O. Box 750 561, > > 28725 Bremen, Germany > > > > > > _______________________________________________ > Bridge-mib mailing list > Bridge-mib@ietf.org > https://www1.ietf.org/mailman/listinfo/bridge-mib > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Fri Nov 5 15:52:32 2004 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 PAA16361 for ; Fri, 5 Nov 2004 15:52:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQBKI-0003ww-70 for bridge-mib-archive@ietf.org; Fri, 05 Nov 2004 16:08:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQAtZ-0005LE-45; Fri, 05 Nov 2004 15:41:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQArr-0004SV-IO for bridge-mib@megatron.ietf.org; Fri, 05 Nov 2004 15:39:38 -0500 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 PAA15389 for ; Fri, 5 Nov 2004 15:39:29 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQB7e-0003Uw-Ub for bridge-mib@ietf.org; Fri, 05 Nov 2004 15:55:51 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A42A53107; Fri, 5 Nov 2004 21:38:54 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30220-04; Fri, 5 Nov 2004 21:38:53 +0100 (CET) Received: from james (I9f74.i.pppool.de [85.73.159.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 850743105; Fri, 5 Nov 2004 21:38:53 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CQArD-0000mP-Pw; Fri, 05 Nov 2004 21:38:51 +0100 Date: Fri, 5 Nov 2004 21:38:51 +0100 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Bridge-mib] Consensus Call Message-ID: <20041105203851.GA2995@james> Mail-Followup-To: David B Harrington , bridge-mib@ietf.org References: <20041102202312.GA2450@james> <200411041533.KAA01397@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411041533.KAA01397@ietf.org> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 On Thu, Nov 04, 2004 at 10:33:06AM -0500, David B Harrington wrote: > If you are not associated with a company, but rather a university or > an open-source product or whatever, will the status level have a real > impact on what you do? Most open source projects are driven by individual interests and in the bridge context, it is usually the MIBs that the vendors have implemented that count. (While there are open source briding implementations around, they usually do not come with an SNMP management interface since they run on general purpose boxes.) So standards status is largely irrelevant as far as I am concerned. Migration between versions is however an issues since we are like everybody else concerned about interoperability and we typically dislike to have complex code just because standards were never finished or made the coexistance rather complicated. In summary, I think open source coders look at these issues like probably most other management application writers, except that we have more freedom to ignore some proprietary solutions by just telling people why we do not support certain things. (You can't do that in a commercial setting I guess.) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Fri Nov 5 15:54:30 2004 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 PAA16593 for ; Fri, 5 Nov 2004 15:54:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQBMB-00041E-Q5 for bridge-mib-archive@ietf.org; Fri, 05 Nov 2004 16:10:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQB5J-0003Qn-RB; Fri, 05 Nov 2004 15:53:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQAwc-00072w-OT for bridge-mib@megatron.ietf.org; Fri, 05 Nov 2004 15:44:27 -0500 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 PAA15707 for ; Fri, 5 Nov 2004 15:44:24 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQBCQ-0003b4-Mt for bridge-mib@ietf.org; Fri, 05 Nov 2004 16:00:47 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id C136230E3; Fri, 5 Nov 2004 21:43:55 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30507-01; Fri, 5 Nov 2004 21:43:54 +0100 (CET) Received: from james (I9f74.i.pppool.de [85.73.159.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 9EA803105; Fri, 5 Nov 2004 21:43:54 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CQAw4-0000mW-Oq; Fri, 05 Nov 2004 21:43:52 +0100 Date: Fri, 5 Nov 2004 21:43:52 +0100 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Bridge-mib] Consensus Call Message-ID: <20041105204352.GB2995@james> Mail-Followup-To: David B Harrington , 'Tom Petch' , bridge-mib@ietf.org References: <044401c4c2b5$cd82ff80$0301a8c0@tom3> <200411042225.RAA14231@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411042225.RAA14231@ietf.org> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "'Tom Petch'" , bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Thu, Nov 04, 2004 at 05:25:02PM -0500, David B Harrington wrote: > My goal, to make it clear, is to get the documents finished. I don't > want to have to re-edit the documents to remove the PathCost32 because > that will take another four to six months to a year at the glacial > rate of this working group. I would like to simply last call the three > documents as they currently stand and be done. Any editing regarding the PathCost32 issue should be rather easy once we have formed an opinion. I now hold the editing token and I am fine to update the document on Friday or Saturday after the IETF if there is a final decision reached next week. From my point of view, all possible solutions (removing or keeping or changing) have more or less the same editing costs. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Fri Nov 5 16:19:40 2004 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 QAA19160 for ; Fri, 5 Nov 2004 16:19:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQBUk-0004cj-1U for bridge-mib-archive@ietf.org; Fri, 05 Nov 2004 16:19:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQBQ1-0007FA-1z; Fri, 05 Nov 2004 16:14:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQBNp-0005oC-3M for bridge-mib@megatron.ietf.org; Fri, 05 Nov 2004 16:12:33 -0500 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 QAA18583 for ; Fri, 5 Nov 2004 16:12:30 -0500 (EST) Message-Id: <200411052112.QAA18583@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQBNo-0004Rg-G7 for bridge-mib@ietf.org; Fri, 05 Nov 2004 16:12:32 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2004110521120001300bpul8e>; Fri, 5 Nov 2004 21:12:01 +0000 From: "David B Harrington" To: Subject: RE: [Bridge-mib] Consensus Call Date: Fri, 5 Nov 2004 16:11:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTDeCscvnk8Je79RgSXIlmm7rEVxwAAz6yg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <20041105204352.GB2995@james> X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: "'Tom Petch'" , bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Note that the RSTP-MIB has dependencies on PathCost32. This makes editing just a touch more difficultt, but not seriously so. dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On > Behalf Of Juergen Schoenwaelder > Sent: Friday, November 05, 2004 3:44 PM > To: David B Harrington > Cc: 'Tom Petch'; bridge-mib@ietf.org > Subject: Re: [Bridge-mib] Consensus Call > > On Thu, Nov 04, 2004 at 05:25:02PM -0500, David B Harrington wrote: > > > My goal, to make it clear, is to get the documents > finished. I don't > > want to have to re-edit the documents to remove the > PathCost32 because > > that will take another four to six months to a year at the glacial > > rate of this working group. I would like to simply last > call the three > > documents as they currently stand and be done. > > Any editing regarding the PathCost32 issue should be rather > easy once we have formed an opinion. I now hold the editing > token and I am fine to update the document on Friday or > Saturday after the IETF if there is a final decision reached > next week. From my point of view, all possible solutions > (removing or keeping or changing) have more or less the same > editing costs. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Wed Nov 10 08:08:24 2004 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 IAA04358 for ; Wed, 10 Nov 2004 08:08:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRsE0-0001Rc-TE for bridge-mib-archive@ietf.org; Wed, 10 Nov 2004 08:09:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRsAA-000540-F9; Wed, 10 Nov 2004 08:05:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRs30-00048G-HT for bridge-mib@megatron.ietf.org; Wed, 10 Nov 2004 07:58:03 -0500 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 HAA02855 for ; Wed, 10 Nov 2004 07:58:01 -0500 (EST) Received: from apollo.nbase.co.il ([194.90.137.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRs3w-0000wA-7E for bridge-mib@ietf.org; Wed, 10 Nov 2004 07:59:02 -0500 Received: from Alexr ([194.90.136.135]) by apollo.nbase.co.il (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-44418U200L2S100) with SMTP id AAA2815; Wed, 10 Nov 2004 14:56:56 +0200 From: arozin@mrv.com (Alex Ruzin) To: "'Congdon, Paul T \(ProCurve\)'" , Date: Wed, 10 Nov 2004 14:57:33 +0200 Message-ID: <00e401c4c724$d92aafe0$87885ac2@Alexr> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <85ECA15B7BB46944BFD4C73AEA554824E8A5A3@cacexc07.americas.cpqcorp.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: c2427de1554ed8e3804597b4bf60f110 Cc: bridge-mib@ietf.org Subject: [Bridge-mib] RE: [802.1] Alex Ruzin MSTP MIB Proposal - explanations X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arozin@mrv.com List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0827313004==" Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 2a25a3f15cd7c4f2ea7dd14d5f6b4bd1 This is a multi-part message in MIME format. --===============0827313004== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E5_01C4C735.9CB37FE0" This is a multi-part message in MIME format. ------=_NextPart_000_00E5_01C4C735.9CB37FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit (Sorry for HTML, but I want you to see a nice diagram below). I dare to provide a number of explanations for ruzin-mstp-mib-00.txt from http://www.ieee802.org/1/files/public/docs2004/ruzin-mstp-mib-00.txt This MIB contains 6 parts: mstpTraps, mstpGen, mstpPortTable, mstpMapTable, mstpXstTable and mstpXstPortTable: 1. mstpTraps help to get information about changes in MSTP active topology asynchronous notifications. Conditions and parameters seem to be clear, while may be discussed. 2. mstpGen. This group is dedicated to manage Bridge Protocol Entity, described in 12.8.1.1 and 12.8.1.3. In a certain sense this group reflects CIST, but without objects, that may be managed in mstpXstTable, see below. 3. mstpPortTable allows to manage physical ports, as it is described in 1.8.2.1., 1.80.2.3., 1.8.2.5 and 12.8.2.7. In a certain sense this group reflects CIST ports, but without objects, that may be managed in mstpXstPortTable, see below. 4. mstpMapTable serves for MSTI List management. It allows to build/delete instances and to map FIDs/VIDs (12.12). Actually, this table reflects MST Configuration Table in format, that is defined in 13.7 item 4). It must be admitted that I "grabbed" the idea of ranges in this table from malhotra-mstpmib-01.txt 5. mstpXstTable reflects instances - both CIST and MSTIs (12.8.1.2 and 12.8.1.4). It contains objects, common for these both types of instances, for example, mstpXstBridgePriority. 6. mstpXstPortTable is dedicated to manage ports inside instances - both CIST and MSTIs (12.8.2.2., 12.8.2.4 and 12.8.2.6). It contains objects, describing port and common for these both types of instances, for example, mstpXstPortState or mstpXstPortPriority. Note, that this table has mstpXstPortInternalRootCost, while mstpPortAdminExternalPathCost belongs to mstpPortTable. Important, that the index mstpXstId in mstpXstTable and mstpXstPortXstId in mstpXstPortTable have type MstiOrCistInstanceIndex : "value of zero" corresponds to CIST. Now, I'd like to mention in passing objects, that are not defined in .1s Let us begin from less questionable. 1. mstpPortAutoEdge. It came from new .1d 917.13.3) and I don't expect many objections here :) 2. mstpXstPortRole. The exploitation of MSTP shows, that managers of complicated networks want to know reasons of ports states assignations. So, they concerned with ports roles. In my opinion, this object is important not only debug purposes. 3. The similar destination have so called BpduCounters. Let's say, when a port stops to be RootPort, a manager may see, that receive BpduCounters on this port do not rise. He may trace bridges and select a point of failure. And what is more, I'd define an object mstpXstPortRxMstBpduCounter to count MSTI Configuration Messages. Sure, all these counters are optional: if an agent cannot provide for them it must return zero. 4. mstpGenCapable. A manager has to know, what version of STP the bridge supplies. If it supplies a number of versions (see mstpGenForceVersion), the eldest one must be returned. 5. mstpGenForceVersion. If the bridge can supply a number of versions of STP (let's say, it has a number of corresponding engines) a manager may want to enable one of them (and of course to disable all others) he may use with this object. This object also show which engine is currently enabled. 6. The value forceNonStp(0) of object mstpGenForceVersion. I remember a few of dispute both in IETF and in IEEE : what is STP disabled into a bridge. I know and share a position of IEEE, that there may not be bridge with STP disabled, nevertheless... The term "Spanning Tree Protocol Emulation" here means, that a bridge is transparent for received BPDUs (does flooding: transmits from all ports, without tags and without VLAN participation) and processes Topology Change bit: does appropriate FDB flushing. 7. mstpPortAdminNonStp. Certain port may be configured as a port, that does not participate in any STP operations: a) it discards all BDPUs, b) does not send BPDUs and c) is always in forwarding state. This option may help to termination point of STP domain. 8. mstpXstMasterPort. Servers the same purposes as mstpXstPortRole and BpduCounters. On the other hand, is not less helpful than mstpXstRootPort; furthermore it may help to indicate fallacious instance mapping (when a manager expects bridges in the same region, this object must be zero). 9. Both mstpXstRootPort and mstpXstMasterPort have type PortIndexOrZero. Brief structure of the MIB (result of "snmptranslate -Tp"): +--mstp(XXX) | +--mstpTraps(0) | | | +--dos1sNewRootBridge(1) | +--dos1sNewRootPort(2) | +--dos1sTopologyChange(3) | +--mstpGen(10) | | | +-- -RW- INTEGER mstpGenBridgeMaxAge(2) | | Textual Convention: Timeout | | Range: 600..4000 | +-- -RW- INTEGER mstpGenBridgeHelloTime(3) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -RW- INTEGER mstpGenBridgeForwardDelay(4) | | Textual Convention: Timeout | | Range: 400..3000 | +-- -R-- INTEGER mstpGenMaxAge(8) | | Textual Convention: Timeout | | Range: 600..4000 | +-- -R-- INTEGER mstpGenHelloTime(9) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -R-- INTEGER mstpGenForwardDelay(10) | | Textual Convention: Timeout | | Range: 400..3000 | +-- -RW- Integer32 mstpGenMaxHops(14) | | Range: 4..30 | +-- -RW- INTEGER mstpGenHoldTime(15) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -RW- INTEGER mstpGenMigrateTime(16) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -RW- EnumVal mstpGenPathCostDefault(18) | | Values: pathCostDefault8021d1998(1), pathCostDefault8021t2001(2) | +-- -R-- EnumVal mstpGenCapable(19) | | Values: nonStp(0), dot1d1998(1), dot1w(2), dot1d2004(3), | | dot1s(4), dot1q(5), unknown(6) | +-- -RW- EnumVal mstpGenForceVersion(20) | | Values: forceNonStp(0), forceLegacyDot1d(1), | | forceDot1w(2), autoDot1s(3), unknown(4) | +-- -RW- String mstpGenCfgName(21) | | Textual Convention: DisplayString | | Size: 32 | +-- -RW- Integer32 mstpGenRevLevel(22) | +-- -R-- String mstpGenReginalRoot(26) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- Integer32 mstpGenExternalRootCost(27) | +--mstpPortTable(11) | | | +--mstpPortEntry(1) | | Index: mstpPortIndex | | | +-- -R-- Integer32 mstpPortIndex(1) | | Textual Convention: PortIndex | | Range: 1..2147483647 | +-- -RW- EnumVal mstpPortAdminMACEnable(2) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -R-- EnumVal mstpPortOperMACEnable(3) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -R-- TimeTicks mstpPortUpTime(4) | +-- -RW- Integer32 mstpPortAdminExternalPathCost(5) | | Range: 0..200000000 | +-- -R-- Integer32 mstpPortOperExternalPathCost(6) | +-- -RW- EnumVal mstpPortAdminEdge(7) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -R-- EnumVal mstpPortOperEdge(8) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -RW- EnumVal mstpPortAutoEdge(9) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -RW- EnumVal mstpPortAdminPointToPoint(10) | | Values: forceTrue(0), forceFalse(1), auto(2) | +-- -R-- EnumVal mstpPortOperPointToPoint(11) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -RW- INTEGER mstpPortHelloTime(12) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -RW- EnumVal mstpPortAdminNonStp(13) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -RW- EnumVal mstpPortProtocolMigration(14) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -R-- Counter mstpPortRxTcnBpduCounter(15) | | Textual Convention: BpduCounter | +-- -R-- Counter mstpPortRxCfgBpduCounter(16) | +-- -R-- Counter mstpPortRxRstBpduCounter(17) | +-- -R-- Counter mstpPortRxMstBpduCounter(18) | +-- -R-- Counter mstpPortTxTcnBpduCounter(19) | +-- -R-- Counter mstpPortTxCfgBpduCounter(20) | +-- -R-- Counter mstpPortTxRstBpduCounter(21) | +-- -R-- Counter mstpPortTxMstBpduCounter(22) | +--mstpMapTable(12) | | | +--mstpMapEntry(1) | | Index: mstpMapMSTiID, mstpMapVlanRangeIndex | | | +-- ---- Integer32 mstpMapMSTiID(1) | | Textual Convention: MstiInstanceIndex | | Range: 1..64 | +-- ---- Integer32 mstpMapVlanRangeIndex(2) | | Range: 1..4094 | | | +--mstpMapVlanMin(3) | | | +--mstpMapVlanMax(4) | | | +-- CR-- EnumVal mstpMapRowStatus(9) | Textual Convention: RowStatus | Values: active(1), notInService(2), notReady(3), | createAndGo(4), createAndWait(5), destroy(6) | +--mstpXstTable(13) | | | +--mstpXstEntry(1) | | Index: mstpXstId | | | +-- ---- Integer32 mstpXstId(1) | | Textual Convention: MstiOrCistInstanceIndex | | Range: 0..64 | +-- -RW- Integer32 mstpXstBridgePriority(2) | | Range: 0..61440 | +-- -R-- String mstpXstBridgeId(3) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- String mstpXstDesignatedRoot(4) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- String mstpXstDesignatedBridge(5) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- Integer32 mstpXstInternalRootCost(6) | +-- -R-- Integer32 mstpXstRootPort(7) | | Textual Convention: PortIndexOrZero | | Range: 0..2147483647 | +-- -R-- Integer32 mstpXstMasterPort(8) | | Textual Convention: PortIndexOrZero | | Range: 0..2147483647 | +-- -R-- TimeTicks mstpXstTimeSinceTopologyChange(11) | +-- -R-- Counter mstpXstTopologyChangesCount(12) | +-- -R-- EnumVal mstpXstTopologyChangeFlag(13) | Textual Convention: TruthValue | Values: true(1), false(2) | +--mstpXstPortTable(14) | +--mstpXstPortEntry(1) | Index: mstpXstPortXstId, mstpXstPortIndex | +-- ---- Integer32 mstpXstPortXstId(1) | Textual Convention: MstiOrCistInstanceIndex | Range: 0..64 +-- -R-- Integer32 mstpXstPortIndex(2) | Textual Convention: PortIndex | Range: 1..2147483647 +-- -R-- EnumVal mstpXstPortState(3) | Values: disabled(1), discarding(1), learning(2), forwarding(3), unknown(4) +-- -R-- EnumVal mstpXstPortRole(4) | Values: disabled(1), alternate(2), backup(3), root(4), | designated(5), master(6), nonStp(7), unknown(8) +-- -R-- String mstpXstPortDesignatedRoot(6) | Textual Convention: BridgeId | Size: 8 +-- -R-- Integer32 mstpXstPortExternalRootCost(7) +-- -R-- String mstpXstPortRegionalBridge(8) | Textual Convention: BridgeId | Size: 8 +-- -R-- Integer32 mstpXstPortInternalRootCost(9) +-- -R-- String mstpXstPortDesignatedBridge(10) | Textual Convention: BridgeId | Size: 8 +-- -R-- String mstpXstPortDesignatedPort(14) | Textual Convention: PortId | Size: 2 +-- -RW- Integer32 mstpXstPortPriority(15) | Range: 0..255 +-- -RW- Integer32 mstpXstPortAdminInternalPathCost(16) | Range: 0..200000000 +-- -R-- Integer32 mstpXstPortOperInternalPathCost(17) On Wednesday, November 03, 2004 4:15 PM Congdon, Paul T (ProCurve) wrote: > I've uploaded Alex Ruzin's MSTP MIB. Note that this is slightly > different than the MIB that Alex cut-and-pasted to a previous email. > The document may be retrieved at: > > http://www.ieee802.org/1/files/public/docs2004/ruzin-mstp-mib-00.txt ------=_NextPart_000_00E5_01C4C735.9CB37FE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(Sorry for HTML, but I want you to see = a nice=20 diagram below).

I = dare to provide=20 a number of explanations for ruzin-mstp-mib-00.txt from http://www.ieee802.org/1/files/public/docs2004/ruzin-mstp-mib-00.txt=

This MIB contains 6 parts: mstpTraps, = mstpGen,=20 mstpPortTable,
mstpMapTable, mstpXstTable and mstpXstPortTable:


1. mstpTraps help to get information about changes in MSTP=20 active
    topology asynchronous notifications. = Conditions and=20 parameters seem to be
    clear, while may be = discussed.
2.=20 mstpGen. This group is dedicated to manage Bridge Protocol=20 Entity,
    described in 12.8.1.1 and 12.8.1.3. In a = certain=20 sense this group reflects
    CIST, but without = objects, that=20 may be managed in mstpXstTable, see below.
3. mstpPortTable allows to = manage=20 physical ports, as it is described in
    1.8.2.1., = 1.80.2.3.,=20 1.8.2.5 and 12.8.2.7. In a certain sense this group=20 reflects
    CIST ports, but without objects, that may = be=20 managed in mstpXstPortTable,
    see below.
4. = mstpMapTable=20 serves for MSTI List management. It allows to = build/delete
   =20 instances and to map FIDs/VIDs (12.12). Actually, this table reflects=20 MST
    Configuration Table in format, that is defined = in 13.7=20 item 4).
    It must be admitted that I "grabbed" the = idea of=20 ranges in this table
    from = malhotra-mstpmib-01.txt
5.=20 mstpXstTable reflects instances - both CIST and MSTIs (12.8.1.2 and=20 12.8.1.4).
    It contains objects, common for these = both=20 types of instances, for example,
   =20 mstpXstBridgePriority.
6. mstpXstPortTable is dedicated to manage = ports=20 inside instances - both CIST
    and MSTIs (12.8.2.2., = 12.8.2.4 and 12.8.2.6). It contains objects, = describing
   =20 port and common for these both types of instances, for=20 example,
    mstpXstPortState or mstpXstPortPriority. = Note,=20 that this table has
    mstpXstPortInternalRootCost, = while=20 mstpPortAdminExternalPathCost belongs
    to=20 mstpPortTable.

Important, that the index mstpXstId in = mstpXstTable and=20 mstpXstPortXstId in
mstpXstPortTable have type = MstiOrCistInstanceIndex :=20 "value of zero"
corresponds to CIST.

Now, I'd like to mention = in=20 passing objects, that are not defined in .1s
Let us begin from less=20 questionable.
1. mstpPortAutoEdge. It came from new .1d 917.13.3) and = I don't=20 expect
    many objections here :)
2. = mstpXstPortRole. The=20 exploitation of MSTP shows, that managers
    of = complicated=20 networks want to know reasons of ports states
   =20 assignations. So, they concerned with ports roles. In my opinion,=20 this
    object is important not only debug = purposes.
3.=20 The similar destination have so called BpduCounters. Let's say,=20 when
    a port stops to be RootPort, a manager may = see, that=20 receive BpduCounters
    on this port do not rise. He = may=20 trace bridges and select a point of
    failure. And = what is=20 more, I'd define an object = mstpXstPortRxMstBpduCounter
    to=20 count MSTI Configuration Messages. Sure, all these counters are=20 optional:
    if an agent cannot provide for them it = must=20 return zero.
4. mstpGenCapable. A manager has to know, what version = of STP=20 the bridge
    supplies. If it supplies a number of = versions=20 (see mstpGenForceVersion),
    the eldest one must be=20 returned.
5. mstpGenForceVersion. If the bridge can supply a number = of=20 versions of STP
    (let's say, it has a number of=20 corresponding engines) a manager may want
    to = enable one of=20 them (and of course to disable all others) he may use = with
   =20 this object. This object also show which engine is currently = enabled.
6. The=20 value forceNonStp(0) of object mstpGenForceVersion. I remember=20 a
    few of dispute both in IETF and in IEEE : what = is STP=20 disabled into a bridge.
    I know and share a = position of=20 IEEE, that there may not be bridge with STP
    = disabled,=20 nevertheless...
    The term "Spanning Tree Protocol=20 Emulation" here means, that a bridge is
    = transparent for=20 received BPDUs (does flooding: transmits from all ports,=20 without
    tags and without VLAN participation) and = processes=20 Topology Change bit:
    does appropriate FDB = flushing.
7.=20 mstpPortAdminNonStp. Certain port may be configured as a port, that does = not
    participate in any STP operations: a) it = discards all=20 BDPUs, b) does not send
    BPDUs and c) is always in=20 forwarding state. This option may help to = termination
   =20 point of STP domain.
8. mstpXstMasterPort. Servers the same purposes = as=20 mstpXstPortRole and
    BpduCounters. On the other = hand, is=20 not less helpful than mstpXstRootPort;
    furthermore = it may=20 help to indicate fallacious instance mapping (when = a
   =20 manager expects bridges in the same region, this object must be = zero).
9.=20 Both mstpXstRootPort and mstpXstMasterPort have type=20 PortIndexOrZero.


Brief structure of the MIB (result of "snmptranslate = -Tp"):
+--mstp(XXX)
  =20 |
   +--mstpTraps(0)
   |  = |
  =20 |  +--dos1sNewRootBridge(1)
   | =20 +--dos1sNewRootPort(2)
   | =20 +--dos1sTopologyChange(3)
   |
  =20 +--mstpGen(10)
   |  |
   |  +-- = -RW-=20 INTEGER   mstpGenBridgeMaxAge(2)
   | =20 |        Textual Convention:=20 Timeout
   |  = |       =20 Range: 600..4000
   |  +-- -RW- INTEGER  =20 mstpGenBridgeHelloTime(3)
   | =20 |        Textual Convention:=20 Timeout
   |  = |       =20 Range: 100..1000
   |  +-- -RW- INTEGER  =20 mstpGenBridgeForwardDelay(4)
   | =20 |        Textual Convention:=20 Timeout
   |  = |       =20 Range: 400..3000
   |  +-- -R-- INTEGER  =20 mstpGenMaxAge(8)
   | =20 |        Textual Convention:=20 Timeout
   |  = |       =20 Range: 600..4000
   |  +-- -R-- INTEGER  =20 mstpGenHelloTime(9)
   | =20 |        Textual Convention:=20 Timeout
   |  = |       =20 Range: 100..1000
   |  +-- -R-- INTEGER  =20 mstpGenForwardDelay(10)
   | =20 |        Textual Convention:=20 Timeout
   |  = |       =20 Range: 400..3000
   |  +-- -RW- Integer32=20 mstpGenMaxHops(14)
   | =20 |        Range: 4..30
   = | =20 +-- -RW- INTEGER   mstpGenHoldTime(15)
   |  = |        Textual Convention:=20 Timeout
   |  = |       =20 Range: 100..1000
   |  +-- -RW- INTEGER  =20 mstpGenMigrateTime(16)
   | =20 |        Textual Convention:=20 Timeout
   |  = |       =20 Range: 100..1000
   |  +-- -RW- EnumVal  =20 mstpGenPathCostDefault(18)
   | =20 |        Values: = pathCostDefault8021d1998(1),=20 pathCostDefault8021t2001(2)
   |  +-- -R-- = EnumVal  =20 mstpGenCapable(19)
   | =20 |        Values: nonStp(0), = dot1d1998(1),=20 dot1w(2), dot1d2004(3),
   | =20 |            =    =20 dot1s(4), dot1q(5), unknown(6)
   |  +-- -RW-=20 EnumVal   mstpGenForceVersion(20)
   | =20 |        Values: forceNonStp(0),=20 forceLegacyDot1d(1),
   | =20 |            =    =20 forceDot1w(2), autoDot1s(3), unknown(4)
   |  +-- -RW- = String    mstpGenCfgName(21)
   | =20 |        Textual Convention:=20 DisplayString
   | =20 |        Size: 32
   = |  +--=20 -RW- Integer32 mstpGenRevLevel(22)
   |  +-- -R--=20 String    mstpGenReginalRoot(26)
   | =20 |        Textual Convention:=20 BridgeId
   |  = |       =20 Size: 8
   |  +-- -R-- Integer32=20 mstpGenExternalRootCost(27)
   |
  =20 +--mstpPortTable(11)
   |  |
   | =20 +--mstpPortEntry(1)
   |     |  = Index:=20 mstpPortIndex
   |     = |
  =20 |     +-- -R-- Integer32 = mstpPortIndex(1)
  =20 |     |        = Textual=20 Convention: PortIndex
   |    =20 |        Range: = 1..2147483647
  =20 |     +-- -RW- EnumVal  =20 mstpPortAdminMACEnable(2)
   |    =20 |        Textual Convention:=20 TruthValue
   |    =20 |        Values: true(1),=20 false(2)
   |     +-- -R-- = EnumVal  =20 mstpPortOperMACEnable(3)
   |    =20 |        Textual Convention:=20 TruthValue
   |    =20 |        Values: true(1),=20 false(2)
   |     +-- -R-- TimeTicks=20 mstpPortUpTime(4)
   |     +-- -RW- = Integer32=20 mstpPortAdminExternalPathCost(5)
   = |    =20 |        Range: = 0..200000000
  =20 |     +-- -R-- Integer32=20 mstpPortOperExternalPathCost(6)
   = |     +--=20 -RW- EnumVal   mstpPortAdminEdge(7)
  =20 |     |        = Textual=20 Convention: TruthValue
   |    =20 |        Values: true(1),=20 false(2)
   |     +-- -R-- = EnumVal  =20 mstpPortOperEdge(8)
   |    =20 |        Textual Convention:=20 TruthValue
   |    =20 |        Values: true(1),=20 false(2)
   |     +-- -RW- = EnumVal  =20 mstpPortAutoEdge(9)
   |    =20 |        Textual Convention:=20 TruthValue
   |    =20 |        Values: true(1),=20 false(2)
   |     +-- -RW- = EnumVal  =20 mstpPortAdminPointToPoint(10)
   |    =20 |        Values: forceTrue(0), = forceFalse(1),=20 auto(2)
   |     +-- -R-- = EnumVal  =20 mstpPortOperPointToPoint(11)
   |    =20 |        Textual Convention:=20 TruthValue
   |    =20 |        Values: true(1),=20 false(2)
   |     +-- -RW- = INTEGER  =20 mstpPortHelloTime(12)
   |    =20 |        Textual Convention:=20 Timeout
   |    =20 |        Range: = 100..1000
  =20 |     +-- -RW- EnumVal  =20 mstpPortAdminNonStp(13)
   |    =20 |        Textual Convention:=20 TruthValue
   |    =20 |        Values: true(1),=20 false(2)
   |     +-- -RW- = EnumVal  =20 mstpPortProtocolMigration(14)
   |    =20 |        Textual Convention:=20 TruthValue
   |    =20 |        Values: true(1),=20 false(2)
   |     +-- -R-- = Counter  =20 mstpPortRxTcnBpduCounter(15)
   |    =20 |        Textual Convention:=20 BpduCounter
   |     +-- -R--=20 Counter   mstpPortRxCfgBpduCounter(16)
  =20 |     +-- -R-- Counter  =20 mstpPortRxRstBpduCounter(17)
   |     = +-- -R--=20 Counter   mstpPortRxMstBpduCounter(18)
  =20 |     +-- -R-- Counter  =20 mstpPortTxTcnBpduCounter(19)
   |     = +-- -R--=20 Counter   mstpPortTxCfgBpduCounter(20)
  =20 |     +-- -R-- Counter  =20 mstpPortTxRstBpduCounter(21)
   |     = +-- -R--=20 Counter   mstpPortTxMstBpduCounter(22)
  =20 |
   +--mstpMapTable(12)
   |  = |
  =20 |  +--mstpMapEntry(1)
   |     = | =20 Index: mstpMapMSTiID, mstpMapVlanRangeIndex
  =20 |     |
   |     = +-- ----=20 Integer32 mstpMapMSTiID(1)
   |    =20 |        Textual Convention:=20 MstiInstanceIndex
   |    =20 |        Range: 1..64
   = |     +-- ---- Integer32=20 mstpMapVlanRangeIndex(2)
   |    =20 |        Range: = 1..4094
  =20 |     |
   |    =20 +--mstpMapVlanMin(3)
   |     = |
  =20 |     +--mstpMapVlanMax(4)
  =20 |     |
   |     = +-- CR--=20 EnumVal   mstpMapRowStatus(9)
  =20 |            =  =20 Textual Convention: RowStatus
  =20 |            =  =20 Values: active(1), notInService(2), notReady(3),
  =20 |            =          =20 createAndGo(4), createAndWait(5), destroy(6)
   = |
  =20 +--mstpXstTable(13)
   |  |
   | =20 +--mstpXstEntry(1)
   |     |  = Index:=20 mstpXstId
   |     |
  =20 |     +-- ---- Integer32 = mstpXstId(1)
  =20 |     |        = Textual=20 Convention: MstiOrCistInstanceIndex
   = |    =20 |        Range: 0..64
   = |     +-- -RW- Integer32=20 mstpXstBridgePriority(2)
   |    =20 |        Range: = 0..61440
  =20 |     +-- -R-- String   =20 mstpXstBridgeId(3)
   |    =20 |        Textual Convention:=20 BridgeId
   |    =20 |        Size: 8
  =20 |     +-- -R-- String   =20 mstpXstDesignatedRoot(4)
   |    =20 |        Textual Convention:=20 BridgeId
   |    =20 |        Size: 8
  =20 |     +-- -R-- String   =20 mstpXstDesignatedBridge(5)
   |    =20 |        Textual Convention:=20 BridgeId
   |    =20 |        Size: 8
  =20 |     +-- -R-- Integer32=20 mstpXstInternalRootCost(6)
   |     +-- = -R--=20 Integer32 mstpXstRootPort(7)
   |    =20 |        Textual Convention:=20 PortIndexOrZero
   |    =20 |        Range: = 0..2147483647
  =20 |     +-- -R-- Integer32=20 mstpXstMasterPort(8)
   |    =20 |        Textual Convention:=20 PortIndexOrZero
   |    =20 |        Range: = 0..2147483647
  =20 |     +-- -R-- TimeTicks=20 mstpXstTimeSinceTopologyChange(11)
   = |     +--=20 -R-- Counter   mstpXstTopologyChangesCount(12)
   = |     +-- -R-- EnumVal  =20 mstpXstTopologyChangeFlag(13)
  =20 |            =  =20 Textual Convention: TruthValue
  =20 |            =  =20 Values: true(1), false(2)
   |
  =20 +--mstpXstPortTable(14)
     =20 |
     =20 +--mstpXstPortEntry(1)
        = ;=20 |  Index: mstpXstPortXstId,=20 mstpXstPortIndex
        =20 |
         +-- ---- Integer32 = mstpXstPortXstId(1)
        =20 |        Textual Convention:=20 MstiOrCistInstanceIndex
       &nbs= p;=20 |        Range:=20 0..64
         +-- -R-- = Integer32=20 mstpXstPortIndex(2)
        =20 |        Textual Convention:=20 PortIndex
        =20 |        Range:=20 1..2147483647
         +-- = -R--=20 EnumVal  =20 mstpXstPortState(3)
        =20 |        Values: disabled(1), = discarding(1),=20 learning(2), forwarding(3),=20 unknown(4)
         +-- -R--=20 EnumVal  =20 mstpXstPortRole(4)
        =20 |        Values: disabled(1), = alternate(2),=20 backup(3), root(4),
        =20 |            =    =20 designated(5), master(6), nonStp(7),=20 unknown(8)
         +-- -R--=20 String   =20 mstpXstPortDesignatedRoot(6)
       = ; =20 |        Textual Convention:=20 BridgeId
        =20 |        Size:=20 8
         +-- -R-- Integer32 = mstpXstPortExternalRootCost(7)
      &nb= sp; =20 +-- -R-- String   =20 mstpXstPortRegionalBridge(8)
       = ; =20 |        Textual Convention:=20 BridgeId
        =20 |        Size:=20 8
         +-- -R-- Integer32 = mstpXstPortInternalRootCost(9)
      &nb= sp; =20 +-- -R-- String   =20 mstpXstPortDesignatedBridge(10)
      &n= bsp; =20 |        Textual Convention:=20 BridgeId
        =20 |        Size:=20 8
         +-- -R--=20 String   =20 mstpXstPortDesignatedPort(14)
      &nbs= p; =20 |        Textual Convention:=20 PortId
        =20 |        Size:=20 2
         +-- -RW- Integer32 = mstpXstPortPriority(15)
       &nbs= p;=20 |        Range:=20 0..255
         +-- -RW- = Integer32=20 mstpXstPortAdminInternalPathCost(16)
     &nb= sp;  =20 |        Range:=20 0..200000000
         +-- = -R--=20 Integer32 mstpXstPortOperInternalPathCost(17)

On Wednesday,=20 November 03, 2004 4:15 PM  Congdon, Paul T (ProCurve)=20 wrote:
> I've uploaded Alex Ruzin's = MSTP=20 MIB.  Note that this is slightly
> different than the MIB = that Alex=20 cut-and-pasted to a previous email.
> The document may be = retrieved=20 at:
>
> http://www.ieee802.org/1/files/public/docs200= 4/ruzin-mstp-mib-00.txt

------=_NextPart_000_00E5_01C4C735.9CB37FE0-- --===============0827313004== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib --===============0827313004==-- From bridge-mib-bounces@ietf.org Wed Nov 10 15:13:48 2004 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 PAA22229 for ; Wed, 10 Nov 2004 15:13:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRyrl-0003zn-PO for bridge-mib-archive@ietf.org; Wed, 10 Nov 2004 15:14:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRymV-000443-43; Wed, 10 Nov 2004 15:09:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRyau-0002NQ-3a for bridge-mib@megatron.ietf.org; Wed, 10 Nov 2004 14:57:29 -0500 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 OAA19623 for ; Wed, 10 Nov 2004 14:57:25 -0500 (EST) Message-Id: <200411101957.OAA19623@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRybu-0003Vb-OY for bridge-mib@ietf.org; Wed, 10 Nov 2004 14:58:31 -0500 Received: from djyxpy41 (unknown[130.129.132.118]) by comcast.net (sccrmhc11) with SMTP id <2004111019565501100mf70je>; Wed, 10 Nov 2004 19:56:55 +0000 From: "David B Harrington" To: , "'Congdon, Paul T \(ProCurve\)'" , Subject: RE: [Bridge-mib] RE: [802.1] Alex Ruzin MSTP MIB Proposal - explanations Date: Wed, 10 Nov 2004 14:56:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTHJlwJYuIVWAvDRaiLFjm97achRAANWgVQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <00e401c4c724$d92aafe0$87885ac2@Alexr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 715d0e6950aaebd45af78ef9318d0186 Content-Transfer-Encoding: 7bit Cc: bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 9178bae9f85419fdc08e9f2c86e345d0 Content-Transfer-Encoding: 7bit Hi Alex, Thanks for the explanation. As Bridge WG co-chair, I need to address the MSTP MIB work as we transition development of MIB modules for 802.1 technologies from IETF to IEEE. The MSTP-MIB is out of scope for the IETF BridgeMIB WG, so technical discussion of proposals should not be posted to the Bridge WG mailing list. The appropriate mailing list for MSTP-MIB discussion is STDS-802-1-L@listserv.ieee.org. To subscribe to the STDS-802-1-L list, go to http://www.ieee802.org/1/email-pages/ To see the general information about 802,1, including how they work and how to participate, go to http://www.ieee802.org/1/ Currently, the discussion on STDS-802-1-L is whether to develop a PAR for this work. In IETF terms, the IEEE discussion is whether to add the MSTP-MIB to their charter. They have a formal procedure that needs to be followed. If you have a document related to MSTP-MIB, you can have it posted to the documents folder via the 802.1 chair or vice-chair. I follow the STDS-802-1-L list, and will be happy to advise the Bridge WG that such documents have been posted. (feel free to "ping" me that such documents have been posted on the IEEE web site.) David Harrington dbharrington@comcast.net Bridge WG co-chair ________________________________ From: bridge-mib-bounces@ietf.org [mailto:bridge-mib-bounces@ietf.org] On Behalf Of Alex Ruzin Sent: Wednesday, November 10, 2004 7:58 AM To: 'Congdon, Paul T (ProCurve)'; STDS-802-1-L@listserv.ieee.org Cc: bridge-mib@ietf.org Subject: [Bridge-mib] RE: [802.1] Alex Ruzin MSTP MIB Proposal - explanations (Sorry for HTML, but I want you to see a nice diagram below). I dare to provide a number of explanations for ruzin-mstp-mib-00.txt from http://www.ieee802.org/1/files/public/docs2004/ruzin-mstp-mib-00.txt This MIB contains 6 parts: mstpTraps, mstpGen, mstpPortTable, mstpMapTable, mstpXstTable and mstpXstPortTable: 1. mstpTraps help to get information about changes in MSTP active topology asynchronous notifications. Conditions and parameters seem to be clear, while may be discussed. 2. mstpGen. This group is dedicated to manage Bridge Protocol Entity, described in 12.8.1.1 and 12.8.1.3. In a certain sense this group reflects CIST, but without objects, that may be managed in mstpXstTable, see below. 3. mstpPortTable allows to manage physical ports, as it is described in 1.8.2.1., 1.80.2.3., 1.8.2.5 and 12.8.2.7. In a certain sense this group reflects CIST ports, but without objects, that may be managed in mstpXstPortTable, see below. 4. mstpMapTable serves for MSTI List management. It allows to build/delete instances and to map FIDs/VIDs (12.12). Actually, this table reflects MST Configuration Table in format, that is defined in 13.7 item 4). It must be admitted that I "grabbed" the idea of ranges in this table from malhotra-mstpmib-01.txt 5. mstpXstTable reflects instances - both CIST and MSTIs (12.8.1.2 and 12.8.1.4). It contains objects, common for these both types of instances, for example, mstpXstBridgePriority. 6. mstpXstPortTable is dedicated to manage ports inside instances - both CIST and MSTIs (12.8.2.2., 12.8.2.4 and 12.8.2.6). It contains objects, describing port and common for these both types of instances, for example, mstpXstPortState or mstpXstPortPriority. Note, that this table has mstpXstPortInternalRootCost, while mstpPortAdminExternalPathCost belongs to mstpPortTable. Important, that the index mstpXstId in mstpXstTable and mstpXstPortXstId in mstpXstPortTable have type MstiOrCistInstanceIndex : "value of zero" corresponds to CIST. Now, I'd like to mention in passing objects, that are not defined in .1s Let us begin from less questionable. 1. mstpPortAutoEdge. It came from new .1d 917.13.3) and I don't expect many objections here :) 2. mstpXstPortRole. The exploitation of MSTP shows, that managers of complicated networks want to know reasons of ports states assignations. So, they concerned with ports roles. In my opinion, this object is important not only debug purposes. 3. The similar destination have so called BpduCounters. Let's say, when a port stops to be RootPort, a manager may see, that receive BpduCounters on this port do not rise. He may trace bridges and select a point of failure. And what is more, I'd define an object mstpXstPortRxMstBpduCounter to count MSTI Configuration Messages. Sure, all these counters are optional: if an agent cannot provide for them it must return zero. 4. mstpGenCapable. A manager has to know, what version of STP the bridge supplies. If it supplies a number of versions (see mstpGenForceVersion), the eldest one must be returned. 5. mstpGenForceVersion. If the bridge can supply a number of versions of STP (let's say, it has a number of corresponding engines) a manager may want to enable one of them (and of course to disable all others) he may use with this object. This object also show which engine is currently enabled. 6. The value forceNonStp(0) of object mstpGenForceVersion. I remember a few of dispute both in IETF and in IEEE : what is STP disabled into a bridge. I know and share a position of IEEE, that there may not be bridge with STP disabled, nevertheless... The term "Spanning Tree Protocol Emulation" here means, that a bridge is transparent for received BPDUs (does flooding: transmits from all ports, without tags and without VLAN participation) and processes Topology Change bit: does appropriate FDB flushing. 7. mstpPortAdminNonStp. Certain port may be configured as a port, that does not participate in any STP operations: a) it discards all BDPUs, b) does not send BPDUs and c) is always in forwarding state. This option may help to termination point of STP domain. 8. mstpXstMasterPort. Servers the same purposes as mstpXstPortRole and BpduCounters. On the other hand, is not less helpful than mstpXstRootPort; furthermore it may help to indicate fallacious instance mapping (when a manager expects bridges in the same region, this object must be zero). 9. Both mstpXstRootPort and mstpXstMasterPort have type PortIndexOrZero. Brief structure of the MIB (result of "snmptranslate -Tp"): +--mstp(XXX) | +--mstpTraps(0) | | | +--dos1sNewRootBridge(1) | +--dos1sNewRootPort(2) | +--dos1sTopologyChange(3) | +--mstpGen(10) | | | +-- -RW- INTEGER mstpGenBridgeMaxAge(2) | | Textual Convention: Timeout | | Range: 600..4000 | +-- -RW- INTEGER mstpGenBridgeHelloTime(3) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -RW- INTEGER mstpGenBridgeForwardDelay(4) | | Textual Convention: Timeout | | Range: 400..3000 | +-- -R-- INTEGER mstpGenMaxAge(8) | | Textual Convention: Timeout | | Range: 600..4000 | +-- -R-- INTEGER mstpGenHelloTime(9) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -R-- INTEGER mstpGenForwardDelay(10) | | Textual Convention: Timeout | | Range: 400..3000 | +-- -RW- Integer32 mstpGenMaxHops(14) | | Range: 4..30 | +-- -RW- INTEGER mstpGenHoldTime(15) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -RW- INTEGER mstpGenMigrateTime(16) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -RW- EnumVal mstpGenPathCostDefault(18) | | Values: pathCostDefault8021d1998(1), pathCostDefault8021t2001(2) | +-- -R-- EnumVal mstpGenCapable(19) | | Values: nonStp(0), dot1d1998(1), dot1w(2), dot1d2004(3), | | dot1s(4), dot1q(5), unknown(6) | +-- -RW- EnumVal mstpGenForceVersion(20) | | Values: forceNonStp(0), forceLegacyDot1d(1), | | forceDot1w(2), autoDot1s(3), unknown(4) | +-- -RW- String mstpGenCfgName(21) | | Textual Convention: DisplayString | | Size: 32 | +-- -RW- Integer32 mstpGenRevLevel(22) | +-- -R-- String mstpGenReginalRoot(26) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- Integer32 mstpGenExternalRootCost(27) | +--mstpPortTable(11) | | | +--mstpPortEntry(1) | | Index: mstpPortIndex | | | +-- -R-- Integer32 mstpPortIndex(1) | | Textual Convention: PortIndex | | Range: 1..2147483647 | +-- -RW- EnumVal mstpPortAdminMACEnable(2) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -R-- EnumVal mstpPortOperMACEnable(3) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -R-- TimeTicks mstpPortUpTime(4) | +-- -RW- Integer32 mstpPortAdminExternalPathCost(5) | | Range: 0..200000000 | +-- -R-- Integer32 mstpPortOperExternalPathCost(6) | +-- -RW- EnumVal mstpPortAdminEdge(7) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -R-- EnumVal mstpPortOperEdge(8) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -RW- EnumVal mstpPortAutoEdge(9) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -RW- EnumVal mstpPortAdminPointToPoint(10) | | Values: forceTrue(0), forceFalse(1), auto(2) | +-- -R-- EnumVal mstpPortOperPointToPoint(11) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -RW- INTEGER mstpPortHelloTime(12) | | Textual Convention: Timeout | | Range: 100..1000 | +-- -RW- EnumVal mstpPortAdminNonStp(13) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -RW- EnumVal mstpPortProtocolMigration(14) | | Textual Convention: TruthValue | | Values: true(1), false(2) | +-- -R-- Counter mstpPortRxTcnBpduCounter(15) | | Textual Convention: BpduCounter | +-- -R-- Counter mstpPortRxCfgBpduCounter(16) | +-- -R-- Counter mstpPortRxRstBpduCounter(17) | +-- -R-- Counter mstpPortRxMstBpduCounter(18) | +-- -R-- Counter mstpPortTxTcnBpduCounter(19) | +-- -R-- Counter mstpPortTxCfgBpduCounter(20) | +-- -R-- Counter mstpPortTxRstBpduCounter(21) | +-- -R-- Counter mstpPortTxMstBpduCounter(22) | +--mstpMapTable(12) | | | +--mstpMapEntry(1) | | Index: mstpMapMSTiID, mstpMapVlanRangeIndex | | | +-- ---- Integer32 mstpMapMSTiID(1) | | Textual Convention: MstiInstanceIndex | | Range: 1..64 | +-- ---- Integer32 mstpMapVlanRangeIndex(2) | | Range: 1..4094 | | | +--mstpMapVlanMin(3) | | | +--mstpMapVlanMax(4) | | | +-- CR-- EnumVal mstpMapRowStatus(9) | Textual Convention: RowStatus | Values: active(1), notInService(2), notReady(3), | createAndGo(4), createAndWait(5), destroy(6) | +--mstpXstTable(13) | | | +--mstpXstEntry(1) | | Index: mstpXstId | | | +-- ---- Integer32 mstpXstId(1) | | Textual Convention: MstiOrCistInstanceIndex | | Range: 0..64 | +-- -RW- Integer32 mstpXstBridgePriority(2) | | Range: 0..61440 | +-- -R-- String mstpXstBridgeId(3) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- String mstpXstDesignatedRoot(4) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- String mstpXstDesignatedBridge(5) | | Textual Convention: BridgeId | | Size: 8 | +-- -R-- Integer32 mstpXstInternalRootCost(6) | +-- -R-- Integer32 mstpXstRootPort(7) | | Textual Convention: PortIndexOrZero | | Range: 0..2147483647 | +-- -R-- Integer32 mstpXstMasterPort(8) | | Textual Convention: PortIndexOrZero | | Range: 0..2147483647 | +-- -R-- TimeTicks mstpXstTimeSinceTopologyChange(11) | +-- -R-- Counter mstpXstTopologyChangesCount(12) | +-- -R-- EnumVal mstpXstTopologyChangeFlag(13) | Textual Convention: TruthValue | Values: true(1), false(2) | +--mstpXstPortTable(14) | +--mstpXstPortEntry(1) | Index: mstpXstPortXstId, mstpXstPortIndex | +-- ---- Integer32 mstpXstPortXstId(1) | Textual Convention: MstiOrCistInstanceIndex | Range: 0..64 +-- -R-- Integer32 mstpXstPortIndex(2) | Textual Convention: PortIndex | Range: 1..2147483647 +-- -R-- EnumVal mstpXstPortState(3) | Values: disabled(1), discarding(1), learning(2), forwarding(3), unknown(4) +-- -R-- EnumVal mstpXstPortRole(4) | Values: disabled(1), alternate(2), backup(3), root(4), | designated(5), master(6), nonStp(7), unknown(8) +-- -R-- String mstpXstPortDesignatedRoot(6) | Textual Convention: BridgeId | Size: 8 +-- -R-- Integer32 mstpXstPortExternalRootCost(7) +-- -R-- String mstpXstPortRegionalBridge(8) | Textual Convention: BridgeId | Size: 8 +-- -R-- Integer32 mstpXstPortInternalRootCost(9) +-- -R-- String mstpXstPortDesignatedBridge(10) | Textual Convention: BridgeId | Size: 8 +-- -R-- String mstpXstPortDesignatedPort(14) | Textual Convention: PortId | Size: 2 +-- -RW- Integer32 mstpXstPortPriority(15) | Range: 0..255 +-- -RW- Integer32 mstpXstPortAdminInternalPathCost(16) | Range: 0..200000000 +-- -R-- Integer32 mstpXstPortOperInternalPathCost(17) On Wednesday, November 03, 2004 4:15 PM Congdon, Paul T (ProCurve) wrote: > I've uploaded Alex Ruzin's MSTP MIB. Note that this is slightly > different than the MIB that Alex cut-and-pasted to a previous email. > The document may be retrieved at: > > http://www.ieee802.org/1/files/public/docs2004/ruzin-mstp-mib-00.txt _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 11 03:25:02 2004 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 DAA12695 for ; Thu, 11 Nov 2004 03:25:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSAHU-0003mK-NJ for bridge-mib-archive@ietf.org; Thu, 11 Nov 2004 03:26:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSAF4-0000JM-29; Thu, 11 Nov 2004 03:23:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRsuh-0003kk-M3 for bridge-mib@megatron.ietf.org; Wed, 10 Nov 2004 08:53:31 -0500 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 IAA08504 for ; Wed, 10 Nov 2004 08:53:30 -0500 (EST) Received: from apollo.nbase.co.il ([194.90.137.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRsvf-0002Mi-DT for bridge-mib@ietf.org; Wed, 10 Nov 2004 08:54:32 -0500 Received: from Alexr ([194.90.136.135]) by apollo.nbase.co.il (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-44418U200L2S100) with SMTP id AAA2772; Wed, 10 Nov 2004 15:23:04 +0200 From: arozin@mrv.com (Alex Ruzin) To: Date: Wed, 10 Nov 2004 15:23:42 +0200 Message-ID: <00fb01c4c728$7ffaab10$87885ac2@Alexr> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.6 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-Mailman-Approved-At: Thu, 11 Nov 2004 03:23:40 -0500 Subject: [Bridge-mib] Re: [802.1] Alex Ruzin MSTP MIB Proposal - explanations X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arozin@mrv.com List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0114327431==" Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f This is a multi-part message in MIME format. --===============0114327431== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FC_01C4C739.43837B10" This is a multi-part message in MIME format. ------=_NextPart_000_00FC_01C4C739.43837B10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dan, It would be good if my propositions & comments may be considered "regardless of my presence in the meeting". I forward you a letter, that I got from Paul: On Wednesday, November 03, 2004 4:28 PM Congdon, Paul T (ProCurve) wrote: > Your welcome. > > I understand you will not be able to attend the 802.1 meeting. In the > future, to assure this is getting proper review and to obtain voting > rights within the working group, meeting attendance will be necessary. > For this meeting, if you can persuade someone who understands > the design and intricacies of your mib to present the ideas, we can get > agenda time for that person regardless of your presence... > > Paul Thanks, Alex Wednesday, November 10, 2004 3:03 PM you wrote: > Alex, > > Thanks for the contribution and the comments. It would be > good to prepare a short presentation for the IEEE 802.1 > meeting. As per the agenda the MIB discussion is the first > thing Monday morning at 9AM. > > Regards, > > Dan ------=_NextPart_000_00FC_01C4C739.43837B10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dan,
It would be good if my propositions & comments
may be=20 considered "regardless of my presence in
the meeting". I forward you = a=20 letter, that I got from
Paul:

On Wednesday, November 03, 2004 = 4:28 PM=20 Congdon, Paul T (ProCurve) wrote:
> Your=20 welcome.
>
> I understand you will not be able to attend the = 802.1=20 meeting.  In the
> future, to assure this is getting proper = review=20 and to obtain voting
> rights within the working group, meeting = attendance=20 will be necessary.
> For this meeting, if you can persuade someone = who=20 understands
> the design and intricacies of your mib to = present the=20 ideas, we can get
> agenda time for that person regardless of = your=20 presence...
>
> Paul

Thanks,=20 Alex

Wednesday, November 10, 2004 3:03 PM you = wrote:
> Alex,
>
> Thanks for the contribution = and the=20 comments. It would be
> good to prepare a short presentation for = the IEEE=20 802.1
> meeting. As per the agenda the MIB discussion is the = first
>=20 thing Monday morning at 9AM.
>
> Regards,
>
> = Dan=20

------=_NextPart_000_00FC_01C4C739.43837B10-- --===============0114327431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib --===============0114327431==-- From bridge-mib-bounces@ietf.org Thu Nov 11 16:41:38 2004 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 QAA01657 for ; Thu, 11 Nov 2004 16:41:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSMiV-00063V-Nk for bridge-mib-archive@ietf.org; Thu, 11 Nov 2004 16:42:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMSe-0002ql-Ee; Thu, 11 Nov 2004 16:26:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMHf-0004ts-DW for bridge-mib@megatron.ietf.org; Thu, 11 Nov 2004 16:15:14 -0500 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 QAA28873 for ; Thu, 11 Nov 2004 16:15:09 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSMIr-0005KW-Vf for bridge-mib@ietf.org; Thu, 11 Nov 2004 16:16:28 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id B33C331B6; Thu, 11 Nov 2004 22:14:32 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31981-05; Thu, 11 Nov 2004 22:14:31 +0100 (CET) Received: from james (unknown [130.129.133.233]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id A8FA7313A; Thu, 11 Nov 2004 22:14:31 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CSMH1-00011I-AF; Thu, 11 Nov 2004 22:14:31 +0100 Date: Thu, 11 Nov 2004 22:14:31 +0100 From: Juergen Schoenwaelder To: Les Bell Subject: Re: [Bridge-mib] dot1dStpPortPathCost32 Message-ID: <20041111211431.GA3911@james> Mail-Followup-To: Les Bell , bridge-mib@ietf.org References: <80256F40.003616A1.00@notesmta.eur.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80256F40.003616A1.00@notesmta.eur.3com.com> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Tue, Nov 02, 2004 at 09:50:14AM +0000, Les Bell wrote: > > Use of the 32-bit path cost was defined in both 802.1w (RSTP) and 802.1t. > 802.1t was a collection of enhacements to Bridges, including those that support > legacy STP. So the 32-bit path costs do not just apply to RSTP. > > I think you are right that dot1dStpPortPathCost32 should be conditionally > mandatory, but for any Spanning Tree implementation that supports 32-bit path > costs, not just for RSTP. OK, I have created another group and this makes the support for dot1dStpPortPathCost32 conditionally mandatory. > Implementations that support 32-bit path costs should not use the 16-bit path > cost object, dot1dStpPortPathCost, but I am not sure what is the best way to > deal with this. Are we allowed to allocate a special value to indicate it is > not in use? I think it would be safer to return an SNMP error indicating the > old object is not supported. dot1dStpPortPathCost is Integer32 (1..65535). Is there a value (e.g., 65535) which can be picked for this purpose? What do implementation do? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 11 16:42:14 2004 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 QAA01762 for ; Thu, 11 Nov 2004 16:42:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSMj4-00065I-8w for bridge-mib-archive@ietf.org; Thu, 11 Nov 2004 16:43:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMSf-0002sD-LJ; Thu, 11 Nov 2004 16:26:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMJf-0005wk-1p for bridge-mib@megatron.ietf.org; Thu, 11 Nov 2004 16:17:15 -0500 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 QAA28996 for ; Thu, 11 Nov 2004 16:17:13 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSMKs-0005NR-Sw for bridge-mib@ietf.org; Thu, 11 Nov 2004 16:18:32 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id F3B5B313A for ; Thu, 11 Nov 2004 22:16:42 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 32048-05; Thu, 11 Nov 2004 22:16:42 +0100 (CET) Received: from james (unknown [130.129.133.233]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id C1C1931BB; Thu, 11 Nov 2004 22:16:41 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CSMJ7-00011P-MY; Thu, 11 Nov 2004 22:16:41 +0100 Date: Thu, 11 Nov 2004 22:16:41 +0100 From: Juergen Schoenwaelder To: bridge-mib@ietf.org Message-ID: <20041111211641.GB3911@james> Mail-Followup-To: bridge-mib@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Bridge-mib] unit of dot1dTpPortMaxInfo X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c What is the unit of dot1dTpPortMaxInfo? I guess it is bytes, but the document does not really say so (and the bridges I looked at return values that are, well, somewhat surprising). Is it safe to add UNITS "bytes" here? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Tue Nov 16 16:20:07 2004 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 QAA15387 for ; Tue, 16 Nov 2004 16:20:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUAmU-0008Po-8E for bridge-mib-archive@ietf.org; Tue, 16 Nov 2004 16:22:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUAhR-0000vH-G6; Tue, 16 Nov 2004 16:17:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUAck-0006w5-LQ; Tue, 16 Nov 2004 16:12:26 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14473; Tue, 16 Nov 2004 16:12:25 -0500 (EST) Message-Id: <200411162112.QAA14473@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 16 Nov 2004 16:12:24 -0500 Cc: bridge-mib@ietf.org Subject: [Bridge-mib] I-D ACTION:draft-ietf-bridge-ext-v2-03.txt X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bridge MIB Working Group of the IETF. Title : Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions Author(s) : V. Ngai, E. Bell Filename : draft-ietf-bridge-ext-v2-03.txt Pages : 97 Date : 2004-11-16 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines two MIB modules for managing the new capabilities of MAC bridges defined by the IEEE 802.1D-1998 MAC Bridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'Enhanced Multicast Filtering' components of IEEE 802.1D-1998 and P802.1t-2001. The other MIB module defines objects for managing VLANs, as specified in IEEE 802.1Q-1998, P802.1u and P802.1v. Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes several MIB modules in a manner that is compliant to the SMIv2 [V2SMI]. This memo supplements RFC 1493 [BRIDGEMIB] and (to a lesser extent) RFC 1525 [SBRIDGEMIB]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bridge-ext-v2-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bridge-ext-v2-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bridge-ext-v2-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-16112842.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bridge-ext-v2-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bridge-ext-v2-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-16112842.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib --NextPart-- From bridge-mib-bounces@ietf.org Wed Nov 17 15:13:45 2004 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 PAA07678 for ; Wed, 17 Nov 2004 15:13:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUWE1-0002G8-6M for bridge-mib-archive@ietf.org; Wed, 17 Nov 2004 15:16:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUW30-0002Nt-I7; Wed, 17 Nov 2004 15:04:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUVus-0004AB-Qt for bridge-mib@megatron.ietf.org; Wed, 17 Nov 2004 14:56:34 -0500 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 OAA05621 for ; Wed, 17 Nov 2004 14:56:32 -0500 (EST) Message-Id: <200411171956.OAA05621@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUVxL-0001oT-BP for bridge-mib@ietf.org; Wed, 17 Nov 2004 14:59:08 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc13) with SMTP id <2004111719560201600kiodbe>; Wed, 17 Nov 2004 19:56:02 +0000 From: "David B Harrington" To: Date: Wed, 17 Nov 2004 14:55:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcTM33R7XSdqgiwMR/W5w89e3yzDzw== X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] MSTP MIB proposals X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Hi, The IEEE 802.1WG is considering three MSTP-MIB proposals. They are available on the IEEE 802.1 public files section http://www.ieee802.org/1/files/public/docs2004 The proposals are: http://www.ieee802.org/1/files/public/docs2004/frattura-mstp-mib-0411. txt http://www.ieee802.org/1/files/public/docs2004/malhotra-mstpmib-01.txt http://www.ieee802.org/1/files/public/docs2004/ruzin-mstp-mib-00.txt -- The appropriate mailing list for MSTP-MIB discussion is STDS-802-1-L@listserv.ieee.org. To subscribe to the STDS-802-1-L list, go to http://www.ieee802.org/1/email-pages/ To see the general information about 802,1, including how they work and how to participate, go to http://www.ieee802.org/1/ To see presentations on the technology, go to http://www.ieee802.org/1/files/public/docs2004 David Harrington dbharrington@comcast.net co-chair, IETF Bridge WG _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Wed Nov 17 19:25:40 2004 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 TAA06211 for ; Wed, 17 Nov 2004 19:25:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUa9r-0001sI-9F for bridge-mib-archive@ietf.org; Wed, 17 Nov 2004 19:28:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUa5J-00014h-UW; Wed, 17 Nov 2004 19:23:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUa1K-0008Ts-VJ for bridge-mib@megatron.ietf.org; Wed, 17 Nov 2004 19:19:30 -0500 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 TAA05617 for ; Wed, 17 Nov 2004 19:19:23 -0500 (EST) Message-Id: <200411180019.TAA05617@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUa3c-0001fk-LK for bridge-mib@ietf.org; Wed, 17 Nov 2004 19:22:02 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc13) with SMTP id <2004111800184401600kijb2e>; Thu, 18 Nov 2004 00:18:44 +0000 From: "David B Harrington" To: Date: Wed, 17 Nov 2004 19:18:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcTNBCgGfbrFKx6tQUKMP4r9AMrEAQ== X-Spam-Score: 0.7 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] 802.1AE MIB X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Hi, A proposal for management of 802.1AE (MAC Security) is available in http://www.ieee802.org/1/files/public/docs2004/ae-chao-mgmt-1115-1.ppt The appropriate mailing list for IEEE 802.1 mib module discussion is STDS-802-1-L@listserv.ieee.org. To subscribe to the STDS-802-1-L list, go to http://www.ieee802.org/1/email-pages/ To see the general information about 802,1, including how they work and how to participate, go to http://www.ieee802.org/1/ To see presentations on the technology, go to http://www.ieee802.org/1/files/public/docs2004 David Harrington dbharrington@comcast.net co-chair, IETF Bridge WG _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 18 11:13:07 2004 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 LAA06932 for ; Thu, 18 Nov 2004 11:13:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUowr-0004lC-Jd for bridge-mib-archive@ietf.org; Thu, 18 Nov 2004 11:15:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUol1-0004NR-1T; Thu, 18 Nov 2004 11:03:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUUw8-0000rw-V0 for bridge-mib@megatron.ietf.org; Wed, 17 Nov 2004 13:53:49 -0500 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 NAA29348 for ; Wed, 17 Nov 2004 13:53:46 -0500 (EST) Message-Id: <200411171853.NAA29348@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUUyZ-0000TO-8k for bridge-mib@ietf.org; Wed, 17 Nov 2004 13:56:21 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc12) with SMTP id <20041117185308012009956fe>; Wed, 17 Nov 2004 18:53:08 +0000 From: "David B Harrington" To: Date: Wed, 17 Nov 2004 13:53:01 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_02E2_01C4CCAC.C3230570" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcTMaN5kNDxpQL53Sr6jsnBabOmQcwAWWs/QAATeysA= X-Spam-Score: 0.1 (/) X-Scan-Signature: f3f9301fe8c8f89cf5bf37302b0c0260 X-Mailman-Approved-At: Thu, 18 Nov 2004 11:03:37 -0500 Cc: STDS-802-1-L@listserv.ieee.org Subject: [Bridge-mib] FW: 802.1AE Management and MIB X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 61de08c4faf59d01a69c8d192a300550 This is a multi-part message in MIME format. ------=_NextPart_000_02E2_01C4CCAC.C3230570 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Please find attached a presentation on 802.1AE management and MIB design, prepared by Frank Chao, who is the editor of the MIB in IEEE 802.1AE. This work is being done in the IEEE 802.1 WG as part of the 802.1AE effort. If you have any comments, please send them to mailto:STDS-802-1-L@listserv.ieee.org To subscribe to the STDS-802-1-L list, go to http://www.ieee802.org/1/email-pages/ To see the general information about 802,1, including how they work and how to participate, go to http://www.ieee802.org/1/ Thanks, David Harrington dbharrington@comcast.net co-chair, IETF Bridge WG ------=_NextPart_000_02E2_01C4CCAC.C3230570 Content-Type: application/vnd.ms-powerpoint; name="ae-chao-mgmt-1115-01.ppt" Content-Disposition: attachment; filename="ae-chao-mgmt-1115-01.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAXAAAAAAAAAAA EAAAeAAAAAEAAAD+////AAAAAFsAAAB/AAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8P AOgDBDQAAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAABgAAAAAAAAABAAAAAAAAAQ8A CQRsAQAAAAAKBAQAAAAEAAAADwDXD1gBAAAAANMPBAAAAAMAAAAAALoPngAAAGgAdAB0AHAAOgAv AC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBpAG4AdABlAHIAbgBlAHQALQBkAHIAYQBmAHQA cwAvAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBvAHAAcwAtAG0AaQBiAC0AcgBlAHYAaQBlAHcALQBn AHUAaQBkAGUAbABpAG4AZQBzAC0AMAAzAC4AdAB4AHQAEAC6D54AAABoAHQAdABwADoALwAvAHcA dwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AaQBuAHQAZQByAG4AZQB0AC0AZAByAGEAZgB0AHMALwBk AHIAYQBmAHQALQBpAGUAdABmAC0AbwBwAHMALQBtAGkAYgAtAHIAZQB2AGkAZQB3AC0AZwB1AGkA ZABlAGwAaQBuAGUAcwAtADAAMwAuAHQAeAB0AA8A8gNgAQAALwDIDwwAAAAwANIPBAAAAAAAAAAP ANUHmAAAAAAAtw9EAAAAQQByAGkAYQBsAAAACAAAAAAAAACIuRMAiLkTACgVJwcIuBMA8LcTAPbo BzAIAAAAAAAAAAi4EwDSQgkwALgTAAAABAAQALcPRAAAALBlMH0OZtSaAAAAAAgAAAAAAAAAiLkT AIi5EwAoFScHCLgTAPC3EwD26AcwCAAAAAAAAAAIuBMA0kIJMAC4EwCIAAQSAACkDwgAAACBAEAA gQAAAAAApQ8MAAAAAAAACC4AAAAHAAAAAACpDwoAAAAHAAAAAgAEBAkEQACjD24AAAAFAP/9PwAA ACIgAABkAAAAAP8AAGQAAAAAAAAAAABAAgAAAAAHAAAA///vAIAAAAABAAAA//8SAAAAAAEAAAAF AAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwRUAQAADwAA 8EwBAAAAAAbw4AAAAAVoAAAbAAAAXgAAABMAAAABAAAABwAAAAIAAAArAAAAAAAAAAYAAAAAAAAA PwAAAAUAAAAIAAAABgAAAAQAAAAAAAAAwAAAAAgAAAAEAAAACQAAAAQAAAAKAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAA4AAAAEAAAADwAAAAQAAAAQAAAABAAAABEAAAAEAAAAEgAAAAYA AAATAAAABQAAABQAAAAFAAAAFQAAAAUAAAAWAAAABQAAABcAAAAGAAAAGAAAAAUAAAAAAAAABAAA ABoAAAAFAAAAgwAL8DAAAACBAQQAAAiDAQAAAAiGQQAAAAC/ARAAEADAAQEAAAjFQQAAAAD/AQgA CAABAgIAAAgwABrxDAAAAP8AZgAAAP8A/wAAAEAAHvEQAAAABAAACAEAAAgCAAAI9wAAEB8A8A8c AAAAAADzAxQAAAACAAAAAAAAAAAAAAAAAACAAAAAAA8A0Ad3AQAAHwAUBBwAAAAAABUEFAAAAEaT TwkAypo7+7F3OADKmjsBAQAADwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAAJQAAAGQAAAAlAAAA ZAAAAAgAAAAAAAAAILgTANJCCTAAAAAAAAAAAD7+//+y////AQATAHAA+wMIAAAAAAAAAHAIAABw APsDCAAAAAEAAABACwAAHwATBDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQAAABMuBMAcEMJMIi5 EwAAFScHAAAAAAAAAAAAAAAAAAAAAAABEwAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAAHwAH BDwAAAAAAP0DNAAAACEAAABkAAAAIQAAAGQAAAACAAAATLgTAGhHCTCIuRMAAAAAAAAAAAAAAAAA AAAAAAABEwAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAA AA0ECAAAAADAAAAAwAAAPwDZDwwAAAAAANoPBAAAAA0AJQAPAPAPsS0AAAAA8wMUAAAAGAAAAAQA AAACAAAAEAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPNAAAAEZyYW5rIENoYW8LC2ZjaGFvQGNpc2Nv LmNvbQsLU2FuIEFudG9uaW8LCzExLzE0LzIwMDQAAKEPFAAAADUAAAAAAAAAAAA1AAAAAAACACAA AACqD0AAAAAGAAAABgAAAAkEAAAEAAAABwAAAAMACQQAAAIAAAAGAAAACQQAAA8AAAAHAAAAAwAJ BAAAGgAAAAYAAAAJBAAAEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAACQQAAAAA8wMUAAAA AwAAAAQAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKoPDgAAAAEAAAAHAAAAAAAJBAAAEACf DwQAAAAFAAAAAACqDw4AAAABAAAABwAAAAAACQQAAAAA8wMUAAAACQAAAAAAAAACAAAAAQEAAAAA AAAAAJ8PBAAAAAAAAAAAAKgPFAAAAC4xQUUgTWFuYWdlbWVudCBJbmZvAACqDwwAAAAVAAAABgAA AAkEAAAQAJ8PBAAAAAEAAAAAAKgPOQEAAExNSSAoTGF5ZXIgTWFuYWdlbWVudCBJbnRlcmZhY2Up DURhdGEgU3RydWN0dXJlDUFjY2Vzc2VkIGJ5IC4xQUUsIC4xYWYsIFNOTVAvTUlCLCBFQVANQ29u dGFpbmluZyAuMUFFIGFuZCAuMWFmIGNvbmZpZ3VyYXRpb24sIHByb3RvY29sIHN0YXRlcywgYW5k IGNvdW50ZXIvZGlhZ25vc2lzIGluZm9ybWF0aW9uLg0uMUFFIHVzZXMgTE1JIHRvIGNvbnRyb2wg dGhlIE1BQ3NlYyBwYWNrZXQgcHJvY2Vzc2luZyBkaXJlY3RseSBvciB0aHJvdWdoIEFQSXMuDUNo YW5nZSB0aGUgZGF0YSBpbiBMTUkgbWF5IGNhdXNlIGFjdGlvbnMgaW4gU2VjWSBvciBLYVkAAKEP OAAAACEAAAAAAAAQAABaABkBAAABAAAQAABaACEAAAAAAAAADwAAAAAEBACABP8AZv4KAQAAAAQA AIAEAACqD1oAAADPAAAABgAAAAkEAAAGAAAABwAAAAMACQQAAFkAAAAGAAAACQQAAAQAAAAHAAAA AwAJBAAABAAAAAYAAAAJBAAAAwAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAAAPMDFAAAAAoAAAAA AAAAAgAAAAIBAAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAAAuMUFFIE1hbmFnZW1lbnQgSW5mbwAA qg8MAAAAFQAAAAYAAAAJBAAAEACfDwQAAAABAAAAAACoD18BAABNQUNzZWMgTWdtdCBJbmZvcm1h dGlvbg1FbmFibGUvRGlzYWJsZSAoZ2xvYmFsIGNvbmZpZ3VyYXRpb24pDVNlY1kgTWdtdCBJbmZv cm1hdGlvbg1UYWJsZSBpbmRleGVkIGJ5IEludGVyZmFjZUluZGV4IChJRi1NSUIpLg1WYWxpZGF0 ZVJ4RnJhbWVzIDogZmxhZyBmb3IgdmFsaWRhdGlvbiBwcm9jZXNzIGluIHJlY2VpdmluZy4gKDEw LjUuMykNUHJvdGVjdFR4RnJhbWVzIDogZmxhZyBmb3IgcHJvdGVjdGlvbiBwcm9jZXNzIGluIHRy YW5zbWl0dGluZy4NQ3VycmVudCBDaXBoZXIgU3VpdGUuICgxMC41LjQpIChSb3cgUG9pbnRlcikN YWRtaW5Qb2ludFRvUG9pbnRNQUMsIG9wZXJQb2ludFRvUG9pbnRNQUMgKDYuNSkAAKEPAAEAABgA AAAAAAAQAABaACYAAAABAAAQAABaABYAAAAAAAAQAABaAAwBAAABAAAQAABaABgAAAAAAAIAHAAP AAAAAAAEAAAAAAYWAAAAAAAAAAEAAAAAAAQAAAAABhYAAAAABAIAgAQcABEAAAAACAAAgAgOAAAA AAgEAIAIAAAABgsAAAAACAAAgAgQAAAAAAgEAIAIAAAABjYAAAAACAAAgAgPAAAAAAgEAIAIAAAA BjAAAAAACAAAgAgWAAAAAAgEAIAIAAAABhcAAAAACAAAgAgUAAAAAAgEAIAIAAAABgIAAAAACAAA gAgUAAAAAAgEAIAIAAAABgYAAAAACAAAgAgAAKoPnAAAAAYAAAAHAAAAAwAJBAAAXwAAAAYAAAAJ BAAADgAAAAcAAAADAAkEAAALAAAABgAAAAkEAAAQAAAABwAAAAMACQQAADYAAAAGAAAACQQAAA8A AAAHAAAAAwAJBAAAXQAAAAYAAAAJBAAAFAAAAAcAAAADAAkEAAACAAAABgAAAAkEAAATAAAABwAA AAMACQQAAAcAAAAGAAAACQQAAAAA8wMUAAAACwAAAAAAAAACAAAAAwEAAAAAAAAAAJ8PBAAAAAAA AAAAAKgPFAAAAC4xQUUgTWFuYWdlbWVudCBJbmZvAACqDwwAAAAVAAAABgAAAAkEAAAQAJ8PBAAA AAEAAAAAAKgPGgEAAFJ4UmVwbGF5Q2hrIDogZmxhZyBmb3IgcnggcmVwbGF5IGNoZWNrLiAoMTAu Ni4yKQ1UeCBTQyA6IHRyYW5zbWl0IFNDIGluZm9ybWFpdG9uLg1SeCBTQ3MgOiByZWNlaXZlIFND cyBpbmZvcm1haXRvbi4gKHdpbGwgYmUgaW4gYW5vdGhlciB0YWJsZS4pDWxhc3RVbmtub3duU0Mg OiBhbiBTQ0kgaW5mb3JtYXRpb24gdG8gcmVjb3JkIGxhc3QgcnggdW5rbm93biBTQyAoMTAuNi4x KSB3aXRoIHRpbWUgc3RhbXAsIGl0IGNvdWxkIGJlIGEgbGlzdCAoYSB0YWJsZSwgbWF4aW11bSBl bnRyaWVzKSA/DQAAoQ8yAAAAGwEAAAEAAAAAAAsAAAAAAAQAAAAABoUAAAAAAAAADQAAAAAABAD/ AGb+fgAAAAAAAAAAAKoP6gAAAAsAAAAHAAAAAwAJBAAADAAAAAYAAAAJBAAAAgAAAAcAAAADAAkE AAAYAAAABgAAAAkEAAACAAAABwAAAAMACQQAABIAAAAGAAAACQQAAAsAAAAHAAAAAwAJBAAABQAA AAYAAAAJBAAAAwAAAAcAAAADAAkEAAALAAAABgAAAAkEAAADAAAABwAAAAMACQQAAAEAAAAGAAAA CQQAAAsAAAAHAAAAAwAJBAAAHgAAAAYAAAAJBAAADQAAAAcAAAADAAkEAAAlAAAABgAAAAkEAAAC AAAABwAAAAMACQQAAFcAAAAGAAAACQQAAAAA8wMUAAAADwAAAAAAAAACAAAABwEAAAAAAAAAAJ8P BAAAAAAAAAAAAKgPFAAAAC4xQUUgTWFuYWdlbWVudCBJbmZvAACqDwwAAAAVAAAABgAAAAkEAAAQ AJ8PBAAAAAEAAAAAAKgPFAIAAFR4IFNDIE1nbXQgSW5mb3JtYXRpb24Nc2NTdGF0ZSA6IHN0YXRl IG9mIHRoaXMgdHJhbnNtaXQgU0MgPy4Nc2NDbWQgOiBjb21tYW5kIGV4ZWN1dGluZyBpbiB0aGUg U0MgPy4NU0NJIDogdGhlIFNDSSBmb3IgdGhlIFNDIHVzZWQgYnkgU2VjWSBmb3IgdHJhbnNtaXQu ICgxMC41KQ10eEVuY29kaW5nU0EgOiBjdXJyZW50IFNBIG51bWJlci4gKDEwLjUuMSkgKGNvdWxk IGJlIGEgUm93UG9pbnRlcikNdHhFbmNpcGhlcmluZ1NBIDogcHJldmlvdXMgU0EgbnVtYmVyLiAo MTAuNS40KSAoY291bGQgYmUgYSBSb3dQb2ludGVyKQ1UeCBTQSA6ICh0YWJsZSB3aXRoIDQgZW50 cmllcykNVGFibGUgaW5kZXhlZCBieSBJbnRlcmZhY2VJbmRleCBhbmQgQU4uDXNhU3RhdGUgOiBz dGF0ZSBvZiB0aGlzIHRyYW5zbWl0IFNBLg1zYUNtZCA6IGNvbW1hbmQgZXhlY2N1dGluZyBpbiB0 aGUgU0EuDXR4U0FLIDoga2V5IGZvciB0cmFuc21pdHRpbmcuICg3LjEsIDEwLjUuMSkNdHhOZXh0 UE4gOiBuZXh0IHBhY2tldCBudW1iZXIgKFBOKS4gKDEwLjUuMikAAKEPcgEAABcAAAAAAAAQAABQ ABMBAAABAAAQAABQAB8AAAAAAAAQAABQAMwAAAABAAAQAABQABcAAAAAAAIAHAAHAAAAAAAGABgA AAAABiAAAAAAAAIAGAAFAAAAAAAGABgAAAAABiIAAAAAAAIAGAADAAAAAAAGABgAAAAABjgAAAAA AAIAGAAMAAAAAAAGABgAAAAABjcAAAAAAAIAGAAPAAAAAAAGABgAAAAABjgAAAAAAAIAGAAfAAAA AAQCAIAEHAARAAAAAAgCAIAIGAAOAAAAAAgGAIAIGAAAAAAGBQAAAAAIAgCACBgAAgAAAAAIBgCA CBgAAAAABgIAAAAACAIAgAgYAAcAAAAACAYAgAgYAAAAAAYeAAAAAAgCAIAIGAAFAAAAAAgGAIAI GAAAAAAGIQAAAAAIAgCACBgABQAAAAAIBgCACBgAAAAABicAAAAACAIAgAgYAAgAAAAACAYAgAgY AAAAAAYlAAAAAAgCAIAIGAAAAKoPhgEAAAIAAAAHAAAAAwAJBAAAFQAAAAYAAAAJBAAABwAAAAcA AAADAAkEAAAgAAAABgAAAAkEAAAFAAAABwAAAAMACQQAAEMAAAAGAAAACQQAAAQAAAAHAAAAAwAJ BAAAFgAAAAYAAAAJBAAADAAAAAcAAAADAAkEAAArAAAABgAAAAkEAAAKAAAABwAAAAMACQQAAAIA AAAGAAAACQQAAA8AAAAHAAAAAwAJBAAALAAAAAYAAAAJBAAACgAAAAcAAAADAAkEAAACAAAABgAA AAkEAAACAAAABwAAAAMACQQAAC4AAAAGAAAACQQAAA4AAAAHAAAAAwAJBAAACQAAAAYAAAAJBAAA BwAAAAcAAAADAAkEAAAeAAAABgAAAAkEAAAFAAAABwAAAAMACQQAAAsAAAAGAAAACQQAAAoAAAAH AAAAAwAJBAAADAAAAAYAAAAJBAAABQAAAAcAAAADAAkEAAAnAAAABgAAAAkEAAAIAAAABwAAAAMA CQQAACUAAAAGAAAACQQAAAAA8wMUAAAAEAAAAAAAAAACAAAACAEAAAAAAAAAAJ8PBAAAAAAAAAAA AKgPFAAAAC4xQUUgTWFuYWdlbWVudCBJbmZvAACqDwwAAAAVAAAABgAAAAkEAAAQAJ8PBAAAAAEA AAAAAKgPcAEAAFJ4IFNDcyBNZ210IEluZm9ybWF0aW9uDVRhYmxlIGluZGV4ZWQgYnkgSW50ZXJm YWNlSW5kZXggYW5kIFNDSS4Nc2NTdGF0ZSA6IHN0YXRlIG9mIHRoaXMgdHJhbnNtaXQgU0MgPy4N c2NDbWQgOiBjb21tYW5kIGV4ZWN1dGluZyBpbiB0aGUgU0MgPy4NU0NJIDogdGhlIFNDSSBmb3Ig dGhlIFNDIHVzZWQgYnkgU2VjWSBmb3IgdHJhbnNtaXQuICgxMC41KQ1yeEN1cnJlbnRTQSA6IGN1 cnJlbnQgdXNpbmcgU0EgbnVtYmVyIGluIHRoZSBTQy4gKDEwLjYuMSkgKFJvd1BvaW50ZXIpDWxh c3ROb3RJblVzZUFuIDogbGFzdCBOb3QtaW4tVXNlIEFOIHdpdGggdGltZXN0YW1wLiAoMTAuNi4x KSBhIGxpc3QgKGEgdGFibGUsIG1heGltdW0gZW50cmllcyk/AAChD9IAAAAYAAAAAAAAAAAAWQEA AAEAAAAAABgAAAAAAAIAHAAQAAAAAAQCAIAEGAAQAAAAAAQGAIAEGAAAAAAGAwAAAAAEAgCABBgA DQAAAAAEBgCABBgAAAAABiAAAAAABAIAgAQYAAUAAAAABAYAgAQYAAAAAAYiAAAAAAQCAIAEGAAD AAAAAAQGAIAEGAAAAAAGOAAAAAAEAgCABBgACwAAAAAEBgCABBgAAAAABjwAAAAABAIAgAQYAA4A AAAABAYAgAQYAP8AZv5SAAAAAAQCAIAEGAAAAKoP3AAAAAMAAAAGAAAACQQAAAMAAAAHAAAAAwAJ BAAAIwAAAAYAAAAJBAAADgAAAAcAAAADAAkEAAAKAAAABgAAAAkEAAAHAAAABwAAAAMACQQAACAA AAAGAAAACQQAAAUAAAAHAAAAAwAJBAAAQwAAAAYAAAAJBAAABAAAAAcAAAADAAkEAAAWAAAABgAA AAkEAAALAAAABwAAAAMACQQAADAAAAAGAAAACQQAAAoAAAAHAAAAAwAJBAAAAgAAAAYAAAAJBAAA DgAAAAcAAAADAAkEAABSAAAABgAAAAkEAAAAAPMDFAAAABEAAAAAAAAAAgAAAAkBAAAAAAAAAACf DwQAAAAAAAAAAACoDxQAAAAuMUFFIE1hbmFnZW1lbnQgSW5mbwAAqg8MAAAAFQAAAAYAAAAJBAAA EACfDwQAAAABAAAAAACoDysBAABSeCBTQSBNZ210IEluZm9ybWF0aW9uDVRhYmxlIGluZGV4ZWQg YnkgSW50ZXJmYWNlSW5kZXggYW5kIFNDSSBhbmQgQU4uDXNhU3RhdGUgOiBzdGF0ZSBvZiB0aGlz IHJlY2VpdmUgU0EuDXNhQ21kIDogY29tbWFuZCBleGNlY3V0aW5nIGluIHRoZSBTQS4NcnhTQUsg OiBrZXkgZm9yIHRyYW5zbWl0dGluZy4gKDcuMSwgMTAuNi4xKQ1yeExhc3RQTiA6IGxhc3QgcmVj ZWl2ZWQgcGFja2V0IG51bWJlciAoUE4pLiAoMTAuNi4yKQ1yeExhc3RWYWxpZGF0ZWRQTiA6IGxh c3QgcmVjZWl2ZWQgdmFsaWRhdGVkIFBOLiAoMTAuNi4yKQAAoQ/iAAAAFwAAAAAAABAAAFoAMAAA AAEAABAAAFoA5QAAAAEAIBAAAAAAAAFaABcAAAAAAAAAEAAAAAAEAACABBAAAAAABAQAgAQAAAAG AwAAAAAEAACABAUAAAAABAQAgAQAAAAGAwAAAAAEAACABAwAAAAABAQAgAQAAAAGHQAAAAAEAACA BAUAAAAABAQAgAQAAAAGIQAAAAAEAACABAUAAAAABAQAgAQAAAAGJwAAAAAEAACABAgAAAAABAQA gAQAAAAGLgAAAAAEAACABBEAAAAABAQAgAQAAAAGKAAAAAAEAACABAAAqg9AAAAAKAAAAAYAAAAJ BAAADgAAAAcAAAADAAkEAAARAAAABgAAAAkEAAAHAAAABwAAAAMACQQAAN4AAAAGAAAACQQAAAAA 8wMUAAAAEgAAAAAAAAACAAAACgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFAAAAC4xQUUgTWFuYWdl bWVudCBJbmZvAACqDwwAAAAVAAAABgAAAAkEAAAQAJ8PBAAAAAEAAAAAAKgPxAAAAENpcGhlciBT dWl0ZXMgOg1OYW1lIDogbmFtZSBvZiB0aGlzIGNpcGhlciBzdWl0ZSwgY291bGQgYmUgTUlCIHRh YmxlIGluZGV4Lg1Db25maWRlbnRpYWxpdHkgOiBmbGFnIGluZGljYXRlIHRoZSBjaXBoZXIgc3Vp dGUgd2l0aCBjb25maWRlbnRpYWxpdHkgYWJpbGl0eS4NSUNWIGxlbmd0aCA6IHRoZSBsZW5ndGgg b2YgZ2VuZXJhdGVkIElDVi4AAKEPZAAAABAAAAAAAAAAAAC1AAAAAQAAAAAAEAAAAAAAAAAEAAAA AAQEAIAEAAAABjgAAAAABAAAgAQPAAAAAAQEAIAEAAAABkAAAAAABAAAgAQKAAAAAAQEAIAEAAAA BiAAAAAABAAAgAQAAKoPDAAAAMUAAAAGAAAACQQAAAAA8wMUAAAAEwAAAAQAAAACAAAACwEAAAAA AAAAAJ8PBAAAAAAAAAAAAKoPDgAAAAEAAAAHAAAAAAAJBAAAEACfDwQAAAABAAAAAACqDw4AAAAB AAAABwAAAAAACQQAAAAA8wMUAAAAFAAAAAAAAAACAAAADAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgP FAAAAC4xQUUgTWFuYWdlbWVudCBJbmZvAACqDwwAAAAVAAAABgAAAAkEAAAQAJ8PBAAAAAEAAAAA AKgPAAEAAFNDIFJ4IGNvdW50ZXJzIDoNSW5kZXhlZCBieSBJbnRlcmZhY2VJbmRleCBhbmQgU0NJ DUluWGNhc3RQa3RzTm90UmVjZWl2ZWQNSW5YY2FzdFBrdHNJbnZhbGlkDUluWGNhc3RQa3RzUmVw bGF5ZWQNSW5YY2FzdFBrdHNNaXNvcmRlcmVkDUluWGNhc3RQa3RzT3JkZXJlZA1JblhjYXN0UGt0 c0VuY3J5cHRlZA1JblhjYXN0UGt0c0RlY3J5cHRlZA1JblhjYXN0T2N0ZXRzRW5jcnlwdGVkIChN U0RVKQ1JblhjYXN0T2N0ZXRzRGVjcnlwdGVkIChNU0RVKQ0AAKEPggAAABEAAAAAAAAAAADvAAAA AQAAAAAAAQAAAAEAAQAAAAAAEQAAAAAAAgAcAAsAAAAABAIAgAQYAA4AAAAABAYAgAQYAAAAAAYF AAAAAAQCAIAEGAAEAAAAAAQGAIAEGAAAAAAGVAAAAAAEBgCABBQA/wBm/noAAAAABAYAgAQUAAAA //4AAKoPEAEAABwAAAAGAAAACQQAAA4AAAAHAAAAAwAJBAAACQAAAAYAAAAJBAAAFgAAAAcAAAAD AAkEAAABAAAABgAAAAkEAAASAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABMAAAAHAAAAAwAJBAAA AQAAAAYAAAAJBAAAFQAAAAcAAAADAAkEAAABAAAABgAAAAkEAAASAAAABwAAAAMACQQAAAEAAAAG AAAACQQAABQAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFAAAAAcAAAADAAkEAAABAAAABgAAAAkE AAAWAAAABwAAAAMACQQAAAgAAAAGAAAACQQAABYAAAAHAAAAAwAJBAAACQAAAAYAAAAJBAAAAADz AxQAAAAVAAAAAAAAAAIAAAANAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8UAAAALjFBRSBNYW5hZ2Vt ZW50IEluZm8AAKoPDAAAABUAAAAGAAAACQQAABAAnw8EAAAAAQAAAAAAqA9hAQAAU2VjWSBSeCBD b3VudGVycyA6DVRhYmxlIEluZGV4ZWQgYnkgSW50ZXJmYWNlSW5kZXgNSW5YY2FzdFBrdHNOb1Rh Zw1JblhjYXN0UGt0c0JhZFRhZw1JblhjYXN0UGt0c1Vua25vd25TQ0kNSW5YY2FzdFBrdHNVbnRh Z2dlZA1JblhjYXN0UGt0c1VuY2hlY2tlZA1JblhjYXN0UGt0c05vdFJlY2VpdmVkDUluWGNhc3RQ a3RzSW52YWxpZA1JblhjYXN0UGt0c1JlcGxheWVkDUluWGNhc3RQa3RzTWlzb3JkZXJlZA1Jblhj YXN0UGt0c09yZGVyZWQNSW5YY2FzdFBrdHNFbmNyeXB0ZWQNSW5YY2FzdFBrdHNEZWNyeXB0ZWQN SW5YY2FzdE9jdGV0c0VuY3J5cHRlZCAoTVNEVSkNSW5YY2FzdE9jdGV0c0RlY3J5cHRlZCAoTVNE VSkAAKEPXgAAABMAAAAAAAAQAABQAE8BAAABAAAQAABQABMAAAAAAAIAHAARAAAAAAQCAIAEGAAP AAAAAAQGAIAEGAAAAAAGtgAAAAAEBgCABBQA/wBm/nkAAAAABAYAgAQUAAAA//4AAKoPoAEAAAQA AAAHAAAAAwAJBAAAIAAAAAYAAAAJBAAADgAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAQAAAABwAA AAMACQQAAAEAAAAGAAAACQQAABEAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFQAAAAcAAAADAAkE AAABAAAABgAAAAkEAAATAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABQAAAAHAAAAAwAJBAAAAQAA AAYAAAAJBAAAFgAAAAcAAAADAAkEAAABAAAABgAAAAkEAAASAAAABwAAAAMACQQAAAEAAAAGAAAA CQQAABMAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFQAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAS AAAABwAAAAMACQQAAAEAAAAGAAAACQQAABQAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFAAAAAcA AAADAAkEAAABAAAABgAAAAkEAAAWAAAABwAAAAMACQQAAAgAAAAGAAAACQQAABYAAAAHAAAAAwAJ BAAACAAAAAYAAAAJBAAAAADzAxQAAAAXAAAAAAAAAAIAAAAPAQAAAAAAAAAAnw8EAAAAAAAAAAAA qA8UAAAALjFBRSBNYW5hZ2VtZW50IEluZm8AAKoPDAAAABUAAAAGAAAACQQAABAAnw8EAAAAAQAA AAAAoA8IAgAAUwBBACAAVAB4ACAAYwBvAHUAbgB0AGUAcgBzACAAOgANAFQAYQBiAGwAZQAgAGkA bgBkAGUAeABlAGQAIABiAHkAIABJAG4AdABlAHIAZgBhAGMAZQBJAG4AZABlAHgAIABhAG4AZAAg AEEATgANAE8AdQB0AEMAbgB0AFIAZQBpAG4AaQB0AFQAaQBtAGUAIAA6ACAAQQAgAHQAaQBtAGUA cwB0AGEAbQBwACAAZgBvAHIAIAB0AGgAZQAgAGMAbwB1AG4AdABlAHIAcwAZICAAZABpAHMAYwBv AG4AdABpAG4AdQBpAHQAeQAgAGkAbgAgAHQAaABpAHMAIABTAEEALgANAE8AdQB0AFAAawB0AHMA UABuAEUAeABoAGEAdQBzAHQAZQBkAA0ATwB1AHQAUABrAHQAcwBUAG8AbwBsAG8AbgBnAA0ATwB1 AHQAWABjAGEAcwB0AFAAawB0AHMAUAByAG8AdABlAGMAdABlAGQADQBPAHUAdABYAGMAYQBzAHQA UABrAHQAcwBVAG4AdABhAGcAZwBlAGQADQBPAHUAdABYAGMAYQBzAHQAUABrAHQAcwBFAG4AYwBy AHkAcAB0AGUAZAANAE8AdQB0AFgAYwBhAHMAdABPAGMAdABlAHQAcwBFAG4AYwByAHkAcAB0AGUA ZAAgACgATQBTAEQAVQApAAAAoQ+aAAAAEQAAAAAAAAAAAPQAAAABAAAAAAARAAAAAAACABwAEQAA AAAEAgCABBgADgAAAAAEBgCABBgAAAAABgUAAAAABAIAgAQYABMAAAAABAYAgAQYAAAAAAYDAAAA AAQCAIAEGAA3AAAAAAQCAIAEFAABAAAAAAQCAIAEGABNAAAAAAQGAIAEGAD/AGb+NQAAAAAEBgCA BBgAAAD//gAAqg/2AAAAAwAAAAYAAAAJBAAAAgAAAAcAAAADAAkEAAAdAAAABgAAAAkEAAAOAAAA BwAAAAMACQQAAAgAAAAGAAAACQQAABAAAAAHAAAAAwAJBAAAOwAAAAYAAAAJBAAAEgAAAAcAAAAD AAkEAAABAAAABgAAAAkEAAAOAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABUAAAAHAAAAAwAJBAAA AQAAAAYAAAAJBAAAFAAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAVAAAABwAAAAMACQQAAAEAAAAG AAAACQQAABcAAAAHAAAAAwAJBAAACAAAAAYAAAAJBAAAAADzAxQAAAAWAAAAAAAAAAIAAAAOAQAA AAAAAAAAnw8EAAAAAAAAAAAAqA8UAAAALjFBRSBNYW5hZ2VtZW50IEluZm8AAKoPDAAAABUAAAAG AAAACQQAABAAnw8EAAAAAQAAAAAAqA+2AAAAU2VjWSBUeCBDb3VudGVycyA6DVRhYmxlIGluZGV4 ZWQgYnkgSW50ZXJmYWNlSW5kZXgNT3V0UGt0c1BuRXhoYXVzdGVkDU91dFBrdHNUb29sb25nDU91 dFhjYXN0UGt0c1Byb3RlY3RlZA1PdXRYY2FzdFBrdHNVbnRhZ2dlZA1PdXRYY2FzdFBrdHNFbmNy eXB0ZWQNT3V0WGNhc3RPY3RldHNFbmNyeXB0ZWQgKE1TRFUpDQ0AAKEPUAAAABMAAAAAAAAAAACk AAAAAQAAAAAAEwAAAAAAAAARAAAAAAQAAIAEDwAAAAAEBACABAAAAAZNAAAAAAQEAIAE/wBm/jcA AAAABAQAgAQAAP/+AACqD+oAAAAEAAAABwAAAAMACQQAAAEAAAAGAAAACQQAAAIAAAAHAAAAAwAJ BAAAHQAAAAYAAAAJBAAADgAAAAcAAAADAAkEAAABAAAABgAAAAkEAAASAAAABwAAAAMACQQAAAEA AAAGAAAACQQAAA4AAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFQAAAAcAAAADAAkEAAABAAAABgAA AAkEAAAUAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABUAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAA FwAAAAcAAAADAAkEAAAKAAAABgAAAAkEAAAAAPMDFAAAABkAAAAAAAAAAgAAABEBAAAAAAAAAACf DwQAAAAAAAAAAACoDxQAAAAuMUFFIE1hbmFnZW1lbnQgSW5mbwAAqg8MAAAAFQAAAAYAAAAJBAAA EACfDwQAAAABAAAAAACoD7kDAABSRkMyODYzIDogSW50ZXJmYWNlIE1JQiBjb3VudGVycw0gICAg IAkJaWZJbk9jdGV0c6CgoKCgoKCgoKCgoKAgQ291bnRlcjMyLAugoKCgoKCgoCBpZkluVWNhc3RQ a3RzoKCgoKCgoKCgoCBDb3VudGVyMzIsC6CgoKCgoKCgIGlmSW5EaXNjYXJkc6CgoKCgoKCgoKCg IENvdW50ZXIzMiwLoKCgoKCgoKAgaWZJbkVycm9yc6CgoKCgoKCgoKCgoKAgQ291bnRlcjMyLAug oKCgoKCgoCBpZkluVW5rbm93blByb3Rvc6CgoKCgoCBDb3VudGVyMzIsC6CgoKCgoKCgIGlmT3V0 T2N0ZXRzoKCgoKCgoKCgoKCgIENvdW50ZXIzMiwLoKCgoKCgoKAgaWZPdXRVY2FzdFBrdHOgoKCg oKCgoKAgQ291bnRlcjMyLAugoKCgoKCgoCBpZk91dERpc2NhcmRzoKCgoKCgoKCgoCBDb3VudGVy MzIsC6CgoKCgoKCgIGlmT3V0RXJyb3JzoKCgoKCgoKCgoKCgIENvdW50ZXIzMiwLoKCgoKCgoKAg aWZJbk11bHRpY2FzdFBrdHOgoKCgoKAgQ291bnRlcjMyLAugoKCgoKCgoCBpZkluQnJvYWRjYXN0 UGt0c6CgoKCgoCBDb3VudGVyMzIsC6CgoKCgoKCgIGlmT3V0TXVsdGljYXN0UGt0c6CgoKCgIENv dW50ZXIzMiwLoKCgoKCgoKAgaWZPdXRCcm9hZGNhc3RQa3RzoKCgoKAgQ291bnRlcjMyLAugoKCg oKCgoCBpZkhDSW5PY3RldHOgoKCgoKCgoKCgoCBDb3VudGVyNjQsC6CgoKCgoKCgIGlmSENJblVj YXN0UGt0c6CgoKCgoKCgIENvdW50ZXI2NCwLoKCgoKCgoKAgaWZIQ0luTXVsdGljYXN0UGt0c6Cg oKAgQ291bnRlcjY0LAugoKCgoKCgoCBpZkhDSW5Ccm9hZGNhc3RQa3RzoKCgoCBDb3VudGVyNjQs C6CgoKCgoKCgIGlmSENPdXRPY3RldHOgoKCgoKCgoKCgIENvdW50ZXI2NCwLoKCgoKCgoKAgaWZI Q091dFVjYXN0UGt0c6CgoKCgoKAgQ291bnRlcjY0LAugoKCgoKCgoCBpZkhDT3V0TXVsdGljYXN0 UGt0c6CgoCBDb3VudGVyNjQsC6CgoKCgoKCgIGlmSENPdXRCcm9hZGNhc3RQa3RzoKCgIENvdW50 ZXI2NAAAoQ8kAAAAIQAAAAAAABAAAFAAmQMAAAAAARAAAAAAUAC6AwAAAAACABIAAACqDy4CAAAo AAAABgAAAAkEAAAKAAAABwAAAAMACQQAACIAAAAGAAAACQQAAA0AAAAHAAAAAwAJBAAAHwAAAAYA AAAJBAAADAAAAAcAAAADAAkEAAAgAAAABgAAAAkEAAAKAAAABwAAAAMACQQAACIAAAAGAAAACQQA ABEAAAAHAAAAAwAJBAAAGwAAAAYAAAAJBAAACwAAAAcAAAADAAkEAAAhAAAABgAAAAkEAAAOAAAA BwAAAAMACQQAAB4AAAAGAAAACQQAAA0AAAAHAAAAAwAJBAAAHwAAAAYAAAAJBAAACwAAAAcAAAAD AAkEAAAhAAAABgAAAAkEAAARAAAABwAAAAMACQQAABsAAAAGAAAACQQAABEAAAAHAAAAAwAJBAAA GwAAAAYAAAAJBAAAEgAAAAcAAAADAAkEAAAaAAAABgAAAAkEAAASAAAABwAAAAMACQQAABoAAAAG AAAACQQAAAwAAAAHAAAAAwAJBAAAIAAAAAYAAAAJBAAADwAAAAcAAAADAAkEAAAdAAAABgAAAAkE AAATAAAABwAAAAMACQQAABkAAAAGAAAACQQAABMAAAAHAAAAAwAJBAAAGQAAAAYAAAAJBAAADQAA AAcAAAADAAkEAAAfAAAABgAAAAkEAAAQAAAABwAAAAMACQQAABwAAAAGAAAACQQAABQAAAAHAAAA AwAJBAAAGAAAAAYAAAAJBAAAFAAAAAcAAAADAAkEAAAOAAAABgAAAAkEAAAAAPMDFAAAABoAAAAA AAAAAgAAABIBAAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAAAuMUFFIE1hbmFnZW1lbnQgSW5mbwAA qg8MAAAAFQAAAAYAAAAJBAAAEACfDwQAAAABAAAAAACoDxYBAABNSUIgRGVzaWduDVdpbGwgZm9s bG93IHRoZSBNSUItUkVWSUVXLUdVSURFTElORVMsIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWlldGYtb3BzLW1pYi1yZXZpZXctZ3VpZGVsaW5lcy0wMy50eHQsIHZh bGlkIHRvIERlYy4gMjAwNC4NU05NUHYzIGFjY2VzcyBvbmx5ID8gUHJvYmFibHkgbm90LCBleGNl cHQgdGhlIEtleSBpbmZvcm1hdGlvbi4gKG5lZWQgdG8gdGhpbmsgYWJvdXQgaG93IHRvIGFjaGll dmUgdGhhdCBmb3Igbm9uLXNlY3VyZSBxdWVyeS4pDQAAoQ8mAAAACwAAAAAAAAAAAAwBAAABAAAA AAALAAAAAAAAAAwBAAAABAAAgAQAAKoPJAAAADIAAAAGAAAACQQAAE8AAAAGAAAACQQAAJYAAAAG AAAACQQAAA8A8g8YAAAAAADzDxAAAAAAAAAAAwAAAAQAAAAIZAowAADfDwgAAAAyAAAAgQAAAC8A 8A8cAAAAAADzAxQAAAAHAAAAAAAAAAAAAAAAAQAAAAAAAAAA6gMAAAAADwD4A74JAAACAO8DGAAA AAEAAAABAgcJCAAAAAAAAAAAAAAAAAATAGAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kA AJmZAJnMAABgAPAHIAAAAP///wAAAAAAlpaWAAAAAAD731MA/5lmAMwzAACZZgAAYADwByAAAAD/ //8AAAAAAICAgAAAAAAAmcz/AMzM/wAzM8wAr2f/AGAA8AcgAAAA3vbxAAAAAACWlpYAAAAAAP// /wCNxv8AAGbMAACoAABgAPAHIAAAAP//2QAAAAAAd3d3AAAAAAD///cAM8zMAP9QUAD/mQAAYADw ByAAAAAAgIAA////AABaWAD//5kAAGRiAG1vxwAA//8AAP8AAGAA8AcgAAAAgAAAAP///wBcHwAA 39KTAMwzAAC+eWAA//+ZANOiGQBgAPAHIAAAAAAAmQD///8AADNmAMz//wAzZswAALAAAGbM/wD/ 5wEAYADwByAAAAAAAAAA////ADNmmQDj6/EAADOZAEaKSwBmzP8A8OUAAGAA8AcgAAAAaGtdAP// /wB3d3cA0dHLAJCQggCAnqgA/8xmAOncuQBgAPAHIAAAAGZmmQD///8APj5cAP///wBgWXsAZmb/ AJnM/wD//5kAYADwByAAAABSPiYA////AC0gFQDfwI0AjHtwAI9fLwDMtAAAjJ6gAAAAow8+AAAA AQD//T8AAAAiIAAAZAAAAAD/AQBkAAAAAAAAAAAAQAIAAAAABwAAAP//7wCAAAAAAQAAAP//LAAA AAADAAAQAKMPfAAAAAUA//0/AAEAIiAAAGQAAAAA/wAAZAAUAAAA2AAAAEACAAAAAAcAAAD//+8A gAAAAAEAAAD//yAAAAAAAQAAgAUAABMg1AEgAQAAAgAcAIAFAAAiINACQAIAAAIAGACABQAAEyDw A2ADAAACABQAgAUAALsAEAWABAAAAAAgAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAA/wAAZAAeAAAA AAAAAEACAAAAAAcAAAD//+8AgAAAAAEAAAD//wwAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIA AAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAUACjD1IAAAAFAAAAAQkAAAAAAQAAAAAAAAABAAEJ AAAAAAEAIAEAAAAAAgABCQAAAAABAEACAAAAAAMAAQkAAAAAAQBgAwAAAAAEAAEJAAAAAAEAgAQA AAAAYACjDwwAAAABAAAAAAAAAAAAAABwAKMPPgAAAAUAAAAAAAAAAAACABwAAQAAAAAAAAACABgA AgAAAAAAAAACABQAAwAAAAAAAAACABIABAAAAAAAAAACABIAgACjDz4AAAAFAAAAAAAAAAAAAgAY AAEAAAAAAAAAAgAUAAIAAAAAAAAAAgASAAMAAAAAAAAAAgAQAAQAAAAAAAAAAgAQAA8ADATwBAAA DwAC8OgEAAAQAAjwCAAAAAYAAAAGBAAADwAD8IAEAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAA AAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATw0gAAABIACvAIAAAAAgQAAAAKAACTAAvwNgAAAH8A AQAFAIAA5E8nB4cAAQAAAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAI AAAArQAgAWAVfQMPABHwEAAAAAAAwwsIAAAAAAAAAAEAJwcPAA3wVAAAAAAAnw8EAAAAAAAAAAAA qA8gAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGl0bGUgc3R5bGUAAKIPBgAAACEAAAAAAAAAqg8K AAAAIQAAAAEAAAAAAA8ABPAWAQAAEgAK8AgAAAADBAAAAAoAAIMAC/AwAAAAfwABAAUAgADEUicH gQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAADwAyABYBUTDw8AEfAQ AAAAAADDCwgAAAABAAAAAgAnBw8ADfCeAAAAAACfDwQAAAABAAAAAACoD1IAAABDbGljayB0byBl ZGl0IE1hc3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhpcmQgbGV2ZWwNRm91cnRoIGxl dmVsDUZpZnRoIGxldmVsAACiDx4AAAAhAAAAAAANAAAAAQAMAAAAAgANAAAAAwAMAAAABAAAAKoP CgAAAFMAAAABAAAAAAAPAATw0AAAABIACvAIAAAABAQAAAAKAACDAAvwMAAAAH8AAQAFAIAA6Fgn B4EBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAXg8gAWAGihAPABHw EAAAAAAAwwsIAAAAAgAAAAcBJwcPAA3wWAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFAAA AAIAAAAAAAAAAAACAAAAAAACAA4AAAD4DwQAAAAAAAAAAACqDxIAAAABAAAAAQAAAAAAAQAAAAAA AAAPAATwuAAAABIACvAIAAAABQQAAAAKAACDAAvwMAAAAH8AAQAFAIAATF4nB4EBBAAACIMBAAAA CL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAXg+wB9AOihAPABHwEAAAAAAAwwsIAAAA AwAAAAkCJwcPAA3wQAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFgAAAAIAAAAAAAAIAAAB AAIAAAAAAAIADgAAAPoPBAAAAAAAAAAPAATwuAAAABIACvAIAAAABgQAAAAKAACDAAvwMAAAAH8A AQAFAIAAKGMnB4EBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAXg8g EGAVihAPABHwEAAAAAAAwwsIAAAABAAAAAgCJwcPAA3wQAAAAAAAnw8EAAAABAAAAAAAoA8CAAAA KgAAAKEPFgAAAAIAAAAAAAAIAAACAAIAAAAAAAIADgAAANgPBAAAAAAAAAAPAATwSAAAABIACvAI AAAAAQQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQD CQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAA AA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAFWZxAFw2Ls8 IAC6DxwAAABEAGUAZgBhAHUAbAB0ACAARABlAHMAaQBnAG4ADwDwAw4GAAABAPEDCAAAAAAAAIAA AAowDwAMBI4FAAAPAALwhgUAAFAACPAIAAAABwAAAAcUAAAPAAPwHgUAAA8ABPAoAAAAAQAJ8BAA AAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAFAAABQAAAA8ABPDMAAAAEgAK8AgAAAACFAAAAAoA AIMAC/AwAAAAfwABAAUAgAC8RZMHgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAI AAAQ8AgAAAAAAAAAUAcgAQ8AEfAQAAAAAADDCwgAAAAAAAAACgKTBw8ADfBUAAAAAACfDwQAAAAE AAAAAACgDwIAAAAqAAAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAIADAAAAPkPBAAAAAAAAAAAAKoP DgAAAAIAAAAHAAAAAAAJBAAADwAE8M4AAAASAArwCAAAAAMUAAAACgAAgwAL8DAAAAB/AAEABQCA AHxLkweBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAAAAjwnfECAB DwAR8BAAAAAAAMMLCAAAAAEAAAAHAJMHDwAN8FYAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAACh DxYAAAACAAAAAAAACAAAAgACAAAAAAACAAwAAAD4DwQAAAAAAAAAAACqDw4AAAACAAAABwAAAAAA CQQAAA8ABPBkAAAAEgAK8AgAAAAEFAAAAAoAAGMAC/AkAAAAfwAEAQQBhwABAAAAfwEAAAEAvwER ABEA/wEIAAkAPwIBAAEAAAAQ8AgAAACwAdACEA4gCg8AEfAQAAAAAADDCwgAAAACAAAABQCTBw8A BPAaAQAAEgAK8AgAAAAFFAAAAAoAAIMAC/AwAAAAfwABAAUAgAAYTpMHgQEEAAAIgwEAAAAIvwEB ABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAACwCrABMA/QFA8AEfAQAAAAAADDCwgAAAADAAAA BgKTBw8ADfCiAAAAAACfDwQAAAACAAAAAACoD1IAAABDbGljayB0byBlZGl0IE1hc3RlciB0ZXh0 IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhpcmQgbGV2ZWwNRm91cnRoIGxldmVsDUZpZnRoIGxldmVs AACiDx4AAAAhAAAAAAANAAAAAQAMAAAAAgANAAAAAwAMAAAABAAAAKoPDgAAAFMAAAAHAAAAAAAJ BAAADwAE8NIAAAASAArwCAAAAAYUAAAACgAAkwAL8DYAAAB/AAEABQCAADRjpgCHAAIAAACBAQQA AAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAF8VAABQB38WDwAR8BAAAAAA AMMLCAAAAAQAAAAJAoEHDwAN8FQAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxQAAAACAAAA AAAAAAAAAgAAAAAAAgAMAAAA+g8EAAAAAAAAAAAAqg8OAAAAAgAAAAcAAAAAAAkEAAAPAATw1AAA ABIACvAIAAAABxQAAAAKAACTAAvwNgAAAH8AAQAFAIAAFIWmAIcAAgAAAIEBBAAACIMBAAAACL8B AQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAXxWPCd8QfxYPABHwEAAAAAAAwwsIAAAABQAA AAgCpgAPAA3wVgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFgAAAAIAAAAAAAAIAAACAAIA AAAAAAIADAAAANgPBAAAAAAAAAAAAKoPDgAAAAIAAAAHAAAAAAAJBAAADwAE8EgAAAASAArwCAAA AAEUAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAd69aACUAY6fiwC/ARIAEgD/AQAACAAEAwkA AAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAP AIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAAAZs8QBcL2huw8A 7gN3AwAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAEwAPAAwEjgIAAA8AAvCGAgAAcAEI 8AgAAAAEAAAABVwAAA8AA/AeAgAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArw CAAAAABcAAAFAAAADwAE8HIAAAASAArwCAAAAAJcAAAgAgAAUwAL8B4AAAB/AAAABACAAMRtgQe/ AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAGAG8AAwFdAODwAR8BAAAAAAAMMLCAAAAAAAAAANAIEH DwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwugAAABIACvAIAAAABFwAAAAKAACTAAvwNgAAAH8AAAAF AIAAIG+BB4cAAQAAAIEBBAAACIMBAAAACL8BAAARAMABAQAACP8BAAAJAAECAgAACAAAEPAIAAAA UAFQAZAVIAQPAA3wVAAAAAAAnw8EAAAAAAAAAAAAqA8CAAAACwsAAKEPIgAAAAMAAAAAAAAAAAAC AAAAAAAGADAAAAAAAQEAAAAAAAIAIAAAAKoPDAAAAAMAAAAGAAAACQQAAA8ABPCqAAAAEgAK8AgA AAAFXAAAAAoAAIMAC/AwAAAAfwAAAAUAgAAAcoEHhwABAAAAgQH/mcwAvwEQABEAwAEBAAAI/wEA AAkAAQICAAAIEwAi8QYAAAC/AQAAYAAAABDwCAAAABACIAFgFVAEDwAN8DwAAAAAAJ8PBAAAAAAA AAAAAKgPFAAAAC4xQUUgTWFuYWdlbWVudCBJbmZvAACqDwwAAAAVAAAABgAAAAkEAAAPAATwSAAA ABIACvAIAAAAAVwAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8B AAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAP AIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAHjL xAGQbN1wAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAALkT AP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DEREAAAIA7wMYAAAAAAAA AA8QAAAAAAAAAAAAgAABAAAHABMADwAMBCgQAAAPAALwIBAAACAACPAIAAAAIAAAACoIAAAPAAPw uA8AAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPBS AAAAQgEK8AgAAAAFCAAAAAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGoKQEA /wEYABgAAQICAAAIAAAQ8AgAAACQBqAC8BKQBg8ABPBSAAAAQgEK8AgAAAAHCAAAAAoAAHMAC/Aq AAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGfbwAA/wEYABgAAQICAAAIAAAQ8AgAAABgCTAG MAZwCw8ABPBSAAAAQgEK8AgAAAAICAAAAAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEB AAAIywGfbwAA/wEYABgAAQICAAAIAAAQ8AgAAABwCzAGYA/QDg8ABPBSAAAAQgEK8AgAAAAJCAAA AAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGfbwAA/wEYABgAAQICAAAIAAAQ 8AgAAADQDmAPYA+wEA8ABPBSAAAAQgEK8AgAAAAKCAAAAAoAAHMAC/AqAAAARAEEAAAAfwEAAAEA vwEAABAAwAEBAAAIywGfbwAA/wEYABgAAQICAAAIAAAQ8AgAAABgCdAC0AKAEA8ABPBSAAAAQgEK 8AgAAAALCAAAAAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGfbwAA/wEYABgA AQICAAAIAAAQ8AgAAABgCcASwBKwEA8ABPBqAAAAkgsK8AgAAAAOCAAAAAoAALMAC/BCAAAABAAA AA4BhQACAAAAhwABAAAARwEwKgAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAIywGfbwAA/wEIAAgA AQICAAAIAAAQ8AgAAABgD5ASIBNQEA8ABPBqAAAAkgsK8AgAAAAPCAAAAAoAALMAC/BCAAAABAAA AA4BhQACAAAAhwABAAAARwEwKgAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAIywGfbwAA/wEIAAgA AQICAAAIAAAQ8AgAAABgDzAPwA9QEA8ABPBqAAAAkgsK8AgAAAAQCAAAAAoAALMAC/BCAAAABAAA AA4BhQACAAAAhwABAAAARwEwKgAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAIywGfbwAA/wEIAAgA AQICAAAIAAAQ8AgAAAAAD6ACMAPwDw8ABPBqAAAAkgsK8AgAAAARCAAAAAoAALMAC/BCAAAABAAA AA4BhQACAAAAhwABAAAARwEwKgAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAIywGfbwAA/wEIAAgA AQICAAAIAAAQ8AgAAADACQAGkAawCg8ABPCmAAAAEgAK8AgAAAATCAAAAAoAAKMAC/A8AAAAfwAA AAQAgAAw36YAhQACAAAAhwABAAAAgQEEAAAIvwEQABAAwAEBAAAIzgEGAAAA/wEIAAgAAQICAAAI AAAQ8AgAAACwB2ADABJACA8ADfA6AAAAAACfDwQAAAAEAAAAAACoDwoAAABFdmVudCBBUElzAACh DxQAAAALAAAAAAAACAAAAQALAAAAAAAAAA8ABPCuAAAAEgAK8AgAAAAUCAAAAAoAAKMAC/A8AAAA fwAAAAQAgADE3qYAhQACAAAAhwABAAAAgQEEAAAIvwEQABAAwAEBAAAIzgEGAAAA/wEIAAgAAQIC AAAIAAAQ8AgAAADgBGADABJwBQ8ADfBCAAAAAACfDwQAAAAEAAAAAACoDxIAAABDb25maWd1cmF0 aW9uIEFQSXMAAKEPFAAAABMAAAAAAAAIAAABABMAAAAAAAAADwAE8FgAAABCAQrwCAAAABcIAAAA CgAAgwAL8DAAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjQAQEAAADRAQEAAAD/ARgAGAABAgIA AAgAABDwCAAAAKAIgASABGAJDwAE8FgAAABCAQrwCAAAABgIAAAACgAAgwAL8DAAAABEAQQAAAB/ AQAAAQC/AQAAEADAAQEAAAjQAQEAAADRAQEAAAD/ARgAGAABAgIAAAgAABDwCAAAAKAIkA+QD2AJ DwAE8FgAAABCAQrwCAAAABkIAAAACgAAgwAL8DAAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjQ AQEAAADRAQEAAAD/ARgAGAABAgIAAAgAABDwCAAAAMAGgAqACoAHDwAE8FgAAABCAQrwCAAAABoI AAAACgAAgwAL8DAAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjQAQEAAADRAQEAAAD/ARgAGAAB AgIAAAgAABDwCAAAAKAFgAqACmAGDwAE8FgAAABCAQrwCAAAABsIAAAACgAAgwAL8DAAAABEAQQA AAB/AQAAAQC/AQAAEADAAQEAAAjQAQEAAADRAQEAAAD/ARgAGAABAgIAAAgAABDwCAAAAPADoAWg BbAEDwAE8FgAAABCAQrwCAAAABwIAAAACgAAgwAL8DAAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEA AAjQAQEAAADRAQEAAAD/ARgAGAABAgIAAAgAABDwCAAAAPADcAhwCLAEDwAE8JYAAACiDArwCAAA AB0IAAAACgAAgwAL8DAAAACAAIAtpgC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAA CAABAgIAAAgAABDwCAAAADADgATABhcEDwAN8DYAAAAAAJ8PBAAAAAQAAAAAAKgPBAAAAFNOTVAA AKEPFgAAAAUAAAAAAAAgAAAyAAUAAAABAAAAgQAPAATwkwAAAKIMCvAIAAAAHggAAAAKAACDAAvw MAAAAIAAjN+mAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAI AAAAMAOwBzAJFwQPAA3wMwAAAAAAnw8EAAAABAAAAAAAqA8DAAAAQ0xJAAChDxQAAAAEAAAAAAAA AAAABAAAAAEAAACBAA8ABPBYAAAAQgEK8AgAAAAfCAAAAAoAAIMAC/AwAAAARAEEAAAAfwEAAAEA vwEAABAAwAEBAAAI0AEBAAAA0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAADwA+AN4A2wBA8ABPCX AAAAogwK8AgAAAAgCAAAAAoAAIMAC/AwAAAAgAC0NKYAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAA wAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAAAwA8AMYA8XBA8ADfA3AAAAAACfDwQAAAAEAAAAAACo DwMAAABFQVAAAKEPGAAAAAQAAAAAAAAoAAABADIABAAAAAEAAACBAA8ABPCYAAAAogwK8AgAAAAh CAAAAAoAAIMAC/AwAAAAgAAYOaYAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgA AQICAAAIAAAQ8AgAAADgCkALUA0nDA8ADfA4AAAAAACfDwQAAAAEAAAAAACoDwQAAAAuMWFmAACh DxgAAAAFAAAAAAAAIAAAMgAFAAAAAQACAIEAHAAPAATwsgAAAKIMCvAIAAAAIggAAAAKAACDAAvw MAAAAIAAvDymAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAI AAAAAAbwEvAVbQcPAA3wUgAAAAAAnw8EAAAABAAAAAAAqA8UAAAATE1JIChkYXRhIHN0cnVjdHVy ZSkAAKEPIgAAABUAAAAAAAAgAAAyAAQAAAABAAAAgQARAAAAAQACAIEADgAPAATwnwAAAKIMCvAI AAAAIwgAAAAKAACDAAvwMAAAAIAASEGmAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8B AAAIAAECAgAACAAAEPAIAAAAsA1gAKAC0A4PAA3wPwAAAAAAnw8EAAAABAAAAAAAqA8LAAAAQ29t bW9uIHBvcnQAAKEPGAAAAAwAAAAAAAAgAAAyAAwAAAABAAIAgQAMAA8ABPCjAAAAogwK8AgAAAAk CAAAAAoAAIMAC/AwAAAAgABARaYAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgA AQICAAAIAAAQ8AgAAABgD5AMMA+AEA8ADfBDAAAAAACfDwQAAAAEAAAAAACoDw8AAABDb250cm9s bGVkIHBvcnQAAKEPGAAAABAAAAAAAAAgAAAyABAAAAABAAIAgQAMAA8ABPCrAAAAEgAK8AgAAAAl CAAAAAoAAJMAC/A2AAAAfwAAAAQAgAA4SaYAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI /wEAAAgAAQICAAAIAAAQ8AgAAACQCZAGkAmwCg8ADfBFAAAAAACfDwQAAAAEAAAAAACoDxEAAABV bmNvbnRyb2xsZWQgcG9ydAAAoQ8YAAAAEgAAAAAAACAAADIAEgAAAAEAAgCBAAwADwAE8KkAAACi DArwCAAAACYIAAAACgAAgwAL8DAAAACAABRNpgC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEA AAj/AQAACAABAgIAAAgAABDwCAAAADAPIBOAFooQDwAN8EkAAAAAAJ8PBAAAAAQAAAAAAKgPFQAA AFVzZXIgY29udHJvbGxlZA0gcG9ydAAAoQ8YAAAAFgAAAAAAACAAADIAFgAAAAEAAgCBAAwADwAE 8JgAAACiDArwCAAAACgIAAAACgAAgwAL8DAAAACAAHCXpgC/AAIAAgCBAQQAAAiDAQAAAAi/AQAA EADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAALANkAZgCfcODwAN8DgAAAAAAJ8PBAAAAAQAAAAA AKgPBAAAAC4xQUUAAKEPGAAAAAUAAAAAAAAgAAAyAAUAAAABAAIAgQAcAA8ABPBeAAAAQgEK8AgA AAApCAAAAAoAAJMAC/A2AAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGoKQEAzgECAAAA1wEA AAAA/wEYABgAAQICAAAIAAAQ8AgAAADwA/AJAAzwAw8ABPCqAAAAEgAK8AgAAAAqCAAAAAoAAIMA C/AwAAAAfwAAAAUAgABkOqYAhwABAAAAgQH/mcwAvwEQABEAwAEBAAAI/wEAAAkAAQICAAAIEwAi 8QYAAAC/AQAAYAAAABDwCAAAAJAAIAFgFdACDwAN8DwAAAAAAJ8PBAAAAAYAAAAAAKgPFAAAAC4x QUUgTWFuYWdlbWVudCBJbmZvAACqDwwAAAAVAAAABgAAAAkEAAAPAATwSAAAABIACvAIAAAAAQgA AAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8D AQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJ AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAFWZxAFwSb48AAAAKwQA AAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAALkTAP////8SAAAADwA9 8Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DowIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAA gAAAAAAHABMADwAMBLoBAAAPAALwsgEAAIAACPAIAAAAAwAAAAMgAAAPAAPwSgEAAA8ABPAoAAAA AQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAIAAABQAAAA8ABPCYAAAAEgAK8AgAAAAC IAAAIAIAAJMAC/A2AAAAfwAAAAQAgADgrqYAgAEAAAAAgQH/mcwAggEAAAEAhAEAAAEAvwEQABEA /wEAAAkAAQMCBAAAEwAi8QYAAAC/AQAAYAAAABDwCAAAAK0AIAFgFX0DDwAR8BAAAAAAAMMLCAAA AAAAAAANAKYADwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAyAAACACAABTAAvw HgAAAH8AAAAEAIAAtK+mAL8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA8AMgAWAVEw8PABHwEAAA AAAAwwsIAAAAAQAAAA4ApgAPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABIAAA AAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMB AAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBORAAAADwCKE4kA AAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAAAAAA6y4IAAAAS7XEAeBy3RcAAAArBAAA AAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAuRMA/////xIAAAAPAD3x DQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAA8A7gOjAgAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACA AAAAAAcAEwAPAAwEugEAAA8AAvCyAQAAkAAI8AgAAAADAAAAAyQAAA8AA/BKAQAADwAE8CgAAAAB AAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAkAAAFAAAADwAE8JgAAAASAArwCAAAAAIk AAAgAgAAkwAL8DYAAAB/AAAABACAAFx+pgCAAQAAAACBAf+ZzACCAQAAAQCEAQAAAQC/ARAAEQD/ AQAAAQABAwIEAAATACLxBgAAAL8BAABgAAAAEPAIAAAArQAgAWAVfQMPABHwEAAAAAAAwwsIAAAA AAAAAA0ApgAPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAADJAAAIAIAAFMAC/Ae AAAAfwAAAAQAgAAAf6YAvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgAAADwAyABYBUgEA8AEfAQAAAA AADDCwgAAAABAAAADgCmAA8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAEkAAAA DAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEA AQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIE5EAAAAPAIoTiQAA AAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNpAAAAAADrLggAAAAEt8QBIAT3TgAAACsEAAAA AAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAC5EwD/////EgAAAA8APfEN AAAAQAFC8QUAAAABCQAAAA8AAisAAAAADwDuA6MCAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAA AAAABwATAA8ADAS6AQAADwAC8LIBAACgAAjwCAAAAAMAAAADKAAADwAD8EoBAAAPAATwKAAAAAEA CfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAACgAAAUAAAAPAATwmAAAABIACvAIAAAAAigA ACACAACTAAvwNgAAAH8AAAAEAIAA7IWmAIABAAAAAIEB/5nMAIIBAAABAIQBAAABAL8BEAARAP8B AAAJAAEDAgQAABMAIvEGAAAAvwEAAGAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAA AAAADQCmAA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMoAAAgAgAAUwAL8B4A AAB/AAAABACAAJCGpgC/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAMAD8AAwFeMODwAR8BAAAAAA AMMLCAAAAAEAAAAOAKYADwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAASgAAAAM AACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQAB ABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAA AAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAJy3xAGQago2AAAAKwQAAAAA AAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAALkTAP////8SAAAADwA98Q0A AABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DSgIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAA AAAHABMADwAMBLoBAAAPAALwsgEAAOAACPAIAAAAAwAAAAM4AAAPAAPwSgEAAA8ABPAoAAAAAQAJ 8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAOAAABQAAAA8ABPCYAAAAEgAK8AgAAAACOAAA IAIAAJMAC/A2AAAAfwAAAAQAgACEmoEHgAEAAAAAgQH/mcwAggEAAAEAhAEAAAEAvwEQABEA/wEA AAEAAQMCBAAAEwAi8QYAAAC/AQAAYAAAABDwCAAAAJAAIAFgFdACDwAR8BAAAAAAAMMLCAAAAAAA AAANAIEHDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAzgAACACAABTAAvwHgAA AH8AAAAEAIAAKJuBB78BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAAAAMgAWAVUBAPABHwEAAAAAAA wwsIAAAAAQAAAA4AgQcPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABOAAAAAwA AIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEA EADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAA ALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAr7fEAaA+00gPAO4DSgIAAAIA 7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHABMADwAMBLoBAAAPAALwsgEAAPAACPAIAAAAAwAA AAM8AAAPAAPwSgEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAPAAA BQAAAA8ABPCYAAAAEgAK8AgAAAACPAAAIAIAAJMAC/A2AAAAfwAAAAQAgAC0pYEHgAEAAAAAgQH/ mcwAggEAAAEAhAEAAAEAvwEQABEA/wEAAAkAAQMCBAAAEwAi8QYAAAC/AQAAYAAAABDwCAAAAK0A IAFgFX0DDwAR8BAAAAAAAMMLCAAAAAAAAAANAIEHDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAA ABIACvAIAAAAAzwAACACAABTAAvwHgAAAH8AAAAEAIAAiKaBB78BAAABAP8BAAABAAEDAwQAAAAA EPAIAAAA8AMgAWAVEw8PABHwEAAAAAAAwwsIAAAAAQAAAA4AgQcPAA3wDAAAAAAAng8EAAAAAQAA AA8ABPBIAAAAEgAK8AgAAAABPAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgA vwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAA mZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA 6y4IAAAAsrfEASC9/F4PAO4DowIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHABMADwAM BLoBAAAPAALwsgEAAAABCPAIAAAAAwAAAANAAAAPAAPwSgEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAA AAAAAAAAAAAAAAAAAgAK8AgAAAAAQAAABQAAAA8ABPCYAAAAEgAK8AgAAAACQAAAIAIAAJMAC/A2 AAAAfwAAAAQAgACwWoEHgAEAAAAAgQH/mcwAggEAAAEAhAEAAAEAvwEQABEA/wEAAAEAAQMCBAAA EwAi8QYAAAC/AQAAYAAAABDwCAAAAK0AIAFgFX0DDwAR8BAAAAAAAMMLCAAAAAAAAAANAIEHDwAN 8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAA0AAACACAABTAAvwHgAAAH8AAAAEAIAA hFuBB78BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA8AMgAWAVEw8PABHwEAAAAAAAwwsIAAAAAQAA AA4AgQcPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABQAAAAAwAAIMAC/AwAAAA gQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD/ //8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBORAAAADwCKE4kAAAAAALoPEAAAAF8A XwBfAFAAUABUADEAMAAAAIsTaQAAAAAA6y4IAAAAs7fEAdAgTxYAAAArBAAAAAAAAAAfAETxPQAA AAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAuRMA/////xIAAAAPAD3xDQAAAEABQvEFAAAA AQkAAAAPAAIrAAAAAA8A7gNKAgAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAEwAPAAwE ugEAAA8AAvCyAQAAEAEI8AgAAAADAAAAA0QAAA8AA/BKAQAADwAE8CgAAAABAAnwEAAAAAAAAAAA AAAAAAAAAAAAAAACAArwCAAAAABEAAAFAAAADwAE8JgAAAASAArwCAAAAAJEAAAgAgAAkwAL8DYA AAB/AAAABACAABC4gQeAAQAAAACBAf+ZzACCAQAAAQCEAQAAAQC/ARAAEQD/AQAACQABAwIEAAAT ACLxBgAAAL8BAABgAAAAEPAIAAAArQAgAWAVfQMPABHwEAAAAAAAwwsIAAAAAAAAAA0AgQcPAA3w DAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAADRAAAIAIAAFMAC/AeAAAAfwAAAAQAgADk uIEHvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgAAADwAyABYBUTDw8AEfAQAAAAAADDCwgAAAABAAAA DgCBBw8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAFEAAAADAAAgwAL8DAAAACB AQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP// /wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBf AF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAAC1t8QBkCkZgQ8A7gP6BgAAAgDvAxgAAAABAAAA DQ4AAAAAAAAAAACAAAAAAAcAEwAPAAwEagYAAA8AAvBiBgAAIAEI8AgAAAADAAAABUgAAA8AA/D6 BQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAABIAAAFAAAADwAE8LAA AAASAArwCAAAAARIAAAACgAAkwAL8DYAAAB/AAAABQCAAFDJgQeHAAEAAACBAf+ZzACDAQAAAAi/ ARAAEQDAAQEAAAj/AQAACQABAgIAAAgTACLxBgAAAL8BAABgAAAAEPAIAAAAYAAgAWAVMAMPAA3w PAAAAAAAnw8EAAAAAAAAAAAAqA8UAAAALjFBRSBNYW5hZ2VtZW50IEluZm8AAKoPDAAAABUAAAAG AAAACQQAAA8ABPAKBQAAEgAK8AgAAAAFSAAAAAoAAIMAC/AwAAAAfwAAAAUAgAB814EHgQEEAAAI gwEAAAAIvwEAABEAwAEBAAAI/wEAAAkAAQICAAAIAAAQ8AgAAAAAA1ABkBUjDg8ADfCqBAAAAACf DwQAAAABAAAAAACgD7ICAABTAEEAIABSAHgAIABDAG8AdQBuAHQAZQByAHMAIAA6AA0AVABhAGIA bABlACAAaQBuAGQAZQB4AGUAZAAgAGIAeQAgAEkAbgB0AGUAcgBmAGEAYwBlAEkAbgBkAGUAeAAg AGEAbgBkACAAUwBDAEkAIABhAG4AZAAgAEEATgANAEkAbgBDAG4AdABSAGUAaQBuAGkAdABUAGkA bQBlACAAOgAgAEEAIAB0AGkAbQBlAHMAdABhAG0AcAAgAGYAbwByACAAdABoAGUAIABjAG8AdQBu AHQAZQByAHMAGSAgAGQAaQBzAGMAbwBuAHQAaQBuAHUAaQB0AHkAIABpAG4AIAB0AGgAaQBzACAA UwBBAC4ADQBJAG4AWABjAGEAcwB0AFAAawB0AHMATgBvAHQAUgBlAGMAZQBpAHYAZQBkAA0ASQBu AFgAYwBhAHMAdABQAGsAdABzAEkAbgB2AGEAbABpAGQADQBJAG4AWABjAGEAcwB0AFAAawB0AHMA UgBlAHAAbABhAHkAZQBkAA0ASQBuAFgAYwBhAHMAdABQAGsAdABzAE0AaQBzAG8AcgBkAGUAcgBl AGQAIAANAEkAbgBYAGMAYQBzAHQAUABrAHQAcwBPAHIAZABlAHIAZQBkAA0ASQBuAFgAYwBhAHMA dABQAGsAdABzAEUAbgBjAHIAeQBwAHQAZQBkAA0ASQBuAFgAYwBhAHMAdABQAGsAdABzAEQAZQBj AHIAeQBwAHQAZQBkAA0ASQBuAFgAYwBhAHMAdABPAGMAdABlAHQAcwBFAG4AYwByAHkAcAB0AGUA ZAAgACgATQBTAEQAVQApAA0ASQBuAFgAYwBhAHMAdABPAGMAdABlAHQAcwBEAGUAYwByAHkAcAB0 AGUAZAAgACgATQBTAEQAVQApAA0ADQAAAKEPqgAAABEAAAAAAAAAAABJAQAAAQAAAAAAEQAAAAAA AgAcABEAAAAABAIAgAQYAA4AAAAABAYAgAQYAAAAAAYFAAAAAAQCAIAEGAADAAAAAAQGAIAEGAAA AAAGBQAAAAAEAgCABBgAEgAAAAAEBgCABBgAAAAABjsAAAAABAIAgAQYAFUAAAAABAYAgAQYAP8A Zv55AAAAAAQGAIAEGAAAAP/+AgAAAAAEAgCABBgAAACqDyoBAAAiAAAABgAAAAkEAAAOAAAABwAA AAMACQQAABAAAAAGAAAACQQAAA8AAAAHAAAAAwAJBAAAOwAAAAYAAAAJBAAAFgAAAAcAAAADAAkE AAABAAAABgAAAAkEAAASAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABMAAAAHAAAAAwAJBAAAAQAA AAYAAAAJBAAAFQAAAAcAAAADAAkEAAACAAAABgAAAAkEAAASAAAABwAAAAMACQQAAAEAAAAGAAAA CQQAABQAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFAAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAW AAAABwAAAAMACQQAAAgAAAAGAAAACQQAABYAAAAHAAAAAwAJBAAACgAAAAYAAAAJBAAADwAE8EgA AAASAArwCAAAAAFIAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/ AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAA DwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAABx y8QBQM1oWQ8A7gO8AgAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAEwAPAAwELAIAAA8A AvAkAgAAMAEI8AgAAAADAAAABEwAAA8AA/C8AQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAA AAAAAAACAArwCAAAAABMAAAFAAAADwAE8HIAAAASAArwCAAAAANMAAAgAgAAUwAL8B4AAAB/AAAA BACAAJjsgQe/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAA AAEAAAAOAIEHDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwCgEAABIACvAIAAAABEwAACAKAACjAQvw nAAAAAQAAAAAAH8AAAAFAIAAbO2BB4EAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIYAAAAA AIcAAQAAAIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AEAAfAIABAAAAAIEB/5nMAIIBAAABAIMB AAAACIQBAAABAL8BEAARAMABAQAACP8BAAAJAAECAgAACAEDAgQAAIgDAAAAADMAIvESAAAAjAAB AAAAjQAwZQEAvwEAAGAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAADQCBBw8A DfAMAAAAAACeDwQAAAAAAAAADwAE8EgAAAASAArwCAAAAAFMAAAADAAAgwAL8DAAAACBAQAAAAiD AQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAA gICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQ AFQAMQAwAAAAixMQAAAAAADrLggAAAByy8QBkJgsVg8A7gO8AgAAAgDvAxgAAAABAAAADQ4AAAAA AAAAAACAAAAAAAcAEwAPAAwELAIAAA8AAvAkAgAAQAEI8AgAAAADAAAABFAAAA8AA/C8AQAADwAE 8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAABQAAAFAAAADwAE8HIAAAASAArw CAAAAANQAAAgAgAAUwAL8B4AAAB/AAAABACAAAj7gQe/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAA APADIAFgFeAQDwAR8BAAAAAAAMMLCAAAAAEAAAAOAIEHDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATw CgEAABIACvAIAAAABFAAACAKAACjAQvwnAAAAAQAAAAAAH8AAAAFAIAA3PuBB4EAMGUBAIIAmLIA AIMAMGUBAIQAmLIAAIUAAAAAAIYAAAAAAIcAAQAAAIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8A EAAfAIABAAAAAIEB/5nMAIIBAAABAIMBAAAACIQBAAABAL8BEAARAMABAQAACP8BAAAJAAECAgAA CAEDAgQAAIgDAAAAADMAIvESAAAAjAABAAAAjQAwZQEAvwEAAGAAAAAQ8AgAAACtACABYBV9Aw8A EfAQAAAAAADDCwgAAAAAAAAADQCBBw8ADfAMAAAAAACeDwQAAAAAAAAADwAE8EgAAAASAArwCAAA AAFQAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkA AAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAP AIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAABzy8QBcJit3w8A 7gO8AgAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAEwAPAAwELAIAAA8AAvAkAgAAYAEI 8AgAAAADAAAABFgAAA8AA/C8AQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArw CAAAAABYAAAFAAAADwAE8HIAAAASAArwCAAAAANYAAAgAgAAUwAL8B4AAAB/AAAABACAAAwNkwe/ AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAJMH DwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwCgEAABIACvAIAAAABFgAACAKAACjAQvwnAAAAAQAAAAA AH8AAAAFAIAA4A2TB4EAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIYAAAAAAIcAAQAAAIgA AAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AEAAfAIABAAAAAIEB/5nMAIIBAAABAIMBAAAACIQBAAAB AL8BEAARAMABAQAACP8BAAAJAAECAgAACAEDAgQAAIgDAAAAADMAIvESAAAAjAABAAAAjQAwZQEA vwEAAGAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAADQCTBw8ADfAMAAAAAACe DwQAAAAAAAAADwAE8EgAAAASAArwCAAAAAFYAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6f iwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC7 4OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAA ixMQAAAAAADrLggAAAB3y8QBMNFxGg8A7gO8AgAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAA AAcAEwAPAAwELAIAAA8AAvAkAgAAUAEI8AgAAAADAAAABFQAAA8AA/C8AQAADwAE8CgAAAABAAnw EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAABUAAAFAAAADwAE8HIAAAASAArwCAAAAANUAAAg AgAAUwAL8B4AAAB/AAAABACAAJh5pgC/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAPADIAFgFRMP DwAR8BAAAAAAAMMLCAAAAAEAAAAOAJMHDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwCgEAABIACvAI AAAABFQAACAKAACjAQvwnAAAAAQAAAAAAH8AAAAFAIAAhGymAIEAMGUBAIIAmLIAAIMAMGUBAIQA mLIAAIUAAAAAAIYAAAAAAIcAAQAAAIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AEAAfAIABAAAA AIEB/5nMAIIBAAABAIMBAAAACIQBAAABAL8BEAARAMABAQAACP8BAAAJAAECAgAACAEDAgQAAIgD AAAAADMAIvESAAAAjAABAAAAjQAwZQEAvwEAAGAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADD CwgAAAAAAAAADQCmAA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8EgAAAASAArwCAAAAAFUAAAADAAA gwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQ APAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAA ug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAAB0y8QBAFmXwg8A7gO8AgAAAgDv AxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAEwAPAAwELAIAAA8AAvAkAgAAgAEI8AgAAAADAAAA BGAAAA8AA/C8AQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAABgAAAF AAAADwAE8HIAAAASAArwCAAAAANgAAAgAgAAUwAL8B4AAAB/AAAABACAAIgmkwe/AQAAAQD/AQAA AQABAwMEAAAAABDwCAAAAPADIAFgFVAQDwAR8BAAAAAAAMMLCAAAAAEAAAAOAJMHDwAN8AwAAAAA AJ4PBAAAAAEAAAAPAATwCgEAABIACvAIAAAABGAAACAKAACjAQvwnAAAAAQAAAAAAH8AAAAFAIAA XCeTB4EAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIYAAAAAAIcAAQAAAIgAAAAAAIkAAAAA AIoAAAAAAIsAAAAAAL8AEAAfAIABAAAAAIEB/5nMAIIBAAABAIMBAAAACIQBAAABAL8BEAARAMAB AQAACP8BAAAJAAECAgAACAEDAgQAAIgDAAAAADMAIvESAAAAjAABAAAAjQAwZQEAvwEAAGAAAAAQ 8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAADQCTBw8ADfAMAAAAAACeDwQAAAAAAAAA DwAE8EgAAAASAArwCAAAAAFgAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZ mQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADr LggAAACHy8QBMBAU9g8A7gO8AgAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAEwAPAAwE LAIAAA8AAvAkAgAAoAEI8AgAAAADAAAABGgAAA8AA/C8AQAADwAE8CgAAAABAAnwEAAAAAAAAAAA AAAAAAAAAAAAAAACAArwCAAAAABoAAAFAAAADwAE8HIAAAASAArwCAAAAANoAAAgAgAAUwAL8B4A AAB/AAAABACAAJg4kwe/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAPADIAFgFfAPDwAR8BAAAAAA AMMLCAAAAAEAAAAOAJMHDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwCgEAABIACvAIAAAABGgAACAK AACjAQvwnAAAAAQAAAAAAH8AAAAFAIAAbDmTB4EAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAA AIYAAAAAAIcAAQAAAIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AEAAfAIABAAAAAIEB/5nMAIIB AAABAIMBAAAACIQBAAABAL8BEAARAMABAQAACP8BAAAJAAECAgAACAEDAgQAAIgDAAAAADMAIvES AAAAjAABAAAAjQAwZQEAvwEAAGAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAA DQCTBw8ADfAMAAAAAACeDwQAAAAAAAAADwAE8EgAAAASAArwCAAAAAFoAAAADAAAgwAL8DAAAACB AQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP// /wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBf AF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAAAEzMQBIPqqTg8A8AMsAgAAAQDxAwgAAAAAAQAA BwAKMA8ADASsAQAADwAC8KQBAABgAAjwCAAAAAMAAAADGAAADwAD8DwBAAAPAATwKAAAAAEACfAQ AAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAABgAAAUAAAAPAATwWAAAABIACvAIAAAAAhgAACAC AABDAAvwGAAAAH8ABAAEAL8BAQABAP8BAQABAAEDBBQAAAAAEPAIAAAAsAHQAhAOIAoPABHwEAAA AAAAwwsIAAAAAAAAAAsAkwcPAATwpAAAABIACvAIAAAAAxgAACACAABTAAvwHgAAAH8AAAAEAIAA AFmTB78BAQABAP8BAQABAAEDBRQAAAAAEPAIAAAAsAqwATAP0BQPABHwEAAAAAAAwwsIAAAAAQAA AAwAkwcPAA3wPgAAAAAAnw8EAAAAAgAAAAAAoQ8UAAAAAQAAAAAAAAAAAAEAAAABAAAAgQAAAKoP DgAAAAEAAAAHAAAAAAAJBAAADwAE8EgAAAASAArwCAAAAAEYAAAADAAAgwAL8DAAAACBAQAAAAiD AQUAAAiTAd69aACUAY6fiwC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAA gICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQ AFQAMQAwAAAAixMQAAAAAADrLggAAAAZs8QBUBWwuwAAchdgAAAAAQAwAAAAAAAMNAAAZ0cAAAYA IADSPQAAvIEAAAkAMACAWAAAK1sAANZdAAAPAMAAgWAAANNiAAAlZQAA0GcAACJqAAAkcQAA6HMA AHB5AACsdgAA6EMAADR8AAD4fgAAAAD1DxwAAAASAQAAZRkAAwAAAADwgwAAAQAAABoAAAAPAJ8A DwDoAwQ0AAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAYAAAAAAAAAAQAAAAAAAAEP AAkEbAEAAAAACgQEAAAABAAAAA8A1w9YAQAAAADTDwQAAAADAAAAAAC6D54AAABoAHQAdABwADoA LwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AaQBuAHQAZQByAG4AZQB0AC0AZAByAGEAZgB0 AHMALwBkAHIAYQBmAHQALQBpAGUAdABmAC0AbwBwAHMALQBtAGkAYgAtAHIAZQB2AGkAZQB3AC0A ZwB1AGkAZABlAGwAaQBuAGUAcwAtADAAMwAuAHQAeAB0ABAAug+eAAAAaAB0AHQAcAA6AC8ALwB3 AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAGkAbgB0AGUAcgBuAGUAdAAtAGQAcgBhAGYAdABzAC8A ZAByAGEAZgB0AC0AaQBlAHQAZgAtAG8AcABzAC0AbQBpAGIALQByAGUAdgBpAKuUAA8AAABEZWZh dWx0IERlc2lnbgA1AAAARnJhbmsgQ2hhbyAgZmNoYW9AY2lzY28uY29tICBTYW4gQW50b25pbyAg MTEvMTQvMjAwNAAIAAAAU2xpZGUgMgAVAAAALjFBRSBNYW5hZ2VtZW50IEluZm8AFQAAAC4xQUUg TWFuYWdlbWVudCBJbmZvABUAAAAuMUFFIE1hbmFnZW1lbnQgSW5mbwAVAAAALjFBRSBNYW5hZ2Vt ZW50IEluZm8AFQAAAC4xQUUgTWFuYWdlbWVudCBJbmZvABUAAAAuMUFFIE1hbmFnZW1lbnQgSW5m bwAVAAAALjFBRSBNYW5hZ2VtZW50IEluZm8ACQAAAFNsaWRlIDEwABUAAAAuMUFFIE1hbmFnZW1l bnQgSW5mbwAVAAAALjFBRSBNYW5hZ2VtZW50IEluZm8AFQAAAC4xQUUgTWFuYWdlbWVudCBJbmZv ABUAAAAuMUFFIE1hbmFnZW1lbnQgSW5mbwAVAAAALjFBRSBNYW5hZ2VtZW50IEluZm8AFQAAAC4x QUUgTWFuYWdlbWVudCBJbmZvAAwQAAAGAAAAHgAAAAsAAABGb250cyBVc2VkAAMAAAACAAAAHgAA ABAAAABEZXNpZ24gVGVtcGxhdGUAAwAAAAEAAAAeAAAADQAAAFNsaWRlIFRpdGxlcwADAAAAEAAA AAAAACABAAADAAAAAAAAACAAAAABAAAAOAAAAAIAAABAAAAAAQAAAAIAAAAMAAAAX1BJRF9ITElO S1MAAgAAAOn9AABBAAAA2AAAAAYAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAABwAAAB8A AABQAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAGkAbgB0AGUAcgBu AGUAdAAtAGQAcgBhAGYAdABzAC8AZAByAGEAZgB0AC0AaQBlAHQAZgAtAG8AcABzAC0AbQBpAGIA LQByAGUAdgBpAGUAdwAtAGcAdQBpAGQAZQBsAGkAbgBlAHMALQAwADMALgB0AHgAdAAAAB8AAAAB AAAAAAAAAAQABAAAAC4BAAAEAAAALQEAAPYPIgAAABQAAABfwJHjMVcBAAoA9AMDACcHRnJhbmsg Q2hhbwgAAABGAHIAYQBuAGsAIABDAGgAYQBvAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIBAQAF AAAACQIAAAACHgAAADIKRQAyAA8AAABmY2hhb0BjaXNjby5jb20AAgAEAAQABAAEAAcABAABAAQA BAAEAAEABAAEAAYABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAAAPsC+f90AC0AZAByAGEAZgB0 AHMALwBkAHIAYQBmAHQALQBpAGUAdABmAC0AbwBwAHMALQBtAGkAYgAtAHIAZQB2AGkAZQB3AC0A ZwB1AGkAZABlAGwAaQBuAGUAcwAtADAAMwAuAHQAeAB0AA8A8gNgAQAALwDIDwwAAAAwANIPBAAA AAAAAAAPANUHmAAAAAAAtw9EAAAAQQByAGkAYQBsAAAACAAAAAAAAACIuRMAiLkTACgVJwcIuBMA 8LcTAPboBzAIAAAAAAAAAAi4EwDSQgkwALgTAAAABAAQALcPRAAAALBlMH0OZtSaAAAAAAgAAAAA AAAAiLkTAIi5EwAoFScHCLgTAPC3EwD26AcwCAAAAAAAAAAIuBMA0kIJMAC4EwCIAAQSAACkDwgA AACBAEAAgQAAAAAApQ8MAAAAAAAACC4AAAAHAAAAAACpDwoAAAAHAAAAAgAEBAkEQACjD24AAAAF AP/9PwAAACIgAABkAAAAAP8AAGQAAAAAAAAAAABAAgAAAAAHAAAA///vAIAAAAABAAAA//8SAAAA AAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwRU AQAADwAA8EwBAAAAAAbw4AAAAAVoAAAbAAAAXgAAABMAAAABAAAABwAAAAIAAAArAAAAAAAAAAYA AAAAAAAAPwAAAAUAAAAIAAAABgAAAAQAAAAAAAAAwAAAAAgAAAAEAAAACQAAAAQAAAAKAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAA4AAAAEAAAADwAAAAQAAAAQAAAABAAAABEAAAAEAAAA EgAAAAYAAAATAAAABQAAABQAAAAFAAAAFQAAAAUAAAAWAAAABQAAABcAAAAGAAAAGAAAAAUAAAAA AAAABAAAABoAAAAFAAAAgwAL8DAAAACBAQQAAAiDAQAAAAiGQQAAAAC/ARAAEADAAQEAAAjFQQAA AAD/AQgACAABAgIAAAgwABrxDAAAAP8AZgAAAP8A/wAAAEAAHvEQAAAABAAACAEAAAgCAAAI9wAA EB8A8A8cAAAAAADzAxQAAAACAAAAAAAAAAAAAAAAAACAAAAAAA8A0Ad3AQAAHwAUBBwAAAAAABUE FAAAAEaTTwkAypo7+7F3OADKmjsBAQAADwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAAJQAAAGQA AAAlAAAAZAAAAAgAAAAAAAAAILgTANJCCTAAAAAAAAAAAD7+//+y////AQATAHAA+wMIAAAAAAAA AHAIAABwAPsDCAAAAAEAAABACwAAHwATBDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQAAABMuBMA cEMJMIi5EwAAFScHAAAAAAAAAAAAAAAAAAAAAAABEwAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAAC AAAAHwAHBDwAAAAAAP0DNAAAACEAAABkAAAAIQAAAGQAAAACAAAATLgTAGhHCTCIuRMAAAAAAAAA AAAAAAAAAAAAAAABEwAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACL ExAAAAAAAA0ECAAAAADAAAAAwAAAPwDZDwwAAAAAANoPBAAAAA0AJQAPAPAPYC0AAAAA8wMUAAAA GAAAAAQAAAACAAAAEAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPNAAAAEZyYW5rIENoYW8LC2ZjaGFv QGNpc2NvLmNvbQsLU2FuIEFudG9uaW8LCzExLzE0LzIwMDQAAKEPFAAAADUAAAAAAAAAAAA1AAAA AAACACAAAACqD0AAAAAGAAAABgAAAAkEAAAEAAAABwAAAAMACQQAAAIAAAAGAAAACQQAAA8AAAAH AAAAAwAJBAAAGgAAAAYAAAAJBAAAEACfDwQAAAABAAAAAACqDw4AAAABAAAABwAAAAAACQQAAAAA 8wMUAAAAAwAAAAQAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKoPDgAAAAEAAAAHAAAAAAAJ BAAAEACfDwQAAAAFAAAAAACqDw4AAAABAAAABwAAAAAACQQAAAAA8wMUAAAACQAAAAAAAAACAAAA AQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFAAAAC4xQUUgTWFuYWdlbWVudCBJbmZvAACqDwwAAAAV AAAABgAAAAkEAAAQAJ8PBAAAAAEAAAAAAKgPOQEAAExNSSAoTGF5ZXIgTWFuYWdlbWVudCBJbnRl cmZhY2UpDURhdGEgU3RydWN0dXJlDUFjY2Vzc2VkIGJ5IC4xQUUsIC4xYWYsIFNOTVAvTUlCLCBF QVANQ29udGFpbmluZyAuMUFFIGFuZCAuMWFmIGNvbmZpZ3VyYXRpb24sIHByb3RvY29sIHN0YXRl cywgYW5kIGNvdW50ZXIvZGlhZ25vc2lzIGluZm9ybWF0aW9uLg0uMUFFIHVzZXMgTE1JIHRvIGNv bnRyb2wgdGhlIE1BQ3NlYyBwYWNrZXQgcHJvY2Vzc2luZyBkaXJlY3RseSBvciB0aHJvdWdoIEFQ SXMuDUNoYW5nZSB0aGUgZGF0YSBpbiBMTUkgbWF5IGNhdXNlIGFjdGlvbnMgaW4gU2VjWSBvciBL YVkAAKEPOAAAACEAAAAAAAAQAABaABkBAAABAAAQAABaACEAAAAAAAAADwAAAAAEBACABP8AZv4K AQAAAAQAAIAEAACqD1oAAADPAAAABgAAAAkEAAAGAAAABwAAAAMACQQAAFkAAAAGAAAACQQAAAQA AAAHAAAAAwAJBAAABAAAAAYAAAAJBAAAAwAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAAAPMDFAAA AAoAAAAAAAAAAgAAAAIBAAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAAAuMUFFIE1hbmFnZW1lbnQg SW5mbwAAqg8MAAAAFQAAAAYAAAAJBAAAEACfDwQAAAABAAAAAACoD18BAABNQUNzZWMgTWdtdCBJ bmZvcm1hdGlvbg1FbmFibGUvRGlzYWJsZSAoZ2xvYmFsIGNvbmZpZ3VyYXRpb24pDVNlY1kgTWdt dCBJbmZvcm1hdGlvbg1UYWJsZSBpbmRleGVkIGJ5IEludGVyZmFjZUluZGV4IChJRi1NSUIpLg1W YWxpZGF0ZVJ4RnJhbWVzIDogZmxhZyBmb3IgdmFsaWRhdGlvbiBwcm9jZXNzIGluIHJlY2Vpdmlu Zy4gKDEwLjUuMykNUHJvdGVjdFR4RnJhbWVzIDogZmxhZyBmb3IgcHJvdGVjdGlvbiBwcm9jZXNz IGluIHRyYW5zbWl0dGluZy4NQ3VycmVudCBDaXBoZXIgU3VpdGUuICgxMC41LjQpIChSb3cgUG9p bnRlcikNYWRtaW5Qb2ludFRvUG9pbnRNQUMsIG9wZXJQb2ludFRvUG9pbnRNQUMgKDYuNSkAAKEP AAEAABgAAAAAAAAQAABaACYAAAABAAAQAABaABYAAAAAAAAQAABaAAwBAAABAAAQAABaABgAAAAA AAIAHAAPAAAAAAAEAAAAAAYWAAAAAAAAAAEAAAAAAAQAAAAABhYAAAAABAIAgAQcABEAAAAACAAA gAgOAAAAAAgEAIAIAAAABgsAAAAACAAAgAgQAAAAAAgEAIAIAAAABjYAAAAACAAAgAgPAAAAAAgE AIAIAAAABjAAAAAACAAAgAgWAAAAAAgEAIAIAAAABhcAAAAACAAAgAgUAAAAAAgEAIAIAAAABgIA AAAACAAAgAgUAAAAAAgEAIAIAAAABgYAAAAACAAAgAgAAKoPnAAAAAYAAAAHAAAAAwAJBAAAXwAA AAYAAAAJBAAADgAAAAcAAAADAAkEAAALAAAABgAAAAkEAAAQAAAABwAAAAMACQQAADYAAAAGAAAA CQQAAA8AAAAHAAAAAwAJBAAAXQAAAAYAAAAJBAAAFAAAAAcAAAADAAkEAAACAAAABgAAAAkEAAAT AAAABwAAAAMACQQAAAcAAAAGAAAACQQAAAAA8wMUAAAACwAAAAAAAAACAAAAAwEAAAAAAAAAAJ8P BAAAAAAAAAAAAKgPFAAAAC4xQUUgTWFuYWdlbWVudCBJbmZvAACqDwwAAAAVAAAABgAAAAkEAAAQ AJ8PBAAAAAEAAAAAAKgPGgEAAFJ4UmVwbGF5Q2hrIDogZmxhZyBmb3IgcnggcmVwbGF5IGNoZWNr LiAoMTAuNi4yKQ1UeCBTQyA6IHRyYW5zbWl0IFNDIGluZm9ybWFpdG9uLg1SeCBTQ3MgOiByZWNl aXZlIFNDcyBpbmZvcm1haXRvbi4gKHdpbGwgYmUgaW4gYW5vdGhlciB0YWJsZS4pDWxhc3RVbmtu b3duU0MgOiBhbiBTQ0kgaW5mb3JtYXRpb24gdG8gcmVjb3JkIGxhc3QgcnggdW5rbm93biBTQyAo MTAuNi4xKSB3aXRoIHRpbWUgc3RhbXAsIGl0IGNvdWxkIGJlIGEgbGlzdCAoYSB0YWJsZSwgbWF4 aW11bSBlbnRyaWVzKSA/DQAAoQ8yAAAAGwEAAAEAAAAAAAsAAAAAAAQAAAAABoUAAAAAAAAADQAA AAAABAD/AGb+fgAAAAAAAAAAAKoP6gAAAAsAAAAHAAAAAwAJBAAADAAAAAYAAAAJBAAAAgAAAAcA AAADAAkEAAAYAAAABgAAAAkEAAACAAAABwAAAAMACQQAABIAAAAGAAAACQQAAAsAAAAHAAAAAwAJ BAAABQAAAAYAAAAJBAAAAwAAAAcAAAADAAkEAAALAAAABgAAAAkEAAADAAAABwAAAAMACQQAAAEA AAAGAAAACQQAAAsAAAAHAAAAAwAJBAAAHgAAAAYAAAAJBAAADQAAAAcAAAADAAkEAAAlAAAABgAA AAkEAAACAAAABwAAAAMACQQAAFcAAAAGAAAACQQAAAAA8wMUAAAADwAAAAAAAAACAAAABwEAAAAA AAAAAJ8PBAAAAAAAAAAAAKgPFAAAAC4xQUUgTWFuYWdlbWVudCBJbmZvAACqDwwAAAAVAAAABgAA AAkEAAAQAJ8PBAAAAAEAAAAAAKgPFAIAAFR4IFNDIE1nbXQgSW5mb3JtYXRpb24Nc2NTdGF0ZSA6 IHN0YXRlIG9mIHRoaXMgdHJhbnNtaXQgU0MgPy4Nc2NDbWQgOiBjb21tYW5kIGV4ZWN1dGluZyBp biB0aGUgU0MgPy4NU0NJIDogdGhlIFNDSSBmb3IgdGhlIFNDIHVzZWQgYnkgU2VjWSBmb3IgdHJh bnNtaXQuICgxMC41KQ10eEVuY29kaW5nU0EgOiBjdXJyZW50IFNBIG51bWJlci4gKDEwLjUuMSkg KGNvdWxkIGJlIGEgUm93UG9pbnRlcikNdHhFbmNpcGhlcmluZ1NBIDogcHJldmlvdXMgU0EgbnVt YmVyLiAoMTAuNS40KSAoY291bGQgYmUgYSBSb3dQb2ludGVyKQ1UeCBTQSA6ICh0YWJsZSB3aXRo IDQgZW50cmllcykNVGFibGUgaW5kZXhlZCBieSBJbnRlcmZhY2VJbmRleCBhbmQgQU4uDXNhU3Rh dGUgOiBzdGF0ZSBvZiB0aGlzIHRyYW5zbWl0IFNBLg1zYUNtZCA6IGNvbW1hbmQgZXhlY2N1dGlu ZyBpbiB0aGUgU0EuDXR4U0FLIDoga2V5IGZvciB0cmFuc21pdHRpbmcuICg3LjEsIDEwLjUuMSkN dHhOZXh0UE4gOiBuZXh0IHBhY2tldCBudW1iZXIgKFBOKS4gKDEwLjUuMikAAKEPcgEAABcAAAAA AAAQAABQABMBAAABAAAQAABQAB8AAAAAAAAQAABQAMwAAAABAAAQAABQABcAAAAAAAIAHAAHAAAA AAAGABgAAAAABiAAAAAAAAIAGAAFAAAAAAAGABgAAAAABiIAAAAAAAIAGAADAAAAAAAGABgAAAAA BjgAAAAAAAIAGAAMAAAAAAAGABgAAAAABjcAAAAAAAIAGAAPAAAAAAAGABgAAAAABjgAAAAAAAIA GAAfAAAAAAQCAIAEHAARAAAAAAgCAIAIGAAOAAAAAAgGAIAIGAAAAAAGBQAAAAAIAgCACBgAAgAA AAAIBgCACBgAAAAABgIAAAAACAIAgAgYAAcAAAAACAYAgAgYAAAAAAYeAAAAAAgCAIAIGAAFAAAA AAgGAIAIGAAAAAAGIQAAAAAIAgCACBgABQAAAAAIBgCACBgAAAAABicAAAAACAIAgAgYAAgAAAAA CAYAgAgYAAAAAAYlAAAAAAgCAIAIGAAAAKoPhgEAAAIAAAAHAAAAAwAJBAAAFQAAAAYAAAAJBAAA BwAAAAcAAAADAAkEAAAgAAAABgAAAAkEAAAFAAAABwAAAAMACQQAAEMAAAAGAAAACQQAAAQAAAAH AAAAAwAJBAAAFgAAAAYAAAAJBAAADAAAAAcAAAADAAkEAAArAAAABgAAAAkEAAAKAAAABwAAAAMA CQQAAAIAAAAGAAAACQQAAA8AAAAHAAAAAwAJBAAALAAAAAYAAAAJBAAACgAAAAcAAAADAAkEAAAC AAAABgAAAAkEAAACAAAABwAAAAMACQQAAC4AAAAGAAAACQQAAA4AAAAHAAAAAwAJBAAACQAAAAYA AAAJBAAABwAAAAcAAAADAAkEAAAeAAAABgAAAAkEAAAFAAAABwAAAAMACQQAAAsAAAAGAAAACQQA AAoAAAAHAAAAAwAJBAAADAAAAAYAAAAJBAAABQAAAAcAAAADAAkEAAAnAAAABgAAAAkEAAAIAAAA BwAAAAMACQQAACUAAAAGAAAACQQAAAAA8wMUAAAAEAAAAAAAAAACAAAACAEAAAAAAAAAAJ8PBAAA AAAAAAAAAKgPFAAAAC4xQUUgTWFuYWdlbWVudCBJbmZvAACqDwwAAAAVAAAABgAAAAkEAAAQAJ8P BAAAAAEAAAAAAKgPcAEAAFJ4IFNDcyBNZ210IEluZm9ybWF0aW9uDVRhYmxlIGluZGV4ZWQgYnkg SW50ZXJmYWNlSW5kZXggYW5kIFNDSS4Nc2NTdGF0ZSA6IHN0YXRlIG9mIHRoaXMgdHJhbnNtaXQg U0MgPy4Nc2NDbWQgOiBjb21tYW5kIGV4ZWN1dGluZyBpbiB0aGUgU0MgPy4NU0NJIDogdGhlIFND SSBmb3IgdGhlIFNDIHVzZWQgYnkgU2VjWSBmb3IgdHJhbnNtaXQuICgxMC41KQ1yeEN1cnJlbnRT QSA6IGN1cnJlbnQgdXNpbmcgU0EgbnVtYmVyIGluIHRoZSBTQy4gKDEwLjYuMSkgKFJvd1BvaW50 ZXIpDWxhc3ROb3RJblVzZUFuIDogbGFzdCBOb3QtaW4tVXNlIEFOIHdpdGggdGltZXN0YW1wLiAo MTAuNi4xKSBhIGxpc3QgKGEgdGFibGUsIG1heGltdW0gZW50cmllcyk/AAChD9IAAAAYAAAAAAAA AAAAWQEAAAEAAAAAABgAAAAAAAIAHAAQAAAAAAQCAIAEGAAQAAAAAAQGAIAEGAAAAAAGAwAAAAAE AgCABBgADQAAAAAEBgCABBgAAAAABiAAAAAABAIAgAQYAAUAAAAABAYAgAQYAAAAAAYiAAAAAAQC AIAEGAADAAAAAAQGAIAEGAAAAAAGOAAAAAAEAgCABBgACwAAAAAEBgCABBgAAAAABjwAAAAABAIA gAQYAA4AAAAABAYAgAQYAP8AZv5SAAAAAAQCAIAEGAAAAKoP3AAAAAMAAAAGAAAACQQAAAMAAAAH AAAAAwAJBAAAIwAAAAYAAAAJBAAADgAAAAcAAAADAAkEAAAKAAAABgAAAAkEAAAHAAAABwAAAAMA CQQAACAAAAAGAAAACQQAAAUAAAAHAAAAAwAJBAAAQwAAAAYAAAAJBAAABAAAAAcAAAADAAkEAAAW AAAABgAAAAkEAAALAAAABwAAAAMACQQAADAAAAAGAAAACQQAAAoAAAAHAAAAAwAJBAAAAgAAAAYA AAAJBAAADgAAAAcAAAADAAkEAABSAAAABgAAAAkEAAAAAPMDFAAAABEAAAAAAAAAAgAAAAkBAAAA AAAAAACfDwQAAAAAAAAAAACoDxQAAAAuMUFFIE1hbmFnZW1lbnQgSW5mbwAAqg8MAAAAFQAAAAYA AAAJBAAAEACfDwQAAAABAAAAAACoDysBAABSeCBTQSBNZ210IEluZm9ybWF0aW9uDVRhYmxlIGlu ZGV4ZWQgYnkgSW50ZXJmYWNlSW5kZXggYW5kIFNDSSBhbmQgQU4uDXNhU3RhdGUgOiBzdGF0ZSBv ZiB0aGlzIHJlY2VpdmUgU0EuDXNhQ21kIDogY29tbWFuZCBleGNlY3V0aW5nIGluIHRoZSBTQS4N cnhTQUsgOiBrZXkgZm9yIHRyYW5zbWl0dGluZy4gKDcuMSwgMTAuNi4xKQ1yeExhc3RQTiA6IGxh c3QgcmVjZWl2ZWQgcGFja2V0IG51bWJlciAoUE4pLiAoMTAuNi4yKQ1yeExhc3RWYWxpZGF0ZWRQ TiA6IGxhc3QgcmVjZWl2ZWQgdmFsaWRhdGVkIFBOLiAoMTAuNi4yKQAAoQ/iAAAAFwAAAAAAABAA AFoAMAAAAAEAABAAAFoA5QAAAAEAIBAAAAAAAAFaABcAAAAAAAAAEAAAAAAEAACABBAAAAAABAQA gAQAAAAGAwAAAAAEAACABAUAAAAABAQAgAQAAAAGAwAAAAAEAACABAwAAAAABAQAgAQAAAAGHQAA AAAEAACABAUAAAAABAQAgAQAAAAGIQAAAAAEAACABAUAAAAABAQAgAQAAAAGJwAAAAAEAACABAgA AAAABAQAgAQAAAAGLgAAAAAEAACABBEAAAAABAQAgAQAAAAGKAAAAAAEAACABAAAqg9AAAAAKAAA AAYAAAAJBAAADgAAAAcAAAADAAkEAAARAAAABgAAAAkEAAAHAAAABwAAAAMACQQAAN4AAAAGAAAA CQQAAAAA8wMUAAAAEgAAAAAAAAACAAAACgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFAAAAC4xQUUg TWFuYWdlbWVudCBJbmZvAACqDwwAAAAVAAAABgAAAAkEAAAQAJ8PBAAAAAEAAAAAAKgPxAAAAENp cGhlciBTdWl0ZXMgOg1OYW1lIDogbmFtZSBvZiB0aGlzIGNpcGhlciBzdWl0ZSwgY291bGQgYmUg TUlCIHRhYmxlIGluZGV4Lg1Db25maWRlbnRpYWxpdHkgOiBmbGFnIGluZGljYXRlIHRoZSBjaXBo ZXIgc3VpdGUgd2l0aCBjb25maWRlbnRpYWxpdHkgYWJpbGl0eS4NSUNWIGxlbmd0aCA6IHRoZSBs ZW5ndGggb2YgZ2VuZXJhdGVkIElDVi4AAKEPZAAAABAAAAAAAAAAAAC1AAAAAQAAAAAAEAAAAAAA AAAEAAAAAAQEAIAEAAAABjgAAAAABAAAgAQPAAAAAAQEAIAEAAAABkAAAAAABAAAgAQKAAAAAAQE AIAEAAAABiAAAAAABAAAgAQAAKoPDAAAAMUAAAAGAAAACQQAAAAA8wMUAAAAEwAAAAQAAAACAAAA CwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKoPDgAAAAEAAAAHAAAAAAAJBAAAEACfDwQAAAABAAAAAACq Dw4AAAABAAAABwAAAAAACQQAAAAA8wMUAAAAFAAAAAAAAAACAAAADAEAAAAAAAAAAJ8PBAAAAAAA AAAAAKgPFAAAAC4xQUUgTWFuYWdlbWVudCBJbmZvAACqDwwAAAAVAAAABgAAAAkEAAAQAJ8PBAAA AAEAAAAAAKgPAAEAAFNDIFJ4IGNvdW50ZXJzIDoNSW5kZXhlZCBieSBJbnRlcmZhY2VJbmRleCBh bmQgU0NJDUluWGNhc3RQa3RzTm90UmVjZWl2ZWQNSW5YY2FzdFBrdHNJbnZhbGlkDUluWGNhc3RQ a3RzUmVwbGF5ZWQNSW5YY2FzdFBrdHNNaXNvcmRlcmVkDUluWGNhc3RQa3RzT3JkZXJlZA1Jblhj YXN0UGt0c0VuY3J5cHRlZA1JblhjYXN0UGt0c0RlY3J5cHRlZA1JblhjYXN0T2N0ZXRzRW5jcnlw dGVkIChNU0RVKQ1JblhjYXN0T2N0ZXRzRGVjcnlwdGVkIChNU0RVKQ0AAKEPggAAABEAAAAAAAAA AADvAAAAAQAAAAAAAQAAAAEAAQAAAAAAEQAAAAAAAgAcAAsAAAAABAIAgAQYAA4AAAAABAYAgAQY AAAAAAYFAAAAAAQCAIAEGAAEAAAAAAQGAIAEGAAAAAAGVAAAAAAEBgCABBQA/wBm/noAAAAABAYA gAQUAAAA//4AAKoPEAEAABwAAAAGAAAACQQAAA4AAAAHAAAAAwAJBAAACQAAAAYAAAAJBAAAFgAA AAcAAAADAAkEAAABAAAABgAAAAkEAAASAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABMAAAAHAAAA AwAJBAAAAQAAAAYAAAAJBAAAFQAAAAcAAAADAAkEAAABAAAABgAAAAkEAAASAAAABwAAAAMACQQA AAEAAAAGAAAACQQAABQAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFAAAAAcAAAADAAkEAAABAAAA BgAAAAkEAAAWAAAABwAAAAMACQQAAAgAAAAGAAAACQQAABYAAAAHAAAAAwAJBAAACQAAAAYAAAAJ BAAAAADzAxQAAAAVAAAAAAAAAAIAAAANAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8UAAAALjFBRSBN YW5hZ2VtZW50IEluZm8AAKoPDAAAABUAAAAGAAAACQQAABAAnw8EAAAAAQAAAAAAqA9hAQAAU2Vj WSBSeCBDb3VudGVycyA6DVRhYmxlIEluZGV4ZWQgYnkgSW50ZXJmYWNlSW5kZXgNSW5YY2FzdFBr dHNOb1RhZw1JblhjYXN0UGt0c0JhZFRhZw1JblhjYXN0UGt0c1Vua25vd25TQ0kNSW5YY2FzdFBr dHNVbnRhZ2dlZA1JblhjYXN0UGt0c1VuY2hlY2tlZA1JblhjYXN0UGt0c05vdFJlY2VpdmVkDUlu WGNhc3RQa3RzSW52YWxpZA1JblhjYXN0UGt0c1JlcGxheWVkDUluWGNhc3RQa3RzTWlzb3JkZXJl ZA1JblhjYXN0UGt0c09yZGVyZWQNSW5YY2FzdFBrdHNFbmNyeXB0ZWQNSW5YY2FzdFBrdHNEZWNy eXB0ZWQNSW5YY2FzdE9jdGV0c0VuY3J5cHRlZCAoTVNEVSkNSW5YY2FzdE9jdGV0c0RlY3J5cHRl ZCAoTVNEVSkAAKEPXgAAABMAAAAAAAAQAABQAE8BAAABAAAQAABQABMAAAAAAAIAHAARAAAAAAQC AIAEGAAPAAAAAAQGAIAEGAAAAAAGtgAAAAAEBgCABBQA/wBm/nkAAAAABAYAgAQUAAAA//4AAKoP oAEAAAQAAAAHAAAAAwAJBAAAIAAAAAYAAAAJBAAADgAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAQ AAAABwAAAAMACQQAAAEAAAAGAAAACQQAABEAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFQAAAAcA AAADAAkEAAABAAAABgAAAAkEAAATAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABQAAAAHAAAAAwAJ BAAAAQAAAAYAAAAJBAAAFgAAAAcAAAADAAkEAAABAAAABgAAAAkEAAASAAAABwAAAAMACQQAAAEA AAAGAAAACQQAABMAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFQAAAAcAAAADAAkEAAABAAAABgAA AAkEAAASAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABQAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAA FAAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAWAAAABwAAAAMACQQAAAgAAAAGAAAACQQAABYAAAAH AAAAAwAJBAAACAAAAAYAAAAJBAAAAADzAxQAAAAXAAAAAAAAAAIAAAAPAQAAAAAAAAAAnw8EAAAA AAAAAAAAqA8UAAAALjFBRSBNYW5hZ2VtZW50IEluZm8AAKoPDAAAABUAAAAGAAAACQQAABAAnw8E AAAAAQAAAAAAoA8IAgAAUwBBACAAVAB4ACAAYwBvAHUAbgB0AGUAcgBzACAAOgANAFQAYQBiAGwA ZQAgAGkAbgBkAGUAeABlAGQAIABiAHkAIABJAG4AdABlAHIAZgBhAGMAZQBJAG4AZABlAHgAIABh AG4AZAAgAEEATgANAE8AdQB0AEMAbgB0AFIAZQBpAG4AaQB0AFQAaQBtAGUAIAA6ACAAQQAgAHQA aQBtAGUAcwB0AGEAbQBwACAAZgBvAHIAIAB0AGgAZQAgAGMAbwB1AG4AdABlAHIAcwAZICAAZABp AHMAYwBvAG4AdABpAG4AdQBpAHQAeQAgAGkAbgAgAHQAaABpAHMAIABTAEEALgANAE8AdQB0AFAA awB0AHMAUABuAEUAeABoAGEAdQBzAHQAZQBkAA0ATwB1AHQAUABrAHQAcwBUAG8AbwBsAG8AbgBn AA0ATwB1AHQAWABjAGEAcwB0AFAAawB0AHMAUAByAG8AdABlAGMAdABlAGQADQBPAHUAdABYAGMA YQBzAHQAUABrAHQAcwBVAG4AdABhAGcAZwBlAGQADQBPAHUAdABYAGMAYQBzAHQAUABrAHQAcwBF AG4AYwByAHkAcAB0AGUAZAANAE8AdQB0AFgAYwBhAHMAdABPAGMAdABlAHQAcwBFAG4AYwByAHkA cAB0AGUAZAAgACgATQBTAEQAVQApAAAAoQ+aAAAAEQAAAAAAAAAAAPQAAAABAAAAAAARAAAAAAAC ABwAEQAAAAAEAgCABBgADgAAAAAEBgCABBgAAAAABgUAAAAABAIAgAQYABMAAAAABAYAgAQYAAAA AAYDAAAAAAQCAIAEGAA3AAAAAAQCAIAEFAABAAAAAAQCAIAEGABNAAAAAAQGAIAEGAD/AGb+NQAA AAAEBgCABBgAAAD//gAAqg/2AAAAAwAAAAYAAAAJBAAAAgAAAAcAAAADAAkEAAAdAAAABgAAAAkE AAAOAAAABwAAAAMACQQAAAgAAAAGAAAACQQAABAAAAAHAAAAAwAJBAAAOwAAAAYAAAAJBAAAEgAA AAcAAAADAAkEAAABAAAABgAAAAkEAAAOAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABUAAAAHAAAA AwAJBAAAAQAAAAYAAAAJBAAAFAAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAVAAAABwAAAAMACQQA AAEAAAAGAAAACQQAABcAAAAHAAAAAwAJBAAACAAAAAYAAAAJBAAAAADzAxQAAAAWAAAAAAAAAAIA AAAOAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8UAAAALjFBRSBNYW5hZ2VtZW50IEluZm8AAKoPDAAA ABUAAAAGAAAACQQAABAAnw8EAAAAAQAAAAAAqA+2AAAAU2VjWSBUeCBDb3VudGVycyA6DVRhYmxl IGluZGV4ZWQgYnkgSW50ZXJmYWNlSW5kZXgNT3V0UGt0c1BuRXhoYXVzdGVkDU91dFBrdHNUb29s b25nDU91dFhjYXN0UGt0c1Byb3RlY3RlZA1PdXRYY2FzdFBrdHNVbnRhZ2dlZA1PdXRYY2FzdFBr dHNFbmNyeXB0ZWQNT3V0WGNhc3RPY3RldHNFbmNyeXB0ZWQgKE1TRFUpDQ0AAKEPUAAAABMAAAAA AAAAAACkAAAAAQAAAAAAEwAAAAAAAAARAAAAAAQAAIAEDwAAAAAEBACABAAAAAZNAAAAAAQEAIAE /wBm/jcAAAAABAQAgAQAAP/+AACqD+oAAAAEAAAABwAAAAMACQQAAAEAAAAGAAAACQQAAAIAAAAH AAAAAwAJBAAAHQAAAAYAAAAJBAAADgAAAAcAAAADAAkEAAABAAAABgAAAAkEAAASAAAABwAAAAMA CQQAAAEAAAAGAAAACQQAAA4AAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFQAAAAcAAAADAAkEAAAB AAAABgAAAAkEAAAUAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABUAAAAHAAAAAwAJBAAAAQAAAAYA AAAJBAAAFwAAAAcAAAADAAkEAAAKAAAABgAAAAkEAAAAAPMDFAAAABkAAAAAAAAAAgAAABEBAAAA AAAAAACfDwQAAAAAAAAAAACoDxQAAAAuMUFFIE1hbmFnZW1lbnQgSW5mbwAAqg8MAAAAFQAAAAYA AAAJBAAAEACfDwQAAAABAAAAAACoD7kDAABSRkMyODYzIDogSW50ZXJmYWNlIE1JQiBjb3VudGVy cw0gICAgIAkJaWZJbk9jdGV0c6CgoKCgoKCgoKCgoKAgQ291bnRlcjMyLAugoKCgoKCgoCBpZklu VWNhc3RQa3RzoKCgoKCgoKCgoCBDb3VudGVyMzIsC6CgoKCgoKCgIGlmSW5EaXNjYXJkc6CgoKCg oKCgoKCgIENvdW50ZXIzMiwLoKCgoKCgoKAgaWZJbkVycm9yc6CgoKCgoKCgoKCgoKAgQ291bnRl cjMyLAugoKCgoKCgoCBpZkluVW5rbm93blByb3Rvc6CgoKCgoCBDb3VudGVyMzIsC6CgoKCgoKCg IGlmT3V0T2N0ZXRzoKCgoKCgoKCgoKCgIENvdW50ZXIzMiwLoKCgoKCgoKAgaWZPdXRVY2FzdFBr dHOgoKCgoKCgoKAgQ291bnRlcjMyLAugoKCgoKCgoCBpZk91dERpc2NhcmRzoKCgoKCgoKCgoCBD b3VudGVyMzIsC6CgoKCgoKCgIGlmTwEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAA AAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAA GAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAm AAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQA AAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAA AF4AAABEAAAA/v///0YAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAA UQAAAFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAAWgAAAH0AAAD9////XQAAAP7///9f AAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0A AABuAAAAbwAAAHAAAABxAAAAcgAAAHMAAAB0AAAAdQAAAHYAAAB3AAAARQAAAP7///96AAAAewAA AHwAAABDAAAAfgAAAIAAAAD9////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAQjYFkm0/PEYbqAKoA uSnoAAAAAAAAAAAAAAAA0CUc9E3MxAF5AAAAgAsAAAAAAABDAHUAcgByAGUAbgB0ACAAVQBzAGUA cgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAP////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0AAAA+AAAAAAAAAAUAUwB1AG0A bQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAo AAIBAQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFwG AAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACgAAgECAAAABAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAVVcBAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBm AG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAACwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAGUAdwAtAGcAdQBpAGQAZQBsAGkAbgBlAHMALQAwADMALgB0AHgA dAAPAPIDYAEAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB5gAAAAAALcPRAAAAEEAcgBpAGEAbAAA AAgAAAAAAAAAiLkTAIi5EwAoFScHCLgTAPC3EwD26AcwCAAAAAAAAAAIuBMA0kIJMAC4EwAAAAQA EAC3D0QAAACwZTB9DmbUmgAAAAAIAAAAAAAAAIi5EwCIuRMAKBUnBwi4EwDwtxMA9ugHMAgAAAAA AAAACLgTANJCCTAAuBMAiAAEEgAApA8IAAAAgQBAAIEAAAAAAKUPDAAAAAAAAAguAAAABwAAAAAA qQ8KAAAABwAAAAIABAQJBEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAD/AABkAAAAAAAAAAAAQAIA AAAABwAAAP//7wCAAAAAAQAAAP//EgAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAA YANgAwAAAAAABQAAgASABAAAAAAPAAsEVAEAAA8AAPBMAQAAAAAG8OAAAAAFaAAAGwAAAF4AAAAT AAAAAQAAAAcAAAACAAAAKwAAAAAAAAAGAAAAAAAAAD8AAAAFAAAACAAAAAYAAAAEAAAAAAAAAMAA AAAIAAAABAAAAAkAAAAEAAAACgAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAOAAAABAAA AA8AAAAEAAAAEAAAAAQAAAARAAAABAAAABIAAAAGAAAAEwAAAAUAAAAUAAAABQAAABUAAAAFAAAA FgAAAAUAAAAXAAAABgAAABgAAAAFAAAAAAAAAAQAAAAaAAAABQAAAIMAC/AwAAAAgQEEAAAIgwEA AAAIhkEAAAAAvwEQABAAwAEBAAAIxUEAAAAA/wEIAAgAAQICAAAIMAAa8QwAAAD/AGYAAAD/AP8A AABAAB7xEAAAAAQAAAgBAAAIAgAACPcAABAfAPAPHAAAAAAA8wMUAAAAAgAAAAAAAAAAAAAAAAAA gAAAAAAPANAHdwEAAB8AFAQcAAAAAAAVBBQAAABGk08JAMqaO/uxdzgAypo7AQEAAA8A+gNnAAAA AAD+AwMAAAAAAQAAAP0DNAAAACUAAABkAAAAJQAAAGQAAAAIAAAAAAAAACC4EwDSQgkwAAAAAAAA AAA+/v//sv///wEAEwBwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8AEwQ8AAAAAAD9 AzQAAABkAAAAZAAAAGQAAABkAAAATLgTAHBDCTCIuRMAABUnBwAAAAAAAAAAAAAAAAAAAAAAARMA HwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8ABwQ8AAAAAAD9AzQAAAAhAAAAZAAAACEAAABk AAAAAgAAAEy4EwBoRwkwiLkTAAAAAAAAAAAAAAAAAAAAAAAAARMADwCIEzgAAAAPAIoTMAAAAAAA ug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAAANBAgAAAAAwAAAAMAAAD8A2Q8MAAAAAADa DwQAAAANACUADwDwD7EtAAAAAPMDFAAAABgAAAAEAAAAAgAAABABAAAAAAAAAACfDwQAAAAAAAAA AACoDzQAAABGcmFuayBDaGFvCwtmY2hhb0BjaXNjby5jb20LC1NhbiBBbnRvbmlvCwsxMS8xNC8y MDA0AAChDxQAAAA1AAAAAAAAAAAANQAAAAAAAgAgAAAAqg9AAAAABgAAAAYAAAAJBAAABAAAAAcA AAADAAkEAAACAAAABgAAAAkEAAAPAAAABwAAAAMACQQAABoAAAAGAAAACQQAABAAnw8EAAAAAQAA AAAAqg8OAAAAAQAAAAcAAAAAAAkEAAAAAPMDFAAAAAMAAAAEAAAAAgAAAAABAAAAAAAAAACfDwQA AAAGAAAAAACqDw4AAAABAAAABwAAAAAACQQAABAAnw8EAAAABQAAAAAAqg8OAAAAAQAAAAcAAAAA AAkEAAAAAPMDFAAAAAkAAAAAAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAAAuMUFF IE1hbmFnZW1lbnQgSW5mbwAAqg8MAAAAFQAAAAYAAAAJBAAAEACfDwQAAAABAAAAAACoDzkBAABM TUkgKExheWVyIE1hbmFnZW1lbnQgSW50ZXJmYWNlKQ1EYXRhIFN0cnVjdHVyZQ1BY2Nlc3NlZCBi eSAuMUFFLCAuMWFmLCBTTk1QL01JQiwgRUFQDUNvbnRhaW5pbmcgLjFBRSBhbmQgLjFhZiBjb25m aWd1cmF0aW9uLCBwcm90b2NvbCBzdGF0ZXMsIGFuZCBjb3VudGVyL2RpYWdub3NpcyBpbmZvcm1h dGlvbi4NLjFBRSB1c2VzIExNSSB0byBjb250cm9sIHRoZSBNQUNzZWMgcGFja2V0IHByb2Nlc3Np bmcgZGlyZWN0bHkgb3IgdGhyb3VnaCBBUElzLg1DaGFuZ2UgdGhlIGRhdGEgaW4gTE1JIG1heSBj YXVzZSBhY3Rpb25zIGluIFNlY1kgb3IgS2FZAAChDzgAAAAhAAAAAAAAEAAAWgAZAQAAAQAAEAAA WgAhAAAAAAAAAA8AAAAABAQAgAT/AGb+CgEAAAAEAACABAAAqg9aAAAAzwAAAAYAAAAJBAAABgAA AAcAAAADAAkEAABZAAAABgAAAAkEAAAEAAAABwAAAAMACQQAAAQAAAAGAAAACQQAAAMAAAAHAAAA AwAJBAAAAQAAAAYAAAAJBAAAAADzAxQAAAAKAAAAAAAAAAIAAAACAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8UAAAALjFBRSBNYW5hZ2VtZW50IEluZm8AAKoPDAAAABUAAAAGAAAACQQAABAAnw8EAAAA AQAAAAAAqA9fAQAATUFDc2VjIE1nbXQgSW5mb3JtYXRpb24NRW5hYmxlL0Rpc2FibGUgKGdsb2Jh bCBjb25maWd1cmF0aW9uKQ1TZWNZIE1nbXQgSW5mb3JtYXRpb24NVGFibGUgaW5kZXhlZCBieSBJ bnRlcmZhY2VJbmRleCAoSUYtTUlCKS4NVmFsaWRhdGVSeEZyYW1lcyA6IGZsYWcgZm9yIHZhbGlk YXRpb24gcHJvY2VzcyBpbiByZWNlaXZpbmcuICgxMC41LjMpDVByb3RlY3RUeEZyYW1lcyA6IGZs YWcgZm9yIHByb3RlY3Rpb24gcHJvY2VzcyBpbiB0cmFuc21pdHRpbmcuDUN1cnJlbnQgQ2lwaGVy IFN1aXRlLiAoMTAuNS40KSAoUm93IFBvaW50ZXIpDWFkbWluUG9pbnRUb1BvaW50TUFDLCBvcGVy UG9pbnRUb1BvaW50TUFDICg2LjUpAAChDwABAAAYAAAAAAAAEAAAWgAmAAAAAQAAEAAAWgAWAAAA AAAAEAAAWgAMAQAAAQAAEAAAWgAYAAAAAAACABwADwAAAAAABAAAAAAGFgAAAAAAAAABAAAAAAAE AAAAAAYWAAAAAAQCAIAEHAARAAAAAAgAAIAIDgAAAAAIBACACAAAAAYLAAAAAAgAAIAIEAAAAAAI BACACAAAAAY2AAAAAAgAAIAIDwAAAAAIBACACAAAAAYwAAAAAAgAAIAIFgAAAAAIBACACAAAAAYX AAAAAAgAAIAIFAAAAAAIBACACAAAAAYCAAAAAAgAAIAIFAAAAAAIBACACAAAAAYGAAAAAAgAAIAI AACqD5wAAAAGAAAABwAAAAMACQQAAF8AAAAGAAAACQQAAA4AAAAHAAAAAwAJBAAACwAAAAYAAAAJ BAAAEAAAAAcAAAADAAkEAAA2AAAABgAAAAkEAAAPAAAABwAAAAMACQQAAF0AAAAGAAAACQQAABQA AAAHAAAAAwAJBAAAAgAAAAYAAAAJBAAAEwAAAAcAAAADAAkEAAAHAAAABgAAAAkEAAAAAPMDFAAA AAsAAAAAAAAAAgAAAAMBAAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAAAuMUFFIE1hbmFnZW1lbnQg SW5mbwAAqg8MAAAAFQAAAAYAAAAJBAAAEACfDwQAAAABAAAAAACoDxoBAABSeFJlcGxheUNoayA6 IGZsYWcgZm9yIHJ4IHJlcGxheSBjaGVjay4gKDEwLjYuMikNVHggU0MgOiB0cmFuc21pdCBTQyBp bmZvcm1haXRvbi4NUnggU0NzIDogcmVjZWl2ZSBTQ3MgaW5mb3JtYWl0b24uICh3aWxsIGJlIGlu IGFub3RoZXIgdGFibGUuKQ1sYXN0VW5rbm93blNDIDogYW4gU0NJIGluZm9ybWF0aW9uIHRvIHJl Y29yZCBsYXN0IHJ4IHVua25vd24gU0MgKDEwLjYuMSkgd2l0aCB0aW1lIHN0YW1wLCBpdCBjb3Vs ZCBiZSBhIGxpc3QgKGEgdGFibGUsIG1heGltdW0gZW50cmllcykgPw0AAKEPMgAAABsBAAABAAAA AAALAAAAAAAEAAAAAAaFAAAAAAAAAA0AAAAAAAQA/wBm/n4AAAAAAAAAAACqD+oAAAALAAAABwAA AAMACQQAAAwAAAAGAAAACQQAAAIAAAAHAAAAAwAJBAAAGAAAAAYAAAAJBAAAAgAAAAcAAAADAAkE AAASAAAABgAAAAkEAAALAAAABwAAAAMACQQAAAUAAAAGAAAACQQAAAMAAAAHAAAAAwAJBAAACwAA AAYAAAAJBAAAAwAAAAcAAAADAAkEAAABAAAABgAAAAkEAAALAAAABwAAAAMACQQAAB4AAAAGAAAA CQQAAA0AAAAHAAAAAwAJBAAAJQAAAAYAAAAJBAAAAgAAAAcAAAADAAkEAABXAAAABgAAAAkEAAAA APMDFAAAAA8AAAAAAAAAAgAAAAcBAAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAAAuMUFFIE1hbmFn ZW1lbnQgSW5mbwAAqg8MAAAAFQAAAAYAAAAJBAAAEACfDwQAAAABAAAAAACoDxQCAABUeCBTQyBN Z210IEluZm9ybWF0aW9uDXNjU3RhdGUgOiBzdGF0ZSBvZiB0aGlzIHRyYW5zbWl0IFNDID8uDXNj Q21kIDogY29tbWFuZCBleGVjdXRpbmcgaW4gdGhlIFNDID8uDVNDSSA6IHRoZSBTQ0kgZm9yIHRo ZSBTQyB1c2VkIGJ5IFNlY1kgZm9yIHRyYW5zbWl0LiAoMTAuNSkNdHhFbmNvZGluZ1NBIDogY3Vy cmVudCBTQSBudW1iZXIuICgxMC41LjEpIChjb3VsZCBiZSBhIFJvd1BvaW50ZXIpDXR4RW5jaXBo ZXJpbmdTQSA6IHByZXZpb3VzIFNBIG51bWJlci4gKDEwLjUuNCkgKGNvdWxkIGJlIGEgUm93UG9p bnRlcikNVHggU0EgOiAodGFibGUgd2l0aCA0IGVudHJpZXMpDVRhYmxlIGluZGV4ZWQgYnkgSW50 ZXJmYWNlSW5kZXggYW5kIEFOLg1zYVN0YXRlIDogc3RhdGUgb2YgdGhpcyB0cmFuc21pdCBTQS4N c2FDbWQgOiBjb21tYW5kIGV4ZWNjdXRpbmcgaW4gdGhlIFNBLg10eFNBSyA6IGtleSBmb3IgdHJh bnNtaXR0aW5nLiAoNy4xLCAxMC41LjEpDXR4TmV4dFBOIDogbmV4dCBwYWNrZXQgbnVtYmVyIChQ TikuICgxMC41LjIpAAChD3IBAAAXAAAAAAAAEAAAUAATAQAAAQAAEAAAUAAfAAAAAAAAEAAAUADM AAAAAQAAEAAAUAAXAAAAAAACABwABwAAAAAABgAYAAAAAAYgAAAAAAACABgABQAAAAAABgAYAAAA AAYiAAAAAAACABgAAwAAAAAABgAYAAAAAAY4AAAAAAACABgADAAAAAAABgAYAAAAAAY3AAAAAAAC ABgADwAAAAAABgAYAAAAAAY4AAAAAAACABgAHwAAAAAEAgCABBwAEQAAAAAIAgCACBgADgAAAAAI BgCACBgAAAAABgUAAAAACAIAgAgYAAIAAAAACAYAgAgYAAAAAAYCAAAAAAgCAIAIGAAHAAAAAAgG AIAIGAAAAAAGHgAAAAAIAgCACBgABQAAAAAIBgCACBgAAAAABiEAAAAACAIAgAgYAAUAAAAACAYA gAgYAAAAAAYnAAAAAAgCAIAIGAAIAAAAAAgGAIAIGAAAAAAGJQAAAAAIAgCACBgAAACqD4YBAAAC AAAABwAAAAMACQQAABUAAAAGAAAACQQAAAcAAAAHAAAAAwAJBAAAIAAAAAYAAAAJBAAABQAAAAcA AAADAAkEAABDAAAABgAAAAkEAAAEAAAABwAAAAMACQQAABYAAAAGAAAACQQAAAwAAAAHAAAAAwAJ BAAAKwAAAAYAAAAJBAAACgAAAAcAAAADAAkEAAACAAAABgAAAAkEAAAPAAAABwAAAAMACQQAACwA AAAGAAAACQQAAAoAAAAHAAAAAwAJBAAAAgAAAAYAAAAJBAAAAgAAAAcAAAADAAkEAAAuAAAABgAA AAkEAAAOAAAABwAAAAMACQQAAAkAAAAGAAAACQQAAAcAAAAHAAAAAwAJBAAAHgAAAAYAAAAJBAAA BQAAAAcAAAADAAkEAAALAAAABgAAAAkEAAAKAAAABwAAAAMACQQAAAwAAAAGAAAACQQAAAUAAAAH AAAAAwAJBAAAJwAAAAYAAAAJBAAACAAAAAcAAAADAAkEAAAlAAAABgAAAAkEAAAAAPMDFAAAABAA AAAAAAAAAgAAAAgBAAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAAAuMUFFIE1hbmFnZW1lbnQgSW5m bwAAqg8MAAAAFQAAAAYAAAAJBAAAEACfDwQAAAABAAAAAACoD3ABAABSeCBTQ3MgTWdtdCBJbmZv cm1hdGlvbg1UYWJsZSBpbmRleGVkIGJ5IEludGVyZmFjZUluZGV4IGFuZCBTQ0kuDXNjU3RhdGUg OiBzdGF0ZSBvZiB0aGlzIHRyYW5zbWl0IFNDID8uDXNjQ21kIDogY29tbWFuZCBleGVjdXRpbmcg aW4gdGhlIFNDID8uDVNDSSA6IHRoZSBTQ0kgZm9yIHRoZSBTQyB1c2VkIGJ5IFNlY1kgZm9yIHRy YW5zbWl0LiAoMTAuNSkNcnhDdXJyZW50U0EgOiBjdXJyZW50IHVzaW5nIFNBIG51bWJlciBpbiB0 aGUgU0MuICgxMC42LjEpIChSb3dQb2ludGVyKQ1sYXN0Tm90SW5Vc2VBbiA6IGxhc3QgTm90LWlu LVVzZSBBTiB3aXRoIHRpbWVzdGFtcC4gKDEwLjYuMSkgYSBsaXN0IChhIHRhYmxlLCBtYXhpbXVt IGVudHJpZXMpPwAAoQ/SAAAAGAAAAAAAAAAAAFkBAAABAAAAAAAYAAAAAAACABwAEAAAAAAEAgCA BBgAEAAAAAAEBgCABBgAAAAABgMAAAAABAIAgAQYAA0AAAAABAYAgAQYAAAAAAYgAAAAAAQCAIAE GAAFAAAAAAQGAIAEGAAAAAAGIgAAAAAEAgCABBgAAwAAAAAEBgCABBgAAAAABjgAAAAABAIAgAQY AAsAAAAABAYAgAQYAAAAAAY8AAAAAAQCAIAEGAAOAAAAAAQGAIAEGAD/AGb+UgAAAAAEAgCABBgA AACqD9wAAAADAAAABgAAAAkEAAADAAAABwAAAAMACQQAACMAAAAGAAAACQQAAA4AAAAHAAAAAwAJ BAAACgAAAAYAAAAJBAAABwAAAAcAAAADAAkEAAAgAAAABgAAAAkEAAAFAAAABwAAAAMACQQAAEMA AAAGAAAACQQAAAQAAAAHAAAAAwAJBAAAFgAAAAYAAAAJBAAACwAAAAcAAAADAAkEAAAwAAAABgAA AAkEAAAKAAAABwAAAAMACQQAAAIAAAAGAAAACQQAAA4AAAAHAAAAAwAJBAAAUgAAAAYAAAAJBAAA AADzAxQAAAARAAAAAAAAAAIAAAAJAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8UAAAALjFBRSBNYW5h Z2VtZW50IEluZm8AAKoPDAAAABUAAAAGAAAACQQAABAAnw8EAAAAAQAAAAAAqA8rAQAAUnggU0Eg TWdtdCBJbmZvcm1hdGlvbg1UYWJsZSBpbmRleGVkIGJ5IEludGVyZmFjZUluZGV4IGFuZCBTQ0kg YW5kIEFOLg1zYVN0YXRlIDogc3RhdGUgb2YgdGhpcyByZWNlaXZlIFNBLg1zYUNtZCA6IGNvbW1h bmQgZXhjZWN1dGluZyBpbiB0aGUgU0EuDXJ4U0FLIDoga2V5IGZvciB0cmFuc21pdHRpbmcuICg3 LjEsIDEwLjYuMSkNcnhMYXN0UE4gOiBsYXN0IHJlY2VpdmVkIHBhY2tldCBudW1iZXIgKFBOKS4g KDEwLjYuMikNcnhMYXN0VmFsaWRhdGVkUE4gOiBsYXN0IHJlY2VpdmVkIHZhbGlkYXRlZCBQTi4g KDEwLjYuMikAAKEP4gAAABcAAAAAAAAQAABaADAAAAABAAAQAABaAOUAAAABACAQAAAAAAABWgAX AAAAAAAAABAAAAAABAAAgAQQAAAAAAQEAIAEAAAABgMAAAAABAAAgAQFAAAAAAQEAIAEAAAABgMA AAAABAAAgAQMAAAAAAQEAIAEAAAABh0AAAAABAAAgAQFAAAAAAQEAIAEAAAABiEAAAAABAAAgAQF AAAAAAQEAIAEAAAABicAAAAABAAAgAQIAAAAAAQEAIAEAAAABi4AAAAABAAAgAQRAAAAAAQEAIAE AAAABigAAAAABAAAgAQAAKoPQAAAACgAAAAGAAAACQQAAA4AAAAHAAAAAwAJBAAAEQAAAAYAAAAJ BAAABwAAAAcAAAADAAkEAADeAAAABgAAAAkEAAAAAPMDFAAAABIAAAAAAAAAAgAAAAoBAAAAAAAA AACfDwQAAAAAAAAAAACoDxQAAAAuMUFFIE1hbmFnZW1lbnQgSW5mbwAAqg8MAAAAFQAAAAYAAAAJ BAAAEACfDwQAAAABAAAAAACoD8QAAABDaXBoZXIgU3VpdGVzIDoNTmFtZSA6IG5hbWUgb2YgdGhp cyBjaXBoZXIgc3VpdGUsIGNvdWxkIGJlIE1JQiB0YWJsZSBpbmRleC4NQ29uZmlkZW50aWFsaXR5 IDogZmxhZyBpbmRpY2F0ZSB0aGUgY2lwaGVyIHN1aXRlIHdpdGggY29uZmlkZW50aWFsaXR5IGFi aWxpdHkuDUlDViBsZW5ndGggOiB0aGUgbGVuZ3RoIG9mIGdlbmVyYXRlZCBJQ1YuAAChD2QAAAAQ AAAAAAAAAAAAtQAAAAEAAAAAABAAAAAAAAAABAAAAAAEBACABAAAAAY4AAAAAAQAAIAEDwAAAAAE BACABAAAAAZAAAAAAAQAAIAECgAAAAAEBACABAAAAAYgAAAAAAQAAIAEAACqDwwAAADFAAAABgAA AAkEAAAAAPMDFAAAABMAAAAEAAAAAgAAAAsBAAAAAAAAAACfDwQAAAAAAAAAAACqDw4AAAABAAAA BwAAAAAACQQAABAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAkEAAAAAPMDFAAAABQAAAAA AAAAAgAAAAwBAAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAAAuMUFFIE1hbmFnZW1lbnQgSW5mbwAA qg8MAAAAFQAAAAYAAAAJBAAAEACfDwQAAAABAAAAAACoDwABAABTQyBSeCBjb3VudGVycyA6DUlu ZGV4ZWQgYnkgSW50ZXJmYWNlSW5kZXggYW5kIFNDSQ1JblhjYXN0UGt0c05vdFJlY2VpdmVkDUlu WGNhc3RQa3RzSW52YWxpZA1JblhjYXN0UGt0c1JlcGxheWVkDUluWGNhc3RQa3RzTWlzb3JkZXJl ZA1JblhjYXN0UGt0c09yZGVyZWQNSW5YY2FzdFBrdHNFbmNyeXB0ZWQNSW5YY2FzdFBrdHNEZWNy eXB0ZWQNSW5YY2FzdE9jdGV0c0VuY3J5cHRlZCAoTVNEVSkNSW5YY2FzdE9jdGV0c0RlY3J5cHRl ZCAoTVNEVSkNAAChD4IAAAARAAAAAAAAAAAA7wAAAAEAAAAAAAEAAAABAAEAAAAAABEAAAAAAAIA HAALAAAAAAQCAIAEGAAOAAAAAAQGAIAEGAAAAAAGBQAAAAAEAgCABBgABAAAAAAEBgCABBgAAAAA BlQAAAAABAYAgAQUAP8AZv56AAAAAAQGAIAEFAAAAP/+AACqDxABAAAcAAAABgAAAAkEAAAOAAAA BwAAAAMACQQAAAkAAAAGAAAACQQAABYAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAEgAAAAcAAAAD AAkEAAABAAAABgAAAAkEAAATAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABUAAAAHAAAAAwAJBAAA AQAAAAYAAAAJBAAAEgAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAUAAAABwAAAAMACQQAAAEAAAAG AAAACQQAABQAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFgAAAAcAAAADAAkEAAAIAAAABgAAAAkE AAAWAAAABwAAAAMACQQAAAkAAAAGAAAACQQAAAAA8wMUAAAAFQAAAAAAAAACAAAADQEAAAAAAAAA AJ8PBAAAAAAAAAAAAKgPFAAAAC4xQUUgTWFuYWdlbWVudCBJbmZvAACqDwwAAAAVAAAABgAAAAkE AAAQAJ8PBAAAAAEAAAAAAKgPYQEAAFNlY1kgUnggQ291bnRlcnMgOg1UYWJsZSBJbmRleGVkIGJ5 IEludGVyZmFjZUluZGV4DUluWGNhc3RQa3RzTm9UYWcNSW5YY2FzdFBrdHNCYWRUYWcNSW5YY2Fz dFBrdHNVbmtub3duU0NJDUluWGNhc3RQa3RzVW50YWdnZWQNSW5YY2FzdFBrdHNVbmNoZWNrZWQN SW5YY2FzdFBrdHNOb3RSZWNlaXZlZA1JblhjYXN0UGt0c0ludmFsaWQNSW5YY2FzdFBrdHNSZXBs YXllZA1JblhjYXN0UGt0c01pc29yZGVyZWQNSW5YY2FzdFBrdHNPcmRlcmVkDUluWGNhc3RQa3Rz RW5jcnlwdGVkDUluWGNhc3RQa3RzRGVjcnlwdGVkDUluWGNhc3RPY3RldHNFbmNyeXB0ZWQgKE1T RFUpDUluWGNhc3RPY3RldHNEZWNyeXB0ZWQgKE1TRFUpAAChD14AAAATAAAAAAAAEAAAUABPAQAA AQAAEAAAUAATAAAAAAACABwAEQAAAAAEAgCABBgADwAAAAAEBgCABBgAAAAABrYAAAAABAYAgAQU AP8AZv55AAAAAAQGAIAEFAAAAP/+AACqD6ABAAAEAAAABwAAAAMACQQAACAAAAAGAAAACQQAAA4A AAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAEAAAAAcAAAADAAkEAAABAAAABgAAAAkEAAARAAAABwAA AAMACQQAAAEAAAAGAAAACQQAABUAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAEwAAAAcAAAADAAkE AAABAAAABgAAAAkEAAAUAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABYAAAAHAAAAAwAJBAAAAQAA AAYAAAAJBAAAEgAAAAcAAAADAAkEAAABAAAABgAAAAkEAAATAAAABwAAAAMACQQAAAEAAAAGAAAA CQQAABUAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAEgAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAU AAAABwAAAAMACQQAAAEAAAAGAAAACQQAABQAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFgAAAAcA AAADAAkEAAAIAAAABgAAAAkEAAAWAAAABwAAAAMACQQAAAgAAAAGAAAACQQAAAAA8wMUAAAAFwAA AAAAAAACAAAADwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFAAAAC4xQUUgTWFuYWdlbWVudCBJbmZv AACqDwwAAAAVAAAABgAAAAkEAAAQAJ8PBAAAAAEAAAAAAKAPCAIAAFMAQQAgAFQAeAAgAGMAbwB1 AG4AdABlAHIAcwAgADoADQBUAGEAYgBsAGUAIABpAG4AZABlAHgAZQBkACAAYgB5ACAASQBuAHQA ZQByAGYAYQBjAGUASQBuAGQAZQB4ACAAYQBuAGQAIABBAE4ADQBPAHUAdABDAG4AdABSAGUAaQBu AGkAdABUAGkAbQBlACAAOgAgAEEAIAB0AGkAbQBlAHMAdABhAG0AcAAgAGYAbwByACAAdABoAGUA IABjAG8AdQBuAHQAZQByAHMAGSAgAGQAaQBzAGMAbwBuAHQAaQBuAHUAaQB0AHkAIABpAG4AIAB0 AGgAaQBzACAAUwBBAC4ADQBPAHUAdABQAGsAdABzAFAAbgBFAHgAaABhAHUAcwB0AGUAZAANAE8A dQB0AFAAawB0AHMAVABvAG8AbABvAG4AZwANAE8AdQB0AFgAYwBhAHMAdABQAGsAdABzAFAAcgBv AHQAZQBjAHQAZQBkAA0ATwB1AHQAWABjAGEAcwB0AFAAawB0AHMAVQBuAHQAYQBnAGcAZQBkAA0A TwB1AHQAWABjAGEAcwB0AFAAawB0AHMARQBuAGMAcgB5AHAAdABlAGQADQBPAHUAdABYAGMAYQBz AHQATwBjAHQAZQB0AHMARQBuAGMAcgB5AHAAdABlAGQAIAAoAE0AUwBEAFUAKQAAAKEPmgAAABEA AAAAAAAAAAD0AAAAAQAAAAAAEQAAAAAAAgAcABEAAAAABAIAgAQYAA4AAAAABAYAgAQYAAAAAAYF AAAAAAQCAIAEGAATAAAAAAQGAIAEGAAAAAAGAwAAAAAEAgCABBgANwAAAAAEAgCABBQAAQAAAAAE AgCABBgATQAAAAAEBgCABBgA/wBm/jUAAAAABAYAgAQYAAAA//4AAKoP9gAAAAMAAAAGAAAACQQA AAIAAAAHAAAAAwAJBAAAHQAAAAYAAAAJBAAADgAAAAcAAAADAAkEAAAIAAAABgAAAAkEAAAQAAAA BwAAAAMACQQAADsAAAAGAAAACQQAABIAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAADgAAAAcAAAAD AAkEAAABAAAABgAAAAkEAAAVAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABQAAAAHAAAAAwAJBAAA AQAAAAYAAAAJBAAAFQAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAXAAAABwAAAAMACQQAAAgAAAAG AAAACQQAAAAA8wMUAAAAFgAAAAAAAAACAAAADgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFAAAAC4x QUUgTWFuYWdlbWVudCBJbmZvAACqDwwAAAAVAAAABgAAAAkEAAAQAJ8PBAAAAAEAAAAAAKgPtgAA AFNlY1kgVHggQ291bnRlcnMgOg1UYWJsZSBpbmRleGVkIGJ5IEludGVyZmFjZUluZGV4DU91dFBr dHNQbkV4aGF1c3RlZA1PdXRQa3RzVG9vbG9uZw1PdXRYY2FzdFBrdHNQcm90ZWN0ZWQNT3V0WGNh c3RQa3RzVW50YWdnZWQNT3V0WGNhc3RQa3RzRW5jcnlwdGVkDU91dFhjYXN0T2N0ZXRzRW5jcnlw dGVkIChNU0RVKQ0NAAChD1AAAAATAAAAAAAAAAAApAAAAAEAAAAAABMAAAAAAAAAEQAAAAAEAACA BA8AAAAABAQAgAQAAAAGTQAAAAAEBACABP8AZv43AAAAAAQEAIAEAAD//gAAqg/qAAAABAAAAAcA AAADAAkEAAABAAAABgAAAAkEAAACAAAABwAAAAMACQQAAB0AAAAGAAAACQQAAA4AAAAHAAAAAwAJ BAAAAQAAAAYAAAAJBAAAEgAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAOAAAABwAAAAMACQQAAAEA AAAGAAAACQQAABUAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFAAAAAcAAAADAAkEAAABAAAABgAA AAkEAAAVAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABcAAAAHAAAAAwAJBAAACgAAAAYAAAAJBAAA AADzAxQAAAAZAAAAAAAAAAIAAAARAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8UAAAALjFBRSBNYW5h Z2VtZW50IEluZm8AAKoPDAAAABUAAAAGAAAACQQAABAAnw8EAAAAAQAAAAAAqA+5AwAAUkZDMjg2 MyA6IEludGVyZmFjZSBNSUIgY291bnRlcnMNICAgICAJCWlmSW5PY3RldHOgoKCgoKCgoKCgoKCg IENvdW50ZXIzMiwLoKCgoKCgoKAgaWZJblVjYXN0UGt0c6CgoKCgoKCgoKAgQ291bnRlcjMyLAug oKCgoKCgoCBpZkluRGlzY2FyZHOgoKCgoKCgoKCgoCBDb3VudGVyMzIsC6CgoKCgoKCgIGlmSW5F cnJvcnOgoKCgoKCgoKCgoKCgIENvdW50ZXIzMiwLoKCgoKCgoKAgaWZJblVua25vd25Qcm90b3Og oKCgoKAgQ291bnRlcjMyLAugoKCgoKCgoCBpZk91dE9jdGV0c6CgoKCgoKCgoKCgoCBDb3VudGVy MzIsC6CgoKCgoKCgIGlmT3V0VWNhc3RQa3RzoKCgoKCgoKCgIENvdW50ZXIzMiwLoKCgoKCgoKAg aWZPdXREaXNjYXJkc6CgoKCgoKCgoKAgQ291bnRlcjMyLAugoKCgoKCgoCBpZk91dEVycm9yc6Cg oKCgoKCgoKCgoCBDb3VudGVyMzIsC6CgoKCgoKCgIGlmSW5NdWx0aWNhc3RQa3RzoKCgoKCgIENv dW50ZXIzMiwLoKCgoKCgoKAgaWZJbkJyb2FkY2FzdFBrdHOgoKCgoKAgQ291bnRlcjMyLAugoKCg oKCgoCBpZk91dE11bHRpY2FzdFBrdHOgoKCgoCBDb3VudGVyMzIsC6CgoKCgoKCgIGlmT3V0QnJv YWRjYXN0UGt0c6CgoKCgIENvdW50ZXIzMiwLoKCgoKCgoKAgaWZIQ0luT2N0ZXRzoKCgoKCgoKCg oKAgQ291bnRlcjY0LAugoKCgoKCgoCBpZkhDSW5VY2FzdFBrdHOgoKCgoKCgoCBDb3VudGVyNjQs C6CgoKCgoKCgIGlmSENJbk11bHRpY2FzdFBrdHOgoKCgIENvdW50ZXI2NCwLoKCgoKCgoKAgaWZI Q0luQnJvYWRjYXN0UGt0c6CgoKAgQ291bnRlcjY0LAugoKCgoKCgoCBpZkhDT3V0T2N0ZXRzoKCg oKCgoKCgoCBDb3VudGVyNjQsC6CgoKCgoKCgIGlmSENPdXRVY2FzdFBrdHOgoKCgoKCgIENvdW50 ZXI2NCwLoKCgoKCgoKAgaWZIQ091dE11bHRpY2FzdFBrdHOgoKAgQ291bnRlcjY0LAugoKCgoKCg oCBpZkhDT3V0QnJvYWRjYXN0UGt0c6CgoCBDb3VudGVyNjQAAKEPJAAAACEAAAAAAAAQAABQAJkD AAAAAAEQAAAAAFAAugMAAAAAAgASAAAAqg8uAgAAKAAAAAYAAAAJBAAACgAAAAcAAAADAAkEAAAi AAAABgAAAAkEAAANAAAABwAAAAMACQQAAB8AAAAGAAAACQQAAAwAAAAHAAAAAwAJBAAAIAAAAAYA AAAJBAAACgAAAAcAAAADAAkEAAAiAAAABgAAAAkEAAARAAAABwAAAAMACQQAABsAAAAGAAAACQQA AAsAAAAHAAAAAwAJBAAAIQAAAAYAAAAJBAAADgAAAAcAAAADAAkEAAAeAAAABgAAAAkEAAANAAAA BwAAAAMACQQAAB8AAAAGAAAACQQAAAsAAAAHAAAAAwAJBAAAIQAAAAYAAAAJBAAAEQAAAAcAAAAD AAkEAAAbAAAABgAAAAkEAAARAAAABwAAAAMACQQAABsAAAAGAAAACQQAABIAAAAHAAAAAwAJBAAA GgAAAAYAAAAJBAAAEgAAAAcAAAADAAkEAAAaAAAABgAAAAkEAAAMAAAABwAAAAMACQQAACAAAAAG AAAACQQAAA8AAAAHAAAAAwAJBAAAHQAAAAYAAAAJBAAAEwAAAAcAAAADAAkEAAAZAAAABgAAAAkE AAATAAAABwAAAAMACQQAABkAAAAGAAAACQQAAA0AAAAHAAAAAwAJBAAAHwAAAAYAAAAJBAAAEAAA AAcAAAADAAkEAAAcAAAABgAAAAkEAAAUAAAABwAAAAMACQQAABgAAAAGAAAACQQAABQAAAAHAAAA AwAJBAAADgAAAAYAAAAJBAAAAADzAxQAAAAaAAAAAAAAAAIAAAASAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8UAAAALjFBRSBNYW5hZ2VtZW50IEluZm8AAKoPDAAAABUAAAAGAAAACQQAABAAnw8EAAAA AQAAAAAAqA8WAQAATUlCIERlc2lnbg1XaWxsIGZvbGxvdyB0aGUgTUlCLVJFVklFVy1HVUlERUxJ TkVTLCBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9wcy1t aWItcmV2aWV3LWd1aWRlbGluZXMtMDMudHh0LCB2YWxpZCB0byBEZWMuIDIwMDQuDVNOTVB2MyBh Y2Nlc3Mgb25seSA/IFByb2JhYmx5IG5vdCwgZXhjZXB0IHRoZSBLZXkgaW5mb3JtYXRpb24uIChu ZWVkIHRvIHRoaW5rIGFib3V0IGhvdyB0byBhY2hpZXZlIHRoYXQgZm9yIG5vbi1zZWN1cmUgcXVl cnkuKQ0AAKEPJgAAAAsAAAAAAAAAAAAMAQAAAQAAAAAACwAAAAAAAAAMAQAAAAQAAIAEAACqDyQA AAAyAAAABgAAAAkEAABPAAAABgAAAAkEAACWAAAABgAAAAkEAAAPAPIPGAAAAAAA8w8QAAAAAAAA AAMAAAAEAAAACGQKMAAA3w8IAAAAMgAAAIEAAAAvAPAPHAAAAAAA8wMUAAAABwAAAAAAAAAAAAAA AAEAAAAAAAAAAOoDAAAAAAAAchcIAAAAAQAQAHyEAAAAAPUPHAAAABIBAABlGQADWIQAAIi4AAAB AAAAGgAAAA8AnwAPAOgDszMAAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAABgAAAAAA AAABAAAAAAAAAQ8ACQRsAQAAAAAKBAQAAAAEAAAADwDXD1gBAAAAANMPBAAAAAMAAAAAALoPngAA AGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBpAG4AdABlAHIAbgBlAHQA LQBkAHIAYQBmAHQAcwAvAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBvAHAAcwAtAG0AaQBiAC0AcgBl AHYAaQBlAHcALQBnAHUAaQBkAGUAbABpAG4AZQBzAC0AMAAzAC4AdAB4AHQAEAC6D54AAABoAHQA dABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AaQBuAHQAZQByAG4AZQABAAAAAgAA AAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAA EQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAA/v///xsAAAAcAAAAHQAAAB4AAAAf AAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAP7/ ///+//////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////7/AAAFAQIA AAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAACwGAAALAAAAAQAAAGAAAAAC AAAAaAAAAAQAAAB4AAAACAAAAIwAAAAJAAAAoAAAABIAAACsAAAACgAAAMwAAAAMAAAA2AAAAA0A AADkAAAADwAAAPAAAAARAAAA+AAAAAIAAADkBAAAHgAAAAgAAABTbGlkZSAxAB4AAAALAAAARnJh bmsgQ2hhbwAAHgAAAAsAAABGcmFuayBDaGFvAAAeAAAAAwAAADUyAG4eAAAAFQAAAE1pY3Jvc29m dCBQb3dlclBvaW50AABQAEAAAAAQRNZX1AMAAEAAAAAwBZzYVZnEAUAAAAAQ/hL0TczEAQMAAABP AgAARwAAACoFAAD/////AwAAAAgAiRBnDAAAAQAJAAADjQIAAAYAJQAAAAAABAAAAAMBCAAFAAAA CwIAAAAABQAAAAwCeQChAAMAAAAeAAcAAAD8AgAA////AAAABAAAAC0BAAAIAAAA+gIFAAAAAAD/ //8ABAAAAC0BAQAOAAAAJAMFAP///////3gAoAB4AKAA////////CAAAAPoCAAAAAAAAAAAAAAQA AAAtAQIABwAAAPwCAAD///8AAAAEAAAALQEDAAQAAAAnAf//HAAAAPsC+f8AAAAAAACQAQAAAAAA QAAAQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIB AQAFAAAACQIAAAACEAAAADIKNAA8AAYAAABGcmFuayAEAAIABAAEAAMAAgAEAAAALgEAABwAAAD7 AhAABwAAAAAAvAIAAAAAAQICIlN5c3RlbQAAAAAAABgAAAAgsxMAAgAAAOQEAAAAAAAABAAAAC0B BQAEAAAA8AEEABwAAAD7Avn/AAAAAAAAkAEAAAAAAEAAAEFyaWFsAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAg0AAAAyCjQATwAEAAAA Q2hhbwUABAAEAAQABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAAAPsC+f8AAAAAAACQAQAAAAAA QAAAQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIB AQAFAAAACQIAAAACHgAAADIKRQAyAA8AAABmY2hhb0BjaXNjby5jb20AAgAEAAQABAAEAAcABAAB AAQABAAEAAEABAAEAAYABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAAAPsC+f8AAAAAAACQAQAA AAAAQAAAQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAA AAIBAQAFAAAACQIAAAACGAAAADIKVgA6AAsAAABTYW4gQW50b25pby4FAAQABAACAAUABAACAAQA BAACAAQABAAAAC4BAAAEAAAALQEFAAQAAADwAQQAHAAAAPsC+f8AAAAAAACQAQAAAAAAQAAAQXJp YWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEEAAQAAAAuARgABAAAAAIBAQAFAAAA CQIAAAACFgAAADIKZwA8AAoAAAAxMS8xNC8yMDA0BAAEAAIABAAEAAIABAAEAAQABAAEAAAALgEA AAQAAAAtAQUABAAAAPABBAAEAAAA8AEAAAMAAAAeAAcAAAD8AgAA/5nMAAAABAAAAC0BAAAEAAAA LQEBAA4AAAAkAwUACAAOAAgAHgCYAB4AmAAOAAgADgAEAAAALQECAAQAAAAtAQMABAAAACcB//8c AAAA+wL2/wAAAAAAAJABAAAAAABAAABBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQA AAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIlAAAAMgobAB4AFAAAAC4xQUUgTWFuYWdl bWVudCBJbmZvAwAGAAYABwACAAkABQAFAAYABQAFAAkABQAGAAMAAgADAAYAAgAGAAQAAAAuAQAA BAAAAC0BBQAEAAAA8AEEAAMAAAAAAFMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1Zwu GxCTlwgAKyz5rpADAABMAwAAEAAAAAEAAACIAAAAAwAAAJAAAAAPAAAAqAAAAAQAAADEAAAABgAA AMwAAAAHAAAA1AAAAAgAAADcAAAACQAAAOQAAAAKAAAA7AAAABcAAAD0AAAACwAAAPwAAAAQAAAA BAEAABMAAAAMAQAAFgAAABQBAAANAAAAHAEAAAwAAADpAgAAAgAAAOn9AAAeAAAADwAAAE9uLXNj cmVlbiBTaG93AG8eAAAAFAAAAENpc2NvIFN5c3RlbXMsIEluYy4AAwAAAFVXAQADAAAAjAAAAAMA AAAQAAAAAwAAAAEAAAADAAAAAAAAAAMAAAAAAAAAAwAAADoaCgALAAAAAAAAAAsAAAAAAAAACwAA AAAAAAALAAAAAAAAAB4QAAATAAAABgAAAEFyaWFsAA0AAADmlrDntLDmmI7pdXRFcnJvcnOgoKCg oKCgoKCgoKAgQ291bnRlcjMyLAugoKCgoKCgoCBpZkluTXVsdGljYXN0UGt0c6CgoKCgoCBDb3Vu dGVyMzIsC6CgoKCgoKCgIGlmSW5Ccm9hZGNhc3RQa3RzoKCgoKCgIENvdW50ZXIzMiwLoKCgoKCg oKAgaWZPdXRNdWx0aWNhc3RQa3RzoKCgoKAgQ291bnRlcjMyLAugoKCgoKCgoCBpZk91dEJyb2Fk Y2FzdFBrdHOgoKCgoCBDb3VudGVyMzIsC6CgoKCgoKCgIGlmSENJbk9jdGV0c6CgoKCgoKCgoKCg IENvdW50ZXI2NCwLoKCgoKCgoKAgaWZIQ0luVWNhc3RQa3RzoKCgoKCgoKAgQ291bnRlcjY0LAug oKCgoKCgoCBpZkhDSW5NdWx0aWNhc3RQa3RzoKCgoCBDb3VudGVyNjQsC6CgoKCgoKCgIGlmSENJ bkJyb2FkY2FzdFBrdHOgoKCgIENvdW50ZXI2NCwLoKCgoKCgoKAgaWZIQ091dE9jdGV0c6CgoKCg oKCgoKAgQ291bnRlcjY0LAugoKCgoKCgoCBpZkhDT3V0VWNhc3RQa3RzoKCgoKCgoCBDb3VudGVy NjQsC6CgoKCgoKCgIGlmSENPdXRNdWx0aWNhc3RQa3RzoKCgIENvdW50ZXI2NCwLoKCgoKCgoKAg aWZIQ091dEJyb2FkY2FzdFBrdHOgoKAgQ291bnRlcjY0AAChDyQAAAAhAAAAAAAAEAAAUACZAwAA AAABEAAAAABQALoDAAAAAAIAEgAAAKoPLgIAACgAAAAGAAAACQQAAAoAAAAHAAAAAwAJBAAAIgAA AAYAAAAJBAAADQAAAAcAAAADAAkEAAAfAAAABgAAAAkEAAAMAAAABwAAAAMACQQAACAAAAAGAAAA CQQAAAoAAAAHAAAAAwAJBAAAIgAAAAYAAAAJBAAAEQAAAAcAAAADAAkEAAAbAAAABgAAAAkEAAAL AAAABwAAAAMACQQAACEAAAAGAAAACQQAAA4AAAAHAAAAAwAJBAAAHgAAAAYAAAAJBAAADQAAAAcA AAADAAkEAAAfAAAABgAAAAkEAAALAAAABwAAAAMACQQAACEAAAAGAAAACQQAABEAAAAHAAAAAwAJ BAAAGwAAAAYAAAAJBAAAEQAAAAcAAAADAAkEAAAbAAAABgAAAAkEAAASAAAABwAAAAMACQQAABoA AAAGAAAACQQAABIAAAAHAAAAAwAJBAAAGgAAAAYAAAAJBAAADAAAAAcAAAADAAkEAAAgAAAABgAA AAkEAAAPAAAABwAAAAMACQQAAB0AAAAGAAAACQQAABMAAAAHAAAAAwAJBIEAAACCAAAAgwAAAIQA AACFAAAAhgAAAIcAAACIAAAAiQAAAIoAAACLAAAAjAAAAI0AAACOAAAAjwAAAJAAAACRAAAAkgAA AJMAAACUAAAAlQAAAJYAAACXAAAAmAAAAJkAAACaAAAAmwAAAJwAAACdAAAAngAAAJ8AAACgAAAA oQAAAKIAAACjAAAApAAAAKUAAACmAAAApwAAAKgAAACpAAAAqgAAAKsAAACsAAAArQAAAK4AAACv AAAAsAAAALEAAACyAAAAswAAALQAAAC1AAAAtgAAAP7///////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AAAZAAAABgAAAAkEAAAT AAAABwAAAAMACQQAABkAAAAGAAAACQQAAA0AAAAHAAAAAwAJBAAAHwAAAAYAAAAJBAAAEAAAAAcA AAADAAkEAAAcAAAABgAAAAkEAAAUAAAABwAAAAMACQQAABgAAAAGAAAACQQAABQAAAAHAAAAAwAJ BAAADgAAAAYAAAAJBAAAAADzAxQAAAAaAAAAAAAAAAIAAAASAQAAAAAAAAAAnw8EAAAAAAAAAAAA qA8UAAAALjFBRSBNYW5hZ2VtZW50IEluZm8AAKoPDAAAABUAAAAGAAAACQQAABAAnw8EAAAAAQAA AAAAqA+rAAAATUlCIERlc2lnbg1XaWxsIGZvbGxvdyB0aGUgTUlCLVJFVklFVy1HVUlERUxJTkVT LCBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9wcy1taWIt cmV2aWV3LWd1aWRlbGluZXMtMDMudHh0LCB2YWxpZCB0byBEZWMuIDIwMDQuDVNOTVB2MyBhY2Nl c3Mgb25seSA/AAChDyYAAAALAAAAAAAAAAAAoQAAAAEAAAAAAAsAAAAAAAAAoQAAAAAEAACABAAA qg8+AAAAMgAAAAYAAAAJBAAATwAAAAYAAAAJBAAAKQAAAAYAAAAJBAAAAQAAAAcAAAAAAAkEAAAB AAAABgAAAAkEAAAPAPIPGAAAAAAA8w8QAAAAAAAAAAMAAAAEAAAACGQKMAAA3w8IAAAAMgAAAIEA AAAvAPAPHAAAAAAA8wMUAAAABwAAAAAAAAAAAAAAAAEAAAAAAAAAAOoDAAAAAA8A7gO8AgAAAgDv AxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAEwAPAAwELAIAAA8AAvAkAgAAoAEI8AgAAAADAAAA BGgAAA8AA/C8AQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAABoAAAF AAAADwAE8HIAAAASAArwCAAAAANoAAAgAgAAUwAL8B4AAAB/AAAABACAAJg4kwe/AQAAAQD/AQAA AQABAwMEAAAAABDwCAAAAPADIAFgFfAPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAJMHDwAN8AwAAAAA AJ4PBAAAAAEAAAAPAATwCgEAABIACvAIAAAABGgAACAKAACjAQvwnAAAAAQAAAAAAH8AAAAFAIAA bDmTB4EAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIYAAAAAAIcAAQAAAIgAAAAAAIkAAAAA AIoAAAAAAIsAAAAAAL8AEAAfAIABAAAAAIEB/5nMAIIBAAABAIMBAAAACIQBAAABAL8BEAARAMAB AQAACP8BAAAJAAECAgAACAEDAgQAAIgDAAAAADMAIvESAAAAjAABAAAAjQAwZQEAvwEAAGAAAAAQ 8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAADQCTBw8ADfAMAAAAAACeDwQAAAAAAAAA DwAE8EgAAAASAArwCAAAAAFoAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZ mQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADr LggAAAAEzMQBIPqqTgAAchcQAAAAAQAQALy4AAAaABAAd+wAAAAA9Q8cAAAAEgEAAGUZAAOYuAAA O+8AAAEAAAAaAAAAAQCfAA8A6AOzMwAAAQDpAygAAACAFgAA4BAAAOAQAACAFgAABQAAAAoAAAAG AAAAAAAAAAEAAAAAAAABDwAJBGwBAAAAAAoEBAAAAAQAAAAPANcPWAEAAAAA0w8EAAAAAwAAAAAA ug+eAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAGkAbgB0AGUAcgBu AGUAdAAtAGQAcgBhAGYAdABzAC8AZAByAGEAZgB0AC0AaQBlAHQAZgAtAG8AcABzAC0AbQBpAGIA LQByAGUAdgBpAGUAdwAtAGcAdQBpAGQAZQBsAGkAbgBlAHMALQAwADMALgB0AHgAdAAQALoPngAA AGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBpAG4AdABlAHIAbgBlAHQA LQBkAHIAYQBmAHQAcwAvAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBvAHAAcwAtAG0AaQBiAC0AcgBl AHYAaQBlAHcALQBnAHUAaQBkAGUAbABpAG4AZQBzAC0AMAAzAC4AdAB4AHQADwDyA2ABAAAvAMgP DAAAADAA0g8EAAAAAAAAAA8A1QeYAAAAAAC3D0QAAABBAHIAaQBhAGwAAAAIAAAAAAAAAIi5EwCI uRMAKBUnBwi4EwDwtxMA9ugHMAgAAAAAAAAACLgTANJCCTAAuBMAAAAEABAAtw9EAAAAsGUwfQ5m 1JoAAAAACAAAAAAAAACIuRMAiLkTACgVJwcIuBMA8LcTAPboBzAIAAAAAAAAAAi4EwDSQgkwALgT AIgABBIAAKQPCAAAAIEAQACBAAAAAAClDwwAAAAAAAAILgAAAAcAAAAAAKkPCgAAAAcAAAACAAQE CQRAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAA/wAAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8AgAAA AAEAAAD//xIAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAE gAQAAAAADwALBFQBAAAPAADwTAEAAAAABvDgAAAABWgAABsAAABeAAAAEwAAAAEAAAAHAAAAAgAA ACsAAAAAAAAABgAAAAAAAAA/AAAABQAAAAgAAAAGAAAABAAAAAAAAADAAAAACAAAAAQAAAAJAAAA BAAAAAoAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAADgAAAAQAAAAPAAAABAAAABAAAAAE AAAAEQAAAAQAAAASAAAABgAAABMAAAAFAAAAFAAAAAUAAAAVAAAABQAAABYAAAAFAAAAFwAAAAYA AAAYAAAABQAAAAAAAAAEAAAAGgAAAAUAAACDAAvwMAAAAIEBBAAACIMBAAAACIZBAAAAAL8BEAAQ AMABAQAACMVBAAAAAP8BCAAIAAECAgAACDAAGvEMAAAA/wBmAAAA/wD/AAAAQAAe8RAAAAAEAAAI AQAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAIAAAAAAAAAAAAAAAAAAIAAAAAADwDQB3cBAAAf ABQEHAAAAAAAFQQUAAAARpNPCQDKmjv7sXc4AMqaOwEBAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9 AzQAAAAlAAAAZAAAACUAAABkAAAACAAAAAAAAAAguBMA0kIJMAAAAAAAAAAAPv7//7L///8BABMA cAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABk AAAAZAAAAEy4EwBwQwkwiLkTAAAVJwcAAAAAAAAAAAAAAAAAAAAAAAETAB8A/wMUAAAAAgAABAwA AAAAAAAAAAAAAAIAAAAfAAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAAIAAABMuBMAaEcJ MIi5EwAAAAAAAAAAAAAAAAAAAAAAAAETAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAA UABUADEAMAAAAIsTEAAAAAAADQQIAAAAAMAAAADAAAA/ANkPDAAAAAAA2g8EAAAADQAlAA8A8A9g LQAAAADzAxQAAAAYAAAABAAAAAIAAAAQAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA80AAAARnJhbmsg Q2hhbwsLZmNoYW9AY2lzY28uY29tCwtTYW4gQW50b25pbwsLMTEvMTQvMjAwNAAAoQ8UAAAANQAA AAAAAAAAADUAAAAAAAIAIAAAAKoPQAAAAAYAAAAGAAAACQQAAAQAAAAHAAAAAwAJBAAAAgAAAAYA AAAJBAAADwAAAAcAAAADAAkEAAAaAAAABgAAAAkEAAAQAJ8PBAAAAAEAAAAAAKoPDgAAAAEAAAAH AAAAAAAJBAAAAADzAxQAAAADAAAABAAAAAIAAAAAAQAAAAAAAAAAnw8EAAAABgAAAAAAqg8OAAAA AQAAAAcAAAAAAAkEAAAQAJ8PBAAAAAUAAAAAAKoPDgAAAAEAAAAHAAAAAAAJBAAAAADzAxQAAAAJ AAAAAAAAAAIAAAABAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8UAAAALjFBRSBNYW5hZ2VtZW50IElu Zm8AAKoPDAAAABUAAAAGAAAACQQAABAAnw8EAAAAAQAAAAAAqA85AQAATE1JIChMYXllciBNYW5h Z2VtZW50IEludGVyZmFjZSkNRGF0YSBTdHJ1Y3R1cmUNQWNjZXNzZWQgYnkgLjFBRSwgLjFhZiwg U05NUC9NSUIsIEVBUA1Db250YWluaW5nIC4xQUUgYW5kIC4xYWYgY29uZmlndXJhdGlvbiwgcHJv dG9jb2wgc3RhdGVzLCBhbmQgY291bnRlci9kaWFnbm9zaXMgaW5mb3JtYXRpb24uDS4xQUUgdXNl cyBMTUkgdG8gY29udHJvbCB0aGUgTUFDc2VjIHBhY2tldCBwcm9jZXNzaW5nIGRpcmVjdGx5IG9y IHRocm91Z2ggQVBJcy4NQ2hhbmdlIHRoZSBkYXRhIGluIExNSSBtYXkgY2F1c2UgYWN0aW9ucyBp biBTZWNZIG9yIEthWQAAoQ84AAAAIQAAAAAAABAAAFoAGQEAAAEAABAAAFoAIQAAAAAAAAAPAAAA AAQEAIAE/wBm/goBAAAABAAAgAQAAKoPWgAAAM8AAAAGAAAACQQAAAYAAAAHAAAAAwAJBAAAWQAA AAYAAAAJBAAABAAAAAcAAAADAAkEAAAEAAAABgAAAAkEAAADAAAABwAAAAMACQQAAAEAAAAGAAAA CQQAAAAA8wMUAAAACgAAAAAAAAACAAAAAgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFAAAAC4xQUUg TWFuYWdlbWVudCBJbmZvAACqDwwAAAAVAAAABgAAAAkEAAAQAJ8PBAAAAAEAAAAAAKgPXwEAAE1B Q3NlYyBNZ210IEluZm9ybWF0aW9uDUVuYWJsZS9EaXNhYmxlIChnbG9iYWwgY29uZmlndXJhdGlv bikNU2VjWSBNZ210IEluZm9ybWF0aW9uDVRhYmxlIGluZGV4ZWQgYnkgSW50ZXJmYWNlSW5kZXgg KElGLU1JQikuDVZhbGlkYXRlUnhGcmFtZXMgOiBmbGFnIGZvciB2YWxpZGF0aW9uIHByb2Nlc3Mg aW4gcmVjZWl2aW5nLiAoMTAuNS4zKQ1Qcm90ZWN0VHhGcmFtZXMgOiBmbGFnIGZvciBwcm90ZWN0 aW9uIHByb2Nlc3MgaW4gdHJhbnNtaXR0aW5nLg1DdXJyZW50IENpcGhlciBTdWl0ZS4gKDEwLjUu NCkgKFJvdyBQb2ludGVyKQ1hZG1pblBvaW50VG9Qb2ludE1BQywgb3BlclBvaW50VG9Qb2ludE1B QyAoNi41KQAAoQ8AAQAAGAAAAAAAABAAAFoAJgAAAAEAABAAAFoAFgAAAAAAABAAAFoADAEAAAEA ABAAAFoAGAAAAAAAAgAcAA8AAAAAAAQAAAAABhYAAAAAAAAAAQAAAAAABAAAAAAGFgAAAAAEAgCA BBwAEQAAAAAIAACACA4AAAAACAQAgAgAAAAGCwAAAAAIAACACBAAAAAACAQAgAgAAAAGNgAAAAAI AACACA8AAAAACAQAgAgAAAAGMAAAAAAIAACACBYAAAAACAQAgAgAAAAGFwAAAAAIAACACBQAAAAA CAQAgAgAAAAGAgAAAAAIAACACBQAAAAACAQAgAgAAAAGBgAAAAAIAACACAAAqg+cAAAABgAAAAcA AAADAAkEAABfAAAABgAAAAkEAAAOAAAABwAAAAMACQQAAAsAAAAGAAAACQQAABAAAAAHAAAAAwAJ BAAANgAAAAYAAAAJBAAADwAAAAcAAAADAAkEAABdAAAABgAAAAkEAAAUAAAABwAAAAMACQQAAAIA AAAGAAAACQQAABMAAAAHAAAAAwAJBAAABwAAAAYAAAAJBAAAAADzAxQAAAALAAAAAAAAAAIAAAAD AQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8UAAAALjFBRSBNYW5hZ2VtZW50IEluZm8AAKoPDAAAABUA AAAGAAAACQQAABAAnw8EAAAAAQAAAAAAqA8aAQAAUnhSZXBsYXlDaGsgOiBmbGFnIGZvciByeCBy ZXBsYXkgY2hlY2suICgxMC42LjIpDVR4IFNDIDogdHJhbnNtaXQgU0MgaW5mb3JtYWl0b24uDVJ4 IFNDcyA6IHJlY2VpdmUgU0NzIGluZm9ybWFpdG9uLiAod2lsbCBiZSBpbiBhbm90aGVyIHRhYmxl LikNbGFzdFVua25vd25TQyA6IGFuIFNDSSBpbmZvcm1hdGlvbiB0byByZWNvcmQgbGFzdCByeCB1 bmtub3duIFNDICgxMC42LjEpIHdpdGggdGltZSBzdGFtcCwgaXQgY291bGQgYmUgYSBsaXN0IChh IHRhYmxlLCBtYXhpbXVtIGVudHJpZXMpID8NAAChDzIAAAAbAQAAAQAAAAAACwAAAAAABAAAAAAG hQAAAAAAAAANAAAAAAAEAP8AZv5+AAAAAAAAAAAAqg/qAAAACwAAAAcAAAADAAkEAAAMAAAABgAA AAkEAAACAAAABwAAAAMACQQAABgAAAAGAAAACQQAAAIAAAAHAAAAAwAJBAAAEgAAAAYAAAAJBAAA CwAAAAcAAAADAAkEAAAFAAAABgAAAAkEAAADAAAABwAAAAMACQQAAAsAAAAGAAAACQQAAAMAAAAH AAAAAwAJBAAAAQAAAAYAAAAJBAAACwAAAAcAAAADAAkEAAAeAAAABgAAAAkEAAANAAAABwAAAAMA CQQAACUAAAAGAAAACQQAAAIAAAAHAAAAAwAJBAAAVwAAAAYAAAAJBAAAAADzAxQAAAAPAAAAAAAA AAIAAAAHAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8UAAAALjFBRSBNYW5hZ2VtZW50IEluZm8AAKoP DAAAABUAAAAGAAAACQQAABAAnw8EAAAAAQAAAAAAqA8UAgAAVHggU0MgTWdtdCBJbmZvcm1hdGlv bg1zY1N0YXRlIDogc3RhdGUgb2YgdGhpcyB0cmFuc21pdCBTQyA/Lg1zY0NtZCA6IGNvbW1hbmQg ZXhlY3V0aW5nIGluIHRoZSBTQyA/Lg1TQ0kgOiB0aGUgU0NJIGZvciB0aGUgU0MgdXNlZCBieSBT ZWNZIGZvciB0cmFuc21pdC4gKDEwLjUpDXR4RW5jb2RpbmdTQSA6IGN1cnJlbnQgU0EgbnVtYmVy LiAoMTAuNS4xKSAoY291bGQgYmUgYSBSb3dQb2ludGVyKQ10eEVuY2lwaGVyaW5nU0EgOiBwcmV2 aW91cyBTQSBudW1iZXIuICgxMC41LjQpIChjb3VsZCBiZSBhIFJvd1BvaW50ZXIpDVR4IFNBIDog KHRhYmxlIHdpdGggNCBlbnRyaWVzKQ1UYWJsZSBpbmRleGVkIGJ5IEludGVyZmFjZUluZGV4IGFu ZCBBTi4Nc2FTdGF0ZSA6IHN0YXRlIG9mIHRoaXMgdHJhbnNtaXQgU0EuDXNhQ21kIDogY29tbWFu ZCBleGVjY3V0aW5nIGluIHRoZSBTQS4NdHhTQUsgOiBrZXkgZm9yIHRyYW5zbWl0dGluZy4gKDcu MSwgMTAuNS4xKQ10eE5leHRQTiA6IG5leHQgcGFja2V0IG51bWJlciAoUE4pLiAoMTAuNS4yKQAA oQ9yAQAAFwAAAAAAABAAAFAAEwEAAAEAABAAAFAAHwAAAAAAABAAAFAAzAAAAAEAABAAAFAAFwAA AAAAAgAcAAcAAAAAAAYAGAAAAAAGIAAAAAAAAgAYAAUAAAAAAAYAGAAAAAAGIgAAAAAAAgAYAAMA AAAAAAYAGAAAAAAGOAAAAAAAAgAYAAwAAAAAAAYAGAAAAAAGNwAAAAAAAgAYAA8AAAAAAAYAGAAA AAAGOAAAAAAAAgAYAB8AAAAABAIAgAQcABEAAAAACAIAgAgYAA4AAAAACAYAgAgYAAAAAAYFAAAA AAgCAIAIGAACAAAAAAgGAIAIGAAAAAAGAgAAAAAIAgCACBgABwAAAAAIBgCACBgAAAAABh4AAAAA CAIAgAgYAAUAAAAACAYAgAgYAAAAAAYhAAAAAAgCAIAIGAAFAAAAAAgGAIAIGAAAAAAGJwAAAAAI AgCACBgACAAAAAAIBgCACBgAAAAABiUAAAAACAIAgAgYAAAAqg+GAQAAAgAAAAcAAAADAAkEAAAV AAAABgAAAAkEAAAHAAAABwAAAAMACQQAACAAAAAGAAAACQQAAAUAAAAHAAAAAwAJBAAAQwAAAAYA AAAJBAAABAAAAAcAAAADAAkEAAAWAAAABgAAAAkEAAAMAAAABwAAAAMACQQAACsAAAAGAAAACQQA AAoAAAAHAAAAAwAJBAAAAgAAAAYAAAAJBAAADwAAAAcAAAADAAkEAAAsAAAABgAAAAkEAAAKAAAA BwAAAAMACQQAAAIAAAAGAAAACQQAAAIAAAAHAAAAAwAJBAAALgAAAAYAAAAJBAAADgAAAAcAAAAD AAkEAAAJAAAABgAAAAkEAAAHAAAABwAAAAMACQQAAB4AAAAGAAAACQQAAAUAAAAHAAAAAwAJBAAA CwAAAAYAAAAJBAAACgAAAAcAAAADAAkEAAAMAAAABgAAAAkEAAAFAAAABwAAAAMACQQAACcAAAAG AAAACQQAAAgAAAAHAAAAAwAJBAAAJQAAAAYAAAAJBAAAAADzAxQAAAAQAAAAAAAAAAIAAAAIAQAA AAAAAAAAnw8EAAAAAAAAAAAAqA8UAAAALjFBRSBNYW5hZ2VtZW50IEluZm8AAKoPDAAAABUAAAAG AAAACQQAABAAnw8EAAAAAQAAAAAAqA9wAQAAUnggU0NzIE1nbXQgSW5mb3JtYXRpb24NVGFibGUg aW5kZXhlZCBieSBJbnRlcmZhY2VJbmRleCBhbmQgU0NJLg1zY1N0YXRlIDogc3RhdGUgb2YgdGhp cyB0cmFuc21pdCBTQyA/Lg1zY0NtZCA6IGNvbW1hbmQgZXhlY3V0aW5nIGluIHRoZSBTQyA/Lg1T Q0kgOiB0aGUgU0NJIGZvciB0aGUgU0MgdXNlZCBieSBTZWNZIGZvciB0cmFuc21pdC4gKDEwLjUp DXJ4Q3VycmVudFNBIDogY3VycmVudCB1c2luZyBTQSBudW1iZXIgaW4gdGhlIFNDLiAoMTAuNi4x KSAoUm93UG9pbnRlcikNbGFzdE5vdEluVXNlQW4gOiBsYXN0IE5vdC1pbi1Vc2UgQU4gd2l0aCB0 aW1lc3RhbXAuICgxMC42LjEpIGEgbGlzdCAoYSB0YWJsZSwgbWF4aW11bSBlbnRyaWVzKT8AAKEP 0gAAABgAAAAAAAAAAABZAQAAAQAAAAAAGAAAAAAAAgAcABAAAAAABAIAgAQYABAAAAAABAYAgAQY AAAAAAYDAAAAAAQCAIAEGAANAAAAAAQGAIAEGAAAAAAGIAAAAAAEAgCABBgABQAAAAAEBgCABBgA AAAABiIAAAAABAIAgAQYAAMAAAAABAYAgAQYAAAAAAY4AAAAAAQCAIAEGAALAAAAAAQGAIAEGAAA AAAGPAAAAAAEAgCABBgADgAAAAAEBgCABBgA/wBm/lIAAAAABAIAgAQYAAAAqg/cAAAAAwAAAAYA AAAJBAAAAwAAAAcAAAADAAkEAAAjAAAABgAAAAkEAAAOAAAABwAAAAMACQQAAAoAAAAGAAAACQQA AAcAAAAHAAAAAwAJBAAAIAAAAAYAAAAJBAAABQAAAAcAAAADAAkEAABDAAAABgAAAAkEAAAEAAAA BwAAAAMACQQAABYAAAAGAAAACQQAAAsAAAAHAAAAAwAJBAAAMAAAAAYAAAAJBAAACgAAAAcAAAAD AAkEAAACAAAABgAAAAkEAAAOAAAABwAAAAMACQQAAFIAAAAGAAAACQQAAAAA8wMUAAAAEQAAAAAA AAACAAAACQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFAAAAC4xQUUgTWFuYWdlbWVudCBJbmZvAACq DwwAAAAVAAAABgAAAAkEAAAQAJ8PBAAAAAEAAAAAAKgPKwEAAFJ4IFNBIE1nbXQgSW5mb3JtYXRp b24NVGFibGUgaW5kZXhlZCBieSBJbnRlcmZhY2VJbmRleCBhbmQgU0NJIGFuZCBBTi4Nc2FTdGF0 ZSA6IHN0YXRlIG9mIHRoaXMgcmVjZWl2ZSBTQS4Nc2FDbWQgOiBjb21tYW5kIGV4Y2VjdXRpbmcg aW4gdGhlIFNBLg1yeFNBSyA6IGtleSBmb3IgdHJhbnNtaXR0aW5nLiAoNy4xLCAxMC42LjEpDXJ4 TGFzdFBOIDogbGFzdCByZWNlaXZlZCBwYWNrZXQgbnVtYmVyIChQTikuICgxMC42LjIpDXJ4TGFz dFZhbGlkYXRlZFBOIDogbGFzdCByZWNlaXZlZCB2YWxpZGF0ZWQgUE4uICgxMC42LjIpAAChD+IA AAAXAAAAAAAAEAAAWgAwAAAAAQAAEAAAWgDlAAAAAQAgEAAAAAAAAVoAFwAAAAAAAAAQAAAAAAQA AIAEEAAAAAAEBACABAAAAAYDAAAAAAQAAIAEBQAAAAAEBACABAAAAAYDAAAAAAQAAIAEDAAAAAAE BACABAAAAAYdAAAAAAQAAIAEBQAAAAAEBACABAAAAAYhAAAAAAQAAIAEBQAAAAAEBACABAAAAAYn AAAAAAQAAIAECAAAAAAEBACABAAAAAYuAAAAAAQAAIAEEQAAAAAEBACABAAAAAYoAAAAAAQAAIAE AACqD0AAAAAoAAAABgAAAAkEAAAOAAAABwAAAAMACQQAABEAAAAGAAAACQQAAAcAAAAHAAAAAwAJ BAAA3gAAAAYAAAAJBAAAAADzAxQAAAASAAAAAAAAAAIAAAAKAQAAAAAAAAAAnw8EAAAAAAAAAAAA qA8UAAAALjFBRSBNYW5hZ2VtZW50IEluZm8AAKoPDAAAABUAAAAGAAAACQQAABAAnw8EAAAAAQAA AAAAqA/EAAAAQ2lwaGVyIFN1aXRlcyA6DU5hbWUgOiBuYW1lIG9mIHRoaXMgY2lwaGVyIHN1aXRl LCBjb3VsZCBiZSBNSUIgdGFibGUgaW5kZXguDUNvbmZpZGVudGlhbGl0eSA6IGZsYWcgaW5kaWNh dGUgdGhlIGNpcGhlciBzdWl0ZSB3aXRoIGNvbmZpZGVudGlhbGl0eSBhYmlsaXR5Lg1JQ1YgbGVu Z3RoIDogdGhlIGxlbmd0aCBvZiBnZW5lcmF0ZWQgSUNWLgAAoQ9kAAAAEAAAAAAAAAAAALUAAAAB AAAAAAAQAAAAAAAAAAQAAAAABAQAgAQAAAAGOAAAAAAEAACABA8AAAAABAQAgAQAAAAGQAAAAAAE AACABAoAAAAABAQAgAQAAAAGIAAAAAAEAACABAAAqg8MAAAAxQAAAAYAAAAJBAAAAADzAxQAAAAT AAAABAAAAAIAAAALAQAAAAAAAAAAnw8EAAAAAAAAAAAAqg8OAAAAAQAAAAcAAAAAAAkEAAAQAJ8P BAAAAAEAAAAAAKoPDgAAAAEAAAAHAAAAAAAJBAAAAADzAxQAAAAUAAAAAAAAAAIAAAAMAQAAAAAA AAAAnw8EAAAAAAAAAAAAqA8UAAAALjFBRSBNYW5hZ2VtZW50IEluZm8AAKoPDAAAABUAAAAGAAAA CQQAABAAnw8EAAAAAQAAAAAAqA8AAQAAU0MgUnggY291bnRlcnMgOg1JbmRleGVkIGJ5IEludGVy ZmFjZUluZGV4IGFuZCBTQ0kNSW5YY2FzdFBrdHNOb3RSZWNlaXZlZA1JblhjYXN0UGt0c0ludmFs aWQNSW5YY2FzdFBrdHNSZXBsYXllZA1JblhjYXN0UGt0c01pc29yZGVyZWQNSW5YY2FzdFBrdHNP cmRlcmVkDUluWGNhc3RQa3RzRW5jcnlwdGVkDUluWGNhc3RQa3RzRGVjcnlwdGVkDUluWGNhc3RP Y3RldHNFbmNyeXB0ZWQgKE1TRFUpDUluWGNhc3RPY3RldHNEZWNyeXB0ZWQgKE1TRFUpDQAAoQ+C AAAAEQAAAAAAAAAAAO8AAAABAAAAAAABAAAAAQABAAAAAAARAAAAAAACABwACwAAAAAEAgCABBgA DgAAAAAEBgCABBgAAAAABgUAAAAABAIAgAQYAAQAAAAABAYAgAQYAAAAAAZUAAAAAAQGAIAEFAD/ AGb+egAAAAAEBgCABBQAAAD//gAAqg8QAQAAHAAAAAYAAAAJBAAADgAAAAcAAAADAAkEAAAJAAAA BgAAAAkEAAAWAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABIAAAAHAAAAAwAJBAAAAQAAAAYAAAAJ BAAAEwAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAVAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABIA AAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFAAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAUAAAABwAA AAMACQQAAAEAAAAGAAAACQQAABYAAAAHAAAAAwAJBAAACAAAAAYAAAAJBAAAFgAAAAcAAAADAAkE AAAJAAAABgAAAAkEAAAAAPMDFAAAABUAAAAAAAAAAgAAAA0BAAAAAAAAAACfDwQAAAAAAAAAAACo DxQAAAAuMUFFIE1hbmFnZW1lbnQgSW5mbwAAqg8MAAAAFQAAAAYAAAAJBAAAEACfDwQAAAABAAAA AACoD2EBAABTZWNZIFJ4IENvdW50ZXJzIDoNVGFibGUgSW5kZXhlZCBieSBJbnRlcmZhY2VJbmRl eA1JblhjYXN0UGt0c05vVGFnDUluWGNhc3RQa3RzQmFkVGFnDUluWGNhc3RQa3RzVW5rbm93blND SQ1JblhjYXN0UGt0c1VudGFnZ2VkDUluWGNhc3RQa3RzVW5jaGVja2VkDUluWGNhc3RQa3RzTm90 UmVjZWl2ZWQNSW5YY2FzdFBrdHNJbnZhbGlkDUluWGNhc3RQa3RzUmVwbGF5ZWQNSW5YY2FzdFBr dHNNaXNvcmRlcmVkDUluWGNhc3RQa3RzT3JkZXJlZA1JblhjYXN0UGt0c0VuY3J5cHRlZA1Jblhj YXN0UGt0c0RlY3J5cHRlZA1JblhjYXN0T2N0ZXRzRW5jcnlwdGVkIChNU0RVKQ1JblhjYXN0T2N0 ZXRzRGVjcnlwdGVkIChNU0RVKQAAoQ9eAAAAEwAAAAAAABAAAFAATwEAAAEAABAAAFAAEwAAAAAA AgAcABEAAAAABAIAgAQYAA8AAAAABAYAgAQYAAAAAAa2AAAAAAQGAIAEFAD/AGb+eQAAAAAEBgCA BBQAAAD//gAAqg+gAQAABAAAAAcAAAADAAkEAAAgAAAABgAAAAkEAAAOAAAABwAAAAMACQQAAAEA AAAGAAAACQQAABAAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAEQAAAAcAAAADAAkEAAABAAAABgAA AAkEAAAVAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABMAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAA FAAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAWAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABIAAAAH AAAAAwAJBAAAAQAAAAYAAAAJBAAAEwAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAVAAAABwAAAAMA CQQAAAEAAAAGAAAACQQAABIAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFAAAAAcAAAADAAkEAAAB AAAABgAAAAkEAAAUAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABYAAAAHAAAAAwAJBAAACAAAAAYA AAAJBAAAFgAAAAcAAAADAAkEAAAIAAAABgAAAAkEAAAAAPMDFAAAABcAAAAAAAAAAgAAAA8BAAAA AAAAAACfDwQAAAAAAAAAAACoDxQAAAAuMUFFIE1hbmFnZW1lbnQgSW5mbwAAqg8MAAAAFQAAAAYA AAAJBAAAEACfDwQAAAABAAAAAACgDwgCAABTAEEAIABUAHgAIABjAG8AdQBuAHQAZQByAHMAIAA6 AA0AVABhAGIAbABlACAAaQBuAGQAZQB4AGUAZAAgAGIAeQAgAEkAbgB0AGUAcgBmAGEAYwBlAEkA bgBkAGUAeAAgAGEAbgBkACAAQQBOAA0ATwB1AHQAQwBuAHQAUgBlAGkAbgBpAHQAVABpAG0AZQAg ADoAIABBACAAdABpAG0AZQBzAHQAYQBtAHAAIABmAG8AcgAgAHQAaABlACAAYwBvAHUAbgB0AGUA cgBzABkgIABkAGkAcwBjAG8AbgB0AGkAbgB1AGkAdAB5ACAAaQBuACAAdABoAGkAcwAgAFMAQQAu AA0ATwB1AHQAUABrAHQAcwBQAG4ARQB4AGgAYQB1AHMAdABlAGQADQBPAHUAdABQAGsAdABzAFQA bwBvAGwAbwBuAGcADQBPAHUAdABYAGMAYQBzAHQAUABrAHQAcwBQAHIAbwB0AGUAYwB0AGUAZAAN AE8AdQB0AFgAYwBhAHMAdABQAGsAdABzAFUAbgB0AGEAZwBnAGUAZAANAE8AdQB0AFgAYwBhAHMA dABQAGsAdABzAEUAbgBjAHIAeQBwAHQAZQBkAA0ATwB1AHQAWABjAGEAcwB0AE8AYwB0AGUAdABz AEUAbgBjAHIAeQBwAHQAZQBkACAAKABNAFMARABVACkAAAChD5oAAAARAAAAAAAAAAAA9AAAAAEA AAAAABEAAAAAAAIAHAARAAAAAAQCAIAEGAAOAAAAAAQGAIAEGAAAAAAGBQAAAAAEAgCABBgAEwAA AAAEBgCABBgAAAAABgMAAAAABAIAgAQYADcAAAAABAIAgAQUAAEAAAAABAIAgAQYAE0AAAAABAYA gAQYAP8AZv41AAAAAAQGAIAEGAAAAP/+AACqD/YAAAADAAAABgAAAAkEAAACAAAABwAAAAMACQQA AB0AAAAGAAAACQQAAA4AAAAHAAAAAwAJBAAACAAAAAYAAAAJBAAAEAAAAAcAAAADAAkEAAA7AAAA BgAAAAkEAAASAAAABwAAAAMACQQAAAEAAAAGAAAACQQAAA4AAAAHAAAAAwAJBAAAAQAAAAYAAAAJ BAAAFQAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAUAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABUA AAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFwAAAAcAAAADAAkEAAAIAAAABgAAAAkEAAAAAPMDFAAA ABYAAAAAAAAAAgAAAA4BAAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAAAuMUFFIE1hbmFnZW1lbnQg SW5mbwAAqg8MAAAAFQAAAAYAAAAJBAAAEACfDwQAAAABAAAAAACoD7YAAABTZWNZIFR4IENvdW50 ZXJzIDoNVGFibGUgaW5kZXhlZCBieSBJbnRlcmZhY2VJbmRleA1PdXRQa3RzUG5FeGhhdXN0ZWQN T3V0UGt0c1Rvb2xvbmcNT3V0WGNhc3RQa3RzUHJvdGVjdGVkDU91dFhjYXN0UGt0c1VudGFnZ2Vk DU91dFhjYXN0UGt0c0VuY3J5cHRlZA1PdXRYY2FzdE9jdGV0c0VuY3J5cHRlZCAoTVNEVSkNDQAA oQ9QAAAAEwAAAAAAAAAAAKQAAAABAAAAAAATAAAAAAAAABEAAAAABAAAgAQPAAAAAAQEAIAEAAAA Bk0AAAAABAQAgAT/AGb+NwAAAAAEBACABAAA//4AAKoP6gAAAAQAAAAHAAAAAwAJBAAAAQAAAAYA AAAJBAAAAgAAAAcAAAADAAkEAAAdAAAABgAAAAkEAAAOAAAABwAAAAMACQQAAAEAAAAGAAAACQQA ABIAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAADgAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAVAAAA BwAAAAMACQQAAAEAAAAGAAAACQQAABQAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFQAAAAcAAAAD AAkEAAABAAAABgAAAAkEAAAXAAAABwAAAAMACQQAAAoAAAAGAAAACQQAAAAA8wMUAAAAGQAAAAAA AAACAAAAEQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFAAAAC4xQUUgTWFuYWdlbWVudCBJbmZvAACq DwwAAAAVAAAABgAAAAkEAAAQAJ8PBAAAAAEAAAAAAKgPuQMAAFJGQzI4NjMgOiBJbnRlcmZhY2Ug TUlCIGNvdW50ZXJzDSAgICAgCQlpZkluT2N0ZXRzoKCgoKCgoKCgoKCgoCBDb3VudGVyMzIsC6Cg oKCgoKCgIGlmSW5VY2FzdFBrdHOgoKCgoKCgoKCgIENvdW50ZXIzMiwLoKCgoKCgoKAgaWZJbkRp c2NhcmRzoKCgoKCgoKCgoKAgQ291bnRlcjMyLAugoKCgoKCgoCBpZkluRXJyb3JzoKCgoKCgoKCg oKCgoCBDb3VudGVyMzIsC6CgoKCgoKCgIGlmSW5Vbmtub3duUHJvdG9zoKCgoKCgIENvdW50ZXIz MiwLoKCgoKCgoKAgaWZPdXRPY3RldHOgoKCgoKCgoKCgoKAgQ291bnRlcjMyLAugoKCgoKCgoCBp Zk91dFVjYXN0UGt0c6CgoKCgoKCgoCBDb3VudGVyMzIsC6CgoKCgoKCgIGlmT3V0RGlzY2FyZHOg oKCgoKCgoKCgIENvdW50ZXIzMiwLoKCgoKCgoKAgaWZPdXRFcnJvcnOgoKCgoKCgoKCgoKAgQ291 bnRlcjMyLAugoKCgoKCgoCBpZkluTXVsdGljYXN0UGt0c6CgoKCgoCBDb3VudGVyMzIsC6CgoKCg oKCgIGlmSW5Ccm9hZGNhc3RQa3RzoKCgoKCgIENvdW50ZXIzMiwLoKCgoKCgoKAgaWZPdXRNdWx0 aWNhc3RQa3RzoKCgoKAgQ291bnRlcjMyLAugoKCgoKCgoCBpZk91dEJyb2FkY2FzdFBrdHOgoKCg oCBDb3VudGVyMzIsC6CgoKCgoKCgIGlmSENJbk9jdGV0c6CgoKCgoKCgoKCgIENvdW50ZXI2NCwL oKCgoKCgoKAgaWZIQ0luVWNhc3RQa3RzoKCgoKCgoKAgQ291bnRlcjY0LAugoKCgoKCgoCBpZkhD SW5NdWx0aWNhc3RQa3RzoKCgoCBDb3VudGVyNjQsC6CgoKCgoKCgIGlmSENJbkJyb2FkY2FzdFBr dHOgoKCgIENvdW50ZXI2NCwLoKCgoKCgoKAgaWZIQ091dE9jdGV0c6CgoKCgoKCgoKAgQ291bnRl cjY0LAugoKCgoKCgoCBpZkhDT3V0VWNhc3RQa3RzoKCgoKCgoCBDb3VudGVyNjQsC6CgoKCgoKCg IGlmSENPdXRNdWx0aWNhc3RQa3RzoKCgIENvdW50ZXI2NCwLoKCgoKCgoKAgaWZIQ091dEJyb2Fk Y2FzdFBrdHOgoKAgQ291bnRlcjY0AAChDyQAAAAhAAAAAAAAEAAAUACZAwAAAAABEAAAAABQALoD AAAAAAIAEgAAAKoPLgIAACgAAAAGAAAACQQAAAoAAAAHAAAAAwAJBAAAIgAAAAYAAAAJBAAADQAA AAcAAAADAAkEAAAfAAAABgAAAAkEAAAMAAAABwAAAAMACQQAACAAAAAGAAAACQQAAAoAAAAHAAAA AwAJBAAAIgAAAAYAAAAJBAAAEQAAAAcAAAADAAkEAAAbAAAABgAAAAkEAAALAAAABwAAAAMACQQA ACEAAAAGAAAACQQAAA4AAAAHAAAAAwAJBAAAHgAAAAYAAAAJBAAADQAAAAcAAAADAAkEAAAfAAAA BgAAAAkEAAALAAAABwAAAAMACQQAACEAAAAGAAAACQQAABEAAAAHAAAAAwAJBAAAGwAAAAYAAAAJ BAAAEQAAAAcAAAADAAkEAAAbAAAABgAAAAkEAAASAAAABwAAAAMACQQAABoAAAAGAAAACQQAABIA AAAHAAAAAwAJBAAAGgAAAAYAAAAJBAAADAAAAAcAAAADAAkEAAAgAAAABgAAAAkEAAAPAAAABwAA AAMACQQAAB0AAAAGAAAACQQAABMAAAAHAAAAAwAJBAAAGQAAAAYAAAAJBAAAEwAAAAcAAAADAAkE AAAZAAAABgAAAAkEAAANAAAABwAAAAMACQQAAB8AAAAGAAAACQQAABAAAAAHAAAAAwAJBAAAHAAA AAYAAAAJBAAAFAAAAAcAAAADAAkEAAAYAAAABgAAAAkEAAAUAAAABwAAAAMACQQAAA4AAAAGAAAA CQQAAAAA8wMUAAAAGgAAAAAAAAACAAAAEgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFAAAAC4xQUUg TWFuYWdlbWVudCBJbmZvAACqDwwAAAAVAAAABgAAAAkEAAAQAJ8PBAAAAAEAAAAAAKgPqwAAAE1J QiBEZXNpZ24NV2lsbCBmb2xsb3cgdGhlIE1JQi1SRVZJRVctR1VJREVMSU5FUywgaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1vcHMtbWliLXJldmlldy1ndWlk ZWxpbmVzLTAzLnR4dCwgdmFsaWQgdG8gRGVjLiAyMDA0Lg1TTk1QdjMgYWNjZXNzIG9ubHkgPwAA oQ8mAAAACwAAAAAAAAAAAKEAAAABAAAAAAALAAAAAAAAAKEAAAAABAAAgAQAAKoPPgAAADIAAAAG AAAACQQAAE8AAAAGAAAACQQAACkAAAAGAAAACQQAAAEAAAAHAAAAAAAJBAAAAQAAAAYAAAAJBAAA DwDyDxgAAAAAAPMPEAAAAAAAAAADAAAABAAAAAhkCjAAAN8PCAAAADIAAACBAAAALwDwDxwAAAAA APMDFAAAAAcAAAAAAAAAAAAAAAABAAAAAAAAAADqAwAAAAAAAHIXCAAAAAEAEAB37wAAAAD1DxwA AAAAAAAAZRkAA1PvAAAyIwEAAQAAABoAAAAPAJ8ADwDoA7MzAAABAOkDKAAAAIAWAADgEAAA4BAA AIAWAAAFAAAACgAAAAYAAAAAAAAAAQAAAAAAAAEPAAkEbAEAAAAACgQEAAAABAAAAA8A1w9YAQAA AADTDwQAAAADAAAAAAC6D54AAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBn AC8AaQBuAHQAZQByAG4AZQB0AC0AZAByAGEAZgB0AHMALwBkAHIAYQBmAHQALQBpAGUAdABmAC0A bwBwAHMALQBtAGkAYgAtAHIAZQB2AGkAZQB3AC0AZwB1AGkAZABlAGwAaQBuAGUAcwAtADAAMwAu AHQAeAB0ABAAug+eAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAGkA bgB0AGUAcgBuAGUAdAAtAGQAcgBhAGYAdABzAC8AZAByAGEAZgB0AC0AaQBlAHQAZgAtAG8AcABz AC0AbQBpAGIALQByAGUAdgBpAGUAdwAtAGcAdQBpAGQAZQBsAGkAbgBlAHMALQAwADMALgB0AHgA dAAPAPIDYAEAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB5gAAAAAALcPRAAAAEEAcgBpAGEAbAAA AAgAAAAAAAAAiLkTAIi5EwAoFScHCLgTAPC3EwD26AcwCAAAAAAAAAAIuBMA0kIJMAC4EwAAAAQA EAC3D0QAAACwZTB9DmbUmgAAAAAIAAAAAAAAAIi5EwCIuRMAKBUnBwi4EwDwtxMA9ugHMAgAAAAA AAAACLgTANJCCTAAuBMAiAAEEgAApA8IAAAAgQBAAIEAAAAAAKUPDAAAAAAAAAguAAAABwAAAAAA qQ8KAAAABwAAAAIABAQJBEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAD/AABkAAAAAAAAAAAAQAIA AAAABwAAAP//7wCAAAAAAQAAAP//EgAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAA YANgAwAAAAAABQAAgASABAAAAAAPAAsEVAEAAA8AAPBMAQAAAAAG8OAAAAAFaAAAGwAAAF4AAAAT AAAAAQAAAAcAAAACAAAAKwAAAAAAAAAGAAAAAAAAAD8AAAAFAAAACAAAAAYAAAAEAAAAAAAAAMAA AAAIAAAABAAAAAkAAAAEAAAACgAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAOAAAABAAA AA8AAAAEAAAAEAAAAAQAAAARAAAABAAAABIAAAAGAAAAEwAAAAUAAAAUAAAABQAAABUAAAAFAAAA FgAAAAUAAAAXAAAABgAAABgAAAAFAAAAAAAAAAQAAAAaAAAABQAAAIMAC/AwAAAAgQEEAAAIgwEA AAAIhkEAAAAAvwEQABAAwAEBAAAIxUEAAAAA/wEIAAgAAQICAAAIMAAa8QwAAAD/AGYAAAD/AP8A AABAAB7xEAAAAAQAAAgBAAAIAgAACPcAABAfAPAPHAAAAAAA8wMUAAAAAgAAAAAAAAAAAAAAAAAA gAAAAAAPANAHdwEAAB8AFAQcAAAAAAAVBBQAAABGk08JAMqaO/uxdzgAypo7AQEAAA8A+gNnAAAA AAD+AwMAAAAAAQAAAP0DNAAAACUAAABkAAAAJQAAAGQAAAAIAAAAAAAAACC4EwDSQgkwAAAAAAAA AAA+/v//sv///wEAEwBwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8AEwQ8AAAAAAD9 AzQAAABkAAAAZAAAAGQAAABkAAAATLgTAHBDCTCIuRMAABUnBwAAAAAAAAAAAAAAAAAAAAAAARMA HwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8ABwQ8AAAAAAD9AzQAAAAhAAAAZAAAACEAAABk AAAAAgAAAEy4EwBoRwkwiLkTAAAAAAAAAAAAAAAAAAAAAAAAARMADwCIEzgAAAAPAIoTMAAAAAAA ug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAAANBAgAAAAAwAAAAMAAAD8A2Q8MAAAAAADa DwQAAAANACUADwDwD2AtAAAAAPMDFAAAABgAAAAEAAAAAgAAABABAAAAAAAAAACfDwQAAAAAAAAA AACoDzQAAABGcmFuayBDaGFvCwtmY2hhb0BjaXNjby5jb20LC1NhbiBBbnRvbmlvCwsxMS8xNC8y MDA0AAChDxQAAAA1AAAAAAAAAAAANQAAAAAAAgAgAAAAqg9AAAAABgAAAAYAAAAJBAAABAAAAAcA AAADAAkEAAACAAAABgAAAAkEAAAPAAAABwAAAAMACQQAABoAAAAGAAAACQQAABAAnw8EAAAAAQAA AAAAqg8OAAAAAQAAAAcAAAAAAAkEAAAAAPMDFAAAAAMAAAAEAAAAAgAAAAABAAAAAAAAAACfDwQA AAAGAAAAAACqDw4AAAABAAAABwAAAAAACQQAABAAnw8EAAAABQAAAAAAqg8OAAAAAQAAAAcAAAAA AAkEAAAAAPMDFAAAAAkAAAAAAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAAAuMUFF IE1hbmFnZW1lbnQgSW5mbwAAqg8MAAAAFQAAAAYAAAAJBAAAEACfDwQAAAABAAAAAACoDzkBAABM TUkgKExheWVyIE1hbmFnZW1lbnQgSW50ZXJmYWNlKQ1EYXRhIFN0cnVjdHVyZQ1BY2Nlc3NlZCBi eSAuMUFFLCAuMWFmLCBTTk1QL01JQiwgRUFQDUNvbnRhaW5pbmcgLjFBRSBhbmQgLjFhZiBjb25m aWd1cmF0aW9uLCBwcm90b2NvbCBzdGF0ZXMsIGFuZCBjb3VudGVyL2RpYWdub3NpcyBpbmZvcm1h dGlvbi4NLjFBRSB1c2VzIExNSSB0byBjb250cm9sIHRoZSBNQUNzZWMgcGFja2V0IHByb2Nlc3Np bmcgZGlyZWN0bHkgb3IgdGhyb3VnaCBBUElzLg1DaGFuZ2UgdGhlIGRhdGEgaW4gTE1JIG1heSBj YXVzZSBhY3Rpb25zIGluIFNlY1kgb3IgS2FZAAChDzgAAAAhAAAAAAAAEAAAWgAZAQAAAQAAEAAA WgAhAAAAAAAAAA8AAAAABAQAgAT/AGb+CgEAAAAEAACABAAAqg9aAAAAzwAAAAYAAAAJBAAABgAA AAcAAAADAAkEAABZAAAABgAAAAkEAAAEAAAABwAAAAMACQQAAAQAAAAGAAAACQQAAAMAAAAHAAAA AwAJBAAAAQAAAAYAAAAJBAAAAADzAxQAAAAKAAAAAAAAAAIAAAACAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8UAAAALjFBRSBNYW5hZ2VtZW50IEluZm8AAKoPDAAAABUAAAAGAAAACQQAABAAnw8EAAAA AQAAAAAAqA9fAQAATUFDc2VjIE1nbXQgSW5mb3JtYXRpb24NRW5hYmxlL0Rpc2FibGUgKGdsb2Jh bCBjb25maWd1cmF0aW9uKQ1TZWNZIE1nbXQgSW5mb3JtYXRpb24NVGFibGUgaW5kZXhlZCBieSBJ bnRlcmZhY2VJbmRleCAoSUYtTUlCKS4NVmFsaWRhdGVSeEZyYW1lcyA6IGZsYWcgZm9yIHZhbGlk YXRpb24gcHJvY2VzcyBpbiByZWNlaXZpbmcuICgxMC41LjMpDVByb3RlY3RUeEZyYW1lcyA6IGZs YWcgZm9yIHByb3RlY3Rpb24gcHJvY2VzcyBpbiB0cmFuc21pdHRpbmcuDUN1cnJlbnQgQ2lwaGVy IFN1aXRlLiAoMTAuNS40KSAoUm93IFBvaW50ZXIpDWFkbWluUG9pbnRUb1BvaW50TUFDLCBvcGVy UG9pbnRUb1BvaW50TUFDICg2LjUpAAChDwABAAAYAAAAAAAAEAAAWgAmAAAAAQAAEAAAWgAWAAAA AAAAEAAAWgAMAQAAAQAAEAAAWgAYAAAAAAACABwADwAAAAAABAAAAAAGFgAAAAAAAAABAAAAAAAE AAAAAAYWAAAAAAQCAIAEHAARAAAAAAgAAIAIDgAAAAAIBACACAAAAAYLAAAAAAgAAIAIEAAAAAAI BACACAAAAAY2AAAAAAgAAIAIDwAAAAAIBACACAAAAAYwAAAAAAgAAIAIFgAAAAAIBACACAAAAAYX AAAAAAgAAIAIFAAAAAAIBACACAAAAAYCAAAAAAgAAIAIFAAAAAAIBACACAAAAAYGAAAAAAgAAIAI AACqD5wAAAAGAAAABwAAAAMACQQAAF8AAAAGAAAACQQAAA4AAAAHAAAAAwAJBAAACwAAAAYAAAAJ BAAAEAAAAAcAAAADAAkEAAA2AAAABgAAAAkEAAAPAAAABwAAAAMACQQAAF0AAAAGAAAACQQAABQA AAAHAAAAAwAJBAAAAgAAAAYAAAAJBAAAEwAAAAcAAAADAAkEAAAHAAAABgAAAAkEAAAAAPMDFAAA AAsAAAAAAAAAAgAAAAMBAAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAAAuMUFFIE1hbmFnZW1lbnQg SW5mbwAAqg8MAAAAFQAAAAYAAAAJBAAAEACfDwQAAAABAAAAAACoDxoBAABSeFJlcGxheUNoayA6 IGZsYWcgZm9yIHJ4IHJlcGxheSBjaGVjay4gKDEwLjYuMikNVHggU0MgOiB0cmFuc21pdCBTQyBp bmZvcm1haXRvbi4NUnggU0NzIDogcmVjZWl2ZSBTQ3MgaW5mb3JtYWl0b24uICh3aWxsIGJlIGlu IGFub3RoZXIgdGFibGUuKQ1sYXN0VW5rbm93blNDIDogYW4gU0NJIGluZm9ybWF0aW9uIHRvIHJl Y29yZCBsYXN0IHJ4IHVua25vd24gU0MgKDEwLjYuMSkgd2l0aCB0aW1lIHN0YW1wLCBpdCBjb3Vs ZCBiZSBhIGxpc3QgKGEgdGFibGUsIG1heGltdW0gZW50cmllcykgPw0AAKEPMgAAABsBAAABAAAA AAALAAAAAAAEAAAAAAaFAAAAAAAAAA0AAAAAAAQA/wBm/n4AAAAAAAAAAACqD+oAAAALAAAABwAA AAMACQQAAAwAAAAGAAAACQQAAAIAAAAHAAAAAwAJBAAAGAAAAAYAAAAJBAAAAgAAAAcAAAADAAkE AAASAAAABgAAAAkEAAALAAAABwAAAAMACQQAAAUAAAAGAAAACQQAAAMAAAAHAAAAAwAJBAAACwAA AAYAAAAJBAAAAwAAAAcAAAADAAkEAAABAAAABgAAAAkEAAALAAAABwAAAAMACQQAAB4AAAAGAAAA CQQAAA0AAAAHAAAAAwAJBAAAJQAAAAYAAAAJBAAAAgAAAAcAAAADAAkEAABXAAAABgAAAAkEAAAA APMDFAAAAA8AAAAAAAAAAgAAAAcBAAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAAAuMUFFIE1hbmFn ZW1lbnQgSW5mbwAAqg8MAAAAFQAAAAYAAAAJBAAAEACfDwQAAAABAAAAAACoDxQCAABUeCBTQyBN Z210IEluZm9ybWF0aW9uDXNjU3RhdGUgOiBzdGF0ZSBvZiB0aGlzIHRyYW5zbWl0IFNDID8uDXNj Q21kIDogY29tbWFuZCBleGVjdXRpbmcgaW4gdGhlIFNDID8uDVNDSSA6IHRoZSBTQ0kgZm9yIHRo ZSBTQyB1c2VkIGJ5IFNlY1kgZm9yIHRyYW5zbWl0LiAoMTAuNSkNdHhFbmNvZGluZ1NBIDogY3Vy cmVudCBTQSBudW1iZXIuICgxMC41LjEpIChjb3VsZCBiZSBhIFJvd1BvaW50ZXIpDXR4RW5jaXBo ZXJpbmdTQSA6IHByZXZpb3VzIFNBIG51bWJlci4gKDEwLjUuNCkgKGNvdWxkIGJlIGEgUm93UG9p bnRlcikNVHggU0EgOiAodGFibGUgd2l0aCA0IGVudHJpZXMpDVRhYmxlIGluZGV4ZWQgYnkgSW50 ZXJmYWNlSW5kZXggYW5kIEFOLg1zYVN0YXRlIDogc3RhdGUgb2YgdGhpcyB0cmFuc21pdCBTQS4N c2FDbWQgOiBjb21tYW5kIGV4ZWNjdXRpbmcgaW4gdGhlIFNBLg10eFNBSyA6IGtleSBmb3IgdHJh bnNtaXR0aW5nLiAoNy4xLCAxMC41LjEpDXR4TmV4dFBOIDogbmV4dCBwYWNrZXQgbnVtYmVyIChQ TikuICgxMC41LjIpAAChD3IBAAAXAAAAAAAAEAAAUAATAQAAAQAAEAAAUAAfAAAAAAAAEAAAUADM AAAAAQAAEAAAUAAXAAAAAAACABwABwAAAAAABgAYAAAAAAYgAAAAAAACABgABQAAAAAABgAYAAAA AAYiAAAAAAACABgAAwAAAAAABgAYAAAAAAY4AAAAAAACABgADAAAAAAABgAYAAAAAAY3AAAAAAAC ABgADwAAAAAABgAYAAAAAAY4AAAAAAACABgAHwAAAAAEAgCABBwAEQAAAAAIAgCACBgADgAAAAAI BgCACBgAAAAABgUAAAAACAIAgAgYAAIAAAAACAYAgAgYAAAAAAYCAAAAAAgCAIAIGAAHAAAAAAgG AIAIGAAAAAAGHgAAAAAIAgCACBgABQAAAAAIBgCACBgAAAAABiEAAAAACAIAgAgYAAUAAAAACAYA gAgYAAAAAAYnAAAAAAgCAIAIGAAIAAAAAAgGAIAIGAAAAAAGJQAAAAAIAgCACBgAAACqD4YBAAAC AAAABwAAAAMACQQAABUAAAAGAAAACQQAAAcAAAAHAAAAAwAJBAAAIAAAAAYAAAAJBAAABQAAAAcA AAADAAkEAABDAAAABgAAAAkEAAAEAAAABwAAAAMACQQAABYAAAAGAAAACQQAAAwAAAAHAAAAAwAJ BAAAKwAAAAYAAAAJBAAACgAAAAcAAAADAAkEAAACAAAABgAAAAkEAAAPAAAABwAAAAMACQQAACwA AAAGAAAACQQAAAoAAAAHAAAAAwAJBAAAAgAAAAYAAAAJBAAAAgAAAAcAAAADAAkEAAAuAAAABgAA AAkEAAAOAAAABwAAAAMACQQAAAkAAAAGAAAACQQAAAcAAAAHAAAAAwAJBAAAHgAAAAYAAAAJBAAA BQAAAAcAAAADAAkEAAALAAAABgAAAAkEAAAKAAAABwAAAAMACQQAAAwAAAAGAAAACQQAAAUAAAAH AAAAAwAJBAAAJwAAAAYAAAAJBAAACAAAAAcAAAADAAkEAAAlAAAABgAAAAkEAAAAAPMDFAAAABAA AAAAAAAAAgAAAAgBAAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAAAuMUFFIE1hbmFnZW1lbnQgSW5m bwAAqg8MAAAAFQAAAAYAAAAJBAAAEACfDwQAAAABAAAAAACoD3ABAABSeCBTQ3MgTWdtdCBJbmZv cm1hdGlvbg1UYWJsZSBpbmRleGVkIGJ5IEludGVyZmFjZUluZGV4IGFuZCBTQ0kuDXNjU3RhdGUg OiBzdGF0ZSBvZiB0aGlzIHRyYW5zbWl0IFNDID8uDXNjQ21kIDogY29tbWFuZCBleGVjdXRpbmcg aW4gdGhlIFNDID8uDVNDSSA6IHRoZSBTQ0kgZm9yIHRoZSBTQyB1c2VkIGJ5IFNlY1kgZm9yIHRy YW5zbWl0LiAoMTAuNSkNcnhDdXJyZW50U0EgOiBjdXJyZW50IHVzaW5nIFNBIG51bWJlciBpbiB0 aGUgU0MuICgxMC42LjEpIChSb3dQb2ludGVyKQ1sYXN0Tm90SW5Vc2VBbiA6IGxhc3QgTm90LWlu LVVzZSBBTiB3aXRoIHRpbWVzdGFtcC4gKDEwLjYuMSkgYSBsaXN0IChhIHRhYmxlLCBtYXhpbXVt IGVudHJpZXMpPwAAoQ/SAAAAGAAAAAAAAAAAAFkBAAABAAAAAAAYAAAAAAACABwAEAAAAAAEAgCA BBgAEAAAAAAEBgCABBgAAAAABgMAAAAABAIAgAQYAA0AAAAABAYAgAQYAAAAAAYgAAAAAAQCAIAE GAAFAAAAAAQGAIAEGAAAAAAGIgAAAAAEAgCABBgAAwAAAAAEBgCABBgAAAAABjgAAAAABAIAgAQY AAsAAAAABAYAgAQYAAAAAAY8AAAAAAQCAIAEGAAOAAAAAAQGAIAEGAD/AGb+UgAAAAAEAgCABBgA AACqD9wAAAADAAAABgAAAAkEAAADAAAABwAAAAMACQQAACMAAAAGAAAACQQAAA4AAAAHAAAAAwAJ BAAACgAAAAYAAAAJBAAABwAAAAcAAAADAAkEAAAgAAAABgAAAAkEAAAFAAAABwAAAAMACQQAAEMA AAAGAAAACQQAAAQAAAAHAAAAAwAJBAAAFgAAAAYAAAAJBAAACwAAAAcAAAADAAkEAAAwAAAABgAA AAkEAAAKAAAABwAAAAMACQQAAAIAAAAGAAAACQQAAA4AAAAHAAAAAwAJBAAAUgAAAAYAAAAJBAAA AADzAxQAAAARAAAAAAAAAAIAAAAJAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8UAAAALjFBRSBNYW5h Z2VtZW50IEluZm8AAKoPDAAAABUAAAAGAAAACQQAABAAnw8EAAAAAQAAAAAAqA8rAQAAUnggU0Eg TWdtdCBJbmZvcm1hdGlvbg1UYWJsZSBpbmRleGVkIGJ5IEludGVyZmFjZUluZGV4IGFuZCBTQ0kg YW5kIEFOLg1zYVN0YXRlIDogc3RhdGUgb2YgdGhpcyByZWNlaXZlIFNBLg1zYUNtZCA6IGNvbW1h bmQgZXhjZWN1dGluZyBpbiB0aGUgU0EuDXJ4U0FLIDoga2V5IGZvciB0cmFuc21pdHRpbmcuICg3 LjEsIDEwLjYuMSkNcnhMYXN0UE4gOiBsYXN0IHJlY2VpdmVkIHBhY2tldCBudW1iZXIgKFBOKS4g KDEwLjYuMikNcnhMYXN0VmFsaWRhdGVkUE4gOiBsYXN0IHJlY2VpdmVkIHZhbGlkYXRlZCBQTi4g KDEwLjYuMikAAKEP4gAAABcAAAAAAAAQAABaADAAAAABAAAQAABaAOUAAAABACAQAAAAAAABWgAX AAAAAAAAABAAAAAABAAAgAQQAAAAAAQEAIAEAAAABgMAAAAABAAAgAQFAAAAAAQEAIAEAAAABgMA AAAABAAAgAQMAAAAAAQEAIAEAAAABh0AAAAABAAAgAQFAAAAAAQEAIAEAAAABiEAAAAABAAAgAQF AAAAAAQEAIAEAAAABicAAAAABAAAgAQIAAAAAAQEAIAEAAAABi4AAAAABAAAgAQRAAAAAAQEAIAE AAAABigAAAAABAAAgAQAAKoPQAAAACgAAAAGAAAACQQAAA4AAAAHAAAAAwAJBAAAEQAAAAYAAAAJ BAAABwAAAAcAAAADAAkEAADeAAAABgAAAAkEAAAAAPMDFAAAABIAAAAAAAAAAgAAAAoBAAAAAAAA AACfDwQAAAAAAAAAAACoDxQAAAAuMUFFIE1hbmFnZW1lbnQgSW5mbwAAqg8MAAAAFQAAAAYAAAAJ BAAAEACfDwQAAAABAAAAAACoD8QAAABDaXBoZXIgU3VpdGVzIDoNTmFtZSA6IG5hbWUgb2YgdGhp cyBjaXBoZXIgc3VpdGUsIGNvdWxkIGJlIE1JQiB0YWJsZSBpbmRleC4NQ29uZmlkZW50aWFsaXR5 IDogZmxhZyBpbmRpY2F0ZSB0aGUgY2lwaGVyIHN1aXRlIHdpdGggY29uZmlkZW50aWFsaXR5IGFi aWxpdHkuDUlDViBsZW5ndGggOiB0aGUgbGVuZ3RoIG9mIGdlbmVyYXRlZCBJQ1YuAAChD2QAAAAQ AAAAAAAAAAAAtQAAAAEAAAAAABAAAAAAAAAABAAAAAAEBACABAAAAAY4AAAAAAQAAIAEDwAAAAAE BACABAAAAAZAAAAAAAQAAIAECgAAAAAEBACABAAAAAYgAAAAAAQAAIAEAACqDwwAAADFAAAABgAA AAkEAAAAAPMDFAAAABMAAAAEAAAAAgAAAAsBAAAAAAAAAACfDwQAAAAAAAAAAACqDw4AAAABAAAA BwAAAAAACQQAABAAnw8EAAAAAQAAAAAAqg8OAAAAAQAAAAcAAAAAAAkEAAAAAPMDFAAAABQAAAAA AAAAAgAAAAwBAAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAAAuMUFFIE1hbmFnZW1lbnQgSW5mbwAA qg8MAAAAFQAAAAYAAAAJBAAAEACfDwQAAAABAAAAAACoDwABAABTQyBSeCBjb3VudGVycyA6DUlu ZGV4ZWQgYnkgSW50ZXJmYWNlSW5kZXggYW5kIFNDSQ1JblhjYXN0UGt0c05vdFJlY2VpdmVkDUlu WGNhc3RQa3RzSW52YWxpZA1JblhjYXN0UGt0c1JlcGxheWVkDUluWGNhc3RQa3RzTWlzb3JkZXJl ZA1JblhjYXN0UGt0c09yZGVyZWQNSW5YY2FzdFBrdHNFbmNyeXB0ZWQNSW5YY2FzdFBrdHNEZWNy eXB0ZWQNSW5YY2FzdE9jdGV0c0VuY3J5cHRlZCAoTVNEVSkNSW5YY2FzdE9jdGV0c0RlY3J5cHRl ZCAoTVNEVSkNAAChD4IAAAARAAAAAAAAAAAA7wAAAAEAAAAAAAEAAAABAAEAAAAAABEAAAAAAAIA HAALAAAAAAQCAIAEGAAOAAAAAAQGAIAEGAAAAAAGBQAAAAAEAgCABBgABAAAAAAEBgCABBgAAAAA BlQAAAAABAYAgAQUAP8AZv56AAAAAAQGAIAEFAAAAP/+AACqDxABAAAcAAAABgAAAAkEAAAOAAAA BwAAAAMACQQAAAkAAAAGAAAACQQAABYAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAEgAAAAcAAAAD AAkEAAABAAAABgAAAAkEAAATAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABUAAAAHAAAAAwAJBAAA AQAAAAYAAAAJBAAAEgAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAUAAAABwAAAAMACQQAAAEAAAAG AAAACQQAABQAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFgAAAAcAAAADAAkEAAAIAAAABgAAAAkE AAAWAAAABwAAAAMACQQAAAkAAAAGAAAACQQAAAAA8wMUAAAAFQAAAAAAAAACAAAADQEAAAAAAAAA AJ8PBAAAAAAAAAAAAKgPFAAAAC4xQUUgTWFuYWdlbWVudCBJbmZvAACqDwwAAAAVAAAABgAAAAkE AAAQAJ8PBAAAAAEAAAAAAKgPYQEAAFNlY1kgUnggQ291bnRlcnMgOg1UYWJsZSBJbmRleGVkIGJ5 IEludGVyZmFjZUluZGV4DUluWGNhc3RQa3RzTm9UYWcNSW5YY2FzdFBrdHNCYWRUYWcNSW5YY2Fz dFBrdHNVbmtub3duU0NJDUluWGNhc3RQa3RzVW50YWdnZWQNSW5YY2FzdFBrdHNVbmNoZWNrZWQN SW5YY2FzdFBrdHNOb3RSZWNlaXZlZA1JblhjYXN0UGt0c0ludmFsaWQNSW5YY2FzdFBrdHNSZXBs YXllZA1JblhjYXN0UGt0c01pc29yZGVyZWQNSW5YY2FzdFBrdHNPcmRlcmVkDUluWGNhc3RQa3Rz RW5jcnlwdGVkDUluWGNhc3RQa3RzRGVjcnlwdGVkDUluWGNhc3RPY3RldHNFbmNyeXB0ZWQgKE1T RFUpDUluWGNhc3RPY3RldHNEZWNyeXB0ZWQgKE1TRFUpAAChD14AAAATAAAAAAAAEAAAUABPAQAA AQAAEAAAUAATAAAAAAACABwAEQAAAAAEAgCABBgADwAAAAAEBgCABBgAAAAABrYAAAAABAYAgAQU AP8AZv55AAAAAAQGAIAEFAAAAP/+AACqD6ABAAAEAAAABwAAAAMACQQAACAAAAAGAAAACQQAAA4A AAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAEAAAAAcAAAADAAkEAAABAAAABgAAAAkEAAARAAAABwAA AAMACQQAAAEAAAAGAAAACQQAABUAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAEwAAAAcAAAADAAkE AAABAAAABgAAAAkEAAAUAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABYAAAAHAAAAAwAJBAAAAQAA AAYAAAAJBAAAEgAAAAcAAAADAAkEAAABAAAABgAAAAkEAAATAAAABwAAAAMACQQAAAEAAAAGAAAA CQQAABUAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAEgAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAU AAAABwAAAAMACQQAAAEAAAAGAAAACQQAABQAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFgAAAAcA AAADAAkEAAAIAAAABgAAAAkEAAAWAAAABwAAAAMACQQAAAgAAAAGAAAACQQAAAAA8wMUAAAAFwAA AAAAAAACAAAADwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFAAAAC4xQUUgTWFuYWdlbWVudCBJbmZv AACqDwwAAAAVAAAABgAAAAkEAAAQAJ8PBAAAAAEAAAAAAKAPCAIAAFMAQQAgAFQAeAAgAGMAbwB1 AG4AdABlAHIAcwAgADoADQBUAGEAYgBsAGUAIABpAG4AZABlAHgAZQBkACAAYgB5ACAASQBuAHQA ZQByAGYAYQBjAGUASQBuAGQAZQB4ACAAYQBuAGQAIABBAE4ADQBPAHUAdABDAG4AdABSAGUAaQBu AGkAdABUAGkAbQBlACAAOgAgAEEAIAB0AGkAbQBlAHMAdABhAG0AcAAgAGYAbwByACAAdABoAGUA IABjAG8AdQBuAHQAZQByAHMAGSAgAGQAaQBzAGMAbwBuAHQAaQBuAHUAaQB0AHkAIABpAG4AIAB0 AGgAaQBzACAAUwBBAC4ADQBPAHUAdABQAGsAdABzAFAAbgBFAHgAaABhAHUAcwB0AGUAZAANAE8A dQB0AFAAawB0AHMAVABvAG8AbABvAG4AZwANAE8AdQB0AFgAYwBhAHMAdABQAGsAdABzAFAAcgBv AHQAZQBjAHQAZQBkAA0ATwB1AHQAWABjAGEAcwB0AFAAawB0AHMAVQBuAHQAYQBnAGcAZQBkAA0A TwB1AHQAWABjAGEAcwB0AFAAawB0AHMARQBuAGMAcgB5AHAAdABlAGQADQBPAHUAdABYAGMAYQBz AHQATwBjAHQAZQB0AHMARQBuAGMAcgB5AHAAdABlAGQAIAAoAE0AUwBEAFUAKQAAAKEPmgAAABEA AAAAAAAAAAD0AAAAAQAAAAAAEQAAAAAAAgAcABEAAAAABAIAgAQYAA4AAAAABAYAgAQYAAAAAAYF AAAAAAQCAIAEGAATAAAAAAQGAIAEGAAAAAAGAwAAAAAEAgCABBgANwAAAAAEAgCABBQAAQAAAAAE AgCABBgATQAAAAAEBgCABBgA/wBm/jUAAAAABAYAgAQYAAAA//4AAKoP9gAAAAMAAAAGAAAACQQA AAIAAAAHAAAAAwAJBAAAHQAAAAYAAAAJBAAADgAAAAcAAAADAAkEAAAIAAAABgAAAAkEAAAQAAAA BwAAAAMACQQAADsAAAAGAAAACQQAABIAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAADgAAAAcAAAAD AAkEAAABAAAABgAAAAkEAAAVAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABQAAAAHAAAAAwAJBAAA AQAAAAYAAAAJBAAAFQAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAXAAAABwAAAAMACQQAAAgAAAAG AAAACQQAAAAA8wMUAAAAFgAAAAAAAAACAAAADgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFAAAAC4x QUUgTWFuYWdlbWVudCBJbmZvAACqDwwAAAAVAAAABgAAAAkEAAAQAJ8PBAAAAAEAAAAAAKgPtgAA AFNlY1kgVHggQ291bnRlcnMgOg1UYWJsZSBpbmRleGVkIGJ5IEludGVyZmFjZUluZGV4DU91dFBr dHNQbkV4aGF1c3RlZA1PdXRQa3RzVG9vbG9uZw1PdXRYY2FzdFBrdHNQcm90ZWN0ZWQNT3V0WGNh c3RQa3RzVW50YWdnZWQNT3V0WGNhc3RQa3RzRW5jcnlwdGVkDU91dFhjYXN0T2N0ZXRzRW5jcnlw dGVkIChNU0RVKQ0NAAChD1AAAAATAAAAAAAAAAAApAAAAAEAAAAAABMAAAAAAAAAEQAAAAAEAACA BA8AAAAABAQAgAQAAAAGTQAAAAAEBACABP8AZv43AAAAAAQEAIAEAAD//gAAqg/qAAAABAAAAAcA AAADAAkEAAABAAAABgAAAAkEAAACAAAABwAAAAMACQQAAB0AAAAGAAAACQQAAA4AAAAHAAAAAwAJ BAAAAQAAAAYAAAAJBAAAEgAAAAcAAAADAAkEAAABAAAABgAAAAkEAAAOAAAABwAAAAMACQQAAAEA AAAGAAAACQQAABUAAAAHAAAAAwAJBAAAAQAAAAYAAAAJBAAAFAAAAAcAAAADAAkEAAABAAAABgAA AAkEAAAVAAAABwAAAAMACQQAAAEAAAAGAAAACQQAABcAAAAHAAAAAwAJBAAACgAAAAYAAAAJBAAA AADzAxQAAAAZAAAAAAAAAAIAAAARAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8UAAAALjFBRSBNYW5h Z2VtZW50IEluZm8AAKoPDAAAABUAAAAGAAAACQQAABAAnw8EAAAAAQAAAAAAqA+5AwAAUkZDMjg2 MyA6IEludGVyZmFjZSBNSUIgY291bnRlcnMNICAgICAJCWlmSW5PY3RldHOgoKCgoKCgoKCgoKCg IENvdW50ZXIzMiwLoKCgoKCgoKAgaWZJblVjYXN0UGt0c6CgoKCgoKCgoKAgQ291bnRlcjMyLAug oKCgoKCgoCBpZkluRGlzY2FyZHOgoKCgoKCgoKCgoCBDb3VudGVyMzIsC6CgoKCgoKCgIGlmSW5F cnJvcnOgoKCgoKCgoKCgoKCgIENvdW50ZXIzMiwLoKCgoKCgoKAgaWZJblVua25vd25Qcm90b3Og oKCgoKAgQ291bnRlcjMyLAugoKCgoKCgoCBpZk91dE9jdGV0c6CgoKCgoKCgoKCgoCBDb3VudGVy MzIsC6CgoKCgoKCgIGlmT3V0VWNhc3RQa3RzoKCgoKCgoKCgIENvdW50ZXIzMiwLoKCgoKCgoKAg aWZPdXREaXNjYXJkc6CgoKCgoKCgoKAgQ291bnRlcjMyLAugoKCgoKCgoCBpZk91dEVycm9yc6Cg oKCgoKCgoKCgoCBDb3VudGVyMzIsC6CgoKCgoKCgIGlmSW5NdWx0aWNhc3RQa3RzoKCgoKCgIENv dW50ZXIzMiwLoKCgoKCgoKAgaWZJbkJyb2FkY2FzdFBrdHOgoKCgoKAgQ291bnRlcjMyLAugoKCg oKCgoCBpZk91dE11bHRpY2FzdFBrdHOgoKCgoCBDb3VudGVyMzIsC6CgoKCgoKCgIGlmT3V0QnJv YWRjYXN0UGt0c6CgoKCgIENvdW50ZXIzMiwLoKCgoKCgoKAgaWZIQ0luT2N0ZXRzoKCgoKCgoKCg oKAgQ291bnRlcjY0LAugoKCgoKCgoCBpZkhDSW5VY2FzdFBrdHOgoKCgoKCgoCBDb3VudGVyNjQs C6CgoKCgoKCgIGlmSENJbk11bHRpY2FzdFBrdHOgoKCgIENvdW50ZXI2NCwLoKCgoKCgoKAgaWZI Q0luQnJvYWRjYXN0UGt0c6CgoKAgQ291bnRlcjY0LAugoKCgoKCgoCBpZkhDT3V0T2N0ZXRzoKCg oKCgoKCgoCBDb3VudGVyNjQsC6CgoKCgoKCgIGlmSENPdXRVY2FzdFBrdHOgoKCgoKCgIENvdW50 ZXI2NCwLoKCgoKCgoKAgaWZIQ091dE11bHRpY2FzdFBrdHOgoKAgQ291bnRlcjY0LAugoKCgoKCg oCBpZkhDT3V0QnJvYWRjYXN0UGt0c6CgoCBDb3VudGVyNjQAAKEPJAAAACEAAAAAAAAQAABQAJkD AAAAAAEQAAAAAFAAugMAAAAAAgASAAAAqg8uAgAAKAAAAAYAAAAJBAAACgAAAAcAAAADAAkEAAAi AAAABgAAAAkEAAANAAAABwAAAAMACQQAAB8AAAAGAAAACQQAAAwAAAAHAAAAAwAJBAAAIAAAAAYA AAAJBAAACgAAAAcAAAADAAkEAAAiAAAABgAAAAkEAAARAAAABwAAAAMACQQAABsAAAAGAAAACQQA AAsAAAAHAAAAAwAJBAAAIQAAAAYAAAAJBAAADgAAAAcAAAADAAkEAAAeAAAABgAAAAkEAAANAAAA BwAAAAMACQQAAB8AAAAGAAAACQQAAAsAAAAHAAAAAwAJBAAAIQAAAAYAAAAJBAAAEQAAAAcAAAAD AAkEAAAbAAAABgAAAAkEAAARAAAABwAAAAMACQQAABsAAAAGAAAACQQAABIAAAAHAAAAAwAJBAAA GgAAAAYAAAAJBAAAEgAAAAcAAAADAAkEAAAaAAAABgAAAAkEAAAMAAAABwAAAAMACQQAACAAAAAG AAAACQQAAA8AAAAHAAAAAwAJBAAAHQAAAAYAAAAJBAAAEwAAAAcAAAADAAkEAAAZAAAABgAAAAkE AAATAAAABwAAAAMACQQAABkAAAAGAAAACQQAAA0AAAAHAAAAAwAJBAAAHwAAAAYAAAAJBAAAEAAA AAcAAAADAAkEAAAcAAAABgAAAAkEAAAUAAAABwAAAAMACQQAABgAAAAGAAAACQQAABQAAAAHAAAA AwAJBAAADgAAAAYAAAAJBAAAAADzAxQAAAAaAAAAAAAAAAIAAAASAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8UAAAALjFBRSBNYW5hZ2VtZW50IEluZm8AAKoPDAAAABUAAAAGAAAACQQAABAAnw8EAAAA AQAAAAAAqA+rAAAATUlCIERlc2lnbg1XaWxsIGZvbGxvdyB0aGUgTUlCLVJFVklFVy1HVUlERUxJ TkVTLCBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9wcy1t aWItcmV2aWV3LWd1aWRlbGluZXMtMDMudHh0LCB2YWxpZCB0byBEZWMuIDIwMDQuDVNOTVB2MyBh Y2Nlc3Mgb25seSA/AAChDyYAAAALAAAAAAAAAAAAoQAAAAEAAAAAAAsAAAAAAAAAoQAAAAAEAACA BAAAqg8+AAAAMgAAAAYAAAAJBAAATwAAAAYAAAAJBAAAKQAAAAYAAAAJBAAAAQAAAAcAAAAAAAkE AAABAAAABgAAAAkEAAAPAPIPGAAAAAAA8w8QAAAAAAAAAAMAAAAEAAAACGQKMAAA3w8IAAAAMgAA AIEAAAAvAPAPHAAAAAAA8wMUAAAABwAAAAAAAAAAAAAAAAEAAAAAAAAAAOoDAAAAAAAAchcIAAAA AQAQAGYjAQAAAPUPHAAAAAAAAABlGQADQiMBACFXAQABAAAAGgAAAA8AnwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_02E2_01C4CCAC.C3230570 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib ------=_NextPart_000_02E2_01C4CCAC.C3230570-- From bridge-mib-bounces@ietf.org Thu Nov 18 13:07:41 2004 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 NAA17567 for ; Thu, 18 Nov 2004 13:07:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUqjl-0007lc-I1 for bridge-mib-archive@ietf.org; Thu, 18 Nov 2004 13:10:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUqUu-0004Tm-NH; Thu, 18 Nov 2004 12:55:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUqPf-00031D-K7 for bridge-mib@megatron.ietf.org; Thu, 18 Nov 2004 12:49:43 -0500 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 MAA16067 for ; Thu, 18 Nov 2004 12:49:39 -0500 (EST) Message-Id: <200411181749.MAA16067@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUqSI-0007GC-5M for bridge-mib@ietf.org; Thu, 18 Nov 2004 12:52:28 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc11) with SMTP id <2004111817490901100otivhe>; Thu, 18 Nov 2004 17:49:09 +0000 From: "David B Harrington" To: Date: Thu, 18 Nov 2004 12:49:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcTMzSobN3CZslaPQTyFbuMi0xouRgAyTipw X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] FW: [802.1] 802.1 PARs X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit FYI. There are three PARs being considered in IEEE 802.1 The first will definitely use a MIB. The second will either use a MIB directly, or indirectly. I'm not sure if the third PAR plans to develop a MIB a not. The appropriate mailing list for IEEE 802.1 mib module discussion is STDS-802-1-L@listserv.ieee.org. To subscribe to the STDS-802-1-L list, go to http://www.ieee802.org/1/email-pages/ To see the general information about 802,1, including how they work and how to participate, go to http://www.ieee802.org/1/ To see presentations on the technology, go to http://www.ieee802.org/1/files/public/docs2004 David Harrington dbharrington@comcast.net co-chair, IETF Bridge WG ________________________________ From: IEEE 802.1 [mailto:hdk-0316.pflrk@att.net] On Behalf Of Tony Jeffree Sent: Wednesday, November 17, 2004 12:44 PM To: STDS-802-1-L@listserv.ieee.org Subject: [802.1] 802.1 PARs I have uploaded revised versions of the 3 802.1 proposed PARs, with changes made in resolution of comments received. PLEASE NOTE that in response to Pat Thaler's comment that accepted practice avoids the use if "i" in project numbering, the P802.1ai PAR has been renumbered as p802.1ak. The 5c's are unchanged, with the exception of the p802.1ai 5c which has been relabeled as p802.1ak. The files for the revised PARs and 5Cs are located here: http://www.ieee802.org/1/files/public/docs2004/802-1ah-draft-par-for-3 0-day-rule-revised.htm http://www.ieee802.org/1/files/public/docs2004/802-1ah-5c.pdf http://www.ieee802.org/1/files/public/docs2004/802-1aj-draft-par-for-3 0-day-rule-revised.htm http://www.ieee802.org/1/files/public/docs2004/802-1-aj-5c.pdf http://www.ieee802.org/1/files/public/docs2004/802-1ak-draft-par-for-3 0-day-rule-revised.htm http://www.ieee802.org/1/files/public/docs2004/802-1ak-5c.pdf Regards, Tony IEEE 802.1 list info: http://www.ieee802.org/1/email-pages/sjqnf904.html _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 18 17:05:42 2004 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 RAA23240; Thu, 18 Nov 2004 17:05:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUuS8-0000Fh-2k; Thu, 18 Nov 2004 17:08:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUuAO-0001Tp-Jx; Thu, 18 Nov 2004 16:50:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUtxH-0002oT-UM for bridge-mib@megatron.ietf.org; Thu, 18 Nov 2004 16:36:39 -0500 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 QAA18482 for ; Thu, 18 Nov 2004 16:36:37 -0500 (EST) Message-Id: <200411182136.QAA18482@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUtzy-0007VB-Fi for bridge-mib@ietf.org; Thu, 18 Nov 2004 16:39:27 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc11) with SMTP id <2004111821360701100opr1fe>; Thu, 18 Nov 2004 21:36:07 +0000 From: "David B Harrington" To: Date: Thu, 18 Nov 2004 16:36:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcTNtprTmotccm0ZSCGD3+e4KAKEVQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] archives X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit FYI. The HTML archive has been corrected and should now be up-to-date. http://www1.ietf.org/mail-archive/web/bridge-mib/current/index.html Let me know if you have any problems with the archive. David Harrington dbharrington@comcast.net co-chair, IETF Bridge WG _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Nov 18 20:58:23 2004 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 UAA16517; Thu, 18 Nov 2004 20:58:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUy5L-0005ro-JH; Thu, 18 Nov 2004 21:01:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUxwA-0001gt-1b; Thu, 18 Nov 2004 20:51:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUxul-0001Sd-CJ; Thu, 18 Nov 2004 20:50:19 -0500 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 UAA15941; Thu, 18 Nov 2004 20:50:17 -0500 (EST) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUxxU-0005hj-Nm; Thu, 18 Nov 2004 20:53:09 -0500 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 iAJ1mOZ4001582; Thu, 18 Nov 2004 20:48:24 -0500 (EST) 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 iAJ1mMZ4001557; Thu, 18 Nov 2004 20:48:23 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Bridge-mib] FW: [802.1] 802.1 PARs Date: Fri, 19 Nov 2004 03:50:14 +0200 Message-ID: Thread-Topic: [Bridge-mib] FW: [802.1] 802.1 PARs Thread-Index: AcTMzSobN3CZslaPQTyFbuMi0xouRgAyTipwABCOz0A= From: "Romascanu, Dan \(Dan\)" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable Cc: hubmib@ietf.org, STDS-802-1-L@listserv.ieee.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable My understanding from the discussions at the 802.1 Plenary session this = week is that all 802.1 projects will include the definition of the = management model, management objects, and an SMIv2 MIB definition = wherever applicable - even if this is not explicitly mentioned in the = PAR. My understanding is that all the three projects whose PARs is being = discussed now will have such MIB modules defined.=20 - 802.1aj may extend the 802.3ae OAM. If so, it may need at least an = extension of the EFM OAM MIB defined now in hubmib. They also are = talking about some kind of agent-sub-agent model, possibly using the = extensions of the OAM protocol - 802.1ak looks like will need to extend the son-of-2674 MIB for MRP = operation Regards, Dan > -----Original Message----- > From: bridge-mib-bounces@ietf.org=20 > [mailto:bridge-mib-bounces@ietf.org]On Behalf Of David B Harrington > Sent: 18 November, 2004 7:49 PM > To: bridge-mib@ietf.org > Subject: [Bridge-mib] FW: [802.1] 802.1 PARs >=20 >=20 > FYI.=20 >=20 > There are three PARs being considered in IEEE 802.1 > The first will definitely use a MIB. > The second will either use a MIB directly, or indirectly. > I'm not sure if the third PAR plans to develop a MIB a not. > =20 > The appropriate mailing list for IEEE 802.1 mib module discussion is > STDS-802-1-L@listserv.ieee.org. > To subscribe to the STDS-802-1-L list, go to > http://www.ieee802.org/1/email-pages/ > To see the general information about 802,1, including how they work > and how to participate, go to http://www.ieee802.org/1/ > To see presentations on the technology, go to > http://www.ieee802.org/1/files/public/docs2004 > =20 >=20 > David Harrington > dbharrington@comcast.net > co-chair, IETF Bridge WG > =20 > ________________________________ >=20 > From: IEEE 802.1 [mailto:hdk-0316.pflrk@att.net] On Behalf Of > Tony Jeffree > Sent: Wednesday, November 17, 2004 12:44 PM > To: STDS-802-1-L@listserv.ieee.org > Subject: [802.1] 802.1 PARs > =09 > =09 > I have uploaded revised versions of the 3 802.1 proposed PARs, > with changes made in resolution of comments received.=20 > =09 > PLEASE NOTE that in response to Pat Thaler's comment that > accepted practice avoids the use if "i" in project numbering, the > P802.1ai PAR has been renumbered as p802.1ak. > =09 > The 5c's are unchanged, with the exception of the p802.1ai 5c > which has been relabeled as p802.1ak. > =09 > The files for the revised PARs and 5Cs are located here: > =09 > =09 > http://www.ieee802.org/1/files/public/docs2004/802-1ah-draft-par-for-3 > 0-day-rule-revised.htm > http://www.ieee802.org/1/files/public/docs2004/802-1ah-5c.pdf > =09 > =09 > http://www.ieee802.org/1/files/public/docs2004/802-1aj-draft-par-for-3 > 0-day-rule-revised.htm > =09 > 30-day-rule-revised.htm> > http://www.ieee802.org/1/files/public/docs2004/802-1-aj-5c.pdf > =09 > =09 > > http://www.ieee802.org/1/files/public/docs2004/802-1ak-draft-par-for-3 > 0-day-rule-revised.htm > http://www.ieee802.org/1/files/public/docs2004/802-1ak-5c.pdf > =09 > =09 >=20 > Regards, > Tony > IEEE 802.1 list info: > http://www.ieee802.org/1/email-pages/sjqnf904.html=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Bridge-mib mailing list > Bridge-mib@ietf.org > https://www1.ietf.org/mailman/listinfo/bridge-mib >=20 _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Fri Nov 19 21:51:08 2004 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 VAA21636; Fri, 19 Nov 2004 21:51:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVLO9-0000pl-Bm; Fri, 19 Nov 2004 21:54:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVLJA-00052L-R6; Fri, 19 Nov 2004 21:49:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVLFE-0003YT-Qa for bridge-mib@megatron.ietf.org; Fri, 19 Nov 2004 21:45:00 -0500 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 VAA21067 for ; Fri, 19 Nov 2004 21:44:58 -0500 (EST) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVLIA-0000iG-Va for bridge-mib@ietf.org; Fri, 19 Nov 2004 21:48:03 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel10.hp.com (Postfix) with ESMTP id CF5F773A2D for ; Fri, 19 Nov 2004 18:44:57 -0800 (PST) Received: from [127.0.0.1] (ros54018lap.americas.hpqcorp.net [15.255.5.65]) by rosemail.rose.hp.com (Postfix) with ESMTP id 62DB48420; Fri, 19 Nov 2004 18:44:57 -0800 (PST) Message-ID: <419EAE82.8010707@hp.com> Date: Fri, 19 Nov 2004 18:40:02 -0800 From: John Flick User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bridge-mib@ietf.org Subject: Re: [Bridge-mib] WG Last Call:dratf-ietf-bridge-ext-v2-03.txt References: <200411031734.MAA00472@ietf.org> In-Reply-To: <200411031734.MAA00472@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: 7bit Cc: "Congdon, Paul T" X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: 7bit Hi, I have the following comments on this draft. I have divided my comments into introductory text, P-BRIDGE-MIB, and Q-BRIDGE-MIB. Introductory text comments: 1. Throughout the document, references to 802.1D-1998 should be updated to refer to 802.1D-2004. 2. References to RFC 1493 should refer to the updated version in draft-ietf-bridge-bridgemib-smiv2-07.txt. 3. Separate references to 802.1t are unnecessary, as .1t is now included in D-2004. 4. Separate references to 802.1u and 802.1v are unnecessary, as they are included in 802.1Q-2003. (Note, I realize we are just trying to ship what we have and let IEEE deal with maintaining this, but it does seem unwise to approve a document for the IETF standards track that references obsolete versions of an IEEE specification, or that references an RFC that we are about to obsolete.) 5. The RFC editor does not allow references in the Abstract. (Again, I realize the goal is to just ship it, but the RFC Editor will not publish this as is.) 6. In Section 2, the following sentence: "IEEE 802.1Q defined port-based Virtual LANs where membership is determined by the bridge port on which data frames are received" should be updated for protocol VLANs. 7. Section 2.1 begins with "This MIB includes...". This should be replaced with "This document includes" or "The MIB modules defined in this document include" 8. In the Historical note in 2.1, bullet 4 says "Limit the total of objects.", which should probably be "Limit the total number of objects." 9. I'm not sure what we should do with section 3.1.1, since 802.1D-2004 no longer defines the managed objects that we refer to here. 10. Section 3.3, first paragraph seems like an archaic leftover from SMIv1. Do we really need to define what a T-C is here? End of second paragraph talks about PIB modules, which I thought were dead. 11. Section 3.4 and 3.4.1 refer to MIB-II and RFC 1213 for the system group. Shouldn't we be referring to RFC 3418 for the system group? 12. In section 3.4.2.1, second paragraph, the recommendation that VLANs are not represented in the ifTable conflicts with SMON. Not sure what to do about this one, and I'm not sure IEEE is the right place to deal with it. 13. Much of the text in section 3.4.3 is about to be rendered obsolete by draft-ietf-bridge-bridgemib-smiv2-07.txt. P-BRIDGE-MIB comments: 1. There are several problems with the MODULE-IDENTITY: - LAST-UPDATED and REVISION dates need updating - Need to keep the original REVISION clause from 2674 and just add another revision for this version - DESCRIPTION needs the required copyright boilerplate - REVISION DESCRIPTION needs to identify changes made to this module since 2674 (one of Bert's favorite IESG Discusses...) - CONTACT-INFO normally has editor's contact info 2. REFERENCE clauses should point to currently published IEEE document, not to an old IEEE draft. 3. Several formatting oopses throughout See dot1dPortPriorityT able for an example. There were more spurious line feeds like this scattered throughout the document. 4. Description of dot1dPortOutboundAccessPriority seems wrong - outbound definition talks about received frame instead of transmitted frame. 5. pBridgePortGmrpGroup adds a new object to an existing group from 2674, which is forbidden by the SMI. We will need to deprecate the existing group and define a new group that includes the new object. Note that this will also mean defining a new MODULE-COMPLIANCE that includes the new group. Q-BRIDGE-MIB comments: 1. MODULE-IDENTITY has the same problems listed above. 2. VlanIdOrAny, VlanIdOrNone, VlanIdOrAnyOrNone: The statement in section 3.3 that says: "Notre that a MIB object that is defined using one of these textual conventions should clarify the meaning of 'any VLAN' and/or 'no VLAN' in its DESCRIPTION clause." should be included in the DESCRIPTION clauses of these T-Cs. 3. dot1qForwardAllStaticPorts description talks about non-EFS behaviour, but the acronym EFS has not been defined, and does not appear anywhere else in this document. 4. The description of dot1qPortAcceptableFrameTypes is no longer accurate with protocol VLANs. 5. There are several formatting glitches in this module, like in P-BRIDGE-MIB. Note that these make the module uncompilable. 6. Again, qBridgePortGroup was modified from RFC 2674, which the SMI does not allow. 7. qBridgeCompliance was also modified to add the two new OBJECT-GROUPs which is also not allowed by the SMI. 8. 802.1Q says that support for management configuration of the protocol group database is optional. An implementation that implements a fixed set of database entries is fully compliant. Therefore, the new MODULE-COMPLIANCE must allow dot1vProtocolGroupId and dot1vProtocolGroupRowStatus to be implemented read-only, otherwise we are taking something that is optional in 802.1Q and making it mandatory to comply with the MIB defintion. Thanks, John David B Harrington wrote: > Hi, > > This starts the WG last call for the update to RFC2674. > We missed the IETF61 publication deadline, so the document can be > found at: > > http://www.ibr.cs.tu-bs.de/users/schoenw/draft-ietf-bridge-ext-v2-03.t > xt > > The WG last call will end November 23. > This date has been chosen to ensure that > 1) IETF61 attendees have two weeks to perform reviews, > 2) attendees of the IEEE meeting the following week have two > weeks to perform reviews, > 3) the ID publication lockout is lifted and the document > becomes available in the normal repository > If anybody has objection to this date, please post your concerns to > bridge-mib@ietf.org. > If anybody has comments on the draft, please post them to > bridge-mib@ietf.org > > Thanks, > David Harrington > dbharrington@comcast.net > Bridge-mib co-chair > > > > > > _______________________________________________ > Bridge-mib mailing list > Bridge-mib@ietf.org > https://www1.ietf.org/mailman/listinfo/bridge-mib > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Mon Nov 22 09:14:41 2004 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 JAA01375; Mon, 22 Nov 2004 09:14:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWF1G-00062r-0S; Mon, 22 Nov 2004 09:18:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWEpx-0004xM-Qk; Mon, 22 Nov 2004 09:06:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWEkT-00047s-Ez for bridge-mib@megatron.ietf.org; Mon, 22 Nov 2004 09:00:57 -0500 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 JAA00236 for ; Mon, 22 Nov 2004 09:00:56 -0500 (EST) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWEnw-0005GE-7G for bridge-mib@ietf.org; Mon, 22 Nov 2004 09:04:32 -0500 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 iAMDwuZ4004602 for ; Mon, 22 Nov 2004 08:58:56 -0500 (EST) 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 iAMDwsZ4004550 for ; Mon, 22 Nov 2004 08:58:55 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Bridge-mib] WG Last Call:dratf-ietf-bridge-ext-v2-03.txt Date: Mon, 22 Nov 2004 16:00:46 +0200 Message-ID: Thread-Topic: [Bridge-mib] WG Last Call:dratf-ietf-bridge-ext-v2-03.txt Thread-Index: AcTOq9X/r1aOyJfQQt208Qj2ZVF56gB7zZ1g From: "Romascanu, Dan \(Dan\)" To: "John Flick" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: "Congdon, Paul T" X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable True. I am not sure where this recommendation comes from, but this = indeed contradicts RFC 2613, which recommends that a 'propVirtual' = ifEntry is created for a smonDataSource of type VLAN.=20 I would suggest that this recommendation be relaxed, by replacing: OLD: This document recommends that, within an entity, VLANs which are instantiated as an entry in dot1qVlanCurrentTable by either management configuration through dot1qVlanStaticTable or by dynamic means (e.g. through GVRP), are NOT also represented by an entry in ifTable. with NEW: This document does not make any assumption that within an entity, VLANs = which are instantiated as an entry in dot1qVlanCurrentTable by either management configuration through dot1qVlanStaticTable or by dynamic means (e.g. through GVRP), are also represented by an entry in ifTable. Regards, Dan > 12. In section 3.4.2.1, second paragraph, the recommendation=20 > that VLANs > are not represented in the ifTable conflicts with SMON. Not sure > what to do about this one, and I'm not sure IEEE is the=20 > right place > to deal with it. >=20 >=20 _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Mon Nov 22 10:54:06 2004 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 KAA10589; Mon, 22 Nov 2004 10:54:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWGZT-0002rQ-Tc; Mon, 22 Nov 2004 10:57:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWGPb-0004FL-53; Mon, 22 Nov 2004 10:47:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWGOc-000412-3j for bridge-mib@megatron.ietf.org; Mon, 22 Nov 2004 10:46:31 -0500 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 KAA09779 for ; Mon, 22 Nov 2004 10:46:25 -0500 (EST) Received: from columba.eur.3com.com ([161.71.171.238]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWGS2-0002NL-CY for bridge-mib@ietf.org; Mon, 22 Nov 2004 10:50:03 -0500 Received: from toucana.eur.3com.com (eurelay.eur.3com.com [140.204.220.50]) by columba.eur.3com.com with ESMTP id iAMFjiuQ002330; Mon, 22 Nov 2004 15:45:44 GMT Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id iAMFmQAH025674; Mon, 22 Nov 2004 15:48:26 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256F54.0056762F ; Mon, 22 Nov 2004 15:44:23 +0000 X-Lotus-FromDomain: 3COM From: "Les Bell" To: "Romascanu, Dan \(Dan\)" Message-ID: <80256F54.005674A5.00@notesmta.eur.3com.com> Date: Mon, 22 Nov 2004 15:43:49 +0000 Subject: RE: [Bridge-mib] WG Last Call:dratf-ietf-bridge-ext-v2-03.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: "Congdon, Paul T" , John Flick , bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be I remember that in the meetings when this was discussed, it was the decision of the WG that a VLAN should not be represented as an entry in the ifTable. There was a lot of debate about this, with strong feelings in both camps. Eventually, the debate was won by those who did not consider a VLAN to be an interface. This debate occured before RFC 2613 was published. I think the argument goes something like: "A VLAN is a logical medium shared by a collection of interfaces." I believe things have moved on since then and it would be useful to acknowledge that many implementations represent VLANs in the ifTable, but I think we should not mandate it, as that would mean any implementation that had strictly conformed to RFC 2674 would then be non-conformant. So I would suggest changing the wording below to say "... may also be represented by an entry in ifTable." Les... "Romascanu, Dan \(Dan\)" @ietf.org on 22/11/2004 14:00:46 Sent by: bridge-mib-bounces@ietf.org To: "John Flick" , cc: "Congdon, Paul T" Subject: RE: [Bridge-mib] WG Last Call:dratf-ietf-bridge-ext-v2-03.txt True. I am not sure where this recommendation comes from, but this indeed contradicts RFC 2613, which recommends that a 'propVirtual' ifEntry is created for a smonDataSource of type VLAN. I would suggest that this recommendation be relaxed, by replacing: OLD: This document recommends that, within an entity, VLANs which are instantiated as an entry in dot1qVlanCurrentTable by either management configuration through dot1qVlanStaticTable or by dynamic means (e.g. through GVRP), are NOT also represented by an entry in ifTable. with NEW: This document does not make any assumption that within an entity, VLANs which are instantiated as an entry in dot1qVlanCurrentTable by either management configuration through dot1qVlanStaticTable or by dynamic means (e.g. through GVRP), are also represented by an entry in ifTable. Regards, Dan > 12. In section 3.4.2.1, second paragraph, the recommendation > that VLANs > are not represented in the ifTable conflicts with SMON. Not sure > what to do about this one, and I'm not sure IEEE is the > right place > to deal with it. > > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Mon Nov 22 11:08:35 2004 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 LAA12167; Mon, 22 Nov 2004 11:08:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWGnV-0003jL-Ci; Mon, 22 Nov 2004 11:12:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWGi9-0008F9-6q; Mon, 22 Nov 2004 11:06:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWGY5-0005kl-U1 for bridge-mib@megatron.ietf.org; Mon, 22 Nov 2004 10:56:18 -0500 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 KAA10828 for ; Mon, 22 Nov 2004 10:56:15 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWGbZ-0002uq-FA for bridge-mib@ietf.org; Mon, 22 Nov 2004 10:59:53 -0500 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 iAMFlnri004728 for ; Mon, 22 Nov 2004 10:47:50 -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 iAMFkNri003039 for ; Mon, 22 Nov 2004 10:46:41 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Bridge-mib] WG Last Call:dratf-ietf-bridge-ext-v2-03.txt Date: Mon, 22 Nov 2004 17:54:36 +0200 Message-ID: Thread-Topic: [Bridge-mib] WG Last Call:dratf-ietf-bridge-ext-v2-03.txt Thread-Index: AcTQqnmxEa37bWdRQYa96O6pg3vfHgAAPWyA From: "Romascanu, Dan \(Dan\)" To: "Les Bell" X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Cc: "Congdon, Paul T" , John Flick , bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable I actually was not suggesting for a recommendation either way, but for a = text that says 'makes no assumption', which reflects a neutral stand.=20 Regards, Dan > -----Original Message----- > From: Les Bell [mailto:Les_Bell@eur.3com.com] > Sent: 22 November, 2004 5:44 PM > To: Romascanu, Dan (Dan) > Cc: John Flick; bridge-mib@ietf.org; Congdon, Paul T > Subject: RE: [Bridge-mib] WG Last Call:dratf-ietf-bridge-ext-v2-03.txt >=20 >=20 >=20 >=20 >=20 > I remember that in the meetings when this was discussed, it=20 > was the decision of > the WG that a VLAN should not be represented as an entry in=20 > the ifTable. There > was a lot of debate about this, with strong feelings in both=20 > camps. Eventually, > the debate was won by those who did not consider a VLAN to be=20 > an interface. > This debate occured before RFC 2613 was published. I think=20 > the argument goes > something like: "A VLAN is a logical medium shared by a collection of > interfaces." >=20 > I believe things have moved on since then and it would be=20 > useful to acknowledge > that many implementations represent VLANs in the ifTable, but=20 > I think we should > not mandate it, as that would mean any implementation that=20 > had strictly > conformed to RFC 2674 would then be non-conformant. So I=20 > would suggest changing > the wording below to say "... may also be represented by an=20 > entry in ifTable." >=20 > Les... >=20 >=20 >=20 >=20 >=20 > "Romascanu, Dan \(Dan\)" @ietf.org on=20 > 22/11/2004 14:00:46 >=20 > Sent by: bridge-mib-bounces@ietf.org >=20 >=20 > To: "John Flick" , > cc: "Congdon, Paul T" > Subject: RE: [Bridge-mib] WG Last=20 > Call:dratf-ietf-bridge-ext-v2-03.txt >=20 >=20 > True. I am not sure where this recommendation comes from, but=20 > this indeed > contradicts RFC 2613, which recommends that a 'propVirtual'=20 > ifEntry is created > for a smonDataSource of type VLAN. >=20 > I would suggest that this recommendation be relaxed, by replacing: >=20 > OLD: >=20 > This document recommends that, within an entity, VLANs which are > instantiated as an entry in dot1qVlanCurrentTable by either > management configuration through dot1qVlanStaticTable or by dynamic > means (e.g. through GVRP), are NOT also represented by an entry in > ifTable. >=20 > with >=20 > NEW: >=20 > This document does not make any assumption that within an=20 > entity, VLANs which > are > instantiated as an entry in dot1qVlanCurrentTable by either > management configuration through dot1qVlanStaticTable or by dynamic > means (e.g. through GVRP), are also represented by an entry in > ifTable. >=20 >=20 >=20 > Regards, >=20 > Dan >=20 >=20 >=20 > > 12. In section 3.4.2.1, second paragraph, the recommendation > > that VLANs > > are not represented in the ifTable conflicts with=20 > SMON. Not sure > > what to do about this one, and I'm not sure IEEE is the > > right place > > to deal with it. > > > > >=20 > _______________________________________________ > Bridge-mib mailing list > Bridge-mib@ietf.org > https://www1.ietf.org/mailman/listinfo/bridge-mib >=20 >=20 >=20 >=20 >=20 _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Wed Nov 24 04:44:36 2004 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 EAA04207; Wed, 24 Nov 2004 04:44:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWtlN-0004c3-36; Wed, 24 Nov 2004 04:48:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWtgS-00088s-C5; Wed, 24 Nov 2004 04:43:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWtd3-0007LS-UX for bridge-mib@megatron.ietf.org; Wed, 24 Nov 2004 04:40:02 -0500 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 EAA03567 for ; Wed, 24 Nov 2004 04:39:59 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWtgt-0003qR-3n for bridge-mib@ietf.org; Wed, 24 Nov 2004 04:44:00 -0500 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 iAO9VWri005016 for ; Wed, 24 Nov 2004 04:31:32 -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 iAO9VTri004988 for ; Wed, 24 Nov 2004 04:31:30 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Nov 2004 11:39:56 +0200 Message-ID: Thread-Topic: [802.1] updated slides on 802.1AE management Thread-Index: AcTRueBb3rEP6ItNRlWOLlK5mHVa/gAT5Z+g From: "Romascanu, Dan \(Dan\)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Subject: [Bridge-mib] FW: [802.1] updated slides on 802.1AE management X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Regards, Dan -----Original Message----- From: IEEE 802.1 [mailto:hdk-1023.dwkfdq@ATT.NET]On Behalf Of Allyn = Romanow Sent: 24 November, 2004 2:04 AM To: STDS-802-1-L@listserv.ieee.org Subject: [802.1] updated slides on 802.1AE management Folks, Frank's slides on .1AE management have been updated, they are available = at http://www.ieee802.org/1/files/public/docs2004/ae-chao-mgmt-1104.ppt IEEE 802.1 list info: http://www.ieee802.org/1/email-pages/sjqnf904.html _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib