From nobody Mon Aug 3 07:03:48 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D9C1A8A89; Mon, 3 Aug 2015 07:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxOSGrRZtdhg; Mon, 3 Aug 2015 07:03:45 -0700 (PDT) Received: from ENFICSETS1.metaswitch.com (enficsets1.metaswitch.com [192.91.191.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7961A89C6; Mon, 3 Aug 2015 07:03:43 -0700 (PDT) Received: from ENFIRHCAS1.datcon.co.uk (172.18.74.33) by ENFICSETS1.metaswitch.com (172.18.4.18) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 3 Aug 2015 15:03:42 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHCAS1.datcon.co.uk ([fe80::85a7:aa4e:2516:c2ad%11]) with mapi id 14.03.0248.002; Mon, 3 Aug 2015 15:03:41 +0100 From: Jonathan Hardwick To: "'routing-discussion@ietf.org'" , "'rtg-chairs@ietf.org'" , "'rtg-dir@ietf.org'" , "rtg-ads@tools.ietf.org" , "Jon Hudson" Thread-Topic: Routing Area draft minutes available Thread-Index: AdDN9Pduj2u8XLDRQo+irz2DJ6DcnQ== Date: Mon, 3 Aug 2015 14:03:41 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBA0139BD4547@ENFICSMBX1.datcon.co.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.4.11] Content-Type: multipart/alternative; boundary="_000_09CE6C3BE5E1EA40B987BF5F25D8DDBA0139BD4547ENFICSMBX1dat_" MIME-Version: 1.0 Archived-At: Subject: [RTG-DIR] Routing Area draft minutes available X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 14:03:47 -0000 --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBA0139BD4547ENFICSMBX1dat_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft minutes for the RTGAREA meeting at IETF 93 are now available. Pl= ease let me know if you have any comments. https://www.ietf.org/proceedings/93/minutes/minutes-93-rtgarea Best regards Jon --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBA0139BD4547ENFICSMBX1dat_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The draft minutes for the RTGAREA meeting at IETF 93= are now available.  Please let me know if you have any comments.=

https://www.ietf.org/proceedings/93/minutes/minutes-= 93-rtgarea

 

Best regards

Jon

 

&nbs= p;

--_000_09CE6C3BE5E1EA40B987BF5F25D8DDBA0139BD4547ENFICSMBX1dat_-- From nobody Mon Aug 3 21:06:03 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1922B1B343F; Mon, 3 Aug 2015 21:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xa78OfoIgOcY; Mon, 3 Aug 2015 21:05:59 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0352E1B343C; Mon, 3 Aug 2015 21:05:58 -0700 (PDT) Received: from mb-aye.local ([IPv6:2601:647:4200:7a31:68b4:b868:3c8f:e2e1]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t7443rb4067388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 4 Aug 2015 04:03:54 GMT (envelope-from joelja@bogus.com) To: Terry Manderson , "rtg-ads@tools.ietf.org" References: From: joel jaeggli Message-ID: <55C039A8.2090807@bogus.com> Date: Mon, 3 Aug 2015 21:03:52 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l85RHR7volSVC73M1Qk5gqW7G3mxPcOI1" Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-grow-irr-routing-policy-considerations.all@tools.ietf.org" , "grow@ietf.org" Subject: Re: [RTG-DIR] [GROW] RtgDir Review: draft-ietf-grow-irr-routing-policy-considerations-05 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 04:06:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --l85RHR7volSVC73M1Qk5gqW7G3mxPcOI1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's been a long time in coming but we have an update to this draft which I figured I would run by you, before we return it to the IESG. draft-ietf-grow-irr-routing-policy-considerations-06 is out https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-grow-irr-routing-policy-co= nsiderations-05&url2=3Ddraft-ietf-grow-irr-routing-policy-considerations-= 06 On 11/24/14 3:44 PM, Terry Manderson wrote: > Hello, >=20 > I have been selected as the Routing Directorate reviewer for this draft= =2E > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review. The purpose= of > the review is to provide assistance to the Routing ADs. For more > information about the Routing Directorate, please see > =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >=20 >=20 > Although these comments are primarily for the use of the Routing ADs, i= t > would be helpful if you could consider them along with any other IETF L= ast > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. >=20 >=20 > Document: draft-ietf-grow-irr-routing-policy-considerations-05 > Reviewer: Terry Manderson > Review Date: 2014-11-24 > IETF LC End Date: 2014-12-01 > Intended Status: Informational >=20 > Summary:=20 > I have a handful of minor concerns about this document which should be > resolved prior to publication, and a few comments centered around gener= al > draft direction. >=20 >=20 > Comments:=20 > I think the handling of the historical issues of IRRs is fair. There is= > often a reach to 'beat up' on the perceived faults of a system - this > draft doesn't do this. Indeed I thought the first half of the draft was= > very well constructed and provides an appropriate discussion. >=20 > When discussing the data integrity (or lack thereof) of an IRR I feel > insufficient attention is given to overall integrity of the IRR source,= > esp. wrt mirroring (sec 5.1). That is, are all the objects completely > mirrored, is there a way to tell? why not? etc? As it is RIPE withhold > certain objects for PII reasons, what else could be missing that is > operationally important? >=20 > The lack of C.I.A. on the NRTM stream is touched on, but not given due > attention. Additionally the lack of C.I.A on the current query side > (WHOIS/TCP/43) should be iterated as a part of the attack surface, both= > for the IRR operator and the IRR user. > =20 > A number of times within the draft the similarities, differences, and > 'nice to have' aspects between the IRR and the RPKI are highlighted. I'= m > left wondering if this topic actually needs its own section. For exampl= e: > the RPKI has RPKI-RTR, yet that in itself will not carry policy based > information. Without turning such a section into "what the RPKI doesn't= > do", some time spent highlighting what the IRR provides and what RPKI m= ay > provide could help the reader. The underpinning statement from the draf= t > appears to be that RPKI origin validation is or could be good, but it > (RPKI) currently is not scoped to replace RPSL and the nuanced policy > applications which providers employ now. If this is a pragmatism holds > true, then for completeness of the discussion the Authors and ADs might= > wish to include it. >=20 >=20 > Major Issues:=20 > No major issues found. >=20 >=20 > Minor Issues:=20 > Section 5, Para 4: I feel it is glib to state that "it can be observed > that the most common circuit size used by ISPs is now 10 Gbps". > Qualifying this with the economic development or network development of= > the region is prudent, or perhaps provide a reference to a survey if on= e > exists. >=20 > Section 5.2, Para 5. I found the last sentence in para 5 difficult to > parse. Please consider rewording. >=20 > Section 7.2, Para 2. Please consider re-writing the second sentence of > this para. The (over) use of commas makes it hard to read. >=20 > Section 7.3, Para 1. I don't think you actually mean '"offline" server'= =2E. > Perhaps "disparate"? or "configuration"??? Please clarify, or perhaps > define the term in the context here. "offline" is an overloaded term. >=20 > Nits:=20 >=20 > Section 5.1, para 3: s/(Edge)/(edge)/ > Section 5.2, para 4: "turn-up", word suggestion: "commission" > Section 5.2, para 4: s/call up/call/ (the "up" is superfluous) > Section 6, para 4: s/take affect/take effect/ x2 > Section 7.2, para 4: s/so have the some of the scaling/so have some of = the > scaling/ >=20 > Section 8: 1st sentence. I read this and thought: "the green leaf is > green".. This might just be a style difference around over-stating the > obvious. >=20 >=20 >=20 > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow >=20 --l85RHR7volSVC73M1Qk5gqW7G3mxPcOI1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlXAOakACgkQ8AA1q7Z/VrJc1QCdGcZfKsAimwENt+EHB0RDOYCt e7IAnjEicsEtsDBTA/TLMQ0XEsTf3xvf =mDHy -----END PGP SIGNATURE----- --l85RHR7volSVC73M1Qk5gqW7G3mxPcOI1-- From nobody Tue Aug 4 08:24:26 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3C01A92E6; Mon, 3 Aug 2015 09:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bVGPbsZkD8B; Mon, 3 Aug 2015 09:20:23 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E2661AC3AF; Mon, 3 Aug 2015 09:20:22 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.15,602,1432594800"; d="scan'208,217"; a="11178591" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by ukmta1.baesystems.com with ESMTP; 03 Aug 2015 17:20:20 +0100 X-IronPort-AV: E=Sophos;i="5.15,602,1432594800"; d="scan'208,217";a="107382567" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds017.greenlnk.net with ESMTP; 03 Aug 2015 17:20:20 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.110]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0248.002; Mon, 3 Aug 2015 17:20:20 +0100 From: "Dearlove, Christopher (UK)" To: Jonathan Hardwick , "'routing-discussion@ietf.org'" , "'rtg-chairs@ietf.org'" , "'rtg-dir@ietf.org'" , "rtg-ads@tools.ietf.org" , "Jon Hudson" Thread-Topic: Routing Area draft minutes available Thread-Index: AdDN9Pduj2u8XLDRQo+irz2DJ6DcnQAEHgkg Date: Mon, 3 Aug 2015 16:20:18 +0000 Message-ID: References: <09CE6C3BE5E1EA40B987BF5F25D8DDBA0139BD4547@ENFICSMBX1.datcon.co.uk> In-Reply-To: <09CE6C3BE5E1EA40B987BF5F25D8DDBA0139BD4547@ENFICSMBX1.datcon.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D482644B3GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 04 Aug 2015 08:24:26 -0700 Subject: Re: [RTG-DIR] Routing Area draft minutes available X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 16:20:27 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D482644B3GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Under MANET, LSR should be OLSRv2. And multi-topology should be multipath. = (There is an OLSRv2 multi-topology draft, but that's with the IESG, and has= been some time.) -- Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Be= half Of Jonathan Hardwick Sent: 03 August 2015 15:04 To: 'routing-discussion@ietf.org'; 'rtg-chairs@ietf.org'; 'rtg-dir@ietf.org= '; rtg-ads@tools.ietf.org; Jon Hudson Subject: Routing Area draft minutes available *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. The draft minutes for the RTGAREA meeting at IETF 93 are now available. Pl= ease let me know if you have any comments. https://www.ietf.org/proceedings/93/minutes/minutes-93-rtgarea Best regards Jon ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D482644B3GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Under MANET, LSR shoul= d be OLSRv2. And multi-topology should be multipath. (There is an OLSRv2 mu= lti-topology draft, but that’s with the IESG, and has been some time.= )

 

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
_____________________________________________________= _____________________

T: &nb= sp;+44 (0)1245 242194  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP=

 

 

From: routing-discussion [mailto:routing-discussion-bounces= @ietf.org] On Behalf Of Jonathan Hardwick
Sent: 03 August 2015 15:04
To: 'routing-discussion@ietf.org'; 'rtg-chairs@ietf.org'; 'rtg-dir@i= etf.org'; rtg-ads@tools.ietf.org; Jon Hudson
Subject: Routing Area draft minutes available

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Co= nsider carefully whether you should click on any links, open any attachment= s or reply.
Fo= r information regarding
Red Flags that you can look out for in emails you rec= eive, click here.
If= you feel the email is suspicious, please follow this process.

The draft minutes for the RTGAREA meeting at IETF 93= are now available.  Please let me know if you have any comments.=

https://www.ietf.org/proceedings/93/minutes/minutes-= 93-rtgarea

 

Best regards

Jon

 

&nbs= p;

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D482644B3GLKXM0002VGREEN_-- From nobody Wed Aug 5 12:53:19 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36921A0063; Wed, 5 Aug 2015 12:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaFikqBFnpOQ; Wed, 5 Aug 2015 12:53:15 -0700 (PDT) Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.230]) by ietfa.amsl.com (Postfix) with ESMTP id 303011A0052; Wed, 5 Aug 2015 12:53:15 -0700 (PDT) Received: from poro.lan (80.220.64.126) by jenni1.inet.fi (8.5.142.08) (authenticated as stenma-47) id 5511FF5807B81646; Wed, 5 Aug 2015 22:53:08 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Markus Stenberg In-Reply-To: Date: Wed, 5 Aug 2015 22:53:06 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55857123.90205@openwrt.org> <43C47623-C61D-4397-BA4A-8CBF8878B516@thomasclausen.org> <9630E81F-8AA0-4516-A9AE-56E0EB634599@iki.fi> To: Thomas Clausen X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "" , Steven Barth , "homenet@ietf.org Group" , "" Subject: Re: [RTG-DIR] [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 19:53:18 -0000 Now -09 is available. Changelog (diff is relatively large, but these are = the main parts): - Reserved 1024+ TLV types for future versions (=3Dversioning mechanism); private use section moved from 192-255 to 512-767. - Added applicability statement and clarified some text based on reviews. URL: = https://www.ietf.org/internet-drafts/draft-ietf-homenet-dncp-09.txt Status: = https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/ Htmlized: https://tools.ietf.org/html/draft-ietf-homenet-dncp-09 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-dncp-09 On 29.7.2015, at 15.02, Thomas Clausen wrote: >> Anyway, on to comments.. >>=20 >> Caveat: These are my comments, Steven is likely to fix typos before = we actually hit publish button on -09 :) >>=20 >> Executive summary: Minor edits, but as you are good with words, time = to ask for advice - how would you explain =E2=80=9CEndpoint=E2=80=9D in = the terminology? (Anyone else on the list too, feel free to chime up..) >>=20 >=20 > Actually, when doing my review I tried if I could come up with some = text that I would thing worked =E2=80=94 which, if I had succeeded, = I=E2=80=99d have been throwing it at you saying =E2=80=9C=E2=80=A6but = this would make me happy=E2=80=9D. >=20 > I didn=E2=80=99t come up with something that I actually liked. So = instead, you get my random thoughts =E2=80=A6=20 Steven came up with a new definition =3D> another attempt :) (one of = these days I will count the different definitions..) > Proposal=E2=80=A6.you say that you have a large TLV type space so = =E2=80=A6.why don=E2=80=99t we set aside the first two bits in the TLV = type field, call that =E2=80=9CVersion=E2=80=9D, and define =E2=80=9Cif = both are cleared, then it means this specification, DNCPv1" and then = have 2^14 =E2=80=9CTLV types=E2=80=9D =E2=80=94 with a potential for 4 = DNCP =E2=80=9Cversions=E2=80=9D? >=20 > Then, we take an appointment in 15 years time. If by then we still = have not found a reason to flip either of these two version bits, then = (i) we write an =E2=80=9CUpdates DNCPv1=E2=80=9D RFC which reassigns = that field as =E2=80=9C16 bit TLV Type=E2=80=9D, and I buy lunch =E2=80=94= otherwise, lunch is on you?=20 We chose only 2^10 TLV types + 6 bits for future use. Looking forward to = the lunch. (Then again, I do not think the 2^10 bits run out so third = option of =E2=80=98protocol was left as is=E2=80=99 is the most likely = one I think.) >> (802-style) broadcast domain is what we=E2=80=99re probably looking = for. There=E2=80=99s also =E2=80=98multiple access link=E2=80=99 in one = place in the spec, to denote availability of link-local multicast I = guess. >>=20 >> This terminology could use some further work I think though. > Thanks, let me know when you want me to look at something concrete. -09 is hopefully bit more correct in what it refers to as links. Please = take a look. > Recapitulating, I see basically two potential issues where we do not = yet have resolution: >=20 > o Versioning=20 > o Address/Endpoint terminology Hopefully both addressed (then again, only me + Steven like the current = address + endpoint text; random anonymous lurker on the mailing list, = now it=E2=80=99s your chance is now to be the third!). Cheers, -Markus From nobody Thu Aug 6 23:40:20 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72201B372B; Thu, 6 Aug 2015 23:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.949 X-Spam-Level: X-Spam-Status: No, score=0.949 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkKlMPsGWXJ3; Thu, 6 Aug 2015 23:40:10 -0700 (PDT) Received: from mail.core-networks.de (mx1.core-networks.de [IPv6:2001:1bc0:d::4:8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3BF1B372D; Thu, 6 Aug 2015 23:40:09 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZNbK0-0005JX-MT with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Fri, 07 Aug 2015 08:40:05 +0200 To: Thomas Clausen , "" References: <564C2726-F2B9-4FDB-AB36-949ADE3C2869@thomasclausen.org> From: Steven Barth Message-ID: <55C452C2.3070808@openwrt.org> Date: Fri, 7 Aug 2015 08:40:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <564C2726-F2B9-4FDB-AB36-949ADE3C2869@thomasclausen.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "" , "homenet@ietf.org Group" , draft-ietf-homenet-hncp.all@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-homenet-hncp-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 06:40:19 -0000 Hello Thomas, as you might have seen already, we pushed hncp-08 yesterday and dncp-09 the day before and for hncp the editorial changes have been quite big. Now please also find our detailed reply to the points you raised and, as usual, we tried to address them as best as possible. Thanks, Steven (& Markus) > Comments: > > o This document is a profile for and specialization of > draft-ietf-homenet-dncp, and > has a normative dependency on that document. Note that I produced a > RTG-DIR review of draft-ietf-homenet-dncp with several suggestions a > short while ago, to which the authors recently responded with an updated > document. I have not had a chance to review that update, and iterate > with the authors, yet. I also note a RTG-DIR review by Les Ginsberg, > as well as several points raised by Juliusz Chroboczek on the topic of > draft-ietf-homenet-dncp, the resolution of which I believe may impact > draft-ietf-homenet-hncp somewhat significantly. > > This is one reason for my summary (above) of "Significant concerns..." > -- before this document can be processed, draft-ietf-homenet-dncp should > be squared off. It is not, however, the only reason dncp is more mature now, so hopefully that has been covered. > o As a general comment, the document would do well with a good editorial > overhaul to bring consistency in language usage, consistency in 2119 > terminology, coherence in defined terms and their definition, document > structure, etc. Agreed. An effort has been made in -08 :) > o Related to this, I found that the lack of a terminology section was > unfortunate, and ended up -- for helping my own reading of the document > -- making a napkin-terminology to refer to as I walked through the doc. > (FWIW, I personally prefer the 2119-paragraph to be part of a > terminology section, although that is a minor issue / personal > preference). The words I'd suggest including, and defining, would be: > > o Node -- is that a router, a host, or both? Again, I was > given to understand that HOMENET did not want to redefine > host behavior, and so I believe that the right term would > be router? Homenet is tasked not to cause _backwards-incompatible_ changes to hosts. While the design is such that it is enough for routers only to participate in it, and the e.g. routing and addressing experience should work, advanced hosts MAY also if they want to e.g. do their own routing and in that case they may also want to do automatic address assignment by themselves. The text now differentiates more clearly between nodes and routers and has appropriate terminology. > o Privat Link - Common Link -- If you *insist* on having these > concepts, then they definitely need a clear-cut definition > here ; I would prefer, though, to not have those concepts. > > o External Interface > o Internal Interface > o Border > o Border router Added terminology section. > You "import" a lot of terminology from DNCP and from > [I-D.ietf-homenet-prefix-assignment], and I found myself constantly > hunting through to figure out which terminology was from where. Suggest > adding a paragraph to the terminology section (assuming you make one) > which recapitulates something like: > > "Additionally, this document uses terminology from DNCP, > specificially the terms XXX, YYY, ZZZ are to be interpreted as > described therein. > > This document also uses terminology from > [I-D.ietf-homenet-prefix-assignment], specifically the terms WWW, > UUU, QQQ are to be interpreted as described therein". > > Reason being: when I came across a term (say "Shared Link"), I wanted > to make sure that I understood what that was. So I went to the > terminology section. Well, there was none. So I went to grep through > this document. Didn't really find a definition. So I started looking > through the references to see if there might be something that made > sense. Fortunately, my guess of what I-D to check first was right, but > it still was more work than it should have been. Added imported terminology lists for both DNCP and PA. > Major Issues: > > o I made this very same comment to draft-ietf-homenet-dncp, as I am going > to make here. > > The introduction does not read well; it contains parts of something that > could be considered as part of an applicability statement (without it > being called out as such, and without forming a complete applicability > statement), and does not actually introduce the protocol. Reading just > the introduction and the abstract, it is very obscure what HNCP is > actually accomplishing, and why one would chose to use HNCP. > > It does, however, transpire that "whatever it is", it imposes a src-dst > routing protocol -- although, that is actually at odds with the claim > (from the Abstract) that the use of HNCP allows "...seamless use of a > routing protocol." ... given that, afaik, no standardized src-dst > routing protocols currently exist. > > As I recommended for DNCP (hey, at least I'm being somewhat > consistent...) I suggest that a proper introduction consisting of three > parts would be beneficial: (i) what this document is, (ii) what doing > HNCP actually gets you, and (iii) the operating conditions under which > HNCP is applicable. > > I am calling this out as a major issue, since I believe that it is > not just editorial, but is a matter of scoping this document correctly, > and in particular not falling into the trap of "claiming applicability > where it's not". Rewrote introduction to some extent, and added applicability subsection which refers to DNCP applicability where applicable (smirk). > o 4. Common Links > > From the document: > > "HNCP uses the concept of Common Links for some of its applications. > A Common Link usually refers to a link layer broadcast domain with > certain properties and is used, e.g., to determine where prefixes > should be assigned or which neighboring nodes participate in the > election of a DHCP(v6) server. The Common Link is computed > separately for each local interface, and it always contains the > local interface. Additionally, if the local interface is not in > ad-hoc mode, it also contains the set of interfaces that are > bidirectionally reachable from the given local interface, i.e. every > remote interface of a remote node meeting all of the following > requirements:" > > > Several issues here: > > 0) "refers to a link layer broadcast domain" -- sounds like a > "full broadcast link" or "something that looks like an Ethernet" Rewrote the text. > 1) "some of its applications" -- what are those? Enumerated applications. > 2) "usually refers to a ..." -- so, that means that there are > situations where you use it to refer to something else, then? > Please don't do that.... Text disappeared in rewrite. > 3) "is computed seperately for each local interface" -- wait, in > 0) it was defined in terms of physical properties, now it is > something which is computed? It is something that is computed. > 4) "which neighboring nodes participate in the election of a > DHCP(v6) server" -- is that a hidden requirement that slid in, > that DHCP(v6) servers are part of the architecture? SLAAC is > out, then? Is that a conscious architectural decision? SLAAC is the default. All HNCP routers MUST send RAs. RFC 7084 (which we “import”) says A-flag MUST be 1 by default. Also our text says “In case no router was elected, stateful DHCPv6 is not provided.“. Some people need DHCPv6 either for PD for “legacy routers” or to collect hostnames since cross-platform naming is totally screwed up with v6, so we try to handle it gracefully. > > Now, I actually read in section 5, bullet number 2 that "if > an interface can receive a delegated prefix by running a > DHCPv6 client on the interface, it must be considered > external". So, at least, if a "common link" connects "internal > interfaces" then if DHCPv6 servers are active on a common > link, then this imposes constraints on what these DHCPv6 > servers are allowed to serve ... This *really* merits being > called out, the relationship DNCP-DHCP is murky, at best. It should be more clearly explained now. Background is that IIRC homenet architecture RFC as well as WG in general wants automatic border discovery so we have to do some black magic using DHCP interactions here to fulfill that. If you have anything (technically) better in mind then please let us know. > 5) "if the local interface is not in ad-hoc mode" -- haaaaang on, > if we are talking about an 802.11/WiFi interface, "ad hoc mode” > does not result in links that look like in 0) ....not at all, actually. It was really talking about ad-hoc category, and not actual low-level things. Fixed, hopefully. > 6) "if the local interface is not in ad-hoc mode" -- I am not sure > that this is actually "the right term" nor that it is > universally understood. At least, I have personally had a heck > of a time conveying what that meant when charaterizing a link — > especually within the IETF" See above. > 7) Reading forward in the document, there's something more on that > in section 5 on page 6 where the document talks about an "ad hoc > category", and where it actually says something about > "transitivity properties" -- specifically that it is not > assumed, then a reference to section 4 is given as-if there was > any further discussion on this point. Rewritten, hopefully clearer now. > 8) "set of interfaces that are bidirectionally reachable from the > given local interface" -- I take it that this means that the below > specifies a part of a protocol (HELLO protocol), which only run > over "ad hoc interface types"? Kind of. We’re talking of using DNCP state to determine (sub)set of nodes that have shared view of the link. In practise, it is the whole subnet, except in meshy cases (ad-hoc fixed category), it is just the local interface as we cannot make any guarantees about anything else. > If "yes" to 8), then I would recommend that you define the interface > types, and their behaviors, completely -- both what characteristics you > expect from the interface (and "ad hoc mode" is not sufficient...), and > what behaviors you exhibit across them. You have, in this text, half-way > defined "broadcast link type" and half-way defined a "non-transitive > non-reflexive link type" > > Also, I really do not understand the choice of "Common Link" as section > header, and as a term. How is that definition different from "an IP > link"? Are the protocol mechanisms that you provide for what you call > "ad hoc mode" providing something which looks like an IP limk to "the > rest of the protocol", etc. > > I am afraid that I do not understand what a common link is. Are you > trying to define a link model? I think there are some misunderstandings here based on earlier text. Hopefully the rewritten version clears it out. > o 3. DNCP Profile > The document reads: > > "A node implementing HNCP > SHOULD generate and use a random node identifier. If using a > random node identifier and there is a node identifier collision, > the node MUST immediately generate and use a new random node > identifier which is not used by any other node." > > Awesome, but that raises two questions: > 1) How does a node detect identifier collision? Section 4.4, NetState handling of DNCP. Added reference. > 2) How does a node generate an identifier which is not used by any > other node? It uses a new random node identifier which is not used by any other node at the time, based on the current DNCP network state. Text changed. > It would seem that if 2) is actually possible, then a colission should > never ever happen. It is essentially a race condition (network split/join come to mind). Notably, when a network boots, it is a series of joins. > Also, if 1) and 2) are done "by this protocol", put in a forward > reference to where the corresponding mechanisms exist. Or if done by > DNCP or something else, stick in a reference. > > As it is, it reads a little like: > "...and then some magic happens, and then poppies and pink unicorns" > > ;) Juliusz said this stuff worked like magic in IETF93, I guess this is further proof of that :) > The document reads: > > "o HNCP nodes use the following Trickle parameters: > > - k SHOULD be 1, as the timer reset when data is updated and > further retransmissions should handle packet loss." > > I am wondering what the justification for "k=1" is here? Actually, I can > infer what it is: the topology in a homenet is constituted by > full-broadcast Ethernet links, with the assumption that "if one station > receives a transmission, all stations on the link received the > transmission" -- if so, then this is actually part of the applicability > statement for HNCP: "MUST only be used on Ethernet-like links and MUST > NOT be used on non-transitive, non-reflexive, or on lossy, links". > > If this interpretation is correct, then you probably should explain > yourself -- for once, I am mostly in agreement with the use of a > SHOULD. It is not; SHOULD is for ‘the default’ which is Ethernet-like links, and the other part is e.g. ad-hoc category lossy non-transitive links. Even they _do_ work with the k=1, given keep-alives are essentially extra Trickle updates that are sent by _every_ node periodically. > One question, however: for a router with multiple interface, do you run > the Trickle algorithm per interface? Would probably merit clarification. > If it is already said in DNCP (I do not recall if it is, and couldn't > immediately find it), perhaps a reminder and a pointer would be good? (DNCP) It is in data model section, and numerous (hopefully correct) references to ‘Trickle instances’. Added per-interface Trickle interface text there. > o Section 4 & 5 > The document seems to define a set of interface types and link types, > but without any clear relationship between them -- and, worse, without > any discussion of what characterize each, what behaviors are exhibited > over each, and what impacts on the system/network behavior and > performance each has. Further, the definitions of the different > interface/link types are incomplete, and seem tied to (without naming > explicitly) specific L2's...hinted at, but not actually referenced. We try to steer clear of link types; interface types (=categories) care only about transitivity or non-transitivity (all categories except ad-hoc are assumed to be transitive; ad-hoc can be either transitive or non-transitive). Added a note to Common Link in terminology about (default) transitivity assumption. Also interface categories have been reorganized. > o Section 5 > > The document reads: > "HNCP router's interfaces are either internal, external or of a > different category derived from the internal one." > > So, this text tells me that there are n different categories of > interface, where n>=2 -- but does not tell me what defines those > different interface categories, or what the actual value for n is. Nor > does this tell me if I should expect different behaviors across these > interfaces, or not. > > Could the document be more specific? Rewritten > The text goes on: > "It is suitable for both IPv4 and IPv6 (single or dual-stack) and > determines whether an HNCP interface is internal, external, or > uses another fixed category." > > So what's "another fixed category"? Is that different from "a different > category derived from the internal one" discussed earlier? Again, what > behaviors to expect, exhibit, across these? Clarified, text now has 2 sections: one defining all categories, one defining the selection. > > With that being said, I would really recommend that the document defines > what a border is, in this context. How do I identify it, what > characterizes a boarder (which perhaps falls off from "what > characterizes an internal and external interface). Clarified that. > > I assume that "internal interface" means "internal to the Internet" > whereas "external" means "external to the internet, i.e., part of the > homenet" -- right? Of course, I am yanking your chain here, but you must > define precisely what these mean. External and Internal are relative > terms... Added to terminology and further specified in 2 other sections. > On that, reading through the algorithm that you give, eseentially you > define as "external" anything on which a DHCPv4 or DHCPv6-PD server > answers, correct? Other than having a hard time reconciling that with > issue 4 under "common links" in Major Issues, that does seem to assume > an architectural choice which imposes constraints ("thou shalt not run > a DHCP server inside a homenet whilst running HNCP") which, at least, > needs to be called out in the applicability statement for HNCP, and > probably even merits more global discussion and decision by the WG? As noted earlier auto border discovery is even mentioned in the architectural RFC. Drafts predating HNCP have defined similar schemes already before (by using dedicated new DHCP options) so this stuff is not exactly new. Also it is not mandatory to implement and is a “MAY use”, you can always use fixed categories and do whatever you want with DHCP. I added a subsection to applicability denoting HNCP assumes certain level of control over DHCP servers. This is not only true for border discovery here but obviously if you have a DHCP-server handing out different prefixes your clients are in trouble anyway. > > But wait, then below the algorithm I read this: > > "In order to avoid conflicts between border discovery and HNCP > routers running DHCPv4...." > > ...and then, requirements that such routers must include a User-Class > string. That actually means that the specified algorithm is incorrect > -- underspecified: the algorithm must capture the "...unless an > User-Class string of .... is included", where appropriate. Added note about it after it (rather not avoid the clumsy language). A lot of reordering of the text as well. Server and client behavior is now more correctly split. > Sure, with efforts of the "...I thought this over, and I am sure that > the authors must have meant XXXX", it's probably possible to implement > but I'd much prefer to have the document tell me what to implement, > rather than have it tell me to guess. > > The last paragraph in section 5 is hugely important: that is where the > normative behavior for each interface category is detailed - but, I > think, only part of the normative behavior is actually specified > therein. This is relative to what I mentioned earlier, that for an > interface/link type/category, it would be helpful to have specified > precisely (i) how to determine if a given interface/link falls within > it, (ii) what precise behaviors to expect over than interface/link. Moved the behavior to the interface category section, added more text in general to clarify. > > o Section 6 > Related to my last comment above to section 5, section 6 brings out > "border routers" -- which is not actually defined in the document. > Some specific behavior is specified for a "border router" and that > brings me to expecting to see: > > o A precise definition of when a router is, or is not, a > border router (given a router, how do I determine if I > should configure it to exhibit that "specific behavior" > > o A precise and complete definition of which behaviors a > "border router", once identified, should expect and exhibit. > > The current text does not do that. Again, I could perhaps try to guess, > but for a document aiming for std.track, I really should not have to. > Added border router to terminology. RFC 7084 as referenced specifies more detailed behavior. > o Section 6.1 > "Each HNCP router MAY obtain external connection information from > one or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241] > or static configuration. This section specifies how such > information is encoded and advertised." > > What is "connection information"? Do you mean "prefixes, addresses, > routing information, DNS resolvers" and such? Or does it mean "bitrate, > error rate, propagation delay"? Or something else? Again, I could > probably guess, and might even get it right, but in a std.track document > I really shouldn't have to. Explicitly note what is part of connection information and referenced the relevant TLVs for encoding. > > "o MAY contain at most one DHCPv6 Data TLV and at most one DHCPv4 > Data TLV encoding options associated with the External > Connection but MUST NOT contain more than one of each otherwise > the External Connection TLV MUST be ignored. > > o MAY contain other TLVs for future use. Such additional TLVs > MUST be ignored." > > Several comments to that specifically, and to the TLV description in > general (please apply also to the other signals/TLVs as > appropriate, the comments to this TLV description / bullet apply through > section 6): > > 0) You define a TLV "EXTERNAL-CONNECTION", within which you have > other TLVs, correct? Would it not be clearer if those "other > TLVs" be called "sub-TLVs" and that term used systematically, > so as to distinguish them from the top-level DNCP TLVs. > > I note that you then set up "sub-sub TLVs" such as "Prefix > Domain". So that means that we'll see: > > o An EXTERNAL-CONNECTION TLV, containing > o A DELEGATED-PREFIX TLV, containing > o A PREFIX-DOMAIN TLV > > Correct? Yes. > The first question that springs to mind is one of IANA > registries. Are you setting up, for each TLV type, a new > registry for sub-TLV-types? Or, are all TLV types out of one > global space? Global space. > More importantly, if out of a global TLV type space, what > happens if, say, a "PREFIX-DOMAIN" TLV is received outside of > a "DELEGATED-PREFIX" TLV? Is that valid? Should it be? What > behavior should I, as an implementer, exhibit if I receive > that? > This, really, is a question about what the context for > processing each (sub)TLV os, or should be, which is not > specified in the document. It is also related to issue 2) below. > > > 1) I would suggest a phrasing such as: > "MAY contain at most one ... and at most one DHCPv4 ... with > the external connection." > > 2) The second part of the first bullet: > "MUST not contain more than one ... MUST be ignored" > > That should, IMO, be a generic comment for all (sub)-TLVs, and > brought forward to section 6.0 or 6.1, for example some > wordsmithing on: > > "Any received TLV, which does not satisfy the requirements > specified in the below, MUST be silently discarded, and > MUST be ignored for processing. > > More to the point, these TLVs (and (sub-)TLVs) are speicified as > being in a specific order, or at least in a specific hierarchy > (TLV within another TLV) on transmission. What are the > constraints on their processing? At what point shall I discard > information based on it being received "out of place" (such as > a "DELEGATED-PREFIX" TLV not contained in an > "EXTERNAL-CONNECTIVITY" TLV)? > > 3) This leads to a general question: are all the constraints on > the sub-TLVs contained in this TLV completely specified? > > I would actually like to see a check-list of "constraints" that > I could implement checks for, both when generating and > processing protocol messages. > 4) Generally, to the fields in the TLVs, I do not see the encoding, > (unsigned/signed, endianness, ...) stipulated. Rather important > for interoperability, this MUST be clarified. > > 5) I am generally not a great fan of having some constraints in the > picture (such as the length >= 9) and some in the text (such as > "MUST NOT have more than n occurences of FOOBAR"). > > 6) "May contain other TLVs or future use" -- sure, but then you go > on to say "these MUST be ignored". Strictly speaking, that means > that you can't "future use" them either. How about: > > "May contain TLVs of other type, for future use. For the > purporse of the processing specified in this document, > such TLVs of unknown TLV type MUST be ignored". > > Note the subtlty here: "unknown TLV types" -- what does that > mean? We're actually back at the IANA/hierarchical/sub-TLV > discussion. Assuming that you have just one, flat IANA registry, > such as you actually have. An EXTERNAL-CONNECTIVITY TLV sure is > a "known TLV Type". If you get a DELEGATED-PREFIX TLV containing > an EXTERNAL-CONNECTIVITY TLV, is that valid, or must that be > ignored? It should be more clear now. We completely reorganized all TLV definitions into a single section. There are general rules (partly referencing those from DNCP rules), saying e.g. that integers are unsigned + network byte order by default and that TLVs may contain other sub-TLVs that MUST be ignored. In general we switched from defining “what should can be in a container” to “where might a TLV occur” so this is now clearly defined for each TLV and the text says other occurrences MUST be ignored. > So, with the current set-up of IANA registries, the "unknown TLV > types" is not the right phrase. > > My preference in this sort of situation is actually to set up > hierarchical IANA registries: > > o DNCP sets up the top-level TLV type registry. > o HNCP specifies (from within that regitry) the > EXTERNAL-CONNECTIVITY TLV type, which: > o Sets up a new registry for sub-TLV types > o Allocates the DELEGATED-PREFIX from that new > registry > > (and so on). > > What it does is to set up a context in which "unknown TLV type" > (and such) means something -- and also solves the rest of the > processing context comments above > > Alternatively, sure, you could put something like: > > > "May contain TLVs of other type, for future use. For the > purporse of the processing specified in this document, > TLVs of types other than FOO, BAR, FOOBAR, and GNYF type > MUST be ignored". > > IMO this is less flexible and leads to more repetition. As noted, we redefined TLV definitions to state where they can occur. We are sticking with a single TLV space for now since it is probably more easy to manage and grasp, also we already have at least one TLV already which can occur in different containers which would also cause duplication then. > o Section 6.1.2 > > The document reads: > > "Valid Lifetime: The time in seconds the delegated prefix is > valid. The value is relative to the point in time the Node-Data TLV > was last published. It MUST be updated whenever the node > republishes its Node-Data TLV." > > I just can't parse that. Well, I can, but what I get doesn't make > sense to me: > > "relative to the point in time the Node-Data TLV was last published" > > So, I publish a NODE-DATA TLV. Must I now remember when I did that, say, > at t0, and then next time I publish a NODE-DATA TLV include (t-t0) as Valid > Lifetime? That does look like what the text says, but it also > doesn't sound like a "Vaid Lifetime". Given the name of the field, > Lifetime, I would expect it to mean "Upon receiving this TLV, please > consider the information valid for this much time" -- but, that's not what the text says. > > Same comment applies to Preferred Lifetime Names changed to “Valid/Preferred Lifetime Since Origination” and added descriptive text. > Also, from this section: > > "* Zero or more Prefix Domain TLVs. In absence of any such TLV > the prefix is assumed to be generated by an HNCP-router and for > internal use only." > > Could gain from being a little more specific: what is "internal use > only" (internal to whom?) -- related to my previous comment about > definition of External/Internal. Also "use" -- do you mean that "this > prefix MUST NOT be leaked externally, i.e., addresses from within this > prefix MUST NOT be used as a source address for traffic outside the > homenet? If so, does this mean that you allow a homenet router to grab > any odd global prefix and treat as private? Or, is this a matter of > simply reflecting the already existing "don't route 192.168/16" (and > equiv.) rules? > > Either way, that needs to be clarified. Got rid of that imbagiuous wording, IPv4 / ULA generation deals with locally generated prefixes. > > o 6.2.1 > > "All HNCP nodes running the prefix assignment algorithm MUST use the > following parameters:" > > First, I think that an element of clarification would be good. These > parameters, where are they from? Do they come from > [I-D.ietf-homenet-prefix-assignment], are they in that specification > given as "optional" (so that one might get the idea to not use them), > or? > > Second, is it the parameters - or their values - that must be used? > > This goes a little bit deeper; I think that what you are doing here is, > in part, to specify "which values to assign to the different parameters > from [I-D.ietf-homenet-prefix-assignment]" -- although that document > is not particularly clear on which parameters form the interface to HNCP > and to other protocols. > > But, the question is, what does it mean to "MUST use the following > parameters" here? I can see that using these terms/definitions in > the description of HNCP makes sense, but that does not a "MUST use > the following parameters" make. > > So, I simply do not understand what you intend with 6.2.1. Addressed, now simply stated as fact. > o Section 6.2.2, 6.3, etc.... > > This links in with previous comments regarding the hierarchy and > location of protocol elements. The TLVs defined herin, are they > "top level TLVs" or are they sub-TLVs, to be carried within another TLV? > And, what's the context of their processing. That should be clear now with the TLV reorganization as noted above. > > This point is particularly obscure since the protocol does not act > symmetric nor consistent here: > > o it defines an "EXTERNAL-CONNECTION" TLV (which really > is what other protocols would call a "messagge") which > carries sub-TLVs that have to do with describing "EXTERNAL > CONNECTIONS". > > o But, for Prefix Assignments, it does, as far as I can tell, > not define a "PREFIX-ASSIGNMENT" message (apologies, TLV) > which contains the related sub-TLVs > > I would like to see this through through -- ideally, re-engineered to > be homogenous and consistent, but (at the very strict minimum) called > out and explained clearly. I do not see the point. The point of DNCP’s TLV ordering is to facilitate fast delta processing, and the more nested the TLV structures become, the less valuable it becomes (as you wind just removing+adding big container TLVs). Due to that, HNCP TLV space was originally defined to be _as flat as possible_ given the data structures being encoded (-Markus). Furthermore I think that the term message is incorrect here since External-Connection is a container simply for reasons of aggregation: “An External Connection TLV is a container-TLV used to gather network configuration information associated with a single external connection.“ and a single router might have multiple external connections (i.e., a second uplink) and with that more than one EC TLVs, so the aggregation is necessary to correlate and distinguish between multiple connections of a multi-homed router. Prefix Assignment (TLVs) do not need any aggregation since they are “self-sufficient”. You can simply find the delegated prefix they belong to (based on significant bits) but that’s all there is to it. There is no auxiliary data and no additional policy for an assigned other than what is encoded in the AP TLV itself. (-Steven) > o 6.2.3. Making New Assignments > > "Whenever the Prefix Assignment Algorithm subroutine is run on a > Common Link and whenever a new prefix may be assigned (case 1 of the > subroutine), the decision of whether the assignment of a new prefix > is desired MUST follow these rules: " > > Hold on there for a second: > > 1) What is "the Prefix Assignment Algorithm subroutine"? Throw a > citation into [I-D.ietf-homenet-prefix-assignment] here, so > the random reader knows what you're talking about -- and, a > section reference, also. Added. > 2) This is exacerbated by the fact that the descripton pointing to > "case 1 of the subroutine". > I guess that that correspinds to "bullet number 1" on page 9 > in [I-D.ietf-homenet-prefix-assignment], but in a proposed > standard, guessing should not be needed. Updated to be more descriptive. > 3) > That aside, subroutines are programming constructs, not > specification elements. Just out of spite, I'll go implement > HNCP using GOTO's instead of "subroutines" > Agreed. Go hunt Pierre down. Can I take you up on that implementation? :P (-Steven) > 4) I notice that sometimes this is called the "Distributed Prefix > Assignment Algorithm", at other times "prefix assignment algorithm”, > then "Prefix Assignment Algorithm subroutine", etc. > > o Are they all the same? > o If yes, then why are they written, and capitalized, > differently? > o If no, then what're the differences between them? Unified, got rid of the “distributed”, was probably just buzzword bingo fodder. > > Next, the document reads: > > "If the Delegated Prefix TLV contains a DHCPv4 or DHCPv6 Data TLV, > and the meaning of one of the DHCP options is not understood by > the HNCP router, the creation of a new prefix is not desired. > This rule applies to TLVs inside Delegated Prefix TLVs but not to > those inside External Connection TLVs." > > What does "is not desired" mean? > > "...a new prefix MUST NOT be created?" > "...a new prefix SHOULD NOT be created?" > "...a new prefix MAY be created, but is not necessary?" PA ‘subroutine’ in PA draft specifies it - ‘desired’ stuff is done something about. I do not think we want to replicate the logic here. > The document reads: > > "If the remaining preferred lifetime of the prefix is 0 and there > is another delegated prefix of the same IP version used for prefix > assignment with a non-null preferred lifetime, the creation of a > new prefix is not desired." > > Suggest replacing "non-null" by "non-zero" -- but, beyond that, what > does "is not desired" mean? Replaced, but see above. ‘desired’ is PA term. > Same comment for the next paragraph: > > "Otherwise, the creation of a new prefix is desired" > > > Am I right in reading these three paragraphs as: > > 1) If then new prefix MUST NOT be created > 2) if then new prefix MUST NOT be created > 3) Otherwise, if then new prefix MUST be created > > That is how the text reads, which begs the question: > > Is it possible for , , and > to all not be satisfied, and what happens in that case? > > I *think* that this is a case of underspecification, or at least where > it looks like there's a case of underspecification. Correct. 3) was apparently added a condition later. Modified 3), and added 4) which is unconditional ‘MUST NOT’. > o 6.2.4: > "MUST create an appropriate route ..." > > What's "an appropriate route"? > Do you mean "install entry into the routing table", or do you mean to > launch a routing process to discover, calculate, or otherwise obtain > that route? > Do you need the entire path, or just the "next hop towards ..."? Got rid of the route thing, replaced with “MUST forward traffic destined to said prefix to the respective link.“ > o 6.2.6 > "When an HNCP router receives a request for prefix delegation ..." > > OK, how does a HNCP router receive such a request? Grepping through the > document fpr "request" I see no protocol signals that correspond to > this. Addressed (it talks about DHCPv6-PD). > Then, this: > "The assigned prefixes MUST NOT be given to clients" > > made me wonder what a "client" is. I see DHCPv6/v4 client used, > occasionally, and in other places I see just "client" -- is this > intentionally, and, if so, what is a "client"? DHCPv6-PD client of a legacy router. Replaced client with that in this paragraph. > o 6.3 > > "Nodes MAY, at any time, try to reserve a new address from any > applied Assigned Prefix" > > What is an "applied Assigned Prefix". Given capitalization, it is an > "Assigned Prefix" that is applied somewhere, I suppose, but where and > to what? “Applied Assigned Prefix” is a PA term, correctly capitalized and added PA terminology import. > The document reads: > > For any assigned prefix for which SLAAC cannot be used, the first > quarter of the addresses are reserved for routers HNCP based address > assignments, whereas the last three quarters are left to the DHCPv6 > (resp. DHCPv4) elected router (Section 10 specifies the DHCP server > election process). For instance, if the prefix 192.0.2.0/24 is > assigned and applied to a Common Link, addresses included in > 192.0.2.0/26 are reserved for HNCP nodes and the remaining addresses > are reserved for the elected DHCPv4 server. > > Why "the first quarter"? It seems a rather arbitrary value? Is it known > to be enough/too much/too little? It is arbitrary. However, all routers must use same scheme, so we specified an arbitrary value. Please come up with a better one if you can :) > "HNCP routers assign themselves addresses using the Node Address > TLV" > > > OK, but...do they send that TLV to themselves? Or do they send it to > someone else, or ...? Added some text. > Part of the answer to this question is embedded in the text below the > picture in section 6.3, but not all -- and, I believe, this is potentially another problem of more global scope. > > Generally, for each message (or TLV) it's good to know how it is formatted, but it's fantastic to know also how it's generated and > how it is processed. I fali to find that (through and through) in this > document, and that makes it harder to implement. > > Would it be possible to do something like this, (generally, for the TLV > types defined?): > > Section X. FOOBAR TLVs > > > Section X.1 Generation > A FOOBAR TLV is generated when a, b, c happens. > > When generating a FOOBAR TLV, its content is determined as > follows.... > > Section X.2 Processing > On receiving a FOOBAR TLV, take the following steps ... > > That would also be the place (in X.1) to state where > to put information (for example, when a TLV must be inside another TLV) > or constraints on processing (X.2) for example if a TLV is invalid > unless if contained inside another TLV. As mentioned, we have a centralized TLV section now, though not as structured as you suggested (no generation, processing etc), instead we added references back to appropriate sections that discuss generation and processing. So there might be a bit room for improvement still. > o 9 Securing Third-Party Protocols > > I take issue with the below: > > "Pre-shared keys (PSKs) are often required to secure IGPs and other > protocols which lack support for asymmetric security." > > Pre-shared keys are chosen, in some scenarios and for whatever reasons, > regardless of the capacity of the underlaying protocols -- even when > the protocol(s) (IGP or otherwise) are fully capable of and completely > supports assymetric security. Please address this by a less broad claim > for when PSK are used. Added ‘for example’, it does not really aim to be comprehensive. Alternatively we also accept comprehensive text. That said, out of scientific curiosity, what percentage of _deployed_ IGPs support asymmetric crypto? > But, I wonder, reading this section as a whole: you generate, and > distribute through HNCP, a PSK? So all it takes to get access to said > key is to sit by and passively listen to traffic for a bit? That does strike me as a dangerous option to have...reading the security > considerations section, there seems to be nothing securing HNCP against > eavesdropping -- or, if there is, that's not called out. > > I note that the security considerations of DNCP start out by saying: > > "If specified in the DNCP profile, either DTLS [RFC6347] or TLS > [RFC5246] may be used to authenticate and encrypt either some (if > specified optional in the profile), or all unicast traffic" > > And, section 3 of HNCP states: > > o HNCP unicast traffic SHOULD be secured using DTLS [RFC6347] as > described in DNCP if exchanged over unsecured links. UDP on port > HNCP-DTLS-PORT is used for this purpose. A node implementing HNCP > security MUST support the DNCP Pre-Shared Key method, SHOULD > support the DNCP Certificate Based Trust Consensus and MAY support > the PKI-based trust method. > > Note the "SHOULD" and the conditonals "unsecured links" (not sure > what this would be, precisely). I do not know anything meaningful about > DTLS, but I would imagine that sking the SEC-DIR folks about its use > would make sense. > > All that said...sadly, in many conditions and scenarios "getting > security to work is hard" and in a home scenario the choice (to minimize > the amount of support calls, ...) it would not be hard to imagine either > turning OFF or using lowest-common-denominator security. > > Say "nothing" over an Ethernet "because physical access required", and > WEP for WiFi (yes, people still do that) and then declare links "not > unsecured" and therfore consider it legitimate to not implement the SHOULD. > > Effectively, what I fear here is that if HNCP "proposes to share PSKs" > then a (slightly naive) process might actually trust those PSKs to be > useful for security -- which, in fact, they are not since they can be > exposed by simple eavesdropping? > > I'd really like a bullet-proof guarantee that any shared PSKs can't have > been (easily) eavesdropped on -- or, would ratehr that HNCP does not > tempt the use of compromized PSKs. If you do not have L2 link security (either crypto or rabid attack dogs), yet insist on not using HNCP security (e.g. DTLS), the game is lost already. I do not think we can exhaustively enumerate the broken L2s here, as I believe e.g. currently _about anything wireless_ is broken (you can mount off-line dictionary attacks on keys of WPA*, not to even mention TKIP, or WEP). WPA2-Enterprise has non-broken modes (from my point of view) but that is it, and that is also subject to change based on future results. Added some text that the scheme SHOULD be used only with secured unicast transport, and why (the correct reasoning is bit more complex what you say). Bullet-proof guarantee seems rather hard, as we do not want to have MUST on the security in general. Also absent of this approach there is nothing which naturally creates any PSK so the probable outcome would be that protocols requiring some sort of PSK for authentication (like many PSKs) would in practice probably more likely be used completely unsecured. > o Section 10 > What's the solution if the message format changes? For example, that the > type field needs to grow/shrink? > > I've mentioned this in my DNCP review, but I strongly believe that it is > required to have versioning also capture "the frame format", and not > just the "payload". We reserved 6 bits in the Type-Field of TLV in DNCP for that purpose. > Minor Issues: > > o General comments: > > o I recommend using "non-zero" when referring to numerical values, > and not "non-null" Changed. > o Abstract > > Questions: is it clear what "naming" referres to? Is it "name resolution"? > Idem for "network borders", do you configure those, or discover those? > > Routing-specific question here: > What does "seamless use of a routing protocol" mean? That any IP > routing protocol can be used unmodified? I *think* that that's not > the case, given that the use-case that is often trotted for homenet > includes a multi-homed home - and the introduction says as much so > the abstract probably should reflect that. > > How about somehting like this for the abstract: > > "This document describes the Home Networking Control Protocol > (HNCP), an extensible configuration protocol and a set of requirements for home network devices. HNCP is described as a > profile of and extension to the Distributed Node Consensus Protocol (DNCP). HNCP enables automated configuration of addresses, name > resolution, discovery of network borders, and the use of any > src-dest-routing capable routing protocol. Used (and added service discovery, which differs from name resolution). > o Introduction > "HNCP synchronizes state across a small site in order to allow..." > > What precisely is a "small site"? Can we qualify that in terms of, say, > number of routers? > "The protocol enables use of border discovery" > > I am not sure that I understand what this means -- in which way is > border discovery *enabled*? Or, do you mean "This protocol discovers > borders"? Or something else? > > "naming and other services across multiple links." > > So, the first paragraph teaches me that HNCP is applicable somewhere not > too big -- but, of course, I do not know what exactly that is -- , and > it does "some stuff, and other services" -- but, of course, I do not > know what those are, or how they are characterized. That's a little > imprecise for an introduction. > > Suggest being extremely precise. Something like: > HNCP "Synchronizes state" by way of [dncp], and specifies and uses > state for providing the following network services: > o FOO > o BAR > o FOOBAR > > All specified in this document. Additionally, HNCP enables other > services, characterized by ______, for example prefix assignment as > defined by [I-D.ietf-homenet-prefix-assignment] > > Which brings me to a question. The abstract, and introduction, state > that HNCP "enables automated configuration of addresses" -- how is that > different from [I-D.ietf-homenet-prefix-assignment]? Or, is the answer > "it isn't, that I-D is required to do that", in which case what does it > mean that HNCP "enables" it? > > [Of course, reading the document it becomes clear that HNCP does this > by way of a normative reference to [I-D.ietf-homenet-prefix-assignment], > but the abstract and introduction really are unfortunately phrased] > > Reading just the introduction, I'd like to be able to know what HNCP > would bring me, exactly? Implementing and turning on HNCP would do what > to my network? Intro is hopefully better now. (Further improvements welcome of course.) > o 3. DNCP Profile > > "HNCP is defined as a profile of DNCP..." > > Is it not more correctly to say that" > > "HNCP is a profile for DNCP..." > > ? Changed text in general, n/a now. > "HNCP routers MUST assign a unique 32-bit endpoint identifier to > each interface for which HNCP is enabled." > > Any additional requirements to that identifier? Reading into DNCP, that > is actually not entirely clear there. I *think* that the endpoint > identifier MUST be unique to the local node, but that there's no > requirement beyond that -- correct? Yes, it said ‘unique’, but now saying ‘locally unique’. > Could that be called out both in this document, and perhaps in DNCP more > clearly? Addressed in DNCP. > Following the above: > > "The value zero is reserved for internal purposes." > > What internal purposes would that be? Reading through, hidden in the > description of the frame format (6.2.2) I read: > > "The endpoint identifier of the local interface > that belongs to the Common Link the prefix is assigned to, or 0 if > the Common Link is a Private Link (e.g., when the prefix is > assigned for downstream prefix delegation)." > > OK, so leaving that slightly odd phrasing (and the notion of "Common > Link" and "Private Link" -- both of which we will come back to) for a > later comment, can we not bring this up to section 3, thus: > > > "HNCP routers MUST assign a 32-bit endpoint identifier, unique to > the local node, to each interface for which HNCP is enabled. The > value zero MUST NOT be used, except as endpoint identifier for an > interface towards a Private Common Link" > > ? Added reference to TLVs that specify 0 behavior (it isn’t quite that either). > [but, I am no great fan of "Private Link" or "Common Link", see other comments] > > About this: > "Received datagrams with an IPv6 source or destination address which > is not link-local scoped" > > How about: > "Received datagrams where either or both of the IPv6 source or > destination address is not link-local scoped" > > ? Changed. > As a general comment, this section contains an unordered set of bullets, > where a grouping and some common discussion probably would make sense. > For example, a few concern security directly (e.g., 3 & 5) but are not > really DNCP parametrizations -- whereas others are (e.g., 6, 7, 8). > The bullet-set reads somewhat like "the kitchen sink". > (Numbers indicate count from the first bullet in the block). Moved security to the end as it is SHOULD; also Trickle parameters (same reason). This _is_ the kitchen sink ;) > o 5. Border Discovery > > The document reads: > "A router MUST allow setting a category of either auto-detected, > internal or external for each interface which is suitable for both > internal and external connections. In addition the following > specializations of the internal category are defined to modify the > local router behavior:" > > What defines if an interface is "suitable" for an external, or internal, > or both, connections? What does "connections" mean in this context? What > requirements are there for an interface to be "suitable" respectively > "unsuitable"? Rephrased “Each HNCP router SHOULD allow setting the category for each interface which may be connected to either an internal or external device (e.g., an ethernet port that can be connected to a modem, another HNCP router or a client).“ > As part of the discussion of the different categories, some are declared > as SHOULD, others as OPTIONAL. I do not see any which are MUST. I see > that the two SHOULD should be MUST Clarified now, Internal is MUST for all nodes, External is additional MUST for routers. > Also: > > Hybrid category: This declares an interface to be internal while > still running DHCPv4 and DHCPv6-PD clients on it. It is assumed > that the link is under control of a legacy, trustworthy non-HNCP > router, still within the same network. Detection of this category > automatically in addition to manual configuration is out of scope > of this document. Support for this category is OPTIONAL. > > What makes a router "legacy"? What makes it "trustworthy"? Changed to “This is useful, e.g., if the link is shared with a non-HNCP router under control and still within the borders of the same network.” > o In section 6.1.2 I see: > > "Nested TLVs: Other TLVs included in the Delegated Prefix TLV and > starting at the next 32-bit boundary following the end of the > encoded prefix:" > > "Prefix: Significant bits of the prefix padded with zeroes up to > the next byte boundary." > > Question: > Other than "because historically that's how we did things, > because, at the time, that was a good idea", is there any good > reason that you're insisting on byte/32-bit alignments here? It's > been a good while since I've personally written code where 32 bit alignment was a major concern -- but, when generating a packet I > sure could see it as a minor nuisance to do the alignment. > So, I actually see this as "a nuisance introduced in packet > generation, for no real gain in parsing". > > (Note that this is in the MINOR category, though) Force of habit. I am not convinced it is good idea anymore either, but perhaps late to change (-Markus). > o 6.2.3: > > "In any case, a router MUST support a mechanism suitable to > distribute addresses from the considered prefix if the link is > intended to be used by clients. In this case a router assigning an > IPv4 prefix MUST support the L-capability and a router assigning an > IPv6 prefix MUST support serving router advertisements. In > addition if an assigned IPv6 prefix is not suitable for Stateless > Address Autoconfiguration the router MUST also support the > H-capability as defined in Section 10. > > To your credit, you put a forward pointer to Section 10. With that being said, would it not be more logical to discuss that (which appears as "the overall message format of HNCP") somewhere earlier? Moved Versioning section to the beginning. > Nits: > > o Any reason why some TLV types are written in ALL-CAPS whereas others in > Hyphenated-Camel-Case? Found one (managed-psk) and fixed. > o I saw a few "e.g." and "i.e.", which I believe the style guide > prescribes should be "i.e.," and "e.g.,". Yeah, the RFC Editor will > catch this ultimately, but if you re-spin the document then might as > well make their life just a bit easier ;) Addressed. From nobody Sat Aug 8 03:30:36 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366561A1BB4; Sat, 8 Aug 2015 03:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Fto2gQ9gTJR; Sat, 8 Aug 2015 03:30:27 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36C811A1BAC; Sat, 8 Aug 2015 03:30:27 -0700 (PDT) Received: by pdbfa8 with SMTP id fa8so14088419pdb.1; Sat, 08 Aug 2015 03:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:references:mime-version:message-id :content-type; bh=ptWHOfzHQyZRtFhHE7T14BEdMet7ZyQiJpdRD9XaKCY=; b=bnCNy5j9pPLj7x8wAKVxNE9wLhEMavVdzLlwA7YAWXXGpm+NHyc0UfRli82XbC9h8y paEk6S4E33F+3aPp8KsN4W5nsVKhyPDg6fovx6U4MFw4kC2iICEkB6wlACGk33udlJbc 7mWs24foErwd6rshT61BJfnhtlXFKheCtsW01ZhFRbPAzznmMui90hIMlXDZISRXePYW 0f/1x+J//JNnUz5qbzJEIH24qpfY7oYrVWaEFyZudLYcP/9fL0yysX690N5JU45rBsfa SfOQIgqAA2PDBmtIyqcNAhBxopatpio2BPODbCK5z7Kaxeru+I5ZziZNYa/5Wcrq1vUD yGzw== X-Received: by 10.70.126.193 with SMTP id na1mr25249477pdb.26.1439029826673; Sat, 08 Aug 2015 03:30:26 -0700 (PDT) Received: from Lizhong ([27.24.141.109]) by smtp.gmail.com with ESMTPSA id xw4sm13011889pbc.69.2015.08.08.03.30.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Aug 2015 03:30:24 -0700 (PDT) Date: Sat, 8 Aug 2015 18:31:14 +0800 From: "lizho.jin@gmail.com" To: Jiangyuanlong , rtg-ads References: , <3B0A1BED22CAD649A1B3E97BE5DDD68B5A900449@szxema506-mbs.china.huawei.com> X-Priority: 3 X-GUID: C92A02EB-B17A-4BE2-9E00-37FDF85C485F X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 140[en] Mime-Version: 1.0 Message-ID: <20150808183111884135100@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart064338447445_=----" Archived-At: Cc: rtg-dir , draft-ietf-l2vpn-vpls-pe-etree , pals Subject: Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 10:30:33 -0000 This is a multi-part message in MIME format. ------=_001_NextPart064338447445_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksIEkgbWlzc2VkIHRoZSBlbWFpbCwgYW5kIHNvcnJ5IGZvciB0aGUgbGF0ZSByZXBseS4gUGxl YXNlIHNlZSBpbmxpbmUgYmVsb3cuIA0KDQoNCg0KUmVnYXJkcw0KTGl6aG9uZw0KIA0KRnJvbTog Smlhbmd5dWFubG9uZw0KRGF0ZTogMjAxNS0wNi0xMSAwNTo0OA0KVG86IExpemhvbmcgSmluOyBy dGctYWRzDQpDQzogcnRnLWRpcjsgcGFsczsgZHJhZnQtaWV0Zi1sMnZwbi12cGxzLXBlLWV0cmVl QHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSRTogW1BhbHNdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0 LWlldGYtbDJ2cG4tdnBscy1wZS1ldHJlZS0wNy50eHQNCkxpemhvbmcsIA0KIA0KVGhhbmsgeW91 IGEgbG90IGZvciB0aGUgcmV2aWV3LCBwbGVhc2Ugc2VlIG15IGNvbW1lbnRzIHdpdGggW0pZXSBh cyBhIHByZWZpeC4NCiANClJlZ2FyZHMsDQpZdWFubG9uZw0KIA0KRnJvbTogUGFscyBbbWFpbHRv OnBhbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExpemhvbmcgSmluDQpTZW50OiBU dWVzZGF5LCBKdW5lIDAyLCAyMDE1IDU6NTUgUE0NClRvOiBydGctYWRzDQpDYzogcnRnLWRpcjsg cGFsczsgZHJhZnQtaWV0Zi1sMnZwbi12cGxzLXBlLWV0cmVlQHRvb2xzLmlldGYub3JnDQpTdWJq ZWN0OiBbUGFsc10gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1sMnZwbi12cGxzLXBlLWV0cmVl LTA3LnR4dA0KIA0KSGVsbG8sIA0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcg RGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9y YXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRz IGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5k IHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcg aXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5m b3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0 cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpciANCkFsdGhv dWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRp bmcgQURzLCBpdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFs b25nIHdpdGggYW55IG90aGVyIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2Vp dmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1 cGRhdGluZyB0aGUgZHJhZnQuDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1sMnZwbi12cGxzLXBlLWV0 cmVlLTA3LnR4dCANClJldmlld2VyOiBMaXpob25nIEppbg0KUmV2aWV3IERhdGU6IDJuZCBKdW5l DQpJRVRGIExDIEVuZCBEYXRlOiANCkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQpT dW1tYXJ5OiANCkkgaGF2ZSBzb21lIG1pbm9yIGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQg dGhhdCBJIHRoaW5rIHNob3VsZCBiZSByZXNvbHZlZCBiZWZvcmUgcHVibGljYXRpb24uIA0KQ29t bWVudHM6DQpPdmVyYWxsLCBhbHRob3VnaCB0aGVyZSBpcyBubyBtYWpvciB0ZWNobmljYWwgaXNz dWVzIGZvciB0aGlzIGRyYWZ0LCBpdCBpcyBzdHJvbmdseSBzdWdnZXN0ZWQgdG8gaW1wcm92ZSB0 aGUgRW5nbGlzaCBkZXNjcmlwdGlvbiB0byBtYWtlIGl0IG5lYXQsIGFuZCBlYXNpZXIgdG8gYmUg dW5kZXJzdG9vZC4NCk1ham9yIElzc3VlczoNCk5vIG1ham9yIGlzc3VlcyBmb3VuZA0KTWlub3Ig SXNzdWVzOg0KMS4gICAgICAgQWJzdHJhY3Q6IOKAnHNlcnZpY2Vz4oCdIHNob3VsZCBiZSDigJxz ZXJ2aWNl4oCdDQpbSlldIE5vdCBuZWVkZWQsIHNpbmNlIG11bHRpcGxlIEUtVHJlZSBzZXJ2aWNl cyBtYXkgYmUgZGVwbG95ZWQgaW4gYSBzaW5nbGUgVlBMUyBuZXR3b3JrLCBhbmQgdGhlIHNvbHV0 aW9uIGFpbXMgdG8gc3VwcG9ydCB0aGlzIHNjZW5hcmlvLg0KW0xpemhvbmddIFRoZW4gd2h5IHlv dSB1c2UgInVzZXMiIHRvIGRlc2NyaWJlICJzZXJ2aWNlcyI/IEkgYW0gcmVmZXJyaW5nIHRoZSBn cmFtbWFyIGVycm9yIGhlcmUuDQoNCjIuICAgICAgIEFic3RyYWN0OiDigJx0aGUgTUFDIGFkZHJl c3MgYmFzZWQgRXRoZXJuZXQgZm9yd2FyZGluZyBlbmdpbmUgYW5kIHRoZSBQVyB3b3JrIGluIHRo ZSBzYW1lIHdheSBhcyBiZWZvcmXigJ0sIHlvdSBzaG91bGQgdGVsbCB0aGUgZGV0YWlsIG9mIOKA nGJlZm9yZeKAnSBoZXJlLCBvciBhZGQgYSByZWZlcmVuY2UgaGVyZS4NCltKWV0gQWN0dWFsbHks IFNlY3Rpb24gNCBhbmQgNSBkZXNjcmliZSB0aGUgZGV0YWlscyBvZiBob3cgdGhlIEV0aGVybmV0 IGZvcndhcmRpbmcgZW5naW5lIGFuZCB0aGUgUFcgd29yay4gSSBkb24ndCB0aGluayB3ZSBuZWVk IHRvIGRlc2NyaWJlIHRoZSBkZXRhaWxzIGluIGFuIGFic3RyYWN0aW9uIG9yIGZvcndhcmQgcmVm ZXJlbmNlIGFueSBzZWN0aW9ucyBpbiB0aGUgZG9jdW1lbnQgaGVyZS4NCltMaXpob25nXSBJIGRv IG5vdCBhZ3JlZS4gVGhlIGFic3RyYWN0IHNlY3Rpb24gc2hvdWxkIGdpdmUgb3V0IHRoZSBvdXRs aW5lIG9mIHdob2xlIGNvbmNlcHQuIFVzZSB3b3JkICJiZWZvcmUiIGRvZXMgbm90IHByb3ZpZGUg YW55IGluZm9ybWF0aW9uIGZvciB0aGUgcmVhZGVycy4NCg0KMy4gICAgICAgQWJzdHJhY3Q6IOKA nGlz4oCdIHNob3VsZCBiZSDigJxhcmXigJ0NCltKWV0gVGhlcmUgYXJlIDMgY2FzZXMgb2YgImlz IiBpbiB0aGUgYWJzdHJhY3Rpb24sIGJ1dCB0aGUgc3VnZ2VzdGVkIGNoYW5nZSBpcyBub3QgYXBw bGljYWJsZSB0byBhbnkgb2YgdGhlbS4gRnJvbSB0aGUgc2VxdWVuY2UgaXQgc2VlbXMgeW91IGFy ZSByZWZlcnJpbmcgdG8gdGhlIGxhc3Qgb25lLCBidXQgdGhlIHN1YmplY3QgIkEgc2lnbmFsaW5n IG1lY2hhbmlzbSIgaXMgbm90IHBsdXJhbC4NCltMaXpob25nXSBPSywgc2luY2Ugc2lnbmFsaW5n IG1lY2hhbmlzbSBhbHNvIGluY2x1ZGUgVkxBTiBtYXBwaW5nLCB0aGVuIEkgc3VnZ2VzdCB0byBj aGFuZ2UgIlZMQU4gbWFwcGluZyBuZWdvdGlhdGlvbiIgdG8gIkUtVHJlZSBhdHRyaWJ1dGUiLg0K DQo0LiAgICAgICBTZWN0aW9uMyBvdmVyYWxsLCBzdWdnZXN0IHRvIHJlb3JnYW5pemUgc2VjdGlv biAzLiBTcGxpdCB0aGUgc2VjdGlvbiBpbnRvIHR3byBwYXJ0czogMS4gSW50cm9kdWN0aW9uOyAy LiBNb3RpdmF0aW9uDQpbSlldIFRoaXMgaXMgcmVsYXRlZCB0byBxdWVzdGlvbiA2IGFuZCA5LCBu b3Qgc3VyZSB3aGF0IGlzIHRoZSBwcm9ibGVtIHlvdSBhcmUgdHJ5aW5nIHRvIHNvbHZlIGFzIGEg d2hvbGUuDQpbTGl6aG9uZ10gbm90IHdlbGwgb3JnYW5pemVkIGluIHRoaXMgc2VjdGlvbi4gTGV0 IFdHIHRvIGRlY2lkZS4NCg0KNS4gICAgICAgU2VjdGlvbjM6IOKAnGluIGZhY3QsIHRoZXJlIGlz IG5vIGV4YWN0IGNvcnJlc3BvbmRpbmcgdGVybWlub2xvZ3kgaW4gSUVURiB5ZXQu4oCdIOKAnHRl cm1pbm9sb2d54oCdIGNvdWxkIG5vdCBiZSBhIHJlYXNvbi4gWW91IHNob3VsZCBsaXN0IHRoZSB0 ZWNobm9sb2d5IHJlYXNvbiBpZiB5b3Ugd2FudCB0byBjb21wYXJlLg0KW0pZXSBUaGlzIHNlbnRl bmNlIHNpbXBseSBwb2ludHMgb3V0IHRoZSBmYWN0IHRoYXQgRS1UcmVlIGlzIGEgbmV3IHR5cGUg b2Ygc2VydmljZSAobm8gY29ycmVzcG9uZGluZyBzZXJ2aWNlIGRlZmluZWQgaW4gSUVURiB5ZXQp LCB0aGUgdGVjaG5pY2FsIGNvbXBhcmlzb24gaXMgZG9uZSBpbiB0aGUgRS1UcmVlIGZyYW1ld29y ayBhbmQgaXMgcmVmZXJlbmNlZCBpbiB0aGUgbmV4dCBwYXJhZ3JhcGggb2YgdGhpcyBkb2N1bWVu dC4NCltMaXpob25nXSBQbGVhc2Ugc2VlIHRoZSB3aG9sZSBzZW50ZW5jZSBJIGFtIHJlZmVycmlu ZzoNCkFsdGhvdWdoIFZpcnR1YWwgUHJpdmF0ZSBNdWx0aWNhc3QgU2VydmljZSAoVlBNUykKICAg W1ZQTVNdIG9yIFBvaW50LXRvLU11bHRpcG9pbnQgKFAyTVApIG11bHRpY2FzdCBpcyBhIHNvbWV3 aGF0CiAgIHNpbXBsaWZpZWQgdmVyc2lvbiBvZiB0aGlzIHNlcnZpY2UsIGluIGZhY3QsIHRoZXJl IGlzIG5vIGV4YWN0CiAgIGNvcnJlc3BvbmRpbmcgdGVybWlub2xvZ3kgaW4gSUVURiB5ZXQuSSBj b3VsZCBub3QgdW5kZXJzdGFuZCB3aHkgeW91IHNheSB0aGUgInRlcm1pbm9sb2d5IiBoZXJlIHJl ZmVyIHRvIEUtVHJlZS4NCjYuICAgICAgIFNlY3Rpb24zOiDigJxUaG91Z2ggdGhlcmUgd2VyZSBw cm9wb3NhbHMgb24gdXNpbmcgUFcgY29udHJvbCB3b3JkIG9yIFBXcyB0byBpbmRpY2F0ZSB0aGUg cm9vdC9sZWFmIGF0dHJpYnV0ZSBvZiBhbiBFLVRyZWUgZnJhbWUsIGJvdGggbWV0aG9kcyBhcmUg bGltaXRlZCBpbiB0aGF0IHRoZXkgYXJlIG9ubHkgYXBwbGljYWJsZSB0byAiVlBMUyBvbmx5IiBu ZXR3b3Jrcy7igJ0gWW91IHNob3VsZCBoYXZlIHJlZmVyZW5jZSBmb3Igb3RoZXIgcHJvcG9zYWxz LiBCdXQgSSBkb27igJl0IHRoaW5rIHlvdSBuZWVkIHRvIGxpc3QgdGhlc2UgcHJvcG9zYWxzLCBp bnN0ZWFkIG9ubHkgc2F5IHRoZSBtb3RpdmF0aW9uIG9mIHRoZSBWTEFOIGJhc2VkIHNvbHV0aW9u Lg0KW0pZXSBCb3RoIHJlZmVyZW5jZXMgd2VyZSBsaXN0ZWQgaW4gdGhlIG9sZGVyIHZlcnNpb25z IG9mIHRoaXMgZHJhZnQgaW5kZWVkLiBTaW5jZSB0aGVyZSBoYWQgYmVlbiBxdWl0ZSBhIGxvdCBv ZiBlbWFpbHMgZXhjaGFuZ2VkIG92ZXIgdGhlc2UgcHJvcG9zYWxzIGJlZm9yZSB0aGUgV0cgYWRv cHRpb24gb2YgdGhpcyBkcmFmdCwgdGhpcyBzZW50ZW5jZSBzaW1wbHkgcmVmbGVjdHMgYSBzdW1t YXJ5IG9mIHRoZSBjb25jbHVzaW9ucy4gV2UgY2FuIHJlbW92ZSBpdCBpbiB0aGUgbmV4dCByZXZp c2lvbiBpZiB0aGUgV0cgdGhpbmtzIGl0IGFwcHJvcHJpYXRlLg0KW0xpemhvbmddIE9LLg0KDQo3 LiAgICAgICBTZWN0aW9uNC4xOiDigJxGaWcuIDEgYW5kIEZpZy4gMiAoYm90aCBmaWd1cmVzIGFy ZSBleHRyYWN0ZWQgZnJvbSBbUkZDNjI0Nl0p4oCdLiBZb3Ugc2hvdWxkIHN3aXRjaCB0aGUgbnVt YmVyIG9mIEZpZzEgYW5kIEZpZzIsIHNpbmNlIEZpZzEgaXMgYSBkZXRhaWwgZGVzY3JpcHRpb24g b2YgRmlnMi4NCltKWV0gTm90IGV4YWN0bHksIEZpZy4xIGlzIG5vdCBqdXN0IGEgYmxvY2sgb2Yg RmlnLiAyLCBpdCBhbHNvIGRlc2NyaWJlcyBDRSBhY2Nlc3Mgd2hpY2ggaXMgbm90IHNob3duIGlu IGZpZy4yLiBNb3Jlb3ZlciwgdGhlIG9yZGVyIG9mIENFcywgdGhlIGJyaWRnZSBhbmQgdGhlIFZT SSBhcyB0aGV5IGFwcGVhciBpbiBGaWcuMSBhbmQgRmlnLjIgaXMgYWxzbyBtb3JlIGNvbnNpc3Rl bnQgd2l0aCB0aGVpciBuZXR3b3JrIHRvcG9sb2d5LiBIb3dldmVyLCBpZiB3ZSBzd2FwIEZpZy4x IHdpdGggRmlnLjIsIHRoZW4gRmlnLjEgd2lsbCBmb3J3YXJkIHJlZmVyZW5jZSB0byBGaWcuMiwg YW5kIHRoaXMgd291bGQgYmUgYW5vdGhlciBkaXNhZHZhbnRhZ2UuIA0KW0xpemhvbmddIFBsZWFz ZSByZWZlciB0byBSRkM2MjQ2LiBBbmQgbGV0IFdHIHRvIGRlY2lkZS4gVGhhbmtzLg0KDQo4LiAg ICAgICBTZWN0aW9uNC4xOiDigJxUaGVyZWZvcmUsIHRoZSBhc3NvY2lhdGlvbiBiZXR3ZWVuIGFu IEFDIHBvcnQgYW5kIGEgUFcgb24gYSBWU0kgaXMgZGlmZmljdWx0LCBzb21ldGltZXMgZXZlbiBp bXBvc3NpYmxlLuKAnSBDb3VsZCBub3QgdW5kZXJzdGFuZCB3aGF04oCZcyB0aGUgcHVycG9zZSBv ZiB0aGlzIHNlbnRlbmNlIGhlcmU/DQpbSlldIEl0IGlzIHByb3Bvc2VkIHRvIHVwZGF0ZSBpdCB3 aXRoOg0KIlRoZXJlZm9yZSwgdGhlIGFzc29jaWF0aW9uIGJldHdlZW4gYW4gQUMgcG9ydCBhbmQg YSBQVyBvbiBhIFZTSSB3aXRob3V0IHVzaW5nIGFueSBWTEFOIGlzIGRpZmZpY3VsdCwgc29tZXRp bWVzIGV2ZW4gaW1wb3NzaWJsZS4iDQpbTGl6aG9uZ10gc3RpbGwgbm90IGFncmVlLiBWTEFOIGlz IG5vdCBtYW5kb3RhcnkgZm9yIHRoZSBhc3NvY2lhdGlvbi4gVGhlcmUgYXJlIG1hbnkgaW1wbGVt ZW50YXRpb25zIGZvciBWUExTIHRvIGhhdmUgdGhlIGFzc29jaWF0aW9uIHdpdGhvdXQgVkxBTiwg ZS5nLiwgdmlydHVhbC9waHlzaWNhbCBwb3J0LiBJIGNvdWxkIG5vdCBzZWUgdGhlICJkaWZmaWN1 bHQiIGhlcmUuDQoNCjkuICAgICAgIFNlY3Rpb240LjE6IOKAnEFzc3VtaW5nIHRoaXMgbWVjaGFu aXNtIGlzIGltcGxlbWVudGVkIGluIHRoZSBicmlkZ2UgbW9kdWxlLCBpdCBpcyBxdWl0ZSBzdHJh aWdodGZvcndhcmQgdG8gaW5mZXIgYSBWUExTIFBFIG1vZGVsIHdpdGggdHdvIFZTSXMgdG8gc3Vw cG9ydCB0aGUgRS1UcmVlIChhcyBzaG93biBpbiBGaWcuIDMpLuKAnSBDb3VsZCBtb3ZlIHRoZSBh bmFseXNpcyB0byBtb3RpdmF0aW9uIHNlY3Rpb24sIG9yIHJlbW92ZWQuIEFuZCB0aGUgbG9naWMg aGVyZSBpcyBub3QgcmlnaHQuIFRoZSBsZWFmL3Jvb3QgVkxBTiBpbmRpY2F0aW9uIGlzIG9ubHkg Zm9yIGZpbHRlcmluZywgbm90IGJyaWRnaW5nLiBTbyBpdCBpcyBub3QgYWNjdXJhdGUgdG8gaGF2 ZSBSb290L0xlYXZlIFMtVkxBTiBoZXJlIHRvIGdldCB0aGUgZW5oYW5jZWQgbW9kZWwuDQpbSlld IFNvcnJ5LCBJIGFtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB5b3VyIHJlYXNvbmluZyBoZXJlLiBJ dCBpcyBhbHJlYWR5IGEgc3RhbmRhcmRpemVkIG1lY2hhbmlzbSB0byBlbmNhcHN1bGF0ZSBhbmQg c3dpdGNoIGFuIEUtVHJlZSBzZXJ2aWNlIGludG8gdHdvIFZMQU5zIGJ5IGEgYnJpZGdlIGFjY29y ZGluZyB0byBJRUVFIDgwMi4xUS0yMDExLiBIZXJlIGlzIHRoZSBvbmx5IGVuaGFuY2VtZW50OiBh IHJvb3QgVkxBTiBpcyBjb25uZWN0ZWQgdG8gYSByb290IFZTSSBhbmQgYWxsIHRoZSByb290IFZT SXMgaW4gcGVlciBQRXMgY29uc3RpdHV0ZSBvbmUgVlBMUyBpbnN0YW5jZSAod2l0aCBvbmUgbWVz aCBvZiBQV3MpLCBhbmQgYSBsZWFmIFZMQU4gaXMgY29ubmVjdGVkIHRvIGEgbGVhZiBWU0kgYW5k IGFsbCB0aGUgbGVhZiBWU0lzIGNvbnN0aXR1dGUgYW5vdGhlciBWUExTIGluc3RhbmNlICh3aXRo IGFub3RoZXIgbWVzaCBvZiBQV3MpLCBib3RoIFZQTFMgaW5zdGFuY2VzIGFyZSB0cmFuc3BhcmVu dCB0byB0aGUgRS1UcmVlIHRyYWZmaWMsIGFuZCBhbGwgdGhlIGZpbHRlcmluZyBvcGVyYXRpb25z IGFyZSBkb25lIG9uIHRoZSBicmlkZ2UgYWNjb3JkaW5nIHRvIHRoZSBJRUVFIDgwMi4xUSBtZWNo YW5pc20gKHRoYXQgaXMsIFZTSXMgZG8gbm90IG5lZWQgdG8gZmlsdGVyIGFueSBsZWFmIHRyYWZm aWMpLg0KW0xpemhvbmddIEkgbWVhbiB5b3VyIGluZmVycmluZyBpcyBub3QgcmlnaHQuIEluIFJG QzYyNDYsIGl0IHNheXM6DQpUaGUgYnJpZGdlCiAgIG1vZHVsZSBoYXMgYSBzaW5nbGUgIkVtdWxh dGVkIExBTiIgaW50ZXJmYWNlIG92ZXIgd2hpY2ggaXQKICAgY29tbXVuaWNhdGVzIHdpdGggYWxs IFZQTFMgZm9yd2FyZGVycywgYW5kIGVhY2ggVlBMUyBpbnN0YW5jZSBpcwogICByZXByZXNlbnRl ZCBieSBhIHVuaXF1ZSBTLVZMQU4gdGFnLg0KVGhhdCBpcyB0aGUgUy1WTEFOIGlzIHVzZWQgdG8g aW5kZW50aWZ5IFZMQU4gaW5zdGFuY2UuIEJ1dCBub3cgUy1WTEFOIGlzIHVzZWQgdG8gb25seSBp ZGVudGlmeSBFLVRyZWUgYXR0cmlidXRlLCB0aGVuIGl0IGlzIG5vdCByaWdodCB0byBhcHBseSA4 MDIuMWFkIGJyaWRnZSBtb2RlIHRvIGlsbHVzdHJhdGUgRS1UcmVlIG1vZGUuDQoNCjEwLiAgIFNl Y3Rpb240LjI6IOKAnGFuZCBvcHRpb25hbGx5IE1BWSBiZSBhZGRlZCB3aXRoIGFub3RoZXIgcm9v dCBTLVZMQU4u4oCdIFdoZW4gYW5kIHdoeSBhZGQgYW5vdGhlciByb290IFMtVkxBTiBoZXJlPyBB bmQgd2h5IHVzZSB0ZXJtaW5vbG9neSDigJxyb290IFMtVkxBTuKAnSwgbm90IHJvb3QgVkxBTiBh cyBpbmRpY2F0ZWQgaW4gRmlndXJlND8NCltKWV0gRmlndXJlIDQgaXMgYSBnZW5lcmFsaXplZCBk aWFncmFtLCB3aGVyZSBWTEFOIG1heSBiZSBhIEMtVkxBTiwgUy1WTEFOIG9yIEItVkxBTiwgdGhl IHRleHRzIGluIFNlY3Rpb24gNC4yIGRlc2NyaWJlIGVhY2ggY2FzZXMgb2Ygc3BlY2lmaWMgVkxB TnMgcmVzcGVjdGl2ZWx5Lg0KSXQgaXMgcHJvcG9zZWQgdG8gdXBkYXRlIHRoZSAxc3Qgc2VudGVu Y2UgIkluIG9yZGVyIHRvIHN1cHBvcnQgdGhlIEUtVHJlZSBpbiBhIG1vcmUgc2NhbGFibGUgd2F5 Li4uIiBpbiBTZWN0aW9uIDQuMiB3aXRoOg0KIkluIG9yZGVyIHRvIHN1cHBvcnQgdGhlIEUtVHJl ZSBpbiBhIG1vcmUgZ2VuZXJpYyBhbmQgbW9yZSBzY2FsYWJsZSB3YXkuLi4iDQpbTGl6aG9uZ10g QSB3b3JkICJnZW5lcmljIiBkb2VzIG5vdCBzb2x2ZSB0aGUgcHJvYmxlbS4gU2luY2UgeW91IGxp c3QgdGhlIHBvc3NpYmlsaXR5IHRvIGFkZCBvbmUgcm9vdCBDLVZMQU4gYW5kIGFub3RoZXIgcm9v dCBTLVZMQU4sIEkgbmVlZCB0byB1bmRlcnN0YW5kIHRoZSBzY2VuYXJpbyB3aHkgd2UgbmVlZCB0 aGF0LiBUaGUgc3RyYW5nZSB0aGluZyBpcywgYXQgdGhlIGVuZCBvZiB0aGlzIHNlY3Rpb246DQpJ biBhbGwgY2FzZXMsIHRoZSBvdXRlcm1vc3QgVkxBTiBpbiB0aGUgcmVzdWx0ZWQgRXRoZXJuZXQg aGVhZGVyIGlzCiAgIHVzZWQgdG8gaW5kaWNhdGUgdGhlIEUtVHJlZSBhdHRyaWJ1dGUgb2YgYW4g RXRoZXJuZXQgZnJhbWU7IHRoaXMKICAgZG9jdW1lbnQgdXNlcyBWTEFOIHRvIHJlZmVyIHRvIHRo aXMgb3V0ZXJtb3N0IFZMQU4gZm9yIHNpbXBsaWNpdHkgaW4KICAgdGhlIGxhdHRlciBzZWN0aW9u cy4NClRoZW4gd2h5IHdlIHNob3VsZCBhZGQgdGhlIGZpcnN0IHJvb3QgQy1WTEFOPw0KQW5kIHlv dSBzaG91bGQgdXNlIHNhbWUgdGVybWlub2xvZ3kgYWNyb3NzIHRoZSBkb2N1bWVudC4gQW5kIHdo YXQncyB0aGUgZGlmZmVyZW50IGFtb25nICJSb290IFZMQU4iLCAiUm9vdCBDLVZMQU4iLCAiUm9v dCBTLVZMQU4iLCAiUm9vdCBCLVZMQU4iLCBhbmQgc2FtZSBxdWVzdGlvbiB0byBsZWFmPw0KDQox MS4gICBTZWN0aW9uNC4yOiDigJxGb3IgYW4gUy1WTEFOIHRhZ2dlZCBwb3J0LCB0aGUgUy1WTEFO IHRhZyBpbiB0aGUgRXRoZXJuZXQgZnJhbWVzIHJlY2VpdmVkIGZyb20gdGhlIHJvb3QgQUNzIFNI T1VMRCBiZSB0cmFuc2xhdGVkIHRvIHRoZSByb290IFMtVkxBTiBpbiB0aGUgVlBMUyBuZXR3b3Jr IGRvbWFpbuKAnS4gVGhlIGRlc2NyaXB0aW9uIG9mIFMtVkxBTiB0YWdnZWQgcG9ydCBpcyBub3Qg YWNjdXJhdGUgaGVyZS4gSSB0aGluayBoZXJlLCB5b3Ugd2FudCB0byByZWZlciB0byBhIHBvcnQg cmVjZWl2aW5nIGEgcGFja2V0IHdpdGggYm90aCBTLVZMQU4gJiBDLVZMQU4uIFNvIGl0IGlzIGJl dHRlciB0byBzYXksIOKAnHdoZW4gcmVjZWl2aW5nIGEgcGFja2V0IHdpdGggYm90aCBTJkMgVkxB TuKApuKAnS4gU2FtZSBzdWdnZXN0aW9uIHRvIHByZXZpb3VzIHBhcmFncmFwaHMuIA0KW0pZXSBU aGlzIGlzIG5vdCB3aGF0IHdlIHdhbnQuIFRoZXJlIGFyZSBpbXBsZW1lbnRhdGlvbnMgaW4gdGhl IGluZHVzdHJ5IHRoYXQgc3VwcG9ydHMgZW5jYXBzdWxhdGlvbiBvZiBhbGwgdHJhZmZpY3MgZnJv bSBhIHBvcnQgaW50byBhbiBTLVZMQU4gKEJCRiBUUi0xMDEgYWxzbyBzcGVjaWZpZXMgc3VjaCBh IGJlaGF2aW9yKS4gU28gbm8gY2hhbmdlIGlzIG5lZWRlZCBoZXJlLg0KDQpJZiBTLVZMQU4gb25s eSBwYWNrZXQgcmVjZWl2ZWQsIHN0aWxsIHRyYW5zbGF0ZSBTLVZMQU4gdG8gcm9vdCBTLVZMQU4/ DQpbSlldICBZZXMsIHNvbWUgU1BzIG1heSBwcmVmZXIgdG8gdXNlIHN1Y2ggYW4gUy1WTEFOIHRy YW5zbGF0aW9uIGluIHRoZWlyIG5ldHdvcmtzIGZvciBlYXNlIG9mIG1hbmFnZW1lbnQuIFRoaXMg d2FzIGFsc28gZGlzY3Vzc2VkIGluIHRoZSBMMlZQTiBXRyBiZWZvcmUgYW5kIGEgY29uc2Vuc3Vz IHdhcyByZWFjaGVkLg0KW0xpemhvbmddIFRoZW4gSSBjb3VsZCBub3QgYWdyZWUgeW91IHVzZSAi U0hPVUxEIiB0byBtYW5kYXRvcnkgdGhlIHRyYW5zbGF0aW9uLiBJdCBpcyBub3QgbmVjZXNzYXJ5 IHRvIGRvIHRyYW5zbGF0aW9uIGZvciBTLVZMQU4gb25seSBwYWNrZXQgaW4gbWFueSBjYXNlcy4g Q291bGQgV0cgY2hhaXIgY29uZmlybSB0aGUgY29uc2Vuc3VzIFl1YW5sb25nIHJlZmVycyB0by4N Cg0KMTIuICAgU2VjdGlvbjQuMjog4oCcdGhlIEUtVHJlZSBhdHRyaWJ1dGUgbWF5IGFsc28gYmUg aW5kaWNhdGVkIHdpdGggdHdvIEktU0lEIHRhZ3MgaW4gdGhlIGJyaWRnZSBtb2R1bGXigJ0uIFN1 Z2dlc3QgdG8gcmVtb3ZlIHNpbmNlIGl0IGlzIG5vdCBwYXJ0IG9mIHRoaXMgZG9jdW1lbnQuDQpb SlldIEFzIEkgcmVtZW1iZXIsIHRoaXMgbm90ZSB3YXMgYWRkZWQgdG8gcmVzb2x2ZSBhIGNvbW1l bnQgcmFpc2VkIGluIHRoZSBMMlZQTiBXRyBtYWlsaW5nIGxpc3QsIGFuZCBpdCB3YXMgYWNjZXB0 ZWQgaW50byB0aGUgZG9jdW1lbnQgd2l0aCBubyBvYmplY3Rpb24uIFRoaXMgbm90ZSBpcyB0b3Rh bGx5IGluZm9ybWF0aW9uYWwsIGFuZCBJIGFtIG5vdCBzdXJlIGl0IGlzIGFwcHJvcHJpYXRlIHRv IGRlbGV0ZSBpdC4NCltMaXpob25nXSBZb3UgZGVzY3JpYmUgdGhlIGJyaWVmIG1ldGhvZCwgYnV0 IGRvZXMgbm90IHByb3ZpZGUgdGhlIGRldGFpbC4gTXkgY29uY2VybiBpcywgaWYgdGhlcmUgaXMg ZnV0dXJlIGRvY3VtZW50IHRvIGRlc2NyaWJlIEUtVHJlZSBmb3IgUEJCLVZMQU4sIGFuZCBiYXNp YyBtZXRob2QgaXMgZGlmZmVyZW50IHdpdGggdGhpcyBkb2N1bWVudCwgdGhlbiB0aGVyZSB3aWxs IGJlIGNvbmZsaWN0LiANCg0KMTMuICAgU2VjdGlvbjUuMjog4oCcRm9yIGJvdGggbWV0aG9kcywg VkxBTiBtYXBwaW5nIHBhcmFtZXRlcnMgZnJvbSBhIHJlbW90ZSBQRSBjYW4gYmUgcHJvdmlzaW9u ZWQgb3IgZGV0ZXJtaW5lZCBieSBhIHNpZ25hbGluZyBwcm90b2NvbCBhcyBkZXNjcmliZWQgaW4g U2VjdGlvbiA2IHdoZW4gYSBQVyBpcyBiZWluZyBlc3RhYmxpc2hlZOKAnS4gRm9yIHRoZSBnbG9i YWwgbWV0aG9kLCB3aHkgd2UgbmVlZCBzaWduYWxpbmc/DQpbSlldIEp1c3QgYXMgdGhlIHNlbnRl bmNlIHNheXMsIHRoZSBnbG9iYWwgVkxBTiBtZXRob2QgZG9lcyBub3QgcmVseSBvbiBzaWduYWxp bmcgZm9yIGl0cyB3b3JrLg0KQnV0IHRoZSBTUHMgbWF5IHByZWZlciB0byB1c2Ugb25lIG1ldGhv ZCAoZS5nLiwgZ2xvYmFsIFZMQU4gYmFzZWQpIGluIHNjZW5hcmlvIEEgYW5kIHRoZSBvdGhlciBt ZXRob2QgKGUuZy4sIGxvY2FsIFZMQU4gYmFzZWQpIGluIHNjZW5hcmlvIEIsIGFuZCB0aGV5IHdv dWxkIGxpa2UgdG8ga2VlcCBib3RoIG1ldGhvZHMgd29yayBpbiBhIHNpbWlsYXIgd2F5LCBzbyB0 aGUgc2lnbmFsaW5nIHByb3RvY29sIHdhcyBkZXNpZ25lZCB0byBiZSBhcHBsaWNhYmxlIGluIGJv dGggbWV0aG9kcyB0byBnaXZlIHRoZW0gYSBzaW1pbGFyIG9wZXJhdGlvbiBleHBlcmllbmNlIChp ZiBzaWduYWxpbmcgaXMgc3VwcG9ydGVkKS4NCltMaXpob25nXSBJIGRvbid0IGFncmVlLCB3aGF0 IGlmIGRlcGxveWluZyBvbmx5IGdsb2JhbCBtb2RlPyBZb3UgYXJlIHRhbGtpbmcgYWJvdXQgdGhl IG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UsIGJ1dCBJIGFtIHRhbGtpbmcgYWJvdXQgdGhlIHRlY2hu b2xvZ3kuIEl0IGlzIHZlcnkgY29uZnVzaW5nIGZvciB0aGUgcmVhZGVycy4NCg0KMTQuICAgU2Vj dGlvbjUuMy4xOiDigJxpLmUuLCB0aGUgbG9jYWwgbGVhZiBWTEFOIGluIGEgZnJhbWUgaXMgdHJh bnNsYXRlZCB0byB0aGUgcmVtb3RlIGxlYWYgVkxBTjsgdGhlIGxvY2FsIHJvb3QgVkxBTiBpbiBh IGZyYW1lIGlzIHRyYW5zbGF0ZWQgdG8gdGhlIHJlbW90ZSByb290IFZMQU7igJ0uIEhlcmUgeW91 IHNob3VsZCByZWZlciBiYWNrIHRvIHNlY3Rpb24gNC4NCltKWV0gQXQgdGhlIGVuZCBvZiBTZWN0 aW9uIDQsIGl0IGFscmVhZHkgc2F5czoNCiIgIEluIGFsbCBjYXNlcywgdGhlIG91dGVybW9zdCBW TEFOIGluIHRoZSByZXN1bHRlZCBFdGhlcm5ldCBoZWFkZXIgaXMNCiAgIHVzZWQgdG8gaW5kaWNh dGUgdGhlIEUtVHJlZSBhdHRyaWJ1dGUgb2YgYW4gRXRoZXJuZXQgZnJhbWU7IHRoaXMNCiAgIGRv Y3VtZW50IHVzZXMgVkxBTiB0byByZWZlciB0byB0aGlzIG91dGVybW9zdCBWTEFOIGZvciBzaW1w bGljaXR5IGluDQogICB0aGUgbGF0dGVyIHNlY3Rpb25zLiINClNpbmNlIHRoZXJlIGFyZSBkb3pl bnMgb2YgIlZMQU4icyBpbiBzZWN0aW9uIDUgJiA2ICgidGhlIGxhdHRlciBzZWN0aW9ucyIgYWZv cmVtZW50aW9uZWQpLCByZWZlcnJpbmcgdG8gU2VjdGlvbiA0IGZvciBlYWNoIHVzZSBvZiBWTEFO IGlzIHRodXMgYm90aCB1bm5lY2Vzc2FyeSBhbmQgY3VtYmVyc29tZS4gICANCltMaXpob25nXSBC dXQgaGVyZSBpcyAibG9jYWwgbGVhZiBWTEFOIiBhbmQgInJlbW90ZSBsZWFmIFZMQU4iLCBpZiBJ IGV4cGFuZCwgdGhleSB3aWxsIGNoYW5nZSB0byAibG9jYWwgbGVhZiBvdXRlcm1vc3QgVkxBTiIg YW5kICJyZW1vdGUgbGVhZiBvdXRlcm1vc3QgVkxBTiIuIFRoZW4gcXVlc3Rpb24gaXMgd2hhdCBp cyB0aGUgInJlbW90ZSBsZWFmIG91dGVybW9zdCBWTEFOIj8NCg0KMTUuICAgU2VjdGlvbjUuMy4y OiDigJxVcG9uIHJlY2VpdmluZyBmcmFtZXMgb24gdGhlIFBXLCBhZGQgYSBWTEFOIHRhZyB3aXRo IGEgdmFsdWUgb2YgdGhlIGxvY2FsIHJvb3QgVkxBTiB0byB0aGUgZnJhbWVzLuKAnSBOb3QgdW5k ZXJzdGFuZCBoZXJlLiBEb2VzIHRoYXQgbWVhbiBhbGwgcmVjZWl2aW5nIGZyYW1lcyB3aWxsIGJl IGNvbnNpZGVyZWQgdG8gYmUgZnJvbSByb290PyBUaGVuIGhvdyB0byBpc29sYXRlIHRyYWZmaWMg YmV0d2VlbiB0d28gbGVhdmVzPw0KW0pZXSBZZXMsIGFsbCB0aGUgcmVjZWl2ZWQgZnJhbWVzIGZy b20gdGhlIFBXIHdpbGwgYmUgZnJvbSByb290cy4gQXMgdGhlIDFzdCBwYXJhZ3JhcGggaW4gdGhp cyBzZWN0aW9uIGFscmVhZHkgc2F5czoidGhlIFZQTFMgUEUgd2l0aCBhIHRyYWRpdGlvbmFsIFZT SSBjYW4gb25seSBiZSBhdHRhY2hlZCB3aXRoIHJvb3Qgbm9kZXMuIg0KW0xpemhvbmddIE9LLg0K DQoxNi4gICBTZWN0aW9uNS4zLjM6IOKAnElmIGEgUEUgaXMgaW4gdGhlIE9wdGltaXplZCBNb2Rl IGZvciBhIFBXLCB1cG9uIHRyYW5zbWl04oCdLiBTdWdnZXN0IHRvOiBJZiBhIFBFIGlzIGluIHRo ZSBPcHRpbWl6ZWQgTW9kZSBmb3IgYSBQVywgdXBvbiB0cmFuc21pdCB0byBsZWFmIG9ubHkgbm9k ZXMuDQpbSlldIEFzIGl0IGFscmVhZHkgc2F5cyBpbiB0aGUgMXN0IHBhcmFncmFwaCBvZiBTZWN0 aW9uIDUuMy4zLCBhIFBFIHdvcmtzIGluIE9wdGltaXplZCBNb2RlIGZvciBhIFBXIG9ubHkgd2hl biBpdHMgcGVlciBQRSBpcyBhdHRhY2hlZCB3aXRoIG9ubHkgbGVhZiBub2Rlcy4gV2h5IGFkZCB0 aGlzIGNvbmRpdGlvbiBhZ2FpbiAoaW4gaW1wbGVtZW50YXRpb24sIHlvdSBuZWVkIGFuIGV4dHJh IGRhdGEgcGxhbmUgb3BlcmF0aW9uIHRvIGRldGVybWluZSB3aGV0aGVyIHRoaXMgY29uZGl0aW9u IGlzIG1ldCwgZnVydGhlcm1vcmUsIGl0IGlzIGRpZmZpY3VsdCB0byBkZXRlcm1pbmUgd2hldGhl ciBhIGRlc3RpbmF0aW9uIG5vZGUgaXMgYSByb290IG9yIGxlYWYgaW4gdGhlIGRhdGEgcGxhbmUp Pw0KW0xpemhvbmddIG5vLCBieSBzaWduYWxpbmcsIHRoZSBkYXRhcGxhbmUgc2hvdWxkIGtub3cg dGhlIHJlbW90ZSBQRSBpcyBsZWFmIG9ubHkgb3Igbm90LiBXaGF0IEkgbWVhbiBpcywgdGhlIGRy b3Agb3BlcmF0aW9uIGlzIG9ubHkgdmFsaWQgZm9yIGxlYWYtb25seSBub2Rlcy4NCg0KMTcuICAg U2VjdGlvbjYuMTog4oCcSWYgdGhlIGJpdCBWIGlzIHNldCwgYW5kIHRoZSBQRSBpcyBjYXBhYmxl IG9mIFZMQU4gbWFwcGluZywgdGhlbiB0aGUgUEUgd2l0aCB0aGUgbWluaW11bSBJUCBhZGRyZXNz IE1VU1Qgc2V0IFZMQU4tTWFwcGluZy1Nb2RlIHRvIFRSVUU74oCdIFdoaWNoIElQIGFkZHJlc3M/ IFRoZSBhZGRyZXNzIGluIHRoZSBMRFAgSVAgaGVhZGVyPyANCltKWV0gWWVzLg0KW0xpemhvbmdd IHlvdSBzaG91bGQgZXhwbGljaXRseSBzYXkgdGhhdC4gQnV0IEkgcGVyc29uYWx5IHN1Z2dlc3Qg dG8gY29tcGFyZSB0aGUgTERQIElEIGluIExEUCBzaWduYWxpbmcuDQoNCjE4LiAgIFNlY3Rpb242 LjE6IOKAnDIpIElmIHRoZSBQIGJpdCBpcyBzZXQsIHRoZW464oCdIElmIGFib3ZlIGlzIHBzZXVk byBjb2RlLCB0aGVuIHRoZSBjb2RlIGZvcm1hdCBzaG91bGQgYmUgbW9yZSBmb3JtYWwsIHRvIG1h a2UgaXQgY2xlYXIgYW5kIG5lYXQuDQpbSlldIFRoYW5rcywgd2Ugd2lsbCByZW1vdmUgdGhlIGNo YXJhY3RlciAiOiIgaW4gdGhlIG5leHQgcmV2aXNpb24uIERvZXMgdGhpcyByZXNvbHZlIHlvdXIg Y29uY2VybnM/DQpbTGl6aG9uZ10geW91IGNvdWxkIHJlZmVyIHRvIFJGQzQzNzkgc2VjdGlvbiA0 LjQuDQoNCjE5LiAgIFNlY3Rpb242LjE6IOKAnElmIHRoZSBQRSBpcyBhIGxlYWYtb25seSBub2Rl IGl0c2VsZiwgdGhlbiBhIGxhYmVsIHJlbGVhc2UgbWVzc2FnZSB3aXRoIGEgc3RhdHVzIGNvZGUg IkxlYWYgdG8gTGVhZiBQVyByZWxlYXNlZCIgaXMgc2VudCB0byB0aGUgcGVlciBQRSBhbmQgZXhp dCB0aGUgcHJvY2VzczvigJ0gV2hlbiBib3RoIFBFIHJlbGVhc2UgdGhlIG1hcHBpbmcuIFRoZW4g d2hlbiBvbmUgUEUxIGNoYW5nZSB0aGUgc2V0dGluZyB0byBoYXZlIGJvdGggcm9vdCZsZWFmLCBh bmQgc2VuZCBsYWJlbCBtYXBwaW5nIHRvIFBFMiwgd2lsbCBQRTIgYmUgdHJpZ2dlcmVkIHRvIHNl bmQgbGFiZWwgbWFwcGluZyB0byBQRTE/IEFjY29yZGluZyB0byBSRkM1MDM2LCBJIHRoaW5rIHRo ZSBhbnN3ZXIgaXMgbm8uIFlvdSBuZWVkIGFkZGl0aW9uYWwgbWVjaGFuaXNtIGhlcmUuDQpbSlld IFdoeSBQRTIgY2Fubm90IGJlIHRyaWdnZXJlZCB0byBzZW5kIGxhYmVsIG1hcHBpbmcgdG8gUEUx PyBJTU8sIHdlIGRvbid0IG5lZWQgYW55IGFkZGl0aW9uYWwgbWVjaGFuaXNtIGhlcmUuIElmIHRo ZSBjb25maWd1cmF0aW9uIGlzIGNoYW5nZWQgZm9yIGEgZmFpbGVkIFBXIGVzdGFibGlzaGluZyBz ZXNzaW9uLCB0aGVuIGEgbmV3IHJvdW5kIG9mIFBXIG5lZ290aWF0aW9ucyBjYW4gdGFrZSBwbGFj ZSBiZXR3ZWVuIFBFMSBhbmQgUEUyLiBGdXJ0aGVybW9yZSwgdGhlIFBXIG5lZ290aWF0aW9uIHBy b2Nlc3MgaXMgc3RhbmRhcmRpemVkIGluIFJGQyA0NDQ3IHJhdGhlciB0aGFuIFJGQyA1MDM2LCBh bmQgeW91IGNhbiBmaW5kIGFuc3dlcnMgdGhlcmUuDQpbTGl6aG9uZ10gWW91IHNob3VsZCBnaXZl IG91dCB0aGUgdGVjaG5pY2FsIHJlYXNvbi4gVGhlcmUgaXMgbm8gY29uZmlndXJhdGlvbiBjaGFu Z2luZyBvbiBQRTIsIGFuZCBQRTEgcmVsZWFzZSB0aGUgbWFwcGluZyBmcm9tIFBFMiwgdGhlbiB0 aGUgUEUyIHdpbGwgbm90IHNlbmQgbWFwcGluZyBhZ2FpbiBzaW5jZSBEVSBtb2RlIGlzIHVzZWQg Zm9yIFBXIHNpZ25hbGluZy4gQlRXLCB0aGUgUFcgc2lnbmFsaW5nIFJGQzQ0NDcgaXMgYmFzZWQg b24gUkZDNTAzNiwgYW5kIGFsc28gdXBkYXRlZCBieSBSRkM2NzIzLiBPbmUgbWV0aG9kIGlzLCBs aWtlIFJGQzY3MjMsIFBFMSBuZWVkIExEUCByZXF1ZXN0IG1lc3NhZ2UgdG8gcmVlc3RhYmxpc2gg dGhlIFBXLg0KDQoyMC4gICBTZWN0aW9uNi4xOiB0aGUgRS1UcmVlIFN1Yi1UTFYgcGFyYW1ldGVy cyB1cGRhdGluZyBzaG91bGQgYmUgYWxzbyBtZW50aW9uZWQgaW4gdGhpcyBzZWN0aW9uLg0KW0pZ XSBDb3VsZCB5b3UgZWxhYm9yYXRlIG1vcmUgb24gdGhlIHNwZWNpZmljIHJlcXVpcmVtZW50cyBh bmQgc2NlbmFyaW9zIGluIHlvdXIgbWluZD8gQXJlIHlvdSBzdWdnZXN0aW5nIHRvIHN1cHBvcnQg dmVyc2lvbnMgZm9yIHRoaXMgVExWPyBJIGFtIG5vdCBzdXJlIHdlIG5lZWQgc3VjaCBhIGNvbXBs ZXggbWVjaGFuaXNtLg0KW0xpemhvbmddIFRoZSBtb3N0IHNpbXBsZSB1cGRhdGluZyBtZWNoYW5p bXMgaXMgdG8gTERQIHdpdGhkcmF3IGFuZCBtYXBwaW5nIGFnYWluLiBJZiB5b3Ugd2FudCB0byBi ZSBzaW1wbGUsIGl0IGlzIGJldHRlciB0byBleHBsaWN0bHkgc2F5IHRoYXQuDQoNCjIxLiAgIFNl Y3Rpb242LjI6IOKAnERhdGEgcGxhbmUgaW4gdGhlIFZQTFMgaXMgdGhlIHNhbWUgYXMgZGVzY3Jp YmVkIGluIFNlY3Rpb24gNC4yIG9mIFtSRkM0NzYxXSwgYW5kIGRhdGEgcGxhbmUgcHJvY2Vzc2lu ZyBmb3IgYSBQVyBpcyB0aGUgc2FtZSBhcyBkZXNjcmliZWQgYXQgdGhlIGVuZCBvZiBTZWN0aW9u IDYuMS7igJ0gV2h5IHNhbWUgYXMgUkZDNDc2MSBoZXJlPyBEb27igJl0IHlvdSBoYXZlIFZMQU4t TWFwcGluZy1Nb2RlIGFuZCBvdGhlciBtb2RlIGRhdGEgcGxhbmUgb3BlcmF0aW9uPw0KW0pZXSBQ bGVhc2Ugc2VlIHRoZSBlbmQgb2Ygc2VjdGlvbiA2LjEsIGl0IHNheXM6DQoiICAgRGF0YSBwbGFu ZSBwcm9jZXNzaW5nIGZvciB0aGlzIFBXIGlzIGFzIGZvbGxvd2luZzoNCiAgIElmIE9wdGltaXpl ZC1Nb2RlIGlzIFRSVUUsIHRoZW4gZGF0YSBwbGFuZSBwcm9jZXNzaW5nIGFzIGRlc2NyaWJlZA0K ICAgaW4gU2VjdGlvbiA1LjMuMyBhcHBsaWVzLg0KICAgSWYgVkxBTi1NYXBwaW5nLU1vZGUgaXMg VFJVRSwgdGhlbiBkYXRhIHBsYW5lIHByb2Nlc3NpbmcgYXMNCiAgIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDUuMy4xIGFwcGxpZXMuDQogICBJZiBDb21wYXRpYmxlLU1vZGUgaXMgVFJVRSwgdGhlbiBk YXRhIHBsYW5lIHByb2Nlc3NpbmcgaXMgYXMNCiAgIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuMy4y LiIgDQogICBUaGVzZSBzdWItc2VjdGlvbnMgZGVmaW5pdGVseSBkZWFsIHdpdGggRS1UcmVlIHNw ZWNpZmljIGRhdGEgcGxhbmUgb3BlcmF0aW9ucyBzdWNoIGFzIFZMQU4gbWFwcGluZy4NCltMaXpo b25nXSBZb3Ugc2hvdWxkIHNheSB0aGF0LCBsaWtlOiBleGNlcHQgZGVzY3JpYmVkIGluIHNlY3Rp b24gNi4xLCBvdGhlciBkYXRhcGxhbmUgYmVoYXZpb3IgaXMgc2FtZSBhcyAuLi4uLg0KDQoyMi4g ICBTZWN0aW9uODogVGhpcyBzZWN0aW9uIGlzIHRvbyBzaW1wbGUgdG8gcmVtb3ZlIGl0LiBPciBw bGVhc2UgYWRkIG1vcmUgZGV0YWlsLg0KW0pZXSBUaGUgZGV0YWlscyBhcmUgYWxyZWFkeSBjb3Zl cmVkIGluIFNlY3Rpb24gNCBhbmQgQXBwZW5kaXggQSwgc28gdGhpcyBzZWN0aW9uIGlzIGp1c3Qg YSBzdW1tYXJ5IG9mIHRoZSBhcHBsaWNhdGlvbiBzY2VuYXJpb3MgaXQgY2FuIHdvcmsuDQpbTGl6 aG9uZ10gc2luY2UgY292ZXJlZCwgd2h5IHdlIG5lZWQgc3VtbWFyeSBoZXJlPyBMZXQgV0cgZGVj aWRlLg0KDQoyMy4gICBTZWN0aW9uOTogTmV3IHNlY3VyaXR5IGNvbmNlcm4gd2lsbCBpbmNsdWRl OiBzaW5jZSB0aGUgb3V0bW9zdCBWTEFOIGlzIGxlYWYgb3Igcm9vdCwgaXQgaXMgZWFzeSB0byBw YXJzZSB0aGUgbGVhZiBhbmQgcm9vdCBWTEFOIGluZm9ybWF0aW9uLg0KW0pZXSBJdCBpcyB1bmNs ZWFyIHRvIG1lIHdoYXQgaXMgdGhlIHNlY3VyaXR5IGhvbGUgeW91IGFyZSB0cnlpbmcgdG8gaW5k aWNhdGUgYW5kIHdoYXQgc2VjdXJpdHkgbWVhc3VyZSBpcyBpbiB5b3VyIG1pbmQuIENvdWxkIHlv dSBlbGFib3JhdGUgYSBsaXR0bGUgbW9yZSBvbiBpdD8gSW4gbXkgb3BpbmlvbiwgVkxBTnMgaW4g dGhpcyBkb2N1bWVudCBhcmUgbm90IG1vcmUgdnVsbmVyYWJsZSBjb21wYXJlZCB3aXRoIHRoZSBW TEFOcyBpbiBhIHRhZ2dlZCBQVyAoc2VlIFJGQyA0NDQ4KSBhbmQgdGhlIHNlY3VyaXR5IG1lYXN1 cmVzIGFzIHByb3Bvc2VkIGluIFJGQyA0NzYyIGFuZCBSRkMgNDQ0OCBhcmUgc3VmZmljaWVudC4N CltMaXpob25nXSBjb21wYXJlZCB3aXRoIFZQTFMsIHBhcnNlIHRoZSBWTEFOIGNvdWxkIGdldCB0 aGUgRS1UcmVlIHRvcG9sb2d5IGZvciB0aGUgRS10cmVlIFZQTFMuIFRvcG9sb2d5IGluZm9ybWF0 aW9uIGxlYWtpbmcgaXMgdGhlIGNvbmNlcm4uDQoNCjI0LiAgIFNlY3Rpb24xMDogVGhlIGFsbG9j YXRlZCB2YWx1ZSBzaG91bGQgYmUg4oCcVEJE4oCdLg0KW0pZXSBTb3JyeSwgSSBmYWlsZWQgdG8g dW5kZXJzdGFuZCB0aGUgcG9pbnQuIEJ1dCBhbGwgdGhlIHZhbHVlcyBoYXZlIGFscmVhZHkgYmVl biBhbGxvY2F0ZWQgb2ZmaWNpYWxseSBieSBJQU5BLCB3aHkgZG8geW91IHN1Z2dlc3QgdG8gdXNl ICJUQkQiIGluc3RlYWQ/DQpbTGl6aG9uZ10gSSB0aGluayBJQU5BIGlzIHByZS1hbGxvY2F0ZWQs IG5vdCBmaW5hbC4gTGV0IFdHIGRlY2lkZS4NCg0KUmVnYXJkcw0KTGl6aG9uZw0K ------=_001_NextPart064338447445_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0AHi Yuanlong,
I could not agree with some of your= explanations, and would like to raise comment 13 & 19 as the major is= sue. Please AD and chairs pay attention to this. I believe we must resolve= the two comments before any further steps. Thanks.
=0A


=0A
Regards
Lizhong
= =0A
 
From: <= a href=3D"mailto:jiangyuanlong@huawei.com" style=3D"color: blue; text-deco= ration: underline;">Jiangyuanlong
Date: 2015-08-= 12 19:44
Subject: RE: [Pals] RtgDir r= eview: draft-ietf-l2vpn-vpls-pe-etree-07.txt
=0A= =0A=0A=0A=0A=0A

Hi Lizhong= ,

=0A

 

=0A

Please se= e my further comments inline with [JY2].=0A

=0A

Th= anks a lot for your discussion.

=0A

 

=0A

I also cc to Dave and Don for their suggestions, and= cc to the chairs for their guidance.

=0A

&nb= sp;

=0A

Best regards,

=0A

Yuan= long

=0A
=0A

=0A 

=0A
=0A

 

=0A
=0A
=0A

From: lizho.jin@gmail.com=0A [mailto:lizho.jin= @gmail.com]
=0ASent: Saturday, August 08, 2015 6:31 PM
=0ATo: Jiangyuanlong; rtg-ads
=0ACc: rtg-dir; pals; draft-ietf= -l2vpn-vpls-pe-etree
=0ASubject: RE: [Pals] RtgDir review: draft= -ietf-l2vpn-vpls-pe-etree-07.txt

=0A
=0A
= =0A

 

=0A
=0A

Hi, I missed the email, and sorry for the lat= e reply. Please see inline below. 

=0A
=0A<= div>=0A

 

=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A

Regards

=0A
=0A
=0A=

Lizhong

=0A
=0A
=0A
=0A
=0A
=0A

 

=0A
= =0A
=0A
=0A
=0A

=0A Jiangyuanlong

=0A
=0A
=0A

=0A= Date: 2015-06-11 05:48

=0A=0A
=0A

=0ATo:=  Lizhong Jin;=0Artg-ads

=0A
=0A=0A

=0ACC: rtg-dir;=0Ap= als; =0Adraft-ietf-l2vpn-vpl= s-pe-etree@tools.ietf.org

=0A
=0A
=0A

=0A<= b>Subject: RE: [Pals] RtgDir review: draft-ietf-l2vpn-= vpls-pe-etree-07.txt

=0A
=0A
=0A
=0A=0A
=0A

Lizhong,=0A

=0A

 

=0A

Thank you a lot for the revi= ew, please see my comments with [JY] as a prefix.

=0A

 

=0A

Regards,=

= =0A

Yuanlong

=0A

 

=0A
=0A

=0AFrom: Pals [mailto:pals-bounces= @ietf.org]=0AOn Behalf Of Lizhong Jin
=0ASent: Tuesda= y, June 02, 2015 5:55 PM
=0ATo: rtg-ads
=0ACc: rtg-dir= ; pals; =0Adraft-ietf-l2vpn-vpls= -pe-etree@tools.ietf.org
=0ASubject: [Pals] RtgDir review: d= raft-ietf-l2vpn-vpls-pe-etree-07.txt

=0A
=0A

 

=0A
=0A

=0A

I have been selected as the = Routing Directorate reviewer for this draft. The Routing Directorate seeks= to=0A review all routing or routing-related drafts as they pass through I= ETF last call and IESG review, and sometimes on special request. The purpo= se of the review is to provide assistance to the Routing ADs. For more inf= ormation about the Routing Directorate, please=0A see =E2=80=8Bhttp:/= /trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir=0A

=0A

Although these comments are primarily for the use of the Rou= ting ADs, it would be helpful if you could consider=0A them along with any= other IETF Last Call comments that you receive, and strive to resolve the= m through discussion or by updating the draft.

=0A

Document: draft-ietf-l2vpn-vpls-pe-etree-07.txt=0A
=0AReviewer: = Lizhong Jin
=0AReview Date: 2nd June
=0AIETF LC End Date:=
=0AIntended Status: Standards Track

=0A

Summary:=0A
=0AI have some m= inor concerns about this document that I think should be resolved before p= ublication.=0A

=0A

Comments:

=0A

Overall, although there is no major tech= nical issues for this draft, it is strongly suggested=0A to improve the En= glish description to make it neat, and easier to be understood.

=0A

Major Issues:

=0A

No major issues found

=0A

Minor Issues:

=0A

1.      = ;=0AAbstract: =E2=80=9Cservices=E2= =80=9D should be=0A=E2=80=9Cservice=E2=80=9D=0A

[JY] Not needed, since multiple E-Tree services may be deployed i= n a single VPLS network,=0A and the solution aims to support this scenario= .

= =0A

[Lizhong] = Then why you use "uses" to describe "services"? I am referring the grammar= error here.<= /span>

=0A

[JY2] Please note that =E2=80=9Cwhich uses =E2=80=A6=E2= =80=9D is an attributive clause describing the solution, not the services.=

=0A

   =E2=80=9CA generic Virtual Priva= te LAN Service (VPLS) solution is specified

=0A

&n= bsp;  for Ethernet-Tree (E-Tree) services which uses VLANs to indicat= e

=0A

   root or leaf traffic.=E2=80=9D<= o:p>

=0A

To be clear, it is proposed to move it ahead i= n this way:

=0A

   =E2=80=9CA generic Vi= rtual Private LAN Service (VPLS) solution=0Awhich uses VLANs to indicate

=0A

   root = or leaf traffic=0A is sp= ecified for Ethernet-Tree (E-Tree) services which uses VLANs to indicat= e

=0A

   root or leaf traffic.

= =0A

 

=0A

<= span lang=3D"EN-US" style=3D"color:black">2.      =0AAbstract: =E2=80=9Cthe MAC address based Ethernet forward= ing engine and the PW work in the same way as before=E2=80=9D, you should tell the detail of=0A=E2=80=9Cbefore=E2=80=9D here, or add a ref= erence here.

=0A

[JY] Actually, Section= 4 and 5 describe the details of how the Ethernet forwarding engine=0A and= the PW work. I don't think we need to describe the details in an abstract= ion or forward reference any sections in the document here.

=0A

[Lizhong] = I do not agree. The abstract section should give out the outline of whole = concept.=0A Use word "before" does not provide any information for the rea= ders.<= /p>=0A

[JY2] it simply states that the MAC address based Ethernet forwa= rding engine and the PW will not be changed, and it is proposed to be repl= aced=0A with =E2=80=9Cthe MAC address based Ethernet forwarding engine and= the PW work in the same way as before=0Ain [RFC4762] and [RFC4448] respectively=E2=80=9D.

=0A

 

=0A

 

=0A

3. &nb= sp;    =0AAbstract: =E2=80=9Cis=E2=80=9D should be=0A=E2=80= =9Care=E2=80=9D

=0A

[JY] There are 3 cases of "is" in the abstractio= n, but the suggested change is not applicable=0A to any of them. From the = sequence it seems you are referring to the last one, but the subject "A si= gnaling mechanism" is not plural.

=0A

[Lizhong] OK, since signaling mechan= ism also include VLAN mapping, then I suggest to change=0A "VLAN mapping negotia= tion"= =0A to "-Tree attribute".<= o:p>

=0A

[JY2]  =E2=80=9CE-Tree service attribute= =E2=80=9D is already used in MEF, thus its use may introduce confusion to = the topic, but=0A to be clear, it is proposed to= move the verb ahead:

=0A

=0A   =E2=80= =9CA signaling mechanism=0Ais further described =0Afor E-Tree

=0A=

  =0Acapability and = VLAN mapping negotiation is further described.=E2=80=9D<= /span>

=0A

 

=0A

 

=0A

4. &nb= sp;    =0ASection3 overall, suggest to reorganize section 3. Split the section= into two parts: 1. Introduction; 2. Motivation

=0A

=0A

<= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:"Calibri&qu= ot;,"sans-serif";color:#1F497D">[Lizhong] not well organized in = this section. Let WG to decide.

=0A

 

=0A

5.<= /span>    &= nbsp; =0ASection3: = =E2=80=9Cin fact, = there is no exact corresponding terminology in IETF yet.=E2=80=9D = =E2=80=9Cterminology=E2=80=9D could not be a=0A reason. You should list the technology reason if yo= u want to compare.

=0A

[JY] This sentence = simply points out the fact that E-Tree is a new type of service (no corres= ponding=0A service defined in IETF yet), the technical comparison is done = in the E-Tree framework and is referenced in the next paragraph of this do= cument.

=0A

[Lizhong] Please see the whole sentence I am referring:=

=0A
Although Virtual Private Multicast Service (VPMS)<=
o:p>
=0A
   [VPMS] or Point-to-Multipoint=
 (P2MP) multicast is a somewhat
=0A
   simplif=
ied version of this service, in fact, there is no exact<=
/pre>=0A
&nb=
sp;  corresponding terminology in IETF yet.<=
/pre>=0A
=
I could not understand why you say the "terminology" here refer to E-Tree.=
=0A

[JY2]=0A To be clea= r, rewrite the 2nd part as =E2=80=9C=E2=80=A6, in fact, they ar= e both multicast services and are different from an E-Tree service which m= ay include both=0A unicast and multicast traffic=E2=80=9D.

=0A
=0A
=0A

6.<= /span>    &= nbsp; =0ASection3: = =E2=80=9CThough th= ere were proposals on using PW control word or PWs to indicate the root/le= af attribute of an E-Tree frame, both methods are limited in that=0A they = are only applicable to "VPLS only" networks.=E2=80=9D You should have reference for other proposals. But I don=E2= =80=99t think you need to list these proposals, inste= ad only say the motivation of the VLAN based solution.

=0A

[JY] Both references were listed in the older versions of= this draft indeed. Since there=0A had been quite a lot of emails exchange= d over these proposals before the WG adoption of this draft, this sentence= simply reflects a summary of the conclusions. We can remove it in the nex= t revision if the WG thinks it appropriate.

=0A

[Lizhong] OK.

=0A

 

=0A

7.      =0ASection4.1: = =E2=80=9CFig. 1 and Fig. 2 (both figures are extracte= d from [RFC6246])=E2=80=9D. You should switch = the number of Fig1 and Fig2, since Fig1=0A is a detail description of Fig2= .

=0A

[JY] Not exactly, Fig.1 is not just a= block of Fig. 2, it also describes CE access which=0A is not shown in fig= .2. Moreover, the order of CEs, the bridge and the VSI as they appear in F= ig.1 and Fig.2 is also more consistent with their network topology. Howeve= r, if we swap Fig.1 with Fig.2, then Fig.1 will forward reference to Fig.2= , and this would=0A be another disadvantage.

=0A

[Lizhong] Please refer= to RFC6246. And let WG to decide. Thanks.

=0A

 <= /p>=0A

8.  =     =0ASection4.1: =E2=80=9CTherefore, the association between an AC port and a PW on a VSI is d= ifficult, sometimes even impossible.=E2=80=9D = Could not understand=0A what=E2=80=99s the pur= pose of this sentence here?

=0A

[JY] It is= proposed to update it with:

=0A

"Therefore, the association between an AC= port and a PW on a VSI without using any VLAN=0A is difficult, sometimes = even impossible."

=0A

[Lizhong] still not agree. VLAN is not mandotary for= the association. There are many implementations=0A for VPLS to have the a= ssociation without VLAN, e.g., virtual/physical port. I could not see the = "difficult" here.

=0A

[JY2] To resolve the concern, it is proposed to remo= ve =E2=80=9C, sometimes even impossible=E2=80=9D from the sentence.

=0A

(It should be noted that this paragraph does not man= date anything; and in Ethernet, a virtual port itself is usually implement= ed as VLAN;  using=0A physical ports for internal connections in a de= vice is not a common practice).

=0A

 

=0A

9.=       =0ASection4.1: =E2=80=9C<= span lang=3D"EN-US">Assuming this mechanism is implemented in the bridge m= odule, it is quite straightforward to infer a VPLS PE model with two VSIs = to support the E-Tree=0A (as shown in Fig. 3).=E2=80=9D Could move the analysis to motivation section, or removed. And= the logic here is not right. The leaf/root VLAN indication is only for fi= ltering, not bridging. So it is not accurate to have Root/Leave S-VLAN=0A = here to get the enhanced model.

=0A

[JY] So= rry, I am not sure I understand your reasoning here. It is already a stand= ardized=0A mechanism to encapsulate and switch an E-Tree service into two = VLANs by a bridge according to IEEE 802.1Q-2011. Here is the only enhancem= ent: a root VLAN is connected to a root VSI and all the root VSIs in peer = PEs constitute one VPLS instance (with one mesh=0A of PWs), and a leaf VLA= N is connected to a leaf VSI and all the leaf VSIs constitute another VPLS= instance (with another mesh of PWs), both VPLS instances are transparent = to the E-Tree traffic, and all the filtering operations are done on the br= idge according=0A to the IEEE 802.1Q mechanism (that is, VSIs do not need = to filter any leaf traffic).

=0A

[Lizhong] I mean your inferring is not ri= ght. In RFC6246,=0A it says:<= /span>

=0A=
The bridge
=0A
   module has a single "Emulated LAN" interface over which it
=0A
   communicates with all VPLS forwarders, and each VPLS=
 instance is
=0A
   represented by a unique S-=
VLAN tag.
=0A

That is the S-VLAN is used to indentify VLAN instan= ce. But now S-VLAN=0A is used to only identify E-Tree attribute, then it is = not right to apply 802.1ad bridge mode to illustrate E-Tree mode.

=0A

[JY2= ] I think there is some misunderstanding here, S-VLANs for E-Tree is not d= ifferent from S-VLANs for other services (for example, E-LAN). In=0A IEEE = 802.1, the only requirement is that two unique S-VLAN values are used (one= used for root traffic forwarding, and the other used for leaf traffic for= warding); and the two unique S-VLAN values aforementioned can each represe= nt a VPLS instance (just as described=0A in RFC 6246). It is also noted in= the document =E2=80=9Cboth these VSIs have to share their learned MAC add= resses=E2=80=9D in page 7. VSIs forward E-Tree traffic just like a normal = VPLS service and all E-Tree filtering happens in the bridge module.

=0A

 

=0A

10.  =0ASection4.2: =E2=80=9Cand optionally MAY be added with another ro= ot S-VLAN.=E2=80=9D When and why add another r= oot S-VLAN here? And why use terminology=0A=E2=80=9Croot S-VLAN=E2=80=9D, not root VLAN as i= ndicated in Figure4?

=0A

[JY] Figure 4 is= a generalized diagram, where VLAN may be a C-VLAN, S-VLAN or B-VLAN, the= =0A texts in Section 4.2 describe each cases of specific VLANs respectivel= y.

= =0A

It is proposed to update the 1st sentence "In order to support the = E-Tree in a more scalable=0A way..." in Section 4.2 with:

=0A

"In order = to support the E-Tree in a more generic and more scalable way..."

=0A

[Liz= hong] A word "generic" does not solve the problem. Since you lis= t the possibility to=0A add one root C-VLAN and another root S-VLAN, I nee= d to understand the scenario why we need that. The strange thing is, at th= e end of this section:

=0A
In all cases, the out=
ermost VLAN in the resulted Ethernet header is
=0A<= pre style=3D"margin: 0cm 0cm 0.0001pt; page-break-before: always; font-siz= e: 12pt; font-family: =E5=AE=8B=E4=BD=93;">  = used to indicate the E-Tree attribute of an Ethernet frame; this
=0A
   document uses VLAN to refer to this oute=
rmost VLAN for simplicity in
=0A
   the latter=
 sections.
=0A

Then why we should add the first = root C-VLAN?<= /span>

=0A

And you should use same terminology across the document. = And what's the different among=0A "Root VLAN", "Root C-VLAN", "Root S-VLAN= ", "Root B-VLAN", and same question to leaf?

=0A

[JY2] Similar to the I= EEE terminology (a generic VLAN may be a C-VLAN, S-VLAN or B-VLAN),=0A a Root VLAN may be a "Root C-VLA= N", "Root S-VLAN", or "Root B-VLAN", the same applies to leaf VLAN. We wil= l further clarify it in the terminology section by adding =E2=80=9Cit=0A may be a C-VLAN, an = S-VLAN or a B-VLAN=E2=80=9D to the definition of =E2=80=9CRoot VLAN= =E2=80=9D and =E2=80=9CLeaf VLAN=E2=80=9D, that is:=0A=0A

=0A=E2=80=9C  =0ARoot VLAN: a VLAN ID used to indicate all the frames that are=

=0A

  =0Ao= riginated at a root AC, it may be a C-VLAN, an S-VLAN or a B-VLAN=E2=80=9D<= /span>

=0A

Please note that an 802.1ad bridge module may co-exist wi= th 802.1Q bridge modules in the same PE (as shown in Fig.2 in RFC 6246), a= nd both root=0A C-VLAN and root S-VLAN may be used at the same time, so th= at seamless convergence can be realized (e.g., when 802.1Q bridges co-exis= t with 802.1D bridges in the same customer network and be attached to this= PE).=0A

=0A

To be clear, it is proposed to replac= e the 2nd paragraph in Section 4.2 with:

= =0A

=E2=80=9CFor an untagged port (frames over this port are untagged) = or VLAN-unaware port (VLAN tags in the frames are ignored),=0Awhen the bridge module is a C-= VLAN bridge, the Ethernet frames received from the root ACs SHOULD = be tagged with a root C-VLAN=0Aand optionally MAY be added with another= root S-VLAN; w= hen the bridge module is an 802.1ad bridge, the Ethernet frames received f= rom the root ACs SHOULD be tagged with a root S-VLAN (it can be added=0A w= ith a root C-VLAN firstly but this is out of the scope of this document). =E2=80=9C

=0A

 

= =0A

11.  = =0ASection4.2: =E2=80=9CFor an S-VLAN tagg= ed port, the S-VLAN tag in the Ethernet frames received from the root ACs = SHOULD be translated to the root S-VLAN in the VPLS network=0A domain=E2=80=9D. The description of S-VLAN tagged port is= not accurate here. I think here, you want to refer to a port receiving a = packet with both S-VLAN & C-VLAN. So it is better to say,=0A=E2= =80=9Cwhen receiving a packet with both S&C VLAN<= /span>=E2=80=A6=E2=80=9D. Same suggestion to previous= paragraphs.=0A

=0A

[JY] This is not what = we want. There are implementations in the industry that supports encapsula= tion=0A of all traffics from a port into an S-VLAN (BBF TR-101 also specif= ies such a behavior). So no change is needed here.

=0A

 

=0A

If S-VLAN only packet received, still translate S-VLAN to= root S-VLAN?

=0A

<= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:"Calibri&qu= ot;,"sans-serif";color:#1F497D">[JY]  Yes, some SPs may pre= fer to use such an S-VLAN translation in their networks for ease=0A of man= agement. This was also discussed in the L2VPN WG before and a consensus wa= s reached.

=0A

[Lizhong] Then I could not agree you use "SHOULD" to mand= atory the translation. It is not=0A necessary to do translation for S-VLAN= only packet in many cases. Could WG chair confirm the consensus Yuanlong = refers to.

=0A

[JY2]  Maybe the previous L2VPN chairs has something= to say since all those details were discussed in L2VPN WG as early as in = 2012. I have no strong=0A opinion to change =E2=80=9CSHOULD=E2=80=9D to = =E2=80=9CMAY=E2=80=9D, but it would be better to give a preference when se= veral options are given.

=0A

 

=0A

12.&nbs= p; =0ASection4.2: <= /span>=E2=80=9Cthe E-Tree= attribute may also be indicated with two I-SID tags in the bridge module<= /span>=E2=80=9D. Suggest to remove since it is not=0A= part of this document.

=0A

[JY] As I rem= ember, this note was added to resolve a comment raised in the L2VPN WG mai= ling=0A list, and it was accepted into the document with no objection. Thi= s note is totally informational, and I am not sure it is appropriate to de= lete it.

=0A

[Lizhong] You describe the brief method, but does not provide= the detail. My concern is,=0A if there is future document to describe E-T= ree for PBB-VLAN, and basic method is different with this document, then t= here will be conflict. 

=0A

[JY2] Both Don & Dave mentioned = this approach as a valid option (in=0Ahttp://www.ietf.org/mail-archive/web/l2vpn/current/msg03433.= html=0A and http://www.ietf.org/mail-ar= chive/web/l2vpn/current/msg03365.html respectively),=0A and this parag= raph was added in the E-Tree I-D before the WG adoption. IMO, this is info= rmational and is useful, but let the WG decide it.=0A=

=0A

=  

=0A

13.  =0ASection5.2: =E2=80=9CFor both methods, VLAN mapping parameters from a remote PE can be = provisioned or determined by a signaling protocol as described in Section = 6 when=0A a PW is being established=E2=80=9D. = For the global method, why we need signaling?

= =0A

[JY] Just as the sentence says, the global VLAN method does not rel= y on signaling for its=0A work.

=0A

But the SPs may prefer to use one meth= od (e.g., global VLAN based) in scenario A and the=0A other method (e.g., = local VLAN based) in scenario B, and they would like to keep both methods = work in a similar way, so the signaling protocol was designed to be applic= able in both methods to give them a similar operation experience (if signa= ling is supported).=

=0A

[Lizhong] I don't agree, what if deploying only gl= obal mode? You are talking about the operational=0A experience, but I am t= alking about the technology. It is very confusing for the readers.<= span lang=3D"EN-US" style=3D"color:black">

=0A

[JY= 2] Firstly, signaling for global method is not mandatory. Secondly, when c= ontrol plane is needed, it is simple to implement if the same signaling=0A= can be used in both cases. BTW, even in the global mode, we may save some= work in configuration if we have signaling capability (thus we only need = to configure two VLAN values per router).=0A

=0A

<= o:p> 

=0A

14.  =0ASection5.3.1: =E2=80=9Ci.e., the local leaf VLAN in a frame is translated to the remot= e leaf VLAN; the local root VLAN in a frame is translated to the remote ro= ot VLAN=E2=80=9D.=0A Here you should refer bac= k to section 4.

=0A

[JY] At the end of Sec= tion 4, it already says:=

=0A

"  In all cases, the outermost VLAN in t= he resulted Ethernet header is

=0A

   used to indicate the E-Tre= e attribute of an Ethernet frame; this

=0A

=    document uses VLAN= to refer to this outermost VLAN for simplicity in

=0A

   the la= tter sections."

=0A

Since there are dozens of "VLAN"s in section 5 & 6= ("the latter sections" aforementioned),=0A referring to Section 4 for eac= h use of VLAN is thus both unnecessary and cumbersome.  =0A

=0A

= [Lizhong] But here is "local leaf VLAN" and "remote leaf VLAN", if I expan= d, they will change=0A to "local lea= f outermost VLAN" and "remote leaf outermost VLAN". Then questio= n is what is the "remote leaf outermost VLAN"?

=0A

[= JY2] No, we did not hint such a expansion. The E-Tree VLAN is generic (it = may be C-VLAN, S-VLAN or B-VLAN), and actually indicated by the outermost= =0A VLAN. See comment 10 for the terminology clarification.

=0A

 

=0A

15.  =0ASection5.3.2: = =E2=80=9CUpon receiving frames on the PW, add a VLAN = tag with a value of the local root VLAN to the frames.=E2=80=9D Not understand here.=0A Does that mean all receiving fra= mes will be considered to be from root? Then how to isolate traffic betwee= n two leaves?

=0A

[JY] Yes, all the rece= ived frames from the PW will be from roots. As the 1st paragraph in=0A thi= s section already says:"the VPLS PE with a traditional VSI can only be att= ached with root nodes."<= o:p>

=0A

[Lizhong] OK.

=0A

 

= =0A

16.  = =0ASection5.3.3: = =E2=80=9CIf a PE is in th= e Optimized Mode for a PW, upon transmit=E2=80=9D. Suggest to: If a PE is in the Optimized Mode for a PW, upon=0A transm= it to leaf only nodes.

=0A

[JY] As it alrea= dy says in the 1st paragraph of Section 5.3.3, a PE works in Optimized Mod= e=0A for a PW only when its peer PE is attached with only leaf nodes. Why = add this condition again (in implementation, you need an extra data plane = operation to determine whether this condition is met, furthermore, it is d= ifficult to determine whether a destination=0A node is a root or leaf in t= he data plane)?

=0A

[Lizhong] no, by signaling, the dataplane should know = the remote PE is leaf only or not.=0A What I mean is, the drop operation i= s only valid for leaf-only nodes.

=0A

[JY2] this is always true, so the co= ndition is not needed in the data plane. To be clear, it is proposed to up= date the 1st sentence in Section=0A 5.3.3 =E2=80=9DWhen two PEs (both have= E-Tree capability) are inter-connected =0Awith a PW =E2=80=A6=E2=80=A6its peer PE (e.= g., PE1) should then work in the optimized mode=0Afor this PW.=E2=80=9D

=0A

 

=0A

17.  =0ASection6.1: =E2= =80=9CIf the bit V is set, and the PE is capable of V= LAN mapping, then the PE with the minimum IP address MUST set VLAN-Mapping= -Mode to TRUE;=E2=80=9D=0A Which IP address? T= he address in the LDP IP header?

=0A

[JY]= Yes.<= /p>=0A

[Lizhong] you should explicitly say that. But I personaly sugges= t to compare the LDP ID=0A in LDP signaling.

=0A

[JY2] To be consistent wi= th BGP section, suggest to keep it as is (in both cases, IP addresses used= for comparison are extracted from their respective=0A IP sessions).<= /o:p>

=0A

&= nbsp;

=0A

 

=0A

18.=   =0ASection6.1: =E2=80=9C2) If the P bit is set, then:= =E2=80=9D If above is pseudo code, then the code form= at should be more formal, to make it clear and=0A neat.<= /span>

=0A

[JY] Thanks, we will remove the character ":" in the next= revision. Does this resolve your=0A concerns?

=0A

[Lizhong] you could re= fer to RFC4379 section 4.4.

=0A

[JY2] thanks, we will.=0A

=0A

 

=0A

19.  =0ASection6.1: =E2= =80=9CIf the PE is a leaf-only node itself, then a la= bel release message with a status code "Leaf to Leaf PW released" is sent = to the peer PE and exit the=0A process;=E2=80=9D When both PE release the mapping. Then when one PE1 change the setting = to have both root&leaf, and send label mapping to PE2, will PE2 be tri= ggered to send label mapping to PE1? According to RFC5036, I think the ans= wer is=0A no. You need additional mechanism here.=

=0A

[JY] Why PE2 cannot be triggered to send label mapping to PE1? = IMO, we don't need any additional=0A mechanism here. If the configuration = is changed for a failed PW establishing session, then a new round of PW ne= gotiations can take place between PE1 and PE2. Furthermore, the PW negotia= tion process is standardized in RFC 4447 rather than RFC 5036, and you=0A = can find answers there.<= o:p>

=0A

[Lizhong] You should give out the technical re= ason. There is no configuration changing on=0A PE2, and PE1 release the ma= pping from PE2, then the PE2 will not send mapping again since DU mode is = used for PW signaling. BTW, the PW signaling RFC4447 is based on RFC5036, = and also updated by RFC6723. One method is, like RFC6723, PE1 need LDP req= uest message=0A to reestablish the PW.

=0A

= [JY2] this is similar to commen= t 20 since it deals with topology and TLV parameter updates.

=0A

 

=0A

20.  =0ASection6.1: the E-Tree Sub-TLV parameters updating= should be also mentioned in this section.

=0A

[JY= ] Could you elaborate more on the specific requirements and scenarios in y= our mind? Are=0A you suggesting to support versions for this TLV? I am not= sure we need such a complex mechanism.

=0A

[Lizhong] The most simple up= dating mechanims is to LDP withdraw and mapping again. If you=0A want to b= e simple, it is better to explictly say that.

=0A

[JY2] Please note that= RFC 7152 which specifies the requirements for E-Tree does not have such a= requirement. Definitely, LDP withdrawal and mapping=0A (both have already= been defined in RFC 4447) can be used in updating PW labels and TLVs in L= DP VPLS, but scenarios and requirements are also needed. Maybe a new I-D i= s better to serve this purpose. The guidance from the WG chairs is needed.=

=0A

 

=0A

21.=   =0ASection6.2: =E2=80=9CData plane in the VPLS is the same as= described in Section 4.2 of [RFC4761], and data plane processing for a PW= is the same as described at the end=0A of Section 6.1.=E2=80=9D Why same as RFC4761 here? Don=E2=80=99t you have VLAN-Mapping-Mode and other mode data plane operatio= n?

=0A

[JY] Please see the end of section 6= .1, it says:<= /span>

=0A

"   Data plane processing for this PW is as fol= lowing:

=0A

   If Optimized-Mode is TRUE, then data plane proces= sing as described

=0A

   in Section 5.3.3 applies.

=0A

 &nb= sp; If VLAN-Mapping-Mode is TRUE, then data plane processing as

=0A

&nbs= p;  described in Section 5.3.1 applies.

=0A

   If Compat= ible-Mode is TRUE, then data plane processing is as

=0A

   des= cribed in Section 5.3.2."=0A

=0A

   These sub-sections defi= nitely deal with E-Tree specific data plane operations such as=0A VLAN map= ping.<= /p>=0A

[Lizhong] You should say that, like: except described in section= 6.1, other dataplane behavior=0A is same as .....

=0A

[JY2] They are on d= ifferent topic: the end of Section 6.1 covers PW processing, while Section= 4.2 of [RFC4761] covers VPLS data plane.

=0A

To b= e clear, it is proposed to say:=E2=80=9DData plane in the VPLS is the same= as described in Section 4.2 of [RFC4761], and data plane processing for= =0A a PW is the same as described at the end of Section 6.1 =0Ain this document.=E2=80= =9D=0A

 

=0A

= 22.  =0ASection8: This section is too simple to remove it. Or please = add more detail.

=0A

[JY] The details are already = covered in Section 4 and Appendix A, so this section is just=0A a summary = of the application scenarios it can work.

=0A

[Lizhong] since covered, why= we need summary here? Let WG decide.

=0A

<= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:"Calibri&qu= ot;,"sans-serif";color:#7030A0">[JY2] Please note that RFC 7152 = Section 5.2 has such a requirement.

=0A

 = ;

=0A

23.  =0ASecti= on9: New security concern will include: since the outmost VLAN is leaf or = root, it is easy to parse the leaf and root VLAN information.

=0A

[JY] It is unclear to me what is the security hole you ar= e trying to indicate and what security=0A measure is in your mind. Could y= ou elaborate a little more on it? In my opinion, VLANs in this document ar= e not more vulnerable compared with the VLANs in a tagged PW (see RFC 4448= ) and the security measures as proposed in RFC 4762 and RFC 4448 are suffi= cient.=

=0A

[Lizhong] compared with VPLS, parse the VLAN could get the E-Tr= ee topology for the E-tree=0A VPLS. Topology information leaking is the co= ncern.=

=0A

[JY2] yes, an intruder inside a carrier network may get the inf= ormation on the 2 E-Tree VLAN values used by the carrier, but is it worse = than a=0A single VLAN value in the case of a traditional VPLS? Are there a= ny security measures different? I am still in doubt.

= =0A

 

=0A

24. &nb= sp;=0ASection10: The all= ocated value should be=0A=E2=80=9CTBD=E2=80=9D.

=0A

[JY] Sorry, I failed to understand the point. But all t= he values have already been allocated=0A officially by IANA, why do you su= ggest to use "TBD" instead?

=0A

[Lizhong] I think IANA is pre-allocated, = not final. Let WG decide.

=0A

 

=0A

Regards

=0A

Lizhong

=0A
=0A
= =0A
=0A
=0A
=0A=0A ------=_001_NextPart588004828176_=------ From nobody Thu Aug 13 09:15:24 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6AD1A9245; Wed, 12 Aug 2015 11:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id be2J_hklVL7X; Wed, 12 Aug 2015 11:46:30 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A41AE1A8851; Wed, 12 Aug 2015 11:46:29 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id t7CIkQmh030165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Aug 2015 20:46:26 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id t7CIkOQC018281; Wed, 12 Aug 2015 20:46:24 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id B810261F9A; Wed, 12 Aug 2015 20:46:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id sdQ_iAiEDH9D; Wed, 12 Aug 2015 20:46:24 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A1CA261FA0; Wed, 12 Aug 2015 20:46:22 +0200 (CEST) Date: Wed, 12 Aug 2015 20:46:22 +0200 Message-ID: <87r3n8xs3l.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Pierre Pfister In-Reply-To: References: <55857123.90205@openwrt.org> <43C47623-C61D-4397-BA4A-8CBF8878B516@thomasclausen.org> <9630E81F-8AA0-4516-A9AE-56E0EB634599@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 12 Aug 2015 20:46:26 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 12 Aug 2015 20:46:26 +0200 (CEST) X-Miltered: at korolev with ID 55CB9482.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 55CB9480.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 55CB9482.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 55CB9480.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 55CB9482.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 55CB9480.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: X-Mailman-Approved-At: Thu, 13 Aug 2015 09:15:23 -0700 Cc: "" , "homenet@ietf.org Group" , Markus Stenberg , "" Subject: Re: [RTG-DIR] [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 18:46:31 -0000 > On a different topic, I think reserving 32 TLV types to DNCP is far from > being enough. Seconded. > I guess that comment joins Thomas’ comment about version numbers, with > which I agree (that we should add one). Thirded. -- Juliusz From nobody Thu Aug 13 09:17:29 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6806E1B2E39; Thu, 13 Aug 2015 09:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.85 X-Spam-Level: X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CHvcFFzv3WG; Thu, 13 Aug 2015 09:17:24 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8271B2E3A; Thu, 13 Aug 2015 09:17:24 -0700 (PDT) Received: by oiev193 with SMTP id v193so29002345oie.3; Thu, 13 Aug 2015 09:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=N873477RYaiP2kHC/8au10KQU9PCyKy8JE3jLJwcjtw=; b=eGgY9gvhsh7H9VsnzFFFjQGXLshgUcA/zKlV/m+2xRe0ZmzY1KASegBRfiNsCDIyI1 I4iflp2sZXkF/z1G+ZftXsbyiZ9yqDuRW5BkawNKn7Zfx3Hy0YR5oVZdTkEmt1yRwCFG leFheY+K6Sb292lZqhlVZg/r432BatpsOwvdGh+epmNOhqs+7Mt0marRoGqVLJJ0+Z7N 5/vEWzEbd9sJwVgxCwdjJKEFEu7uNDDnWHxIM6W+NiuRqyJ4yHqaVzbdv0BO2micbfRI xASsOZDSnK7yumQ74lxQYwKdk+sfX00VMIwC2iysEHi0W3tya3Eb8Xptt7h7BHc49aRh OZYQ== X-Received: by 10.202.196.70 with SMTP id u67mr14578050oif.73.1439482644197; Thu, 13 Aug 2015 09:17:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.173.3 with HTTP; Thu, 13 Aug 2015 09:17:09 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Thu, 13 Aug 2015 12:17:09 -0400 Message-ID: To: "Bocci, Matthew (Matthew)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtg-dir@ietf.org" , "trill@ietf.org" , "draft-ietf-trill-directory-assist-mechanisms.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] =?utf-8?q?RtgDir_review=3A_draft-ietf-trill-directory-a?= =?utf-8?q?ssist-mechanisms=E2=80=8B-03=2Etxt?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 16:17:26 -0000 Hi Matthew, My apologies for the delay in this response. On Fri, Jul 31, 2015 at 10:06 AM, Bocci, Matthew (Matthew) wrote: > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and > sometimes on special request. The purpose of the review is to provide > assistance to the Routing ADs. For more information about the Routing > Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-trill-directory-assist-mechanisms-03.txt > Reviewer: Matthew Bocci > Review Date: July 2015 > IETF LC End Date: Unknown > Intended Status: Proposed Standard > > Summary: > I have some minor concerns about this > document that I think should be resolved before publication. > > Comments: > > The draft is mostly ready for publication, but I have some comments > related to which procedures are mandatory to implement, and which > are optional (see minor issues below). I've flagged this because in > my experience it is very important for an RFC to be crystal clear > about what is mandatory for successful interoperability. > > Major Issues: > > No major issues. > > Minor Issues: > > In general, it is very unclear if it is mandatory to implement both > push and pull, or if it is adequate to just implement one or the > other. I appreciate that a hybrid mode is possible, in which case an > implementation would need to support both, but this is only > described at the end in section 4, almost as an afterthought. It > would be much better if the draft could be clear up-front which is > the mandatory (default) mode, or if both must be implemented if the > expectation is that the default operating model is hybrid. Good point. Implementation of push and pull are independent and a directory can support one, the other, or both. Will add explicit words to that effect. > Section: "1. Introduction" > 1st Paragraph: Last sentence > "These mechanisms are optional to implement." > > This statement seems redundant, since technically the whole RFC is > optional unless another RFC makes a normative reference to it :) I > think you should either remove this statement, or use it to clarify > which modes are optional and which are mandatory. Seems like a reasonable place to clarify the independent optionality of the push and pull modes. > Pg14: > "If information previously > pulled is about to expire, a TRILL switch MAY try to refresh it by > issuing a new pull request but, to avoid unnecessary requests, SHOULD > NOT do so if it has not been recently used." > > Can you give more information on what you mean by "recently"? Some > non-normative guidance might be helpful to prevent wildly differing > or unpredictable behaviours in a multi-vendor deployment. I don't see any way that wildly differing interpretations of "recently", in this case, could result in incorrect behavior. Maybe all of the sentence after "pull request" should be dropped. > Nits: > > - There are a few uncommon acronyms. Please expand all acronyms on first > use. OK. > - Pg4 s/MacDA/MAC DA MacDA is common in TRILL documents including RFC 6325, the TRILL base protocol document, although there it is always Inner.MacDA or Outer.MacDA (or Inner.MacSA or Outer.MacSA). In this document, there are two occurrences of "MacDA", although one is just in the acronyms list, and two occurrences of "Inner.MacDA". I don't see any particular problem expanding the one isolated occurrence of "MacDA" in body text and changing the acronym entry to be for "Inner.MacDA". But I would prefer not to change the two existing occurrenes of Inner.MacDA, which refers to the MAC addresses after the TRILL header in a TRILL data packet. > - Pg8 s/angel bracket/angle bracket OK. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Fri Aug 14 07:24:06 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB081A8909; Fri, 14 Aug 2015 07:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtP7BcH3ZMQO; Fri, 14 Aug 2015 07:23:56 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F5A1A8902; Fri, 14 Aug 2015 07:23:55 -0700 (PDT) Received: by lahi9 with SMTP id i9so44653479lah.2; Fri, 14 Aug 2015 07:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BT/kx0LJ5xzuxEOBqS7OceoZlukGSpiHjJ0nTSfwXN4=; b=U5iQHg6WHgQ5sby8oQmrWKSHxUWkL0dPIXv8qGCbX5lqZDoOc7vK/KeyfANf2yCemN uh9R9OigtmcoxsFA9P538PiIbCSqlAlqxZYXxN4Ofo9dXZbKvfaaywiSIsedi/tfD+rw NW9pH8IbmyiPFC4x+3LaYCq7zbzZ8Uc0Ql/YGWVitOwOrnM81Xu9WuMxLl0J0Zq2DwzW 5miPLpd8+f9on4PrsId38f8m2guTkc6MlrRnbbbZ8EiC2hkYGwCz0drzLVIyzEyEi9iw zBIF00whhUWkVUcvlk5sHtvzolfLmkKSZG60+viUgVAYsLRuAh89l4HO07THJPC55qUL 6UZQ== MIME-Version: 1.0 X-Received: by 10.152.6.65 with SMTP id y1mr30486918lay.58.1439562234034; Fri, 14 Aug 2015 07:23:54 -0700 (PDT) Received: by 10.25.211.67 with HTTP; Fri, 14 Aug 2015 07:23:53 -0700 (PDT) In-Reply-To: <201508122345018343936@gmail.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A900449@szxema506-mbs.china.huawei.com> <20150808183111884135100@gmail.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A9B3543@szxema506-mbs.china.huawei.com> <201508122345018343936@gmail.com> Date: Fri, 14 Aug 2015 22:23:53 +0800 Message-ID: From: Lizhong Jin To: Jiangyuanlong , rtg-ads , "Giles Heron (giheron)" , agmalis , stbryant Content-Type: multipart/alternative; boundary=089e01493db2977f2b051d4633b4 Archived-At: Cc: rtg-dir , draft-ietf-l2vpn-vpls-pe-etree , pals Subject: Re: [RTG-DIR] [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 14:24:05 -0000 --089e01493db2977f2b051d4633b4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For comment 17. 17. Section6.1: =E2=80=9CIf the bit V is set, and the PE is capable of VL= AN mapping, then the PE with the minimum IP address MUST set VLAN-Mapping-Mode to TRUE;=E2=80=9D Which IP address? The address in the LDP IP header? [JY] Yes. [Lizhong] you should explicitly say that. But I personaly suggest to compare the LDP ID in LDP signaling. [JY2] To be consistent with BGP section, suggest to keep it as is (in both cases, IP addresses used for comparison are extracted from their respective IP sessions). [Lizhong] I also could not accept such explanation. LDP ID is a stable ID while LDP hello adjacency may not. By using LDP ID to select the master/slave node is a common way in LDP protocol. If you use the IP address in IP header of LDP message, it will bring network unstability. ------------------------------ Regards Lizhong On Wed, Aug 12, 2015 at 11:45 PM, lizho.jin@gmail.com wrote: > Hi Yuanlong, > I could not agree with some of your explanations, and would like to raise > comment 13 & 19 as the major issue. Please AD and chairs pay attention to > this. I believe we must resolve the two comments before any further steps= . > Thanks. > > ------------------------------ > Regards > Lizhong > > > *From:* Jiangyuanlong > *Date:* 2015-08-12 19:44 > *To:* lizho.jin@gmail.com; rtg-ads ; David Allan = I > ; Fedyk, Donald (Don) > ; Giles Heron ; Andre= w > G. Malis ; Stewart Bryant (stbryant) > > *CC:* rtg-dir ; pals ; > draft-ietf-l2vpn-vpls-pe-etree > > *Subject:* RE: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.tx= t > > Hi Lizhong, > > > > Please see my further comments inline with [JY2]. > > Thanks a lot for your discussion. > > > > I also cc to Dave and Don for their suggestions, and cc to the chairs for > their guidance. > > > > Best regards, > > Yuanlong > > > > > > *From:* lizho.jin@gmail.com [mailto:lizho.jin@gmail.com] > *Sent:* Saturday, August 08, 2015 6:31 PM > *To:* Jiangyuanlong; rtg-ads > *Cc:* rtg-dir; pals; draft-ietf-l2vpn-vpls-pe-etree > *Subject:* RE: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.tx= t > > > > Hi, I missed the email, and sorry for the late reply. Please see inline > below. > > > ------------------------------ > > Regards > > Lizhong > > > > *From:* Jiangyuanlong > > *Date:* 2015-06-11 05:48 > > *To:* Lizhong Jin ; rtg-ads > > *CC:* rtg-dir ; pals ; > draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org > > *Subject:* RE: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.tx= t > > Lizhong, > > > > Thank you a lot for the review, please see my comments with [JY] as a > prefix. > > > > Regards, > > Yuanlong > > > > *From:* Pals [mailto:pals-bounces@ietf.org ] *On > Behalf Of *Lizhong Jin > *Sent:* Tuesday, June 02, 2015 5:55 PM > *To:* rtg-ads > *Cc:* rtg-dir; pals; draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org > *Subject:* [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt > > > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and sometimes > on special request. The purpose of the review is to provide assistance to > the Routing ADs. For more information about the Routing Directorate, plea= se > see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Las= t > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-l2vpn-vpls-pe-etree-07.txt > Reviewer: Lizhong Jin > Review Date: 2nd June > IETF LC End Date: > Intended Status: Standards Track > > *Summary:* > I have some minor concerns about this document that I think should be > resolved before publication. > > *Comments:* > > Overall, although there is no major technical issues for this draft, it i= s > strongly suggested to improve the English description to make it neat, an= d > easier to be understood. > > *Major Issues:* > > No major issues found > > *Minor Issues:* > > 1. Abstract: =E2=80=9Cservices=E2=80=9D should be =E2=80=9Cservice= =E2=80=9D > > [JY] Not needed, since multiple E-Tree services may be deployed in a > single VPLS network, and the solution aims to support this scenario. > > [Lizhong] Then why you use "uses" to describe "services"? I am referring > the grammar error here. > > [JY2] Please note that =E2=80=9Cwhich uses =E2=80=A6=E2=80=9D is an attri= butive clause describing > the solution, not the services. > > =E2=80=9CA generic Virtual Private LAN Service (VPLS) solution is spec= ified > > for Ethernet-Tree (E-Tree) services which uses VLANs to indicate > > root or leaf traffic.=E2=80=9D > > To be clear, it is proposed to move it ahead in this way: > > =E2=80=9CA generic Virtual Private LAN Service (VPLS) solution which u= ses > VLANs to indicate > > root or leaf traffic is specified for Ethernet-Tree (E-Tree) services > which uses VLANs to indicate > > root or leaf traffic. > > > > 2. Abstract: =E2=80=9Cthe MAC address based Ethernet forwarding eng= ine and > the PW work in the same way as before=E2=80=9D, you should tell the detai= l of =E2=80=9C > before=E2=80=9D here, or add a reference here. > > [JY] Actually, Section 4 and 5 describe the details of how the Ethernet > forwarding engine and the PW work. I don't think we need to describe the > details in an abstraction or forward reference any sections in the docume= nt > here. > > [Lizhong] I do not agree. The abstract section should give out the outlin= e > of whole concept. Use word "before" does not provide any information for > the readers. > > [JY2] it simply states that the MAC address based Ethernet forwarding > engine and the PW will not be changed, and it is proposed to be replaced > with =E2=80=9Cthe MAC address based Ethernet forwarding engine and the PW= work in > the same way as before in [RFC4762] and [RFC4448] respectively=E2=80=9D. > > > > > > 3. Abstract: =E2=80=9Cis=E2=80=9D should be =E2=80=9Care=E2=80=9D > > [JY] There are 3 cases of "is" in the abstraction, but the suggested > change is not applicable to any of them. From the sequence it seems you a= re > referring to the last one, but the subject "A signaling mechanism" is not > plural. > > [Lizhong] OK, since signaling mechanism also include VLAN mapping, then I > suggest to change "VLAN mapping negotiation" to "E-Tree attribute". > > [JY2] =E2=80=9CE-Tree service attribute=E2=80=9D is already used in MEF,= thus its use may > introduce confusion to the topic, but to be clear, it is proposed to move > the verb ahead: > > =E2=80=9CA signaling mechanism is further described for E-Tree > > capability and VLAN mapping negotiation is further described.=E2=80=9D > > > > > > 4. Section3 overall, suggest to reorganize section 3. Split the > section into two parts: 1. Introduction; 2. Motivation > > [JY] This is related to question 6 and 9, not sure what is the problem yo= u > are trying to solve as a whole. > > [Lizhong] not well organized in this section. Let WG to decide. > > > > 5. Section3: =E2=80=9Cin fact, there is no exact corresponding term= inology > in IETF yet.=E2=80=9D =E2=80=9Cterminology=E2=80=9D could not be a reason= . You should list the > technology reason if you want to compare. > > [JY] This sentence simply points out the fact that E-Tree is a new type o= f > service (no corresponding service defined in IETF yet), the technical > comparison is done in the E-Tree framework and is referenced in the next > paragraph of this document. > > [Lizhong] Please see the whole sentence I am referring: > > Although Virtual Private Multicast Service (VPMS) > > [VPMS ] or Point-to-Multipoint (P2MP) multicast is a somewhat > > simplified version of this service, in fact, there is no exact > > corresponding terminology in IETF yet. > > I could not understand why you say the "terminology" here refer to E-Tree= . > > [JY2] To be clear, rewrite the 2nd part as =E2=80=9C=E2=80=A6, in fact, = they are both > multicast services and are different from an E-Tree service which may > include both unicast and multicast traffic=E2=80=9D. > > 6. Section3: =E2=80=9CThough there were proposals on using PW contr= ol word > or PWs to indicate the root/leaf attribute of an E-Tree frame, both metho= ds > are limited in that they are only applicable to "VPLS only" networks.=E2= =80=9D > You should have reference for other proposals. But I don=E2=80=99t think = you need > to list these proposals, instead only say the motivation of the VLAN base= d > solution. > > [JY] Both references were listed in the older versions of this draft > indeed. Since there had been quite a lot of emails exchanged over these > proposals before the WG adoption of this draft, this sentence simply > reflects a summary of the conclusions. We can remove it in the next > revision if the WG thinks it appropriate. > > [Lizhong] OK. > > > > 7. Section4.1: =E2=80=9CFig. 1 and Fig. 2 (both figures are extract= ed from > [RFC6246])=E2=80=9D. You should switch the number of Fig1 and Fig2, since= Fig1 is > a detail description of Fig2. > > [JY] Not exactly, Fig.1 is not just a block of Fig. 2, it also describes > CE access which is not shown in fig.2. Moreover, the order of CEs, the > bridge and the VSI as they appear in Fig.1 and Fig.2 is also more > consistent with their network topology. However, if we swap Fig.1 with > Fig.2, then Fig.1 will forward reference to Fig.2, and this would be > another disadvantage. > > [Lizhong] Please refer to RFC6246. And let WG to decide. Thanks. > > > > 8. Section4.1: =E2=80=9CTherefore, the association between an AC po= rt and a > PW on a VSI is difficult, sometimes even impossible.=E2=80=9D Could not > understand what=E2=80=99s the purpose of this sentence here? > > [JY] It is proposed to update it with: > > "Therefore, the association between an AC port and a PW on a VSI without > using any VLAN is difficult, sometimes even impossible." > > [Lizhong] still not agree. VLAN is not mandotary for the association. > There are many implementations for VPLS to have the association without > VLAN, e.g., virtual/physical port. I could not see the "difficult" here. > > [JY2] To resolve the concern, it is proposed to remove =E2=80=9C, sometim= es even > impossible=E2=80=9D from the sentence. > > (It should be noted that this paragraph does not mandate anything; and in > Ethernet, a virtual port itself is usually implemented as VLAN; using > physical ports for internal connections in a device is not a common > practice). > > > > 9. Section4.1: =E2=80=9CAssuming this mechanism is implemented in t= he > bridge module, it is quite straightforward to infer a VPLS PE model with > two VSIs to support the E-Tree (as shown in Fig. 3).=E2=80=9D Could move = the > analysis to motivation section, or removed. And the logic here is not > right. The leaf/root VLAN indication is only for filtering, not bridging. > So it is not accurate to have Root/Leave S-VLAN here to get the enhanced > model. > > [JY] Sorry, I am not sure I understand your reasoning here. It is already > a standardized mechanism to encapsulate and switch an E-Tree service into > two VLANs by a bridge according to IEEE 802.1Q-2011. Here is the only > enhancement: a root VLAN is connected to a root VSI and all the root VSIs > in peer PEs constitute one VPLS instance (with one mesh of PWs), and a le= af > VLAN is connected to a leaf VSI and all the leaf VSIs constitute another > VPLS instance (with another mesh of PWs), both VPLS instances are > transparent to the E-Tree traffic, and all the filtering operations are > done on the bridge according to the IEEE 802.1Q mechanism (that is, VSIs = do > not need to filter any leaf traffic). > > [Lizhong] I mean your inferring is not right. In RFC6246, it says: > > The bridge > > module has a single "Emulated LAN" interface over which it > > communicates with all VPLS forwarders, and each VPLS instance is > > represented by a unique S-VLAN tag. > > That is the S-VLAN is used to indentify VLAN instance. But now S-VLAN is > used to only identify E-Tree attribute, then it is not right to apply > 802.1ad bridge mode to illustrate E-Tree mode. > > [JY2] I think there is some misunderstanding here, S-VLANs for E-Tree is > not different from S-VLANs for other services (for example, E-LAN). In IE= EE > 802.1, the only requirement is that two unique S-VLAN values are used (on= e > used for root traffic forwarding, and the other used for leaf traffic > forwarding); and the two unique S-VLAN values aforementioned can each > represent a VPLS instance (just as described in RFC 6246). It is also not= ed > in the document =E2=80=9Cboth these VSIs have to share their learned MAC = addresses=E2=80=9D > in page 7. VSIs forward E-Tree traffic just like a normal VPLS service an= d > all E-Tree filtering happens in the bridge module. > > > > 10. Section4.2: =E2=80=9Cand optionally MAY be added with another root = S-VLAN.=E2=80=9D > When and why add another root S-VLAN here? And why use terminology =E2=80= =9Croot > S-VLAN=E2=80=9D, not root VLAN as indicated in Figure4? > > [JY] Figure 4 is a generalized diagram, where VLAN may be a C-VLAN, S-VLA= N > or B-VLAN, the texts in Section 4.2 describe each cases of specific VLANs > respectively. > > It is proposed to update the 1st sentence "In order to support the E-Tree > in a more scalable way..." in Section 4.2 with: > > "In order to support the E-Tree in a more generic and more scalable way..= ." > > [Lizhong] A word "generic" does not solve the problem. Since you list the > possibility to add one root C-VLAN and another root S-VLAN, I need to > understand the scenario why we need that. The strange thing is, at the en= d > of this section: > > In all cases, the outermost VLAN in the resulted Ethernet header is > > used to indicate the E-Tree attribute of an Ethernet frame; this > > document uses VLAN to refer to this outermost VLAN for simplicity in > > the latter sections. > > Then why we should add the first root C-VLAN? > > And you should use same terminology across the document. And what's the > different among "Root VLAN", "Root C-VLAN", "Root S-VLAN", "Root B-VLAN", > and same question to leaf? > > [JY2] Similar to the IEEE terminology (a generic VLAN may be a C-VLAN, > S-VLAN or B-VLAN), a Root VLAN may be a "Root C-VLAN", "Root S-VLAN", or > "Root B-VLAN", the same applies to leaf VLAN. We will further clarify it = in > the terminology section by adding =E2=80=9Cit may be a C-VLAN, an S-VLAN = or a > B-VLAN=E2=80=9D to the definition of =E2=80=9CRoot VLAN=E2=80=9D and =E2= =80=9CLeaf VLAN=E2=80=9D, that is: > > =E2=80=9C Root VLAN: a VLAN ID used to indicate all the frames that are > > originated at a root AC, it may be a C-VLAN, an S-VLAN or a B-VLAN=E2= =80=9D > > Please note that an 802.1ad bridge module may co-exist with 802.1Q bridge > modules in the same PE (as shown in Fig.2 in RFC 6246), and both root > C-VLAN and root S-VLAN may be used at the same time, so that seamless > convergence can be realized (e.g., when 802.1Q bridges co-exist with 802.= 1D > bridges in the same customer network and be attached to this PE). > > To be clear, it is proposed to replace the 2nd paragraph in Section 4.2 > with: > > =E2=80=9CFor an untagged port (frames over this port are untagged) or VLA= N-unaware > port (VLAN tags in the frames are ignored), when the bridge module is a > C-VLAN bridge, the Ethernet frames received from the root ACs SHOULD be > tagged with a root C-VLAN and optionally MAY be added with another root > S-VLAN; when the bridge module is an 802.1ad bridge, the Ethernet frames > received from the root ACs SHOULD be tagged with a root S-VLAN (it can be > added with a root C-VLAN firstly but this is out of the scope of this > document). =E2=80=9C > > > > 11. Section4.2: =E2=80=9CFor an S-VLAN tagged port, the S-VLAN tag in t= he > Ethernet frames received from the root ACs SHOULD be translated to the ro= ot > S-VLAN in the VPLS network domain=E2=80=9D. The description of S-VLAN tag= ged port > is not accurate here. I think here, you want to refer to a port receiving= a > packet with both S-VLAN & C-VLAN. So it is better to say, =E2=80=9Cwhen r= eceiving > a packet with both S&C VLAN=E2=80=A6=E2=80=9D. Same suggestion to previou= s paragraphs. > > [JY] This is not what we want. There are implementations in the industry > that supports encapsulation of all traffics from a port into an S-VLAN (B= BF > TR-101 also specifies such a behavior). So no change is needed here. > > > > If S-VLAN only packet received, still translate S-VLAN to root S-VLAN? > > [JY] Yes, some SPs may prefer to use such an S-VLAN translation in their > networks for ease of management. This was also discussed in the L2VPN WG > before and a consensus was reached. > > [Lizhong] Then I could not agree you use "SHOULD" to mandatory the > translation. It is not necessary to do translation for S-VLAN only packet > in many cases. Could WG chair confirm the consensus Yuanlong refers to. > > [JY2] Maybe the previous L2VPN chairs has something to say since all > those details were discussed in L2VPN WG as early as in 2012. I have no > strong opinion to change =E2=80=9CSHOULD=E2=80=9D to =E2=80=9CMAY=E2=80= =9D, but it would be better to give > a preference when several options are given. > > > > 12. Section4.2: =E2=80=9Cthe E-Tree attribute may also be indicated wit= h two > I-SID tags in the bridge module=E2=80=9D. Suggest to remove since it is n= ot part > of this document. > > [JY] As I remember, this note was added to resolve a comment raised in th= e > L2VPN WG mailing list, and it was accepted into the document with no > objection. This note is totally informational, and I am not sure it is > appropriate to delete it. > > [Lizhong] You describe the brief method, but does not provide the detail. > My concern is, if there is future document to describe E-Tree for PBB-VLA= N, > and basic method is different with this document, then there will be > conflict. > > [JY2] Both Don & Dave mentioned this approach as a valid option (in > http://www.ietf.org/mail-archive/web/l2vpn/current/msg03433.html and > http://www.ietf.org/mail-archive/web/l2vpn/current/msg03365.html > respectively), and this paragraph was added in the E-Tree I-D before the = WG > adoption. IMO, this is informational and is useful, but let the WG decide > it. > > > > 13. Section5.2: =E2=80=9CFor both methods, VLAN mapping parameters from= a > remote PE can be provisioned or determined by a signaling protocol as > described in Section 6 when a PW is being established=E2=80=9D. For the g= lobal > method, why we need signaling? > > [JY] Just as the sentence says, the global VLAN method does not rely on > signaling for its work. > > But the SPs may prefer to use one method (e.g., global VLAN based) in > scenario A and the other method (e.g., local VLAN based) in scenario B, a= nd > they would like to keep both methods work in a similar way, so the > signaling protocol was designed to be applicable in both methods to give > them a similar operation experience (if signaling is supported). > > [Lizhong] I don't agree, what if deploying only global mode? You are > talking about the operational experience, but I am talking about the > technology. It is very confusing for the readers. > > [JY2] Firstly, signaling for global method is not mandatory. Secondly, > when control plane is needed, it is simple to implement if the same > signaling can be used in both cases. BTW, even in the global mode, we may > save some work in configuration if we have signaling capability (thus we > only need to configure two VLAN values per router). > > > > 14. Section5.3.1: =E2=80=9Ci.e., the local leaf VLAN in a frame is tran= slated > to the remote leaf VLAN; the local root VLAN in a frame is translated to > the remote root VLAN=E2=80=9D. Here you should refer back to section 4. > > [JY] At the end of Section 4, it already says: > > " In all cases, the outermost VLAN in the resulted Ethernet header is > > used to indicate the E-Tree attribute of an Ethernet frame; this > > document uses VLAN to refer to this outermost VLAN for simplicity in > > the latter sections." > > Since there are dozens of "VLAN"s in section 5 & 6 ("the latter sections" > aforementioned), referring to Section 4 for each use of VLAN is thus both > unnecessary and cumbersome. > > [Lizhong] But here is "local leaf VLAN" and "remote leaf VLAN", if I > expand, they will change to "local leaf outermost VLAN" and "remote > leaf outermost VLAN". Then question is what is the "remote > leaf outermost VLAN"? > > [JY2] No, we did not hint such a expansion. The E-Tree VLAN is generic (i= t > may be C-VLAN, S-VLAN or B-VLAN), and actually indicated by the outermost > VLAN. See comment 10 for the terminology clarification. > > > > 15. Section5.3.2: =E2=80=9CUpon receiving frames on the PW, add a VLAN = tag with > a value of the local root VLAN to the frames.=E2=80=9D Not understand her= e. Does > that mean all receiving frames will be considered to be from root? Then h= ow > to isolate traffic between two leaves? > > [JY] Yes, all the received frames from the PW will be from roots. As the > 1st paragraph in this section already says:"the VPLS PE with a traditiona= l > VSI can only be attached with root nodes." > > [Lizhong] OK. > > > > 16. Section5.3.3: =E2=80=9CIf a PE is in the Optimized Mode for a PW, u= pon > transmit=E2=80=9D. Suggest to: If a PE is in the Optimized Mode for a PW,= upon > transmit to leaf only nodes. > > [JY] As it already says in the 1st paragraph of Section 5.3.3, a PE works > in Optimized Mode for a PW only when its peer PE is attached with only le= af > nodes. Why add this condition again (in implementation, you need an extra > data plane operation to determine whether this condition is met, > furthermore, it is difficult to determine whether a destination node is a > root or leaf in the data plane)? > > [Lizhong] no, by signaling, the dataplane should know the remote PE is > leaf only or not. What I mean is, the drop operation is only valid for > leaf-only nodes. > > [JY2] this is always true, so the condition is not needed in the data > plane. To be clear, it is proposed to update the 1st sentence in Section > 5.3.3 =E2=80=9DWhen two PEs (both have E-Tree capability) are inter-conne= cted with > a PW =E2=80=A6=E2=80=A6its peer PE (e.g., PE1) should then work in the op= timized mode for > this PW.=E2=80=9D > > > > 17. Section6.1: =E2=80=9CIf the bit V is set, and the PE is capable of = VLAN > mapping, then the PE with the minimum IP address MUST set VLAN-Mapping-Mo= de > to TRUE;=E2=80=9D Which IP address? The address in the LDP IP header? > > [JY] Yes. > > [Lizhong] you should explicitly say that. But I personaly suggest to > compare the LDP ID in LDP signaling. > > [JY2] To be consistent with BGP section, suggest to keep it as is (in bot= h > cases, IP addresses used for comparison are extracted from their respecti= ve > IP sessions). > > > > > > 18. Section6.1: =E2=80=9C2) If the P bit is set, then:=E2=80=9D If abov= e is pseudo > code, then the code format should be more formal, to make it clear and ne= at. > > [JY] Thanks, we will remove the character ":" in the next revision. Does > this resolve your concerns? > > [Lizhong] you could refer to RFC4379 section 4.4. > > [JY2] thanks, we will. > > > > 19. Section6.1: =E2=80=9CIf the PE is a leaf-only node itself, then a l= abel > release message with a status code "Leaf to Leaf PW released" is sent to > the peer PE and exit the process;=E2=80=9D When both PE release the mappi= ng. Then > when one PE1 change the setting to have both root&leaf, and send label > mapping to PE2, will PE2 be triggered to send label mapping to PE1? > According to RFC5036, I think the answer is no. You need additional > mechanism here. > > [JY] Why PE2 cannot be triggered to send label mapping to PE1? IMO, we > don't need any additional mechanism here. If the configuration is changed > for a failed PW establishing session, then a new round of PW negotiations > can take place between PE1 and PE2. Furthermore, the PW negotiation proce= ss > is standardized in RFC 4447 rather than RFC 5036, and you can find answer= s > there. > > [Lizhong] You should give out the technical reason. There is no > configuration changing on PE2, and PE1 release the mapping from PE2, then > the PE2 will not send mapping again since DU mode is used for PW signalin= g. > BTW, the PW signaling RFC4447 is based on RFC5036, and also updated by > RFC6723. One method is, like RFC6723, PE1 need LDP request message to > reestablish the PW. > > [JY2] this is similar to comment 20 since it deals with topology and TLV > parameter updates. > > > > 20. Section6.1: the E-Tree Sub-TLV parameters updating should be also > mentioned in this section. > > [JY] Could you elaborate more on the specific requirements and scenarios > in your mind? Are you suggesting to support versions for this TLV? I am n= ot > sure we need such a complex mechanism. > > [Lizhong] The most simple updating mechanims is to LDP withdraw and > mapping again. If you want to be simple, it is better to explictly say th= at. > > [JY2] Please note that RFC 7152 which specifies the requirements for > E-Tree does not have such a requirement. Definitely, LDP withdrawal and > mapping (both have already been defined in RFC 4447) can be used in > updating PW labels and TLVs in LDP VPLS, but scenarios and requirements a= re > also needed. Maybe a new I-D is better to serve this purpose. The guidanc= e > from the WG chairs is needed. > > > > 21. Section6.2: =E2=80=9CData plane in the VPLS is the same as describe= d in > Section 4.2 of [RFC4761], and data plane processing for a PW is the same = as > described at the end of Section 6.1.=E2=80=9D Why same as RFC4761 here? D= on=E2=80=99t you > have VLAN-Mapping-Mode and other mode data plane operation? > > [JY] Please see the end of section 6.1, it says: > > " Data plane processing for this PW is as following: > > If Optimized-Mode is TRUE, then data plane processing as described > > in Section 5.3.3 applies. > > If VLAN-Mapping-Mode is TRUE, then data plane processing as > > described in Section 5.3.1 applies. > > If Compatible-Mode is TRUE, then data plane processing is as > > described in Section 5.3.2." > > These sub-sections definitely deal with E-Tree specific data plane > operations such as VLAN mapping. > > [Lizhong] You should say that, like: except described in section 6.1, > other dataplane behavior is same as ..... > > [JY2] They are on different topic: the end of Section 6.1 covers PW > processing, while Section 4.2 of [RFC4761] covers VPLS data plane. > > To be clear, it is proposed to say:=E2=80=9DData plane in the VPLS is the= same as > described in Section 4.2 of [RFC4761], and data plane processing for a PW > is the same as described at the end of Section 6.1 in this document.=E2= =80=9D > > > > 22. Section8: This section is too simple to remove it. Or please add > more detail. > > [JY] The details are already covered in Section 4 and Appendix A, so this > section is just a summary of the application scenarios it can work. > > [Lizhong] since covered, why we need summary here? Let WG decide. > > [JY2] Please note that RFC 7152 Section 5.2 has such a requirement. > > > > 23. Section9: New security concern will include: since the outmost VLAN > is leaf or root, it is easy to parse the leaf and root VLAN information. > > [JY] It is unclear to me what is the security hole you are trying to > indicate and what security measure is in your mind. Could you elaborate a > little more on it? In my opinion, VLANs in this document are not more > vulnerable compared with the VLANs in a tagged PW (see RFC 4448) and the > security measures as proposed in RFC 4762 and RFC 4448 are sufficient. > > [Lizhong] compared with VPLS, parse the VLAN could get the E-Tree topolog= y > for the E-tree VPLS. Topology information leaking is the concern. > > [JY2] yes, an intruder inside a carrier network may get the information o= n > the 2 E-Tree VLAN values used by the carrier, but is it worse than a sing= le > VLAN value in the case of a traditional VPLS? Are there any security > measures different? I am still in doubt. > > > > 24. Section10: The allocated value should be =E2=80=9CTBD=E2=80=9D. > > [JY] Sorry, I failed to understand the point. But all the values have > already been allocated officially by IANA, why do you suggest to use "TBD= " > instead? > > [Lizhong] I think IANA is pre-allocated, not final. Let WG decide. > > > > Regards > > Lizhong > > --089e01493db2977f2b051d4633b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For comment 17.
17.=C2=A0=C2=A0=C2=A0= Section6.1:=C2=A0=E2=80=9CIf the bit V is set, and the PE is capabl= e of VLAN mapping, then the PE with the minimum IP address MUST set VLAN-Ma= pping-Mode to TRUE;=E2=80=9D=C2=A0Which IP address? The address in = the LDP IP header?

[JY] Yes.

[Lizhong] you should explicitly say that. But I personaly suggest to c= ompare the LDP ID in LDP signaling.

[JY2] To be consistent with B= GP section, suggest to keep it as is (in both cases, IP addresses used for = comparison are extracted from their respective IP sessions).

[Lizhong] =C2=A0I= also could not accept such explanation. LDP ID is a stable ID while LDP he= llo adjacency may not. By using LDP ID to select the master/slave node is a= common way in LDP protocol. If you use the IP address in IP header of LDP = message, it will bring network unstability.



Regards
Lizhong


On Wed, A= ug 12, 2015 at 11:45 PM, lizho.jin@g= mail.com <lizho.jin@gmail.com> wrote:
Hi Yuanlong,
I could not agree with some of you= r explanations, and would like to raise comment 13 & 19 as the major is= sue. Please AD and chairs pay attention to this. I believe we must resolve = the two comments before any further steps. Thanks.


Regards
Lizhong
=C2=A0
From:=C2=A0Jiangyuanlong
Date:=C2=A02015-08-12=C2=A019:44=
= Subject:=C2=A0RE: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-= 07.txt

Hi Li= zhong,

=C2=A0

Pleas= e see my further comments inline with [JY2].

Thank= s a lot for your discussion.

=C2=A0

I als= o cc to Dave and Don for their suggestions, and cc to the chairs for their = guidance.

=C2=A0

Best = regards,

Yuanl= ong

=C2=A0

=C2=A0

From:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ;,"sans-serif""> lizho.jin@gmail.com [mailto:lizho.jin= @gmail.com]
Sent: Saturday, August 08, 2015 6:31 PM
To: Jiangyuanlong; rtg-ads
Cc: rtg-dir; pals; draft-ietf-l2vpn-vpls-pe-etree
Subject: RE: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07= .txt

=C2=A0

Hi, = I missed the email, and sorry for the late reply. Please see inline below.= =C2=A0

<= /u>=C2=A0


Regards=

Lizhong=

=C2= =A0

From:=C2=A0Jiangyuanlong

Date:=C2=A02015-06-11=C2=A005:48

Subject:=C2=A0RE: [Pals] RtgDir review: draft-ietf-l2vpn-vpl= s-pe-etree-07.txt

Lizho= ng,

=C2= =A0<= /p>

Thank= you a lot for the review, please see my comments with [JY] as a prefix.

=C2= =A0<= /p>

Regar= ds,<= /p>

Yuanl= ong<= /p>

=C2= =A0<= /p>

From: Pals [mailto:pals-bou= nces@ietf.org] On Behalf Of Lizhong Jin
Sent: Tuesday, June 02, 2015 5:55 PM
To: rtg-ads
Cc: rtg-dir; pals; draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org
Subject: [Pals] RtgDir review: draft-ietf-l2vpn-vpls-pe-etree-07.txt=

=C2= =A0

Hello,

I have been selected as = the Routing Directorate reviewer for this draft. The Routing Directorate se= eks to review all routing or routing-related drafts as they pass through IETF las= t call and IESG review, and sometimes on special request. The purpose of th= e review is to provide assistance to the Routing ADs. For more information = about the Routing Directorate, please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wik= i/RtgDir

Although these comments = are primarily for the use of the Routing ADs, it would be helpful if you co= uld consider them along with any other IETF Last Call comments that you receive, and st= rive to resolve them through discussion or by updating the draft.

Document: draft-ietf-l2v= pn-vpls-pe-etree-07.txt
Reviewer: Lizhong Jin
Review Date: 2nd June
IETF LC End Date:
Intended Status: Standards Track

Summary:
I have some minor concerns about this document that I think should be resol= ved before publication.

Comments:

Over= all, although there is no major technical issues for this draft, it is stro= ngly suggested to improve the English description to make it neat, and easier to be under= stood.

Major Issues:

No major issues found

Minor Issues:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Abstract: =E2=80=9Cservices=E2=80=9D<= span lang=3D"EN-US"> should be =E2=80=9Cservice=E2=80=9D

[JY] = Not needed, since multiple E-Tree services may be deployed in a single VPLS= network, and the solution aims to support this scenario.

[Lizhong] Then why you= use "uses" to describe "services"? I am referring the = grammar error here.

[JY2]= Please note that =E2=80=9Cwhich uses =E2=80=A6=E2=80=9D is an attributive = clause describing the solution, not the services.

=C2= =A0=C2=A0 =E2=80=9CA generic Virtual Private LAN Service (VPLS) solution is= specified

=C2= =A0=C2=A0 for Ethernet-Tree (E-Tree) services which uses VLANs to indicate<= u>

=C2= =A0=C2=A0 root or leaf traffic.=E2=80=9D

To be= clear, it is proposed to move it ahead in this way:

=C2= =A0=C2=A0 =E2=80=9CA generic Virtual Private LAN Service (VPLS) solution which uses VLANs to indicate

=C2=A0=C2=A0 root or leaf traffic is specified for Ethernet-Tree (E-Tree) services which uses VLANs to in= dicate

= =C2=A0=C2=A0 root or leaf traffic.

<= /u>=C2=A0

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Abstract: =E2=80=9Cthe MAC address based Eth= ernet forwarding engine and the PW work in the same way as before=E2= =80=9D, you should tell the detail of =E2=80=9Cbefore=E2=80=9D here, or add a reference here.

[JY] = Actually, Section 4 and 5 describe the details of how the Ethernet forwardi= ng engine and the PW work. I don't think we need to describe the details in an a= bstraction or forward reference any sections in the document here.

[Lizh= ong] I do not agree. The abstract section should give out the outline of wh= ole concept. Use word "before" does not provide any information for the reade= rs.<= /p>

[JY2]= it simply states that the MAC address based Ethernet forwarding engine and= the PW will not be changed, and it is proposed to be replaced with =E2=80=9Cthe MAC address based Ethernet forwarding engine and the PW = work in the same way as before in [RFC4762] and [RFC4448] respectively=E2=80=9D.<= /u>

=C2=A0

<= /u>=C2=A0

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Abstract: =E2=80=9Cis=E2=80=9D should be =E2=80=9Care=E2=80=9D

[JY] = There are 3 cases of "is" in the abstraction, but the suggested c= hange is not applicable to any of them. From the sequence it seems you are referring to the last o= ne, but the subject "A signaling mechanism" is not plural.=

[Lizh= ong] OK, since signaling mechanism also include VLAN mapping, then I sugges= t to change "V= LAN mapping negotiation" to "-Tree attribute".=

[JY2]= =C2=A0 =E2=80=9CE-Tree service attribute=E2=80=9D is already used in MEF, t= hus its use may introduce confusion to the topic, but to be clear, it is propos= ed to move the verb ahead:

=C2=A0=C2=A0 =E2=80=9CA signaling= mechanism is further described for E-Tree

=C2=A0=C2=A0 capability and VLAN mapping negotiation is further described.= =E2=80=9D

=C2=A0

<= /u>=C2=A0

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Section3 overall, suggest= to reorganize section 3. Split the section into two parts: 1. Introduction= ; 2. Motivation

[JY] = This is related to question 6 and 9, not sure what is the problem you are t= rying to solve as a whole.=

[Lizh= ong] not well organized in this section. Let WG to decide.

<= /u>=C2=A0

5.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Section3: =E2=80=9Cin fact, there is no exac= t corresponding terminology in IETF yet.=E2=80=9D =E2=80=9Cterminology=E2=80=9D could not be a reason. You should list the technology reason if you want to compare.

[JY] = This sentence simply points out the fact that E-Tree is a new type of servi= ce (no corresponding service defined in IETF yet), the technical comparison is done in the E-Tr= ee framework and is referenced in the next paragraph of this document.

[Lizh= ong] Please see the whole sentence I am referring:

Alth=
ough Virtual Private Multicast Service (VPMS)
=C2=A0=C2=A0 [VPMS] or Point-to-Multipoint (P=
2MP) multicast is a somewhat
=C2=A0=C2=A0 simplified version of this service, in fact, there is=
 no exact
=C2=A0=C2=A0 corresponding terminology in IETF yet.<=
/span>
I could not understand why you say the &quo=
t;terminology" here refer to E-Tree.

[JY2]= =C2=A0To be clear, rewrite= the 2nd part as =E2=80=9C=E2=80=A6, in fact, they are both mult= icast services and are different from an E-Tree service which may include b= oth unicast and multicast traffic=E2=80=9D.


6.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Section3: =E2=80=9CThough there were proposa= ls on using PW control word or PWs to indicate the root/leaf attribute of a= n E-Tree frame, both methods are limited in that they are only applicable to "VPLS only" networks.=E2=80= =9D You should have reference for other proposals. But= I don=E2=80=99t think you need to list these p= roposals, instead only say the motivation of the VLAN based solution.

[JY] = Both references were listed in the older versions of this draft indeed. Sin= ce there had been quite a lot of emails exchanged over these proposals before the W= G adoption of this draft, this sentence simply reflects a summary of the co= nclusions. We can remove it in the next revision if the WG thinks it approp= riate.

[Lizh= ong] OK.

<= /u>=C2=A0

7.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Section4.1: =E2=80=9CFig. 1 and Fig. 2 (both= figures are extracted from [RFC6246])=E2=80=9D= . You should switch the number of Fig1 and Fig2, since Fig1 is a detail description of Fig2.

[JY] = Not exactly, Fig.1 is not just a block of Fig. 2, it also describes CE acce= ss which is not shown in fig.2. Moreover, the order of CEs, the bridge and the VSI = as they appear in Fig.1 and Fig.2 is also more consistent with their networ= k topology. However, if we swap Fig.1 with Fig.2, then Fig.1 will forward r= eference to Fig.2, and this would be another disadvantage.

[Lizh= ong] Please refer to RFC6246. And let WG to decide. Thanks.

<= /u>=C2=A0

8.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Section4.1: =E2=80=9CTherefore, the associat= ion between an AC port and a PW on a VSI is difficult, sometimes even impos= sible.=E2=80=9D Could not understand what=E2=80=99s the purpose of this sentence he= re?

[JY] = It is proposed to update it with:

"= ;Therefore, the association between an AC port and a PW on a VSI without us= ing any VLAN is difficult, sometimes even impossible."

[Lizh= ong] still not agree. VLAN is not mandotary for the association. There are = many implementations for VPLS to have the association without VLAN, e.g., virtual/physical port= . I could not see the "difficult" here.

[JY2]= To resolve the concern, it is proposed to remove =E2=80=9C, sometimes even= impossible=E2=80=9D from the sentence.

(It s= hould be noted that this paragraph does not mandate anything; and in Ethern= et, a virtual port itself is usually implemented as VLAN;=C2=A0 using physical ports for internal connections in a device is not a common practi= ce).

<= /u>=C2=A0

9.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Section4.1: =E2=80=9CAssuming this mechanism= is implemented in the bridge module, it is quite straightforward to infer = a VPLS PE model with two VSIs to support the E-Tree (as shown in Fig. 3).=E2=80=9D Could move the = analysis to motivation section, or removed. And the logic here is not right= . The leaf/root VLAN indication is only for filtering, not bridging. So it = is not accurate to have Root/Leave S-VLAN here to get the enhanced model.

[JY] = Sorry, I am not sure I understand your reasoning here. It is already a stan= dardized mechanism to encapsulate and switch an E-Tree service into two VLANs by a = bridge according to IEEE 802.1Q-2011. Here is the only enhancement: a root = VLAN is connected to a root VSI and all the root VSIs in peer PEs constitut= e one VPLS instance (with one mesh of PWs), and a leaf VLAN is connected to a leaf VSI and all the leaf VSIs = constitute another VPLS instance (with another mesh of PWs), both VPLS inst= ances are transparent to the E-Tree traffic, and all the filtering operatio= ns are done on the bridge according to the IEEE 802.1Q mechanism (that is, VSIs do not need to filter any leaf= traffic).<= /span>

[Lizh= ong] I mean your inferring is not right.=C2=A0In RFC6246, it says:

The =
bridge
=C2=A0=C2=A0 module has a single "Emulated LAN" interfac=
e over which it
=C2=A0=C2=A0 communicates with all VPLS forwarders, and each VPLS =
instance is
=C2=A0=C2=A0 represented by a unique S-VLAN tag.

That is the S-VLAN is = used to indentify VLAN instance. But now=C2=A0S-VLAN is used to only identify E-Tree attribute, then it is not right to apply 8= 02.1ad bridge mode to illustrate E-Tree mode.

[JY2]= I think there is some misunderstanding here, S-VLANs for E-Tree is not dif= ferent from S-VLANs for other services (for example, E-LAN). In IEEE 802.1, the only requirement is that two unique S-VLAN values are used= (one used for root traffic forwarding, and the other used for leaf traffic= forwarding); and the two unique S-VLAN values aforementioned can each repr= esent a VPLS instance (just as described in RFC 6246). It is also noted in the document =E2=80=9Cboth these VSIs ha= ve to share their learned MAC addresses=E2=80=9D in page 7. VSIs forward E-= Tree traffic just like a normal VPLS service and all E-Tree filtering happe= ns in the bridge module.

<= /u>=C2=A0

10.<= /span>=C2=A0=C2=A0 Section4.2: =E2=80=9Cand optionally MAY be a= dded with another root S-VLAN.=E2=80=9D When an= d why add another root S-VLAN here? And why use terminology =E2=80=9Croot S-VLAN=E2=80=9D, not root VLAN as indicated in Figure4?

[JY] = Figure 4 is a generalized diagram, where VLAN may be a C-VLAN, S-VLAN or B-= VLAN, the texts in Section 4.2 describe each cases of specific VLANs respectively.

It is= proposed to update the 1st sentence "In order to support the E-Tree i= n a more scalable way..." in Section 4.2 with:

"= ;In order to support the E-Tree in a more generic and more scalable way...&= quot;

[Lizh= ong]=C2=A0A word "generic"=C2=A0does not solve the problem. Since= you list the possibility to add one root C-VLAN and another root S-VLAN, I need to understand the scen= ario why we need that. The strange thing is, at the end of this section:

In a=
ll cases, the outermost VLAN in the resulted Ethernet header is
=C2=A0=C2=A0 used to indicate the E-Tree attribute of an Ethernet =
frame; this
=C2=A0=C2=A0 document uses VLAN to refer to this outermost VLAN fo=
r simplicity in
=C2=A0=C2=A0 the latter sections.

Then = why we should add the first root C-VLAN?

And y= ou should use same terminology across the document. And what's the diff= erent among "Root VLAN", "Root C-VLAN", "Root S-VLAN", &= quot;Root B-VLAN", and same question to leaf?

[JY2]= Similar to the IEEE terminology (a generic VLAN may be a C-VLAN, S-VLAN or= B-VLAN), =C2=A0a Root VLAN may be a "Root C-VLAN", "Root= S-VLAN", or "Root B-VLAN", the same applies to leaf VLAN. W= e will further clarify it in the terminology section by adding =E2=80=9Cit may be a C-VLAN, an S-VLAN or a B-VLAN=E2=80=9D to the definition o= f =E2=80=9CRoot VLAN=E2=80=9D and =E2=80=9CLeaf VLAN=E2=80=9D, that is:

=E2=80=9C=C2=A0=C2=A0 Root VLAN: a VLAN ID used to indicate all the frames that are=

=C2=A0=C2=A0 originated at a root AC, it may be= a C-VLAN, an S-VLAN or a B-VLAN=E2=80=9D

Pleas= e note that an 802.1ad bridge module may co-exist with 802.1Q bridge module= s in the same PE (as shown in Fig.2 in RFC 6246), and both root C-VLAN and root S-VLAN may be used at the same time, so that seamless conv= ergence can be realized (e.g., when 802.1Q bridges co-exist with 802.1D bri= dges in the same customer network and be attached to this PE).

To be= clear, it is proposed to replace the 2nd paragraph in Section 4= .2 with:

=E2= =80=9CFor an untagged port (frames over this port are untagged) or VLAN-una= ware port (VLAN tags in the frames are ignored), when the bridge module is a C-VLAN bridge= , the Ethernet frames received from the root ACs SHOULD be tagged wi= th a root C-VLAN and optionally MAY be added with another root S-VLAN; when the bridge module is an 802.1ad bridge, the Ethern= et frames received from the root ACs SHOULD be tagged with a root S-VLAN (i= t can be added with a root C-VLAN firstly but this is out of the scope of this document)<= /span>. =E2=80=9C

<= /u>=C2=A0

11.<= /span>=C2=A0=C2=A0 Section4.2: =E2=80=9CFor an S-VLAN tagged po= rt, the S-VLAN tag in the Ethernet frames received from the root ACs SHOULD= be translated to the root S-VLAN in the VPLS network domain=E2=80=9D. The description of S-VLAN tag= ged port is not accurate here. I think here, you want to refer to a port re= ceiving a packet with both S-VLAN & C-VLAN. So it is better to say, =E2=80=9Cwhen receiving a packet with both S&am= p;C VLAN=E2=80=A6=E2=80=9D. Same suggestion to = previous paragraphs.

[JY] = This is not what we want. There are implementations in the industry that su= pports encapsulation of all traffics from a port into an S-VLAN (BBF TR-101 also specifies such= a behavior). So no change is needed here.

<= /u>=C2=A0

If S= -VLAN only packet received, still translate S-VLAN to root S-VLAN?

[JY] = =C2=A0Yes, some SPs may prefer to use such an S-VLAN translation in their n= etworks for ease of management. This was also discussed in the L2VPN WG before and a consen= sus was reached.

[Lizh= ong] Then I could not agree you use "SHOULD" to mandatory the tra= nslation. It is not necessary to do translation for S-VLAN only packet in many cases. Could WG= chair confirm the consensus Yuanlong refers to.

[JY2]= =C2=A0 Maybe the previous L2VPN chairs has something to say since all those= details were discussed in L2VPN WG as early as in 2012. I have no strong opinion to change =E2=80=9CSHOULD=E2=80=9D to =E2=80=9CMAY=E2=80=9D, but i= t would be better to give a preference when several options are given.

<= /u>=C2=A0

12.<= /span>=C2=A0=C2=A0 Section4.2: =E2=80=9Cthe E-Tree attribute ma= y also be indicated with two I-SID tags in the bridge module=E2=80= =9D. Suggest to remove since it is not part of this document.

[JY] = As I remember, this note was added to resolve a comment raised in the L2VPN= WG mailing list, and it was accepted into the document with no objection. This note i= s totally informational, and I am not sure it is appropriate to delete it.<= /span>

[Lizh= ong] You describe the brief method, but does not provide the detail. My con= cern is, if there is future document to describe E-Tree for PBB-VLAN, and basic met= hod is different with this document, then there will be conflict.=C2=A0

[JY2]= =C2=A0Both Don & Dave mentioned this approach as a valid option (in http://www.ietf.org/mail-archive/w= eb/l2vpn/current/msg03433.html and http://www.ietf.org/mail-arch= ive/web/l2vpn/current/msg03365.html respectively), and this paragraph was added in the E-Tree I-D before the WG adoption. IMO= , this is informational and is useful, but let the WG decide it.

=C2=A0

13.<= /span>=C2=A0=C2=A0 Section5.2: =E2=80=9CFor both methods, VLAN = mapping parameters from a remote PE can be provisioned or determined by a s= ignaling protocol as described in Section 6 when a PW is being established=E2=80=9D. For the gl= obal method, why we need signaling?

[JY] = Just as the sentence says, the global VLAN method does not rely on signalin= g for its work.

But t= he SPs may prefer to use one method (e.g., global VLAN based) in scenario A= and the other method (e.g., local VLAN based) in scenario B, and they would like t= o keep both methods work in a similar way, so the signaling protocol was de= signed to be applicable in both methods to give them a similar operation ex= perience (if signaling is supported).

[Lizh= ong] I don't agree, what if deploying only global mode? You are talking= about the operational experience, but I am talking about the technology. It is very confusing fo= r the readers.<= /u>

[JY2]= Firstly, signaling for global method is not mandatory. Secondly, when cont= rol plane is needed, it is simple to implement if the same signaling can be used in both cases. BTW, even in the global mode, we may save some = work in configuration if we have signaling capability (thus we only need to= configure two VLAN values per router).

<= /u>=C2=A0

14.<= /span>=C2=A0=C2=A0 Section5.3.1: =E2=80=9Ci.e., the local leaf = VLAN in a frame is translated to the remote leaf VLAN; the local root VLAN = in a frame is translated to the remote root VLAN=E2=80=9D. Here you should refer back to section 4.

[JY] = At the end of Section 4, it already says:

"= ;=C2=A0 In all cases, the outermost VLAN in the resulted Ethernet header is=

=C2= =A0=C2=A0 used to indicate the E-Tree attribute of an Ethernet frame; this<= /span>

=C2= =A0=C2=A0 document uses VLAN to refer to this outermost VLAN for simplicity= in<= /p>

=C2= =A0=C2=A0 the latter sections."

Since= there are dozens of "VLAN"s in section 5 & 6 ("the latt= er sections" aforementioned), referring to Section 4 for each use of VLAN is thus both unnecessary and c= umbersome.=C2=A0=C2=A0

[Lizh= ong] But here is "local leaf VLAN" and "remote leaf VLAN&quo= t;, if I expand, they will change to=C2=A0"local leaf outermost VLAN&q= uot; and "remote leaf=C2=A0outermost=C2=A0VLAN". Then question is= what is the=C2=A0"remote leaf=C2=A0outermost=C2=A0VLAN"?<= /span>

[JY2]= No, we did not hint such a expansion. The E-Tree VLAN is generic (it may b= e C-VLAN, S-VLAN or B-VLAN), and actually indicated by the outermost VLAN. See comment 10 for the terminology clarification.

<= /u>=C2=A0

15.<= /span>=C2=A0=C2=A0 Section5.3.2: =E2=80=9CUpon receiving frames= on the PW, add a VLAN tag with a value of the local root VLAN to the frame= s.=E2=80=9D Not understand here. Does that mean all receiving frames will be considered to be from root? Th= en how to isolate traffic between two leaves?

[JY] = Yes, all the received frames from the PW will be from roots. As the 1st par= agraph in this section already says:"the VPLS PE with a traditional VSI can onl= y be attached with root nodes."

[Lizh= ong] OK.

<= /u>=C2=A0

16.<= /span>=C2=A0=C2=A0 Section5.3.3: =E2=80=9CIf a PE is in the Opt= imized Mode for a PW, upon transmit=E2=80=9D. S= uggest to: If a PE is in the Optimized Mode for a PW, upon transmit to leaf only nodes.

[JY] = As it already says in the 1st paragraph of Section 5.3.3, a PE works in Opt= imized Mode for a PW only when its peer PE is attached with only leaf nodes. Why add t= his condition again (in implementation, you need an extra data plane operat= ion to determine whether this condition is met, furthermore, it is difficul= t to determine whether a destination node is a root or leaf in the data plane)?

[Lizh= ong] no, by signaling, the dataplane should know the remote PE is leaf only= or not. What I mean is, the drop operation is only valid for leaf-only nodes.

[JY2]= this is always true, so the condition is not needed in the data plane. To = be clear, it is proposed to update the 1st sentence in Section 5.3.3 =E2=80=9DWhen two PEs (both have E-Tree capability) are inter-connec= ted with a PW =E2=80=A6=E2=80=A6its peer PE (e.g., PE1) should then work= in the optimized mode for this PW.=E2=80=9D

<= /u>=C2=A0

17.<= /span>=C2=A0=C2=A0 Section6.1: =E2=80=9CIf the bit V is set, an= d the PE is capable of VLAN mapping, then the PE with the minimum IP addres= s MUST set VLAN-Mapping-Mode to TRUE;=E2=80=9D Which IP address? The address in the LDP IP header? <= /span>

[JY] = Yes.=

[Lizh= ong] you should explicitly say that. But I personaly suggest to compare the= LDP ID in LDP signaling.=

[JY2]= To be consistent with BGP section, suggest to keep it as is (in both cases= , IP addresses used for comparison are extracted from their respective IP sessions).

=C2=A0

<= /u>=C2=A0

18.<= /span>=C2=A0=C2=A0 Section6.1: =E2=80=9C2) If the P bit is set,= then:=E2=80=9D If above is pseudo code, then t= he code format should be more formal, to make it clear and neat.

[JY] = Thanks, we will remove the character ":" in the next revision. Do= es this resolve your concerns?<= /span>

[Lizh= ong] you could refer to RFC4379 section 4.4.

[JY2]= thanks, we will.

<= /u>=C2=A0

19.<= /span>=C2=A0=C2=A0 Section6.1: =E2=80=9CIf the PE is a leaf-onl= y node itself, then a label release message with a status code "Leaf t= o Leaf PW released" is sent to the peer PE and exit the process;=E2=80=9D When both PE release the map= ping. Then when one PE1 change the setting to have both root&leaf, and = send label mapping to PE2, will PE2 be triggered to send label mapping to P= E1? According to RFC5036, I think the answer is no. You need additional mechanism here.

[JY] = Why PE2 cannot be triggered to send label mapping to PE1? IMO, we don't= need any additional mechanism here. If the configuration is changed for a failed PW establishi= ng session, then a new round of PW negotiations can take place between PE1 = and PE2. Furthermore, the PW negotiation process is standardized in RFC 444= 7 rather than RFC 5036, and you can find answers there.<= u>

[Lizh= ong] You should give out the technical reason. There is no configuration ch= anging on PE2, and PE1 release the mapping from PE2, then the PE2 will not send mapp= ing again since DU mode is used for PW signaling. BTW, the PW signaling RFC= 4447 is based on RFC5036, and also updated by RFC6723. One method is, like = RFC6723, PE1 need LDP request message to reestablish the PW.

[JY2]= this is similar to comment 20 since it deals with topology and TLV paramet= er updates.

<= /u>=C2=A0

20.<= /span>=C2=A0=C2=A0 Section6.1: the E-Tree Su= b-TLV parameters updating should be also mentioned in this section.<= u>

[JY] = Could you elaborate more on the specific requirements and scenarios in your= mind? Are you suggesting to support versions for this TLV? I am not sure we need suc= h a complex mechanism.=

[Lizh= ong] The most simple updating mechanims is to LDP withdraw and mapping agai= n. If you want to be simple, it is better to explictly say that.

[JY2]= Please note that RFC 7152 which specifies the requirements for E-Tree does= not have such a requirement. Definitely, LDP withdrawal and mapping (both have already been defined in RFC 4447) can be used in updating PW la= bels and TLVs in LDP VPLS, but scenarios and requirements are also needed. = Maybe a new I-D is better to serve this purpose. The guidance from the WG c= hairs is needed.

<= /u>=C2=A0

21.<= /span>=C2=A0=C2=A0 Section6.2: =E2=80=9CData plane in the VPLS = is the same as described in Section 4.2 of [RFC4761], and data plane proces= sing for a PW is the same as described at the end of Section 6.1.=E2=80=9D Why same as RFC4761 h= ere? Don=E2=80=99t you have VLAN-Mapping-Mode a= nd other mode data plane operation?

[JY] = Please see the end of section 6.1, it says:

"= ;=C2=A0=C2=A0 Data plane processing for this PW is as following:

=C2= =A0=C2=A0 If Optimized-Mode is TRUE, then data plane processing as describe= d

=C2= =A0=C2=A0 in Section 5.3.3 applies.

=C2= =A0=C2=A0 If VLAN-Mapping-Mode is TRUE, then data plane processing as

=C2= =A0=C2=A0 described in Section 5.3.1 applies.

=C2= =A0=C2=A0 If Compatible-Mode is TRUE, then data plane processing is as

=C2= =A0=C2=A0 described in Section 5.3.2."

=C2= =A0=C2=A0=C2=A0These sub-sections definitely deal with E-Tree specific data= plane operations such as VLAN mapping.<= /u>

[Lizh= ong] You should say that, like: except described in section 6.1, other data= plane behavior is same as .....<= u>

[JY2]= They are on different topic: the end of Section 6.1 covers PW processing, = while Section 4.2 of [RFC4761] covers VPLS data plane.=

To be= clear, it is proposed to say:=E2=80=9DData plane in the VPLS is the same a= s described in Section 4.2 of [RFC4761], and data plane processing for a PW is the same as described at the end of Section 6.1 in this document.=E2=80=9D

<= /u>=C2=A0

22.<= /span>=C2=A0=C2=A0 Section8: This section is= too simple to remove it. Or please add more detail.

[JY] = The details are already covered in Section 4 and Appendix A, so this sectio= n is just a summary of the application scenarios it can work.

[Lizh= ong] since covered, why we need summary here? Let WG decide.

[JY2]= Please note that RFC 7152 Section 5.2 has such a requirement.

<= /u>=C2=A0

23.<= /span>=C2=A0=C2=A0 Section9: New security co= ncern will include: since the outmost VLAN is leaf or root, it is easy to p= arse the leaf and root VLAN information.

[JY] = It is unclear to me what is the security hole you are trying to indicate an= d what security measure is in your mind. Could you elaborate a little more on it? In my op= inion, VLANs in this document are not more vulnerable compared with the VLA= Ns in a tagged PW (see RFC 4448) and the security measures as proposed in R= FC 4762 and RFC 4448 are sufficient.

[Lizh= ong] compared with VPLS, parse the VLAN could get the E-Tree topology for t= he E-tree VPLS. Topology information leaking is the concern.

[JY2]= yes, an intruder inside a carrier network may get the information on the 2= E-Tree VLAN values used by the carrier, but is it worse than a single VLAN value in the case of a traditional VPLS? Are there any securit= y measures different? I am still in doubt.

=C2=A0

24.<= /span>=C2=A0=C2=A0 Section10: The allocated = value should be =E2=80=9CTBD= =E2=80=9D.

[JY] = Sorry, I failed to understand the point. But all the values have already be= en allocated officially by IANA, why do you suggest to use "TBD" instead?

[Lizh= ong] I think IANA is pre-allocated, not final. Let WG decide.

<= /u>=C2=A0

Rega= rds

Lizh= ong


--089e01493db2977f2b051d4633b4-- From nobody Mon Aug 17 08:10:46 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1311A8BB5; Sun, 16 Aug 2015 01:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FshZf9kmmSRd; Sun, 16 Aug 2015 01:28:34 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [82.96.72.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0FA1A8BB0; Sun, 16 Aug 2015 01:28:33 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZQtIr-0007kW-PZ with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Sun, 16 Aug 2015 10:28:29 +0200 Received: from [IPv6:2001:470:52f9:0:fef8:aeff:fe3f:44b3] (unknown [IPv6:2001:470:52f9:0:fef8:aeff:fe3f:44b3]) by lan.midlink.org (Postfix) with ESMTPSA id 3D3527FE68; Sun, 16 Aug 2015 10:30:39 +0200 (CEST) To: Juliusz Chroboczek , Pierre Pfister References: <55857123.90205@openwrt.org> <43C47623-C61D-4397-BA4A-8CBF8878B516@thomasclausen.org> <9630E81F-8AA0-4516-A9AE-56E0EB634599@iki.fi> <87r3n8xs3l.wl-jch@pps.univ-paris-diderot.fr> From: Steven Barth Message-ID: <55D049AC.3050008@midlink.org> Date: Sun, 16 Aug 2015 10:28:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <87r3n8xs3l.wl-jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Mon, 17 Aug 2015 08:10:45 -0700 Cc: "" , "homenet@ietf.org Group" , Markus Stenberg , "" Subject: Re: [RTG-DIR] [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2015 08:28:36 -0000 This has already been addressed in DNCP-09/HNCP-08. Am 12.08.2015 um 20:46 schrieb Juliusz Chroboczek: >> On a different topic, I think reserving 32 TLV types to DNCP is far from >> being enough. > > Seconded. > >> I guess that comment joins Thomas’ comment about version numbers, with >> which I agree (that we should add one). > > Thirded. > > -- Juliusz > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From nobody Wed Aug 19 09:50:02 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CB91A1AA5 for ; Wed, 19 Aug 2015 09:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV_MB2e6Fh6C for ; Wed, 19 Aug 2015 09:49:57 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B5E81A1AAD for ; Wed, 19 Aug 2015 09:49:53 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 43C57207A7 for ; Wed, 19 Aug 2015 12:49:52 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute1.internal (MEProxy); Wed, 19 Aug 2015 12:49:52 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=mm.st; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=FO/ pagLMFmmO0yxfVj5Xss6R0OY=; b=mZVtuZgOL4yW0T0+ON8ds6YkpSQ1RrhPcoN mrpruwH+yHOdjaqKLqyreH8JR2PWABvCYGIZjG5H8mTk9mQ0S6+soBHn3mrqQ/Qs r88mISCjk9zgMAlJBYKYVUOI7lUJsxhU65fkzU7GzoNxpwQPChO55Rap3UCrMeEF LFhulhIE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=FO/pagLMFmmO0yxfVj5Xss6R0OY=; b=pLM2T ZyKmGW68UU3HnvkxZj2882v1A+hE4UBg370zhRKkIt705IkAt0WJRLVDzc0F5pLh GbKbiWV2LD60segatn4yA3u88pCWB6n1n5PPnzlPL1i8afA+dmwL3rSt5L/kfamp bgbRtAqqONhqVpZYHaMcJGXLMJ7Cu80NzUeoWs= Received: by web4.nyi.internal (Postfix, from userid 99) id 17C0E1045E9; Wed, 19 Aug 2015 12:49:52 -0400 (EDT) Message-Id: <1440002992.3391528.360465129.4D684834@webmail.messagingengine.com> X-Sasl-Enc: U8tph645JKrQmcN+tJwKFTM3AFU9iceLTU2j2dQLw4VM 1440002992 From: Dan Frost To: rtg-ads@tools.ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4fee8ba5 Date: Wed, 19 Aug 2015 17:49:52 +0100 Archived-At: Cc: rtg-dir@ietf.org, draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org, mpls@ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-reply-mode-simple-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 16:50:01 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-mpls-lsp-ping-reply-mode-simple-03.txt Reviewer: Dan Frost Review Date: 19 Aug 2015 Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. =20=20=20 Comments: This document addresses an important practical limitation affecting the use of LSP Ping in deployed networks today. It is for the most part clearly written and complete, and contains helpful examples. Major Issues: No major issues found. Minor Issues: - Section 2, last paragraph: "This document adds one Reply Mode value to describe the reverse LSP, ...". This document does not appear to add a Reply Mode value, but rather to modify the semantics of the "Reply via Specified Path (5)" Reply Mode, as stated at the beginning of Section 3, so this sentence needs changing. - Section 3.1, first paragraph: Suggest adding RFC references for associated LSPs, e.g. RFC 5960 for MPLS-TP. - Section 3, general comment: This document is changing the semantics of Reply Mode 5, and in particular changing the case of Mode 5 without a Reply Path TLV from invalid to valid. However, the document does not appear to discuss interoperability issues in networks with a mix of "old" and "new" LSRs. This looks like something that should be addressed explicitly. - Section 3.1, last paragraph: This paragraph is very confusing and either needs to be deleted or completely rewritten. If, as it appears, it is not changing existing requirements for IP addressing of LSP Ping packets per RFCs 4379 and 7110, it should just be deleted. - Section 4.1, preference ordering of reply options: The document specifies that reply paths are to be preferred according to the order in which they appear in the Reply Mode Order TLV. However, it's not clear from this document and RFC 7110 what the order semantics are of including a Reply Path TLV with multiple sub-TLVs. For instance, in Section 4.1.1's example, FEC X and FEC Y are listed as different return paths. If they are different, what is their preference ordering and where is this defined? - General comment: It may be valuable for the authors to include a Manageability Considerations or similar section to provide guidance to implementors on configuration options, defaults, etc., particularly given the operational difficulties that led to this document in the first place. Nits: There are a lot (too many to list here) of minor English grammar problems, such as missing articles, throughout the text. I would suggest the editors do a grammatical review pass to clean these up as much as possible before the RFC Editor stage. Cheers, -d From nobody Wed Aug 19 15:08:22 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F142D1A00C1; Wed, 19 Aug 2015 15:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.915 X-Spam-Level: X-Spam-Status: No, score=-96.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, FM_ASCII_ART_SPACINGc=0.833, HTML_MESSAGE=0.001, TRACKER_ID=1.306, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUxAIi4ZgNKp; Wed, 19 Aug 2015 15:08:06 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3921A00BD; Wed, 19 Aug 2015 15:08:04 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.218.207; From: "Susan Hares" To: , Date: Wed, 19 Aug 2015 18:07:51 -0400 Message-ID: <015601d0dacb$7e234000$7a69c000$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0157_01D0DAA9.F7257620" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDays/iMu+shrF9QCKNtuCFIfwgSQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jonathan Hardwick' , rtg-dir@ietf.org, jon.hudson@gmail.com, 'Alia Atlas' Subject: [RTG-DIR] Mail regarding draft-ietf-trill-oam-mib-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 22:08:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0157_01D0DAA9.F7257620 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0158_01D0DAA9.F7257620" ------=_NextPart_001_0158_01D0DAA9.F7257620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Deepak, Samer, and Tissa: I reviewed draft-ietf-trill-oam-mib-07.txt document as the routing directorate review prior to the IESG evaluation. Below is a summary of my review and the text of the review. Just in case you want a pdf of the review, I've attached this review as well. Please contact me if you have any questions Sue Hares ----------------- Routing Directorate Review Reviewer: Susan Hares Version: draft-ietf-trill-oam-mib-07.txt Hat: routing directorate Other hats: TRILL WG chair Status: Technically ready to go. Editorial suggestions are given to improve readability. Date: 8/19/2015 ============ Caveat: Routing Reviews are a part of the IETF LC process. The authors The reviewer reviewed the concepts in the following table, and found the management concepts to be correct. A Majority of this review is the editorial issues: Editorial issues arise from the text text in sections 5.3.2.1 - 5.3.2.4 and the MIB text itself from various descriptions in the MIB. As the MIB compiles, it is important to re-compile this MIB after making editorial suggestions. In addition, the review found editorial issues (as indicated by other IESG members in review). This reviewer provides alternative text for many of the issues. MIB summary - using top-level structure MIB description: description (this has editorial issues) |--trillOamNotifications (trillOamMib 0} |--trillOamFaultAlarm |--trillOamMibObjects {trillOamMib 1} |--trillOamMep {trillOamMibObjects 1} |--trillOamMepTable {trillOamMep 1} - Local TRLL config | trilloamMepEntry {trillOamMepTable 1} Note: All items were checked in this table, and items 17, 18, 20-23, 26-27, 29-30, and 33 have editorial issues. The editorial issues are listed In this section. trillOamMepRName Unsigned32, { trillOamMepEntry 1 } trillOamMepNextPtmTId Counter32, { trillOamMepEntry 2 } trillOamMepNextMtvmTId Counter32, { trillOamMepEntry 3 } trillOamMepPtrIn Counter32, { trillOamMepEntry 4 } trillOamMepPtrInOutofOrder Counter32, { trillOamMepEntry 5 } trillOamMepPtrOut Counter32, { trillOamMepEntry 6 } trillOamMepMtvrIn Counter32, { trillOamMepEntry 7 } trillOamMepMtvrInOutofOrder Counter32, { trillOamMepEntry 8 } trillOamMepMtvrOut Counter32, { trillOamMepEntry 9 } trillOamMepTxLbmDestRName Unsigned32, { trillOamMepEntry 10 } trillOamMepTxLbmHC Unsigned32, { trillOamMepEntry 11 } trillOamMepTxLbmReplyModeOob TruthValue, { trillOamMepEntry 12 } trillOamMepTransmitLbmReplyIp OCTET STRING, { trillOamMepEntry 13 } trillOamMepTxLbmFlowEntropy OCTET STRING, { trillOamMepEntry 14 } trillOamMepTxPtmDestRName Unsigned32, { trillOamMepEntry 15 } trillOamMepTxPtmHC Unsigned32, {trillOamMepEntry 16 } trillOamMepTxPtmReplyModeOob TruthValue, { trillOamMepEntry 17 } trillOamMepTransmitPtmReplyIp OCTET STRING, { trillOamMepEntry 18 } trillOamMepTxPtmFlowEntropy OCTET STRING, { trillOamMepEntry 19 } trillOamMepTxPtmStatus TruthValue, ( trillOamMepEntry 20 } trillOamMepTxPtmResultOK TruthValue, { trillOamMepEntry 21 } trillOamMepTxPtmSeqNumber Unsigned32, { trillOamMepEntry 22} trillOamMepTxPtmMessages Integer32, { trillOamMepEntry 23 } trillOamMepTxMtvmTree Unsigned32, { trillOamMepEntry 24 } trillOamMepTxMtvmHC Unsigned32, { trillOamMepEntry 25 } trillOamMepTxMtvmReplyModeOob TruthValue, { trillOamMepEntry 26 } trillOamMepTransmitMtvmReplyIp OCTET STRING, { trillOamMepEntry 27 } trillOamMepTxMtvmFlowEntropy OCTET STRING, { trillOamMepEntry 28 } trillOamMepTxMtvmStatus TruthValue, { trillOamMepEntry 29 } trillOamMepTxMtvmResultOK TruthValue, { trillOamMepEntry 30 } trillOamMepTxMtvmMessages Integer32, { trillOamMepEntry 31 } trillOamMepTxMtvmSeqNumber Unsigned32, { trillOamMepEntry 32 } trillOamMepTxMtvmScopeList OCTET STRING, { trillOamMepEntry 33 } trillOamMepDiscontinuityTime TimeStamp { trillOamMepEntry 34 } } |--trillOamMepFlowCfgTable - { trillOamMep 2 } Note: All entries were checked and only the initial description and { trillOamMepFlowCfgEntry 5} have editorial issues trillOamMepFlowCfgIndex Unsigned32, { trillOamMepFlowCfgEntry 1 } trillOamMepFlowCfgFlowEntropy OCTET STRING, { trillOamMepFlowCfgEntry 2 } trillOamMepFlowCfgDestRName Unsigned32, { trillOamMepFlowCfgEntry 3 } trillOamMepFlowCfgFlowHC Unsigned32, { trillOamMepFlowCfgEntry 4 } trillOamMepFlowCfgRowStatus RowStatus { trillOamMepFlowCfgEntry 5 } |--trillOamPtrTable { trillOamMep 3 } Note: all items checked, and only { trillOamPtrEntry 1 } has editorial issues. trillOamMepPtrTransactionId Unsigned32, { trillOamPtrEntry 1 } trillOamMepPtrHC Unsigned32, { trillOamPtrEntry 2 } trillOamMepPtrFlag Unsigned32, { trillOamPtrEntry 3 } trillOamMepPtrErrorCode Unsigned32, { trillOamPtrEntry 4 } trillOamMepPtrTerminalMep TruthValue, { trillOamPtrEntry 5 } trillOamMepPtrLastEgressId Unsigned32, { trillOamPtrEntry 6 } trillOamMepPtrIngress Dot1agCfmIngressActionFieldValue, { trillOamPtrEntry 7 } trillOamMepPtrIngressMac MacAddress, { trillOamPtrEntry 8 } trillOamMepPtrIngressPortIdSubtype LldpPortIdSubtype, { trillOamPtrEntry 9 } trillOamMepPtrIngressPortId LldpPortId, { trillOamPtrEntry 10 } trillOamMepPtrEgress Dot1agCfmEgressActionFieldValue, { trillOamPtrEntry 11 } trillOamMepPtrEgressMac MacAddress, { trillOamPtrEntry 12 } trillOamMepPtrEgressPortIdSubtype LldpPortIdSubtype, { trillOamPtrEntry 13 } trillOamMepPtrEgressPortId LldpPortId, { trillOamPtrEntry 14 } trillOamMepPtrChassisIdSubtype LldpChassisIdSubtype, { trillOamPtrEntry 15 } trillOamMepPtrChassisId LldpChassisId, { trillOamPtrEntry 16 } trillOamMepPtrOrganizationSpecificTlv OCTET STRING, { trillOamPtrEntry 17} trillOamMepPtrNextHopNicknames OCTET STRING { trillOamPtrEntry 18 } |--trillOamMtvrTable { trillOamMep 4 } Note: Main table description needs some pagination fixing. All nodes bolded could use some pagination fixing 1-3, 6, and 8. trillOamMepMtvrTransactionId Unsigned32, { trillOamMtvrEntry 1} trillOamMepMtvrReceiveOrder Unsigned32, { trillOamMtvrEntry 2} trillOamMepMtvrFlag Unsigned32, { trillOamMtvrEntry 3} trillOamMepMtvrErrorCode Unsigned32, { trillOamMtvrEntry 4} trillOamMepMtvrLastEgressId Unsigned32, { trillOamMtvrEntry 5} trillOamMepMtvrIngress Dot1agCfmIngressActionFieldValue, { trillOamMtvrEntry 6 } trillOamMepMtvrIngressMac MacAddress, { trillOamMtvrEntry 7 } trillOamMepMtvrIngressPortIdSubtype LldpPortIdSubtype, { trillOamMtvrEntry 8 } trillOamMepMtvrIngressPortId LldpPortId, { trillOamMtvrEntry 9} trillOamMepMtvrEgress Dot1agCfmEgressActionFieldValue, { trillOamMtvrEntry 10 } trillOamMepMtvrEgressMac MacAddress, { trillOamMtvrEntry 11 } trillOamMepMtvrEgressPortIdSubtype LldpPortIdSubtype, { trillOamMtvrEntry 12 } trillOamMepMtvrEgressPortId LldpPortId, { trillOamMtvrEntry 13 } trillOamMepMtvrChassisIdSubtype LldpChassisIdSubtype, { trillOamMtvrEntry 14 } trillOamMepMtvrChassisId LldpChassisId, { trillOamMtvrEntry 15 } trillOamMepMtvrOrganizationSpecificTlv OCTET STRING, { trillOamMtvrEntry 16 } trillOamMepMtvrNextHopNicknames OCTET STRING, { trillOamMtvrEntry 17 } trillOamMepMtvrReceiverAvailability TruthValue, { trillOamMtvrEntry 18 } trillOamMepMtvrReceiverCount TruthValue { trillOamMtvrEntry 19 } |--trillOamMepDbTable Note: Main table description needs some pagination fixing. The description in node {trillOamMepDbEntry 1 } - could use pagination aid. trillOamMepDbFlowIndex Unsigned32, {trillOamMepDbEntry 1 } trillOamMepDbFlowEntropy OCTET STRING, {trillOamMepDbEntry 1 } trillOamMepDbFlowState Dot1agCfmRemoteMepState, {trillOamMepDbEntry 2 } trillOamMepDbFlowFailedOkTime TimeStamp, {trillOamMepDbEntry 3 } trillOamMepDbRbridgeName Unsigned32, {trillOamMepDbEntry 4 } trillOamMepDbLastGoodSeqNum Counter32 {trillOamMepDbEntry 5 } | trillOamFaultAlarm NOTIFICATION-TYPE { trillOamNotifications 1 } No editorial or problems with this |--TrillOamMibConformance {trillOamMib 2} The main description is good. The descriptions in the following nodes have problems: trillOamMibCompliance MODULE-COMPLIANCE with mandatory groups of: trillOamMepMandatoryGroup, trillOamMepFlowCfgTableGroup, trillOamPtrTableGroup, trillOamMtvrTableGroup, trillOamMepDbGroup, trillOamNotificationGroup The compliance is reasonable, and the descriptions within this group are accurate. trillOamMibReadOnlyCompliance MODULE-COMPLIANCE with mandatory groups of: trillOamMepMandatoryGroup, trillOamMepFlowCfgTableGroup, trillOamPtrTableGroup, trillOamMtvrTableGroup, trillOamMepDbGroup, trillOamNotificationGroup } The compliance seems reasonable, and the description within this group are accurate. Security section: Seems reasonable and meets Security ADs input. IANA Section: Seems reasonable and meets IANA ADs input. Editorial Comments 1) New format needs to be used (See Alissa Cooper's comment) 2) Section 5.3.2.1 - has indentation that needs to be move outward. 3) Section 5.3.2.2 - editorial suggestions: Old: /The table uses four indices/ New: /This table uses four indices/ 4) Section 5.3.2.3 Old : / Each row in the table represents a Path Trace Reply entry for the Defined MEP and Transaction./ New: /Each row in this table represents a Path Trace reply Entry for the Defined MEP and Transaction./ Old: The first three indices identify the MEP and the fourth index specifies the transaction Identifier, and this transaction identifier/ New: The first three indices identify the MEP and the fourth index specifies the transaction identifier. This transaction identifier/ 5) Section 5.3.2.4 Old: This table includes Multi-destination Reply managed objects. New: This table includes managed objects for the Multi-Destination Reply. Old: This table uses five indices: The first three indices are the indices of the Maintenance Domain, MaNet, and MEP tables. The fourth index is the specific Transaction Identifiet on the selected MEP. The fifth index is the receive order of Multi- destination replies. New: This table uses the following five indices: 1) Maintenance Domain, 2) MANET, 3) MEP tables, 4) Transaction identifier of selected MEP, and 5) receive order of Multi-destination replies. 6) Section 5.3.2.4 trilllOamMepDbTable Objects Editorial: Rename the title from: Section 5.3.2.4 trillOamMepDbTable To: Section 5.3.2.5 trillOamMepDbTable Objects MIB Editorial (page numbers only) Page 10 Old: / SNMP Agent An SNMP entity containing one or more command responder and/or notification originator applications (along with their associated SNMP engine). Typically implemented in Network Element. SNMP Manager An SNMP entity containing one or more command generator and/or notification receiver applications ( along with their associated SNMP engine). Typically implemented in an EMS or NMS. / New: / SNMP Agent An SNMP entity containing one or more command Responder and/or notification originator applications (along with their associated SNMP engine). Typically implemented in Network Element. SNMP Manager An SNMP entity containing one or more command generator and/or notification receiver applications ( along with their associated SNMP engine). Typically implemented in an EMS or NMS. Page 11-nn on parameters Old text: Implementation should be unique to identify Transaction ID for MEP with multiple flows. New text Implementation of this identifier should have a unique code value in order to identify the transaction ID for a MEP with multiple flows" page 12: Old text: "Next sequence number/transaction identifier to be sent in a Multi-destination message. This sequence number can be zero because it wraps around. Implementation should be unique to identify Transaction Id for a MEP with multiple flows." New text: "Next sequence number/transaction identifier to be sent in a Multi-destination message. This sequence number can be zero because it wraps around. Implementation of this identifier should be should provide a unique code value in order to identify Transaction Id for a MEP with multiple flows." Page 15 Old text: trillOamMepTxPtmReplyModeOob OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "True Indicates that Reply of Ptm is out of band and out of band IP Address TLV is to be transmitted. False indicates that In band reply is transmitted." REFERENCE "RFC 7455 section 10" DEFVAL { false } ::= { trillOamMepEntry 17 } New text / trillOamMepTxPtmReplyModeOob OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "True Indicates that Reply of Ptm will be made out of band and out of band IP Address TLV is to be transmitted. False indicates that an In band reply is transmitted." REFERENCE "RFC 7455 section 10" DEFVAL { false } ::= { trillOamMepEntry 17 } / [bold only in text to show you the change ] Page 15 Old:/ trillOamMepTransmitPtmReplyIp OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "IP address for out of band IP Address TLV is to be transmitted, Maximum length for IPv6 is 16 OCTET and IPv4 is 4 OCTET." REFERENCE "RFC 7455 section 3 and 10" ::= { trillOamMepEntry 18 } / New: trillOamMepTransmitPtmReplyIp OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "IP address for out of band IP Address TLV is to be Transmitted. The maximum length for IPv6 address is 16 Octets. The maximum length for an IPv4 address is 4 octets." REFERENCE "RFC 7455 section 3 and 10" ::= { trillOamMepEntry 18 } / Page 15-16 Old: trillOamMepTxPtmStatus OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A Boolean flag set to true by the MEP Path Trace Initiator State Machine or an MIB manager to indicate that another PTM is being transmitted. Reset to false by the MEP Initiator State Machine. The PTM managed objects in the MEP table are used in a manner similar to that described for LBM transmission in dot1agCfmMepTable. As per RFC7455 section 10, Operation of the Path Trace Message is identical to the Loopback Message except that it is first transmitted with a TRILL Header Hop count field value of 1 and it's retransmitted incrementing Hop count until a response is received from the destination RBridge, or the Hop Count reaches a configured maximum value. trillOamMepTxPtmStatus Status is reset to FALSE by initiator when last PTM is transmitted." REFERENCE "RFC 7455 section 10" DEFVAL { false } ::= { trillOamMepEntry 20 } / New: / trillOamMepTxPtmStatus OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A Boolean flag set to true by the MEP Path Trace Initiator State Machine or an MIB manager to indicate that another PTM is being transmitted. This is reset to false by the MEP Initiator State Machine. The PTM managed objects in the MEP table are used in a manner similar to that described for LBM transmission in dot1agCfmMepTable. As per RFC7455 section 10, Operation of the Path Trace Message is identical to the Loopback Message except that it is first transmitted with a TRILL Header Hop count field value of 1, and then retransmitted with incrementing Hop count until a response is received from the destination RBridge, or the Hop Count reaches a configured maximum value. trillOamMepTxPtmStatus Status is reset to FALSE by initiator when last PTM is transmitted." REFERENCE "RFC 7455 section 10" DEFVAL { false } ::= { trillOamMepEntry 20 } Page 16 Old: / trillOamMepTxPtmResultOK OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the result of the operation: - true The Path Trace Message(s) will be (or has been) sent. - false The Path Trace Message(s) will not be sent." REFERENCE "RFC 7455 section 10" DEFVAL { true } ::= { trillOamMepEntry 21 } / New: / trillOamMepTxPtmResultOK OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the following results of the operation: - true The Path Trace Message(s) will be (or has been) sent. - false The Path Trace Message(s) will not be sent." REFERENCE "RFC 7455 section 10" DEFVAL { true } ::= { trillOamMepEntry 21 } / Page 16 - pagination only Old: trillOamMepTxPtmSeqNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The Path Trace Transaction Identifier of the first PTM (to be) sent. The value returned is undefined if trillOamMepTxPtmResultOK is false." REFERENCE "RFC 7455 section 10" ::= { trillOamMepEntry 22 } New: trillOamMepTxPtmSeqNumber OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The Path Trace Transaction Identifier of the first PTM (to be) sent. The value returned is undefined if trillOamMepTxPtmResultOK is false." REFERENCE "RFC 7455 section 10" ::= { trillOamMepEntry 22 } / Page 17 Old: maximum value. Once Destination or Hop count reaches it's treated as single Counter increment of this object, and above process is repeated starting Hop count 1 till maximum PTM transmission is reached. It's treated as Repeat Counter for above described operation." REFERENCE "RFC 7455 section 10" ::= { trillOamMepEntry 23 } New: maximum value. The event of the Destination response being received or the Hop count reaching its maximum is treated as single Counter increment of this object. The bove process is repeated starting untill maximum PTM transmission is reached. It's treated as Repeat Counter for above described operation." REFERENCE "RFC 7455 section 10" ::= { trillOamMepEntry 23 } / Page 17 Old: / trillOamMepTxMtvmReplyModeOob OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "True Indicates that Reply of Mtvm is out of band and out of band IP Address TLV is to be transmitted. False indicates that In band reply is transmitted." REFERENCE "RFC 7455 section 11" ::= { trillOamMepEntry 26 } / New trillOamMepTxMtvmReplyModeOob OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A True value Indicates that Reply of Mtvm is out of band and out of band IP Address TLV is to be transmitted. A False value indicates that In band reply is transmitted." REFERENCE "RFC 7455 section 11" ::= { trillOamMepEntry 26 } P17-p18 Old / trillOamMepTransmitMtvmReplyIp OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "IP address for out of band IP Address TLV is to be transmitted, Maximum length for IPv6 is 16 OCTET and IPv4 is 4 OCTET." REFERENCE "RFC 7455 section 11 ::= { trillOamMepEntry 27 } / New/ trillOamMepTransmitMtvmReplyIp OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "IP address for out of band IP Address TLV is to be Transmitted. The maximum length for IPv6 is 16 octets and IPv4 is 4 octets." REFERENCE "RFC 7455 section 11 REFERENCE "RFC 7455 section 11 ::= { trillOamMepEntry 27 } / Page 18 Old/ trillOamMepTxMtvmStatus OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A Boolean flag set to true by the MEP Multi Destination Initiator State Machine or an MIB manager to indicate that another Mtvm is being transmitted. Reset to false by the MEP Initiator State Machine. The Mtvm managed objects in the MEP table are used in a manner similar to that described for LBM transmission in dot1agCfmMepTable. As per RFC7455 section 11, Operation of the MTvm Message is identical to the Loopback Message except that it is first transmitted with a TRILL Header Hop count field value of 1 and it's retransmitted incrementing Hop count until a response is received from the destination RBridge, or the Hop Count reaches a configured maximum value. trillOamMepTxMtvmStatus Status is reset to FALSE by initiator when last Mtvm is transmitted." REFERENCE "RFC 7455 section 11" DEFVAL { false } ::= { trillOamMepEntry 29 } / New: description "A Boolean flag set to true by the MEP Multi Destination Initiator State Machine or an MIB manager to indicate that another Mtvm is being transmitted. This value is reset to false by the MEP Initiator State Machine. The Mtvm managed objects in the MEP table are used in a manner similar to that described for LBM transmission in dot1agCfmMepTable. As per RFC7455 section 11, Operation of the MTvm Message is identical to the Loopback Message except that it is first transmitted with a TRILL Header Hop count field value of 1 and it is retransmitted incrementing Hop count until a response is received from the destination RBridge, or the Hop Count reaches a configured maximum value. trillOamMepTxMtvmStatus Status is reset to FALSE by initiator when last Mtvm is transmitted." / Old/ trillOamMepTxMtvmResultOK OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the result of the operation: - true The Multi-destination Message(s) will be (or has been) sent. - false The Multi-destination Message(s) will not be sent." REFERENCE "RFC 7455 section 11" DEFVAL { true } ::= { trillOamMepEntry 30 } / New description for this text / DESCRIPTION "Indicates the result of the operation in the following way: - true: indicates the Multi-destination Message(s) will be (or has been) sent. - false: indicates the Multi-destination Message(s) will not be sent." / Page 19 Old/ trillOamMepTxMtvmScopeList OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "The Multi-destination Rbridge Scope list, 2 OCTET per Rbridge." REFERENCE "RFC 7455 section 11" ::= { trillOamMepEntry 33 } / New/ trillOamMepTxMtvmScopeList OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "The Multi-destination Rbridge Scope list which requires 2 octets per Rbridge." REFERENCE "RFC 7455 section 11" ::= { trillOamMepEntry 33 } / Page 20: Old/ trillOamMepFlowCfgTable OBJECT-TYPE SYNTAX SEQUENCE OF TrillOamMepFlowCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table includes configuration objects and operations for the Trill OAM RFC 7455. Each row in the table represents a Flow configuration Entry for the defined MEP. This table uses four indices. The first three indices are the indices of the Maintenance Domain, MaNet, and MEP tables. The fourth index is the specific Flow configuration Entry on the selected MEP. / Fix the pagination as follows: New: DESCRIPTION "This table includes configuration objects and operations for the Trill OAM RFC 7455. Each row in the table represents a Flow configuration Entry for the defined MEP. This table uses four indices. The first three indices are the indices of the Maintenance Domain, MaNet, and MEP tables. The fourth index is the specific flow configuration Entry on the selected MEP. / Fix pagination page 21 trillOamMepFlowCfgIndex Unsigned32, { trillOamMepFlowCfgEntry 1 } - text is fine. Fix the pagination in the description. Page 22 Old trillOamPtrTable OBJECT-TYPE SYNTAX SEQUENCE OF TrillOamPtrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table includes Path Trace Reply objects and operations for the Trill OAM RFC 7455. Each row in the table represents a Path Trace Reply Entry for the defined MEP and Transaction. This table uses four indices. The first three indices are the indices of the Maintenance Domain, MaNet, and MEP tables. The fourth index is the specific Transaction Identifier on the selected MEP. Some writable objects in this table are only applicable in certain cases (as described under each object), and attempts to write values for them in other cases will be ignored." REFERENCE "RFC 7455" ::= { trillOamMep 3 } / New description: (Only pagination in the text) DESCRIPTION "This table includes Path Trace Reply objects and operations for the Trill OAM RFC 7455. Each row in the table represents a Path Trace Reply Entry for the defined MEP and Transaction. This table uses four indices. The first three indices are the indices of the Maintenance Domain, MaNet, and MEP tables. The fourth index is the specific Transaction Identifier on the selected MEP. Some writable objects in this table are only applicable in certain cases (as described under each object), and attempts to write values for them in other cases will be ignored." / Pages 23 -25 editorial: |--trillOamPtrTable { trillOamMep 3 } trillOamMepPtrTransactionId Unsigned32, { trillOamPtrEntry 1 } - fix pagination trillOamMepPtrHC Unsigned32, trillOamMepPtrFlag Unsigned32, trillOamMepPtrErrorCode Unsigned32, trillOamMepPtrTerminalMep TruthValue, trillOamMepPtrLastEgressId Unsigned32, trillOamMepPtrIngress Dot1agCfmIngressActionFieldValue, trillOamMepPtrIngressMac MacAddress, trillOamMepPtrIngressPortIdSubtype LldpPortIdSubtype, trillOamMepPtrIngressPortId LldpPortId, trillOamMepPtrEgress Dot1agCfmEgressActionFieldValue, trillOamMepPtrEgressMac MacAddress, trillOamMepPtrEgressPortIdSubtype LldpPortIdSubtype, trillOamMepPtrEgressPortId LldpPortId, trillOamMepPtrChassisIdSubtype LldpChassisIdSubtype, trillOamMepPtrChassisId LldpChassisId, trillOamMepPtrOrganizationSpecificTlv OCTET STRING, ------=_NextPart_001_0158_01D0DAA9.F7257620 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Deepak, = Samer, and Tissa:

 

I reviewed = draft-ietf-trill-oam-mib-07.txt  document as the routing = directorate review prior to the IESG evaluation.   Below is a = summary of my review and the text of the review.  Just in case you = want a pdf of the review, I’ve attached this review as well. =

 

Please contact me if you have any questions =

 

Sue Hares

 

-----------------

Routing Directorate Review

Reviewer:  Susan Hares

Version: = draft-ietf-trill-oam-mib-07.txt

Hat: = routing directorate

Other hats: = TRILL WG chair

Status:  = Technically ready to go.  Editorial suggestions are given to = improve readability.

Date:  = 8/19/2015

 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Caveat:  Routing Reviews are a part of the = IETF LC process.  The authors

 

 

The reviewer = reviewed the concepts in the following table, and found the management = concepts to be correct.  A Majority of this review is the editorial = issues:

 

Editorial issues arise from the text text in sections = 5.3.2.1 – 5.3.2.4 and the MIB text itself from various = descriptions in the MIB.  As the MIB compiles, it is important to = re-compile this MIB after making editorial suggestions. =

 

In addition, the review found editorial issues (as = indicated by other IESG members in review).  This reviewer provides = alternative text for many of the issues.

 

MIB summary – using = top-level structure 

MIB description: =

  description  (this has = editorial issues)

 

|--trillOamNotifications =          (trillOamMib = 0}

  |--trillOamFaultAlarm    =

 |--trillOamMibObjects   =        {trillOamMib = 1}

  = |--trillOamMep        =        {trillOamMibObjects = 1}

      = |--trillOamMepTable =             &= nbsp;         {trillOamMep = 1}  - Local TRLL config

        = ;  | = trilloamMepEntry         &nb= sp;   {trillOamMepTable 1}

 

Note: All items were checked in this table, = and items 17, 18, 20-23, 26-27, 29-30, and 33 have editorial issues. The = editorial issues are listed In this section.

 

      =             &= nbsp;     = trillOamMepRName         &nb= sp;     Unsigned32, { trillOamMepEntry 1 = }

        = ;   =              = trillOamMepNextPtmTId        &nbs= p; Counter32, { trillOamMepEntry 2 }

        = ;   =              = trillOamMepNextMtvmTId         = Counter32, { trillOamMepEntry 3 }

        = ;   =              = trillOamMepPtrIn         &nb= sp;     Counter32,  { trillOamMepEntry 4 = }

        = ;   =              = trillOamMepPtrInOutofOrder     Counter32, { = trillOamMepEntry 5 }

        = ;   =              = trillOamMepPtrOut         &n= bsp;    Counter32, { trillOamMepEntry 6 = }

trillOamMepMtvrIn     =          Counter32, { = trillOamMepEntry 7 }

        = ;   =              = trillOamMepMtvrInOutofOrder    Counter32,  { = trillOamMepEntry 8 }

        = ;   =              = trillOamMepMtvrOut         &= nbsp;   Counter32,  { trillOamMepEntry 9 = }

        = ;   =              = trillOamMepTxLbmDestRName      Unsigned32, { = trillOamMepEntry 10 }

        = ;   =              = trillOamMepTxLbmHC         &= nbsp;   Unsigned32, { trillOamMepEntry 11 = }

        = ;   =              = trillOamMepTxLbmReplyModeOob   TruthValue, { trillOamMepEntry = 12 }

        = ;   =              = trillOamMepTransmitLbmReplyIp  OCTET STRING, { trillOamMepEntry 13 = }

        = ;   =              = trillOamMepTxLbmFlowEntropy    OCTET STRING, { = trillOamMepEntry 14 }

        = ;   =              = trillOamMepTxPtmDestRName      Unsigned32, =   { trillOamMepEntry 15 }

        = ;   =              = trillOamMepTxPtmHC         &= nbsp;   Unsigned32,   =         {trillOamMepEntry 16 = }

        = ;   =            &nbs= p; trillOamMepTxPtmReplyModeOob   TruthValue, { = trillOamMepEntry 17 }

        = ;  =             &= nbsp;  trillOamMepTransmitPtmReplyIp  OCTET STRING, { = trillOamMepEntry 18 }

        = ;   =              = trillOamMepTxPtmFlowEntropy    OCTET STRING,  { = trillOamMepEntry 19 }

        = ;   =              = trillOamMepTxPtmStatus         = TruthValue,          =      ( trillOamMepEntry 20 } =

        = ;            =     = trillOamMepTxPtmResultOK       = TruthValue,         { = trillOamMepEntry 21 }

        = ;   =              = trillOamMepTxPtmSeqNumber      = Unsigned32,   { trillOamMepEntry = 22}

        = ;   =              = trillOamMepTxPtmMessages       = Integer32,        =     { trillOamMepEntry 23 = }

        = ;   =              = trillOamMepTxMtvmTree        &nbs= p; Unsigned32,         { = trillOamMepEntry 24 }

        = ;   =              = trillOamMepTxMtvmHC         =    Unsigned32,        =    { trillOamMepEntry 25 }

        = ;   =              = trillOamMepTxMtvmReplyModeOob  TruthValue,  { trillOamMepEntry = 26 }

        = ;   =              = trillOamMepTransmitMtvmReplyIp OCTET STRING, { trillOamMepEntry 27 = }

        = ;   =              = trillOamMepTxMtvmFlowEntropy   OCTET STRING,   { = trillOamMepEntry 28 }

        = ;   =              = trillOamMepTxMtvmStatus        = TruthValue,       { trillOamMepEntry 29 = }

        = ;   =              = trillOamMepTxMtvmResultOK      = TruthValue,    { trillOamMepEntry 30 = }

        = ; =             &= nbsp;  trillOamMepTxMtvmMessages      = Integer32,       { trillOamMepEntry 31 = }

    =             &= nbsp;       =  trillOamMepTxMtvmSeqNumber     = Unsigned32,    { trillOamMepEntry 32 = }

        = ; =             &= nbsp;   trillOamMepTxMtvmScopeList     = OCTET STRING,   { trillOamMepEntry 33 = }

        =             &= nbsp;    trillOamMepDiscontinuityTime   = TimeStamp { trillOamMepEntry 34 }

   }

 

        = ;   |--trillOamMepFlowCfgTable –   { = trillOamMep 2 }

Note: All entries were checked and only the = initial description and { trillOamMepFlowCfgEntry 5} have editorial = issues 

        = ;  

trillOamMepFlowCfgIndex    =    = Unsigned32,          &n= bsp; { trillOamMepFlowCfgEntry 1 }

trillOamMepFlowCfgFlowEntropy OCTET STRING, { = trillOamMepFlowCfgEntry 2 }

trillOamMepFlowCfgDestRName   = Unsigned32,    { trillOamMepFlowCfgEntry 3 = }

trillOamMepFlowCfgFlowHC    = ;  Unsigned32,       { = trillOamMepFlowCfgEntry 4 }

trillOamMepFlowCfgRowStatus   = RowStatus       { trillOamMepFlowCfgEntry = 5 }

 

        = ;   |--trillOamPtrTable   { trillOamMep 3 = }

Note: all items checked, and only { = trillOamPtrEntry 1 } has editorial issues.

 

        = ;            =     trillOamMepPtrTransactionId    = Unsigned32,        { trillOamPtrEntry 1 = }

=             &= nbsp;          = trillOamMepPtrHC         &nb= sp;            = Unsigned32,       { trillOamPtrEntry 2 = }

        = ;   =              = trillOamMepPtrFlag         &= nbsp;          = Unsigned32,       { trillOamPtrEntry 3 = }

        = ;   =              = trillOamMepPtrErrorCode         = Unsigned32,         { = trillOamPtrEntry 4 }

        =             &= nbsp;   = trillOamMepPtrTerminalMep        =      TruthValue, { trillOamPtrEntry 5 = }

        = ;   =              = trillOamMepPtrLastEgressId        = ;    Unsigned32,  { trillOamPtrEntry 6 = }

        = ;   =              = trillOamMepPtrIngress       = Dot1agCfmIngressActionFieldValue, { trillOamPtrEntry 7 = }

        = ;   =              = trillOamMepPtrIngressMac        &= nbsp;     MacAddress, { trillOamPtrEntry 8 = }

        = ;   =              = trillOamMepPtrIngressPortIdSubtype    = LldpPortIdSubtype,  { trillOamPtrEntry 9 }

        = ;  =             &= nbsp; =  trillOamMepPtrIngressPortId      &nbs= p;    LldpPortId,   { trillOamPtrEntry 10 = }

        = ;   =              = trillOamMepPtrEgress        = Dot1agCfmEgressActionFieldValue,

        = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;  { trillOamPtrEntry 11 }

        = ;            =     = trillOamMepPtrEgressMac        &n= bsp;      MacAddress, { trillOamPtrEntry 12 = }

        = ;   =              = trillOamMepPtrEgressPortIdSubtype     = LldpPortIdSubtype,

        = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =            { = trillOamPtrEntry 13 }

        = ;   =              = trillOamMepPtrEgressPortId        = ;    LldpPortId,      { = trillOamPtrEntry 14 }

        = ;   =              = trillOamMepPtrChassisIdSubtype        = LldpChassisIdSubtype,

        = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;  { trillOamPtrEntry 15 }

        = ;   =              = trillOamMepPtrChassisId        &n= bsp;      = LldpChassisId,     { trillOamPtrEntry 16 = }

        = ;   =              = trillOamMepPtrOrganizationSpecificTlv OCTET STRING,  { = trillOamPtrEntry 17}

        = ;   =              = trillOamMepPtrNextHopNicknames        = OCTET STRING  { trillOamPtrEntry 18 }

        = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;      

        = ;  |--trillOamMtvrTable { trillOamMep 4 }

        = ;            =     Note: Main table description needs some pagination = fixing.

        = ;            =   All nodes bolded could use some pagination fixing 1-3, 6, and 8. =

 

        = ;   trillOamMepMtvrTransactionId    = ;       Unsigned32,    { = trillOamMtvrEntry 1}

        = ;   trillOamMepMtvrReceiveOrder    &nb= sp;       Unsigned32,   { = trillOamMtvrEntry 2}

        = ;   = trillOamMepMtvrFlag         =            = Unsigned32,          &n= bsp;   { trillOamMtvrEntry 3}

        = ;   = trillOamMepMtvrErrorCode        &= nbsp;      = Unsigned32,         { = trillOamMtvrEntry 4}

        = ;   = trillOamMepMtvrLastEgressId       &nbs= p;    = Unsigned32,        { = trillOamMtvrEntry 5}

        = ;   trillOamMepMtvrIngress    = Dot1agCfmIngressActionFieldValue,

{ trillOamMtvrEntry 6 = }

     =       trillOamMepMtvrIngressMac  =             = MacAddress,  { trillOamMtvrEntry 7 }

        = ;   trillOamMepMtvrIngressPortIdSubtype    = LldpPortIdSubtype, { trillOamMtvrEntry 8 }

        = ;   = trillOamMepMtvrIngressPortId       &nb= sp;   LldpPortId,  { trillOamMtvrEntry = 9}

        = ;   trillOamMepMtvrEgress     = Dot1agCfmEgressActionFieldValue, { trillOamMtvrEntry 10 = }

        = ;   = trillOamMepMtvrEgressMac        &= nbsp;      MacAddress, { trillOamMtvrEntry 11 = }

        = ;   trillOamMepMtvrEgressPortIdSubtype     = LldpPortIdSubtype, { trillOamMtvrEntry  12 = }

        = ;   = trillOamMepMtvrEgressPortId       &nbs= p;    LldpPortId, { trillOamMtvrEntry 13 = }

        = ;   = trillOamMepMtvrChassisIdSubtype       = LldpChassisIdSubtype, { trillOamMtvrEntry 14 }

        = ;   = trillOamMepMtvrChassisId        &= nbsp;      LldpChassisId,    { = trillOamMtvrEntry 15 }

        = ;   trillOamMepMtvrOrganizationSpecificTlv OCTET STRING, { = trillOamMtvrEntry 16 }

        = ;   = trillOamMepMtvrNextHopNicknames       = OCTET STRING,  { trillOamMtvrEntry 17 }

        = ;   trillOamMepMtvrReceiverAvailability    = TruthValue,  { trillOamMtvrEntry 18 }

        = ;   = trillOamMepMtvrReceiverCount       &nb= sp;   TruthValue  { trillOamMtvrEntry 19 } =

 

 

 

        = ;  |--trillOamMepDbTable

        = ;            =     Note: Main table description needs some pagination = fixing.

        = ;      =         The description in node = {trillOamMepDbEntry 1 } – could use pagination aid. =

 

        =          trillOamMepDbFlowIn= dex         = Unsigned32,   {trillOamMepDbEntry 1 = }

        = ; trillOamMepDbFlowEntropy       OCTET = STRING,  {trillOamMepDbEntry 1 }

      =    trillOamMepDbFlowState     &nb= sp;   Dot1agCfmRemoteMepState, {trillOamMepDbEntry 2 = }

        = ; trillOamMepDbFlowFailedOkTime  TimeStamp,  = {trillOamMepDbEntry 3 }

        = ; trillOamMepDbRbridgeName       = Unsigned32,  {trillOamMepDbEntry 4 }

        = ; trillOamMepDbLastGoodSeqNum    Counter32   = {trillOamMepDbEntry 5 }

 

       | = trillOamFaultAlarm NOTIFICATION-TYPE { trillOamNotifications 1 = }

        = ;        No editorial or problems = with this  

 

|--TrillOamMibConformance {trillOamMib = 2}

        The = main description is good.

        The = descriptions in the following nodes have problems: =

 

  = trillOamMibCompliance MODULE-COMPLIANCE with mandatory groups of: =

         &nb= sp;           &nbs= p;     trillOamMepMandatoryGroup,

         &nb= sp;           &nbs= p;     = trillOamMepFlowCfgTableGroup,

         &nb= sp;       =           trillOamPtrTa= bleGroup,

         &nb= sp;           &nbs= p;     = trillOamMtvrTableGroup,

         &nb= sp;           &nbs= p;     trillOamMepDbGroup,

         &nb= sp;           &nbs= p;     = trillOamNotificationGroup

 

   The compliance is reasonable, and the = descriptions within this group are accurate.

 

trillOamMibReadOnlyCompliance MODULE-COMPLIANCE with = mandatory groups of:

         &nb= sp;           &nbs= p;     trillOamMepMandatoryGroup,

         &nb= sp;           &nbs= p;     = trillOamMepFlowCfgTableGroup,

         &nb= sp;           &nbs= p;     = trillOamPtrTableGroup,

   =             &= nbsp;           tr= illOamMtvrTableGroup,

         &nb= sp;           &nbs= p;     trillOamMepDbGroup,

         &nb= sp;           &nbs= p;     = trillOamNotificationGroup

         &nb= sp;           &nbs= p;   }

 

The = compliance seems reasonable, and the description within this group are = accurate.

 

Security = section: Seems reasonable and meets Security ADs input.  =

IANA = Section: Seems reasonable and meets IANA ADs input. =

 

Editorial = Comments

1)       = New format needs to be used = (See Alissa Cooper’s comment)

2)       = Section 5.3.2.1 – has = indentation that needs to be move outward.

3)       = Section 5.3.2.2 – = editorial suggestions:

       &nbs= p;      Old: /The table uses four indices/ =

       &nbs= p;        New: /This table uses four = indices/

4)       = Section = 5.3.2.3

Old : / Each row in the = table represents a Path Trace Reply entry for the =

     = ;      Defined MEP and Transaction./ =

New: /Each row in this table = represents a Path Trace reply Entry for the

     = ;     Defined MEP and Transaction./ =

 

<= p class=3DMsoListParagraphCxSpMiddle> Old: The first three = indices identify the MEP and the fourth index specifies the transaction = Identifier, and this transaction identifier/

 

<= p class=3DMsoListParagraphCxSpMiddle>New: The first three indices = identify the MEP and the fourth index specifies the transaction = identifier.  This transaction identifier/

 

<= p class=3DMsoListParagraphCxSpLast = style=3D'text-indent:-.25in;mso-list:l1 level1 lfo1'>5)       = Section 5.3.2.4 =

   Old:   This table = includes Multi-destination Reply managed = objects.

New:  This table includes managed = objects for the Multi-Destination Reply.

Old: This table uses = five indices: The first three indices are the indices of the Maintenance = Domain, MaNet, and MEP tables. The fourth index is the specific = Transaction Identifiet on the selected MEP. The fifth index is the = receive order of Multi- destination replies.

New:  This table = uses the following five indices: 1) Maintenance Domain, 2) MANET, 3) MEP = tables, 4) Transaction identifier of selected MEP, and 5) receive order = of Multi-destination replies.

6)       = Section 5.3.2.4 = trilllOamMepDbTable Objects

Editorial: Rename the = title from:

Section = 5.3.2.4 trillOamMepDbTable

To: =

       &nbs= p;        Section 5.3.2.5 = trillOamMepDbTable Objects

 

MIB Editorial (page = numbers only)

Page 10

Old: =

/

     SNMP Agent =             &= nbsp;       An SNMP entity containing one = or more command

       &nbs= p;            = ;   =             &= nbsp;            = responder

       &nbs= p;   and/or notification originator applications (along = with

       &nbs= p;   their associated SNMP engine).  Typically = implemented in

       &nbs= p;   Network Element.

       &nbs= p;   SNMP Manager An SNMP entity containing one or more = command

       &nbs= p;   generator and/or notification receiver applications = (

       &nbs= p;   along with their associated SNMP engine). = Typically

       &nbs= p;   implemented in an EMS or NMS.

/

New:

/ =

     SNMP Agent =             &= nbsp;       An SNMP entity containing one = or more command

       &nbs= p;            = ;   =             &= nbsp;            = Responder  and/or notification originator = applications

(along with their associated SNMP = engine). 

Typically implemented in Network = Element.

 

    = SNMP Manager =             &= nbsp;  An SNMP entity containing one or more = command

       &nbs= p;   =             &= nbsp;           &n= bsp;            = generator and/or notification receiver applications = (

       &nbs= p;   =             &= nbsp;           &n= bsp;            = along with their associated SNMP engine). = Typically

       &nbs= p;   =             &= nbsp;           &n= bsp;            = implemented in an EMS or NMS.

 

Page 11-nn on = parameters

Old text:

Implementation should = be unique

to identify Transaction ID for MEP with = multiple flows.

 

New text =

Implementation of this identifier should have = a unique code value in order

to identify the = transaction ID for a MEP with multiple = flows”

 

page 12: =

Old text:

       &nbs= p;   "Next sequence number/transaction identifier to = be sent in a

       &nbs= p;   Multi-destination message. This sequence number can be = zero

       &nbs= p;   because it wraps around. Implementation should be unique = to

       &nbs= p;   identify Transaction Id for a MEP with multiple = flows."

New text:

       &nbs= p;   "Next sequence number/transaction identifier to = be sent in a

       &nbs= p;   Multi-destination message. This sequence number can be = zero

       &nbs= p;   because it wraps around. Implementation of this = identifier should be

       &nbs= p;  should provide a unique code value in order to =

       &nbs= p;   identify Transaction Id for a MEP with multiple = flows."

 

Page = 15

Old text:

   trillOamMepTxPtmReplyModeOob= OBJECT-TYPE

       = SYNTAX  =         TruthValue

       = MAX-ACCESS      = read-create

       = STATUS          = current

       = DESCRIPTION

       &nbs= p;   "True Indicates that Reply of Ptm is out of band = and

       &nbs= p;   out of band IP Address TLV is to be = transmitted.

       &nbs= p;   False indicates that In band reply is = transmitted."

       = REFERENCE "RFC 7455 section 10"

       = DEFVAL          { false = }

       ::=3D { = trillOamMepEntry 17 }

 

New text = /

   trillOamMepTxPtmReplyModeOob = OBJECT-TYPE

       = SYNTAX          = TruthValue

       = MAX-ACCESS      = read-create

       = STATUS          = current

       = DESCRIPTION

       &nbs= p;   "True Indicates that Reply of Ptm will be made = out of band and

       &nbs= p;   out of band IP Address TLV is to be = transmitted.

       &nbs= p;   False indicates that an In band reply is = transmitted."

       = REFERENCE "RFC 7455 section 10"

       = DEFVAL          { false = }

       ::=3D { = trillOamMepEntry 17 }

 

/

[bold only in text to = show you the change ]

Page 15

 

Old:/

   = trillOamMepTransmitPtmReplyIp OBJECT-TYPE

       = SYNTAX          OCTET = STRING (SIZE  (4..16))

       = MAX-ACCESS      = read-create

       = STATUS          = current

       = DESCRIPTION

       &nbs= p;   "IP address for out of band IP Address TLV is to = be

       &nbs= p;    transmitted, Maximum length for IPv6 is 16 = OCTET

       &nbs= p;    and IPv4 is 4 OCTET."

       = REFERENCE "RFC 7455 section 3 and 10"

       ::=3D { = trillOamMepEntry 18 }

/

New: =

   trillOamMepTransmitPtmReplyI= p OBJECT-TYPE

       = SYNTAX          OCTET = STRING (SIZE  (4..16))

       = MAX-ACCESS      = read-create

       = STATUS       =    current

       = DESCRIPTION

       &nbs= p;   "IP address for out of band IP Address TLV is to = be

       &nbs= p;    Transmitted.  The  maximum length for = IPv6

       &nbs= p;   address  is 16 Octets.  The maximum = length

       &nbs= p;  for an  IPv4 address is 4 = octets."

       = REFERENCE "RFC 7455 section 3 and 10"

       ::=3D { = trillOamMepEntry 18 }

 

/ =

 

Page 15-16 =

Old:

 

   = trillOamMepTxPtmStatus OBJECT-TYPE

       = SYNTAX          = TruthValue

       = MAX-ACCESS      = read-create

       = STATUS          = current

       = DESCRIPTION

    =        "A Boolean flag set to = true by the MEP Path Trace

       &nbs= p;    Initiator State

       &nbs= p;   Machine or an MIB manager to indicate that = another

       &nbs= p;   PTM is being transmitted.

       &nbs= p;   Reset to false by the MEP Initiator State = Machine.

       &nbs= p;   The PTM managed objects in the MEP table are = used

       &nbs= p;   in a manner similar to that described for = LBM

       &nbs= p;   transmission in dot1agCfmMepTable. As per = RFC7455

       &nbs= p;   section 10, Operation of the Path Trace Message = is

       &nbs= p;   identical to the Loopback Message except that it = is

       &nbs= p;   first transmitted with a TRILL Header Hop = count

       &nbs= p;   field value of 1 and it's retransmitted = incrementing

       &nbs= p;   Hop count until a response is received from = the

       &nbs= p;   destination RBridge, or the Hop Count reaches = a

       &nbs= p;   configured maximum value. = trillOamMepTxPtmStatus

       &nbs= p;   Status is reset to FALSE by initiator when last = PTM

       &nbs= p;   is transmitted."

       = REFERENCE "RFC 7455 section 10"

       = DEFVAL          { false = }

       ::=3D { = trillOamMepEntry 20 }

/

New:  / =

   trillOamMepTxPtmStatus = OBJECT-TYPE

       = SYNTAX          = TruthValue

       = MAX-ACCESS      = read-create

       = STATUS          = current

       = DESCRIPTION

       &nbs= p;   "A Boolean flag set to true by the MEP Path = Trace

       &nbs= p;    Initiator State Machine or an MIB manager =

       &nbs= p;   to indicate that another PTM is being = transmitted.

       &nbs= p;   This is reset to false by the MEP Initiator State = Machine.

       &nbs= p;   The PTM managed objects in the MEP table are = used

       =     in a manner similar to that described for = LBM

       &nbs= p;   transmission in dot1agCfmMepTable.   As = per RFC7455

       &nbs= p;   section 10, Operation of the Path Trace Message = is

       &nbs= p;   identical to the Loopback Message except that it = is

       &nbs= p;   first transmitted with a TRILL Header Hop = count

       &nbs= p;   field value of 1, and then retransmitted with = incrementing

       &nbs= p;   Hop count until a response is received from = the

       &nbs= p;   destination RBridge, or the Hop Count reaches = a

       &nbs= p;   configured maximum value. = trillOamMepTxPtmStatus

       &nbs= p;   Status is reset to FALSE by initiator when last = PTM

       &nbs= p;   is transmitted."

        = REFERENCE "RFC 7455 section 10"

       = DEFVAL          { false = }

       ::=3D { = trillOamMepEntry 20 }

Page 16

Old: / =

   trillOamMepTxPtmResultOK = OBJECT-TYPE

       = SYNTAX          = TruthValue

       = MAX-ACCESS      = read-create

       = STATUS          = current

       = DESCRIPTION

       &nbs= p;   "Indicates the result of the = operation:

       &nbs= p;   - true  The Path Trace Message(s) will be (or has = been)

       &nbs= p;     sent.

       &nbs= p;   - false The Path Trace Message(s) will not be = sent."

     REFERENCE "RFC = 7455 section 10"

       = DEFVAL          { true = }

       ::=3D { = trillOamMepEntry 21 }

/

New:  / =

   trillOamMepTxPtmResultOK = OBJECT-TYPE

       = SYNTAX          = TruthValue

       = MAX-ACCESS      = read-create

       = STATUS          = current

       = DESCRIPTION

       &nbs= p;   "Indicates the following results of the = operation:

-          = true  The Path Trace = Message(s) will be (or has been)

       &nbs= p;     sent.

  =          -   =     false The Path Trace Message(s) will not be = sent."

      REFERENCE = "RFC 7455 section 10"

       = DEFVAL          { true = }

       ::=3D { = trillOamMepEntry 21 }

/

 

Page 16 – = pagination only

Old:

   trillOamMepTxPtmSeqNumber = OBJECT-TYPE

     =   SYNTAX          = Unsigned32

       = MAX-ACCESS      = read-create

       = STATUS          = current

       = DESCRIPTION

       &nbs= p;   "The Path Trace Transaction Identifier of the = first

       &nbs= p;    PTM (to be)

       &nbs= p;   sent. The value returned is undefined = if

   =         trillOamMepTxPtmResultOK = is false."

       = REFERENCE "RFC 7455 section 10"

       ::=3D { = trillOamMepEntry 22 }

 

New: =

   trillOamMepTxPtmSeqNumber = OBJECT-TYPE

       = SYNTAX          = Unsigned32

       = MAX-ACCESS      = read-create

       = STATUS        =   current

       = DESCRIPTION

       &nbs= p;   "The Path Trace Transaction Identifier of the = first

       &nbs= p;    PTM (to be)  sent. The value returned =

       &nbs= p;     is undefined = if

       &nbs= p;    trillOamMepTxPtmResultOK is = false."

       = REFERENCE "RFC 7455 section 10"

       ::=3D { = trillOamMepEntry 22 }

/

 

Page 17 =

Old:

       &nbs= p;    maximum value. Once Destination or Hop count = reaches

       &nbs= p;    it's treated as single Counter increment of = this

       &nbs= p;    object, and above process is repeated = starting

       &nbs= p;    Hop count 1 till maximum PTM = transmission

       &nbs= p;    is reached. It's treated as Repeat Counter = for

       &nbs= p;    above described = operation."

       = REFERENCE "RFC 7455 section 10"

       ::=3D { = trillOamMepEntry 23 }

New:

       &nbs= p;    maximum value. The event of the = Destination

       &nbs= p;   response being received or the  Hop count = reaching

       &nbs= p;  its maximum is treated  as single Counter increment of = this

       &nbs= p;  object.  The bove process is repeated = starting

       &nbs= p;  untill maximum PTM transmission

    =      is reached. It's treated as Repeat Counter = for

       &nbs= p; above described operation."

       = REFERENCE "RFC 7455 section 10"

       ::=3D { = trillOamMepEntry 23 }

 

/

 

 

 

 

Page 17 =

Old:

/ =

      trillOamMe= pTxMtvmReplyModeOob OBJECT-TYPE

       = SYNTAX       =    TruthValue

       = MAX-ACCESS      = read-create

       = STATUS          = current

       = DESCRIPTION

       &nbs= p;   "True Indicates that Reply of Mtvm is out of band = and

       &nbs= p;   out of band IP Address TLV is to be = transmitted.

       &nbs= p;   False indicates that In band reply is = transmitted."

       = REFERENCE "RFC 7455 section 11"

       ::=3D { = trillOamMepEntry 26 }

/

New =

      trillOamMe= pTxMtvmReplyModeOob OBJECT-TYPE

       = SYNTAX          = TruthValue

       = MAX-ACCESS      = read-create

       = STATUS          = current

       = DESCRIPTION

       &nbs= p;   “A True value  Indicates that Reply of Mtvm is = out of band and

       &nbs= p;   out of band IP Address TLV is to be = transmitted.

       &nbs= p;   A False  value indicates that In band reply is = transmitted."

       = REFERENCE "RFC 7455 section 11"

       ::=3D { = trillOamMepEntry 26 }

 

P17-p18

Old = /

   trillOamMepTransmitMtvmReplyIp = OBJECT-TYPE

       = SYNTAX          OCTET = STRING (SIZE  (4..16))

       = MAX-ACCESS      = read-create

       = STATUS          = current

       = DESCRIPTION

       &nbs= p;   "IP address for out of band IP Address TLV is to = be

       &nbs= p;    transmitted, Maximum length for IPv6 is 16 = OCTET

       &nbs= p;    and IPv4 is 4 OCTET."

       = REFERENCE "RFC 7455 section 11      =

 ::=3D { trillOamMepEntry 27 } / =

 

 

New/ =

   trillOamMepTransmitMtvmReply= Ip OBJECT-TYPE

       = SYNTAX          OCTET = STRING (SIZE  (4..16))

       = MAX-ACCESS      = read-create

       = STATUS          = current

       = DESCRIPTION

       &nbs= p;   "IP address for out of band IP Address TLV is to = be

       &nbs= p;    Transmitted. The maximum length for IPv6 is 16 = octets

       &nbs= p;    and IPv4 is 4 = octets.”

       = REFERENCE "RFC 7455 section 11

       = REFERENCE "RFC 7455 section 11  

 ::=3D { = trillOamMepEntry 27 } /

 

 

Page 18 =

Old/

 

   = trillOamMepTxMtvmStatus OBJECT-TYPE

       = SYNTAX         =  TruthValue

       = MAX-ACCESS      = read-create

       = STATUS          = current

       = DESCRIPTION

       &nbs= p;   "A Boolean flag set to true by the MEP Multi = Destination

       &nbs= p;    Initiator State

       &nbs= p;   Machine or an MIB manager to indicate that = another

=           Mtvm is = being transmitted.

       &nbs= p;   Reset to false by the MEP Initiator State = Machine.

       &nbs= p;   The Mtvm managed objects in the MEP table are = used

       &nbs= p;   in a manner similar to that described for = LBM

       &nbs= p;   transmission in dot1agCfmMepTable. As per = RFC7455

       &nbs= p;   section 11, Operation of the MTvm Message = is

       &nbs= p;   identical to the Loopback Message except that it = is

       &nbs= p;   first transmitted with a TRILL Header Hop = count

       &nbs= p;   field value of 1 and it's retransmitted = incrementing

       &nbs= p;   Hop count until a response is received from = the

       &nbs= p;   destination RBridge, or the Hop Count reaches = a

       &nbs= p;   configured maximum value. = trillOamMepTxMtvmStatus

       &nbs= p;   Status is reset to FALSE by initiator when last = Mtvm

    =        is = transmitted."

       = REFERENCE "RFC 7455 section 11"

       = DEFVAL          { false = }

       ::=3D { = trillOamMepEntry 29 }

/

 

New: description =

       &nbs= p;   "A Boolean flag set to true by the MEP Multi = Destination

       &nbs= p;    Initiator State  Machine or an MIB manager to = indicate that another

       &nbs= p;   Mtvm is being transmitted.

       &nbs= p;   This value is reset to false by the MEP Initiator State = Machine.

 

       &nbs= p;   The Mtvm managed objects in the MEP table are = used

       &nbs= p;   in a manner similar to that described for = LBM

       &nbs= p;   transmission in dot1agCfmMepTable. As per = RFC7455

       &nbs= p;   section 11, Operation of the MTvm Message = is

       &nbs= p;   identical to the Loopback Message except that it = is

       &nbs= p;   first transmitted with a TRILL Header Hop = count

       &nbs= p;   field value of 1 and it is retransmitted = incrementing

       &nbs= p;   Hop count until a response is received from = the

       &nbs= p;   destination RBridge, or the Hop Count reaches = a

       &nbs= p;   configured maximum value. = trillOamMepTxMtvmStatus

       &nbs= p;   Status is reset to FALSE by initiator when last = Mtvm

       &nbs= p;   is transmitted."

/

 

Old/

   = trillOamMepTxMtvmResultOK OBJECT-TYPE

       = SYNTAX          = TruthValue

       = MAX-ACCESS      = read-create

       = STATUS          = current

       = DESCRIPTION

       &nbs= p;   "Indicates the result of the = operation:

       &nbs= p;   - true  The Multi-destination Message(s) will = be

       &nbs= p;     (or has been) sent.

       &nbs= p;   - false The Multi-destination Message(s) will not be = sent."

       = REFERENCE "RFC 7455 section 11"

       = DEFVAL          { true = }

       ::=3D { = trillOamMepEntry 30 }

/

New description for = this text 

/

       = DESCRIPTION

       &nbs= p;   "Indicates the result of the operation in the = following way:

       &nbs= p;   - true: indicates the Multi-destination Message(s) = will be

       &nbs= p;     (or has been) sent.

       &nbs= p;   - false: indicates the Multi-destination Message(s) will = not be sent."

/

 

Page 19 =

 

Old/ =

   trillOamMepTxMtvmScopeList = OBJECT-TYPE

       = SYNTAX          OCTET = STRING

      =  MAX-ACCESS      = read-create

       = STATUS          = current

       = DESCRIPTION

       &nbs= p;   "The Multi-destination Rbridge Scope list, 2 = OCTET

       &nbs= p;    per Rbridge."

       = REFERENCE "RFC 7455 section 11"

       ::=3D { = trillOamMepEntry 33 }

/

New/

 

   = trillOamMepTxMtvmScopeList OBJECT-TYPE

       = SYNTAX          OCTET = STRING

       = MAX-ACCESS      = read-create

       = STATUS          = current

       = DESCRIPTION

       &nbs= p;   "The Multi-destination Rbridge Scope list which =

       &nbs= p;   requires 2 octets per = Rbridge."

       = REFERENCE "RFC 7455 section 11"

       ::=3D { = trillOamMepEntry 33 }

/

 

Page 20: =

Old/

 

   = trillOamMepFlowCfgTable OBJECT-TYPE

       = SYNTAX          SEQUENCE OF = TrillOamMepFlowCfgEntry

       = MAX-ACCESS      = not-accessible

       = STATUS          = current

       = DESCRIPTION

       &nbs= p;   "This table includes configuration objects and = operations

       &nbs= p;    for the Trill OAM RFC 7455.

 

       &nbs= p;   Each row in the table represents a Flow = configuration

       &nbs= p;   Entry for

     =       the defined MEP. This table uses = four indices. The first

       &nbs= p;   three indices are the indices of the Maintenance = Domain,

       &nbs= p;   MaNet, and MEP tables. The fourth index is the = specific

       &nbs= p;   Flow configuration Entry on the selected = MEP.

/

Fix the pagination as = follows:

New:

       DESC= RIPTION

       &nbs= p;   "This table includes configuration objects and = operations

       &nbs= p;    for the Trill OAM RFC 7455.

 

       &nbs= p;   Each row in the table represents a Flow = configuration

       &nbs= p;   Entry for  the defined MEP. This table uses four = indices.

       &nbs= p;   The first  three indices are the indices of the = Maintenance

       &nbs= p;   Domain, MaNet, and MEP tables. The fourth index is the =

       &nbs= p;   specific flow configuration Entry on the selected = MEP.

/

 

Fix pagination page = 21

trillOamMepFlowCfgIndex    = ;   = Unsigned32,          &n= bsp; { trillOamMepFlowCfgEntry 1 }

-          = text is fine.  Fix the = pagination in the description.

 

Page = 22

Old

   trillOamPtrTable = OBJECT-TYPE

       = SYNTAX          SEQUENCE OF = TrillOamPtrEntry

       = MAX-ACCESS      = not-accessible

       = STATUS          = current

       = DESCRIPTION

       &nbs= p;   "This table includes Path Trace Reply objects = and

       &nbs= p;    operations for

       &nbs= p;   the Trill OAM RFC 7455.

 

       &nbs= p;   Each row in the table represents a Path Trace Reply Entry = for

       &nbs= p;   the defined MEP and Transaction.

       &nbs= p;    This table uses four = indices.

       &nbs= p;   The first three indices are the indices of = the

       &nbs= p;   Maintenance Domain,

       &nbs= p;   MaNet, and MEP tables. The fourth index is the = specific

       &nbs= p;   Transaction Identifier on the selected = MEP.

 

       &nbs= p;   Some writable objects in this table are only applicable = in

       &nbs= p;   certain cases (as described under each = object),

       &nbs= p;   and attempts to

       &nbs= p;   write values for them in other cases will be = ignored."

       = REFERENCE       "RFC = 7455"

       ::=3D { = trillOamMep 3 }

 

/

New = description:  (Only pagination in the text) =

       DESC= RIPTION

       &nbs= p;   "This table includes Path Trace Reply objects = and

      =       operations for  the Trill OAM = RFC 7455.

 

       &nbs= p;   Each row in the table represents a Path Trace Reply Entry = for

       &nbs= p;   the defined MEP and Transaction.  This table uses = four indices.

       &nbs= p;   The first three indices are the indices of = the

   =         Maintenance = Domain,   MaNet, and MEP tables.

       &nbs= p;  The fourth index is the specific Transaction = Identifier

       &nbs= p;   on the selected MEP.

 

       &nbs= p;   Some writable objects in this table are only applicable = in

       &nbs= p;   certain cases (as described under each = object),

       &nbs= p;   and attempts to  write values for them in other =

       &nbs= p;   cases will be ignored."

 

/

Pages 23 -25 = editorial:

 

       &nbs= p;   |--trillOamPtrTable   { trillOamMep 3 = }

       &nbs= p;       = trillOamMepPtrTransactionId    Unsigned32, { = trillOamPtrEntry 1 } – fix pagination

       &nbs= p;        = trillOamMepPtrHC         &nb= sp;            = Unsigned32,

       &nbs= p;        = trillOamMepPtrFlag         &= nbsp;          = Unsigned32,

       &nbs= p;        = trillOamMepPtrErrorCode         = Unsigned32,

       &nbs= p;        = trillOamMepPtrTerminalMep        =      TruthValue,

       &nbs= p;        = trillOamMepPtrLastEgressId        = ;    Unsigned32,

       &nbs= p;        = trillOamMepPtrIngress       = Dot1agCfmIngressActionFieldValue,

       &nbs= p;        = trillOamMepPtrIngressMac        &= nbsp;     MacAddress,

       &nbs= p;        = trillOamMepPtrIngressPortIdSubtype    = LldpPortIdSubtype,

       &nbs= p;        =  trillOamMepPtrIngressPortId      &nbs= p;    LldpPortId,

       &nbs= p;        = trillOamMepPtrEgress        = Dot1agCfmEgressActionFieldValue,

       &nbs= p;        = trillOamMepPtrEgressMac        &n= bsp;      MacAddress,

       &nbs= p;        = trillOamMepPtrEgressPortIdSubtype     = LldpPortIdSubtype,

       &nbs= p;        = trillOamMepPtrEgressPortId        = ;    LldpPortId,

       &nbs= p;        = trillOamMepPtrChassisIdSubtype        = LldpChassisIdSubtype,

       &nbs= p;        = trillOamMepPtrChassisId        &n= bsp;      = LldpChassisId,

       &nbs= p;        = trillOamMepPtrOrganizationSpecificTlv OCTET = STRING,

 

 

------=_NextPart_001_0158_01D0DAA9.F7257620-- ------=_NextPart_000_0157_01D0DAA9.F7257620 Content-Type: application/pdf; name="trill-oam-mib-rtg-directorate-review-Hares-v1.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="trill-oam-mib-rtg-directorate-review-Hares-v1.pdf" JVBERi0xLjUKJabpz8QNCjQgMCBvYmoKPDwKL0xlbmd0aCA1IDAgUgovRmlsdGVyIC9GbGF0ZURl Y29kZQo+PgpzdHJlYW0NCnjarVpbc9vGFX7Xr+AjMGPS2DvgmT7Ejp2q40vqKO1D3QdaIm0mEqWQ lGyNm/+ec10sSMomp55OTAFY7J7zne9c0T9Onp6dPH5hRsZPGjc6m5+YUQP/MyPfuElsR8nbSTs6 uzr5T3VWw5/V23rsJq46fVmP7aSr8MeESaze0NMf6rGZ2OoVXLhqjBehauoI/yZYaD08ow287PYT vt5MGr07u1vUYw/LZ3ULu3+q/3v2j5PnZyf/BLk+nATfjJJtRi6OxvDfanYyP/kDNWjg4V4tQoA7 fhQ7ENGzGqbfcxJHk+RGExdGq63deXO8FVuQp6O7+Lt9qB0Zs3VosqPUdIgeHfgWkUrVde1B4dva wb8b0DIAFku6+gALnJuY6se6g0tCwFQr/pnVBoE5r8cRXtgwvrzXCjHrqilcuGozQygjQ4nQzgDg UN3VeA5taeXWJzw7Vk96HL6pTuzg9YE2ujttRdt7FVX2xxVeZXwCKwLy5ReQpyEUumrNNmf5l8yP UP2dr+VF2tPB0iOETe2kFWP/Cw4KIqzsSKdGhYSRXNYiJIrgqgsyywDe+Wa8EIrSZmQIU83HtUF7 guGSvrAAvsfqkveXH1zm6DDcEBzGVVfsQPzkim1GQrnqPZ0PT9CLGt4hwa6+muBFp6d/hnfx4ghs IqAZGRsC2uteorxn3jUFXfNxAtkWaS9q8Lo0YG2jZitZa/aylp/MjlHBp0krrvUGAAANPtZKeBLf OsTtI4k50JFMH3pVz2o0hDD6FC5ajGfoYBjWLNr036gIxymXNfJ5c7JkVv0IJUDEIB6FLmGqzbTG /Te3pEsvKbvNGfqUFxUFVZZhifDnoEGPHGmN3IuggTDwHjWy8EeOKzb73gVZWVY4YfM1XqKnfMAX WrEeEjA0sPo5AhXFVeT0LTvH/gmfc4lbml69W2FShBV0ikYNeY6CRN2i91R63zqTWZRjBWwf4A/e UehKMUoDVo4yWVQImlbpa9EPHdD3pgwA12jlpLEuH5KZrjh6dgXmXCAn7nRfMYJcsV73eJEA0SNo YxKmM6LNj0gY33uQ7fnSVi1H5Mc1imwoIHXlLcuCcGo2HHXCXkHcHkE8cjc2kNwllPwNXcjzT4Cf Vi+KnxbO273n+ML17x4qhB2FNmpWeja9YzRnvDV4pmFCIuWfMGkhNYK9E9y/Ra+O/Bj8F0llKaJZ zJZvZ3WCPe6Y9wssRRJmNcvZAwOD1RNWM76BVIQ/UKGbGgk1XdWGQ581HbnPGEk5x+skDyhKWZHa NbDqFF5K4FsdPDpjRF7gvhhzXpKxnvExQY5ZXddIznMOW6R9rNZrvHTkrN7rVnH7sCn6X6MgfWRM SM6mWhUZF22QGjR2gPQBZvBw1Saoh8AIVA/pUyBYKp6aolp60Igu5kgoGg/E7BDijv04mwMrQ3JU MTcGfZsoBRvTs4BctgGvM4jGjBH/VCddEcBjyeZCBV8cbZEv54yjYLKsEcQSai9W2IBMUbnRIKGE ShlbK6HDIFXm1yhYW11eomSt7i86FXQ0nLzQ3NP3ZKzLGR7fVo+YBsCzJd3PiujetyTYkrLJUEun ps7yXDE3Zavph9pwOUcaXtXZr5xAsGHTIBYdiFbAM2Ri2A8PK4Sh1+E57wXzoeM/yBdIIEbCzrlW wyT+Cj0uUufg9ZEoTFkLs+wP3K5gh0JtxvS3GtoPSnYU0xfitIjsPWerULouQN4MXXexZo+OFAqM JoqmICqmqpAXpl3XJyNkRtKuG06vqtoCa0Gw0CUTHXdb31L1x+qunxwIn+8ajZnPuT0rD0zlgVhH FOcxUGvklVFuiEkNRzuTV+UQM1+h4FpNXqnJmQFatomfi68IDp+JM5lp/Iaw8DOv3Ch06m9Q4c3Q h4wQU3ZcXHMJwOQlM7SwJnBCnKCEsXKcESfEIVteGK1a3kEcZms2/LIbvExXcEz/MkLkuR7dddQi NBQRR3jJeeApM8aX2nvW3ik0ScMb7acIQMUxV9Pt2oDKujtuJdRyhFGQsLE+lE1QCmirdZEVwX7t nKURHt2QpQfmCBIvxBy2MGLhH0WQGiIjqc2CR9N5ustXUPX0biRUKVFr9BJYIhV+5AwcZWHbR0zw UIJMfCRvhl1afXLFEeQGQ2sOiSvyKo+2t8JwKgZEQymxUw4d3AyeU3m4V67aiPOVHjMMRAm0xR7g lDrTrOx0LiFFaoQVjwtSDv5cz/yOizrOQViUH8iD0OW2Uli6J47ZQVgx2B5QOGngHM54rggtGy64 BN5BjllPDpKLylSPxZJEPObOUj1weiEeSa23BEBmZ5STcpoti6TQxzeqTcygNmk15HvIGCbnp4aL zjBMyeGbYb+IwlHB4PrOirOqy7ELuOpdxZtMe4pyRSGKntc0cZtu2NTZXiRQonQcNfl5FWW3cujL rpjLVkoov5BJf2I2hrJ+8Eq297oN5q6VyGmKummn5iNRuXR7V/M5ktTtsLpdHBy7QATtpdj/wm7q 3qoxyWFuCCApvFXCiwF3c1qkAi/XXbrTkqZSbIAcQGQniVlm8M5OOpxf0xxNZIpbFdy+ygVs4XYr D+SNnEjs61Rfp1tuwzlxZjQJo0nyODN9/MKPILl0cQtcl3KZ8Yra1FPW9SlHQOnwO2AwJaGrK+LM lM0MWpHf3PPiRhMvjS9uqeNf66htbBCrJbd1H1STDfXv12zNGz5jXDsey0XS3bHbBvIAvLjk05Lu jXskkcXIsedcXWx4GnNby7yM3egw2rkAL7UKzb60VCRSxIkUlHK2SKdJE34fsMindgvBfaMEGiM4 5GjU7M0TFOSazGXPVb1ijsGDER4Qbc1lZFKF0cf1A5aP2EvkGc6ai6FmMJxbM1sbOf2in5v0o6hi cChP+F2ZKCW9K4OjwXxJxtJyD6LHYYayHRhDOPw/cqsxTRv5X8kH0jBccmJ+I4H3iluw16h7p+Ff q5/5QpI8WVSj8N40BzpFjJAa0cV9hQVbh3L+lnpBmLV4z02kTJFd9echyncB2WFbm2u7I/UfiPKC XfuWnUwSHFZt8BoVn1iCHJzObUy50jjaKmGADI5b5Rm3oL9h2DdbreNB6QSC8ECyL5xOSnHQXm+m 6M05WktFq0ayPIjzRxkp2P/fQlwvSti/OUhfqFpD7E9/QF88peMzwz78rT77Kv5S1pgjGGyaMLLF YOk7ooOCypyqGMk4b3Ay8IUGd7sw7Ns7UE8T+7LgRiswQ4O+PzGitiQwJXn6KOHlK1KSJqEvDaUI evuyxqrypXaduMwPw8p8cVBZbzB4gY0xNOcwQBL6Bwwtp5TwmX3wyaeDZZ/FYCtM9p1Fnb4Uwc5/ A0XMC6/062MxkNu1EOb2cBSJOvinn5a8rjnZ9bHcUf3q6HMSfXHiVvRSTOIG9ZTO0XJpiLVsmytC EdDqxHFQocm932kqJfekXG9zzez2dIM0JxZZFQpEzusuD04RFxvqZHIp6MtOXUBM/POIi8uWaOv5 y4PVndvK0t2m/wxq6VbQgUt+nRfG8nup1f/nQLFjkoVdudDRwoa+c8i6uKOTo/ecegbjNL0Tfh5I CMhCyR7X6NJg+qud20TL+DP+FLk1px+2iGxAKf6K48r5YNT5YFt2h/zdQqZBeYhwuVgPeJobwa1u +YFhAxWoeRwuVNUPKyzrIPoc1LobD22Fd/k7724ivaJvbLuuDxHwNVUaU+69OURghHYtRtxfuf1e L3jYsMwjyGxJRyyyPbmJdF+0F9muwQY5vc8W7TDa+WJyjo39vXYqhunYHpjXEBeQxx8PC8cv7rg/ sxQ8VfwZU5GRGb1oIcmEGxMiRMQu5FkelkdqifovDPy2cG3l6kTeO/RbgdAMIrvNELpdCP0uhMOE YRsKHARhdwSERev/XTB8pd1Ky0MEntz5PhGxLyGSjUNMnzFp8mSoRLKcgsv3LImVlpDJAW4IqOhg BqkysB80JE03UCqU4IYSXMPHhn4I5I5maZfyx+FDEaYuLbOR3znVr/bgvo3iNmBgPAg3OukRzowR wb3AfcWZCwrwp9khWPc874s067fmGCZCj9W03w8mBEJKpNv85S3DNX/DfrS6KD7wOR5xuGYvKwfo mn3oujJUUiL/wpllGCrtw7Rs1X0Oo2Uxmwx7aPkXGii63QplbmRzdHJlYW0KZW5kb2JqCjUgMCBv YmoKMzA5NgplbmRvYmoKMTEgMCBvYmoKPDwKL0xlbmd0aCAxMiAwIFIKL0ZpbHRlciAvRmxhdGVE ZWNvZGUKPj4Kc3RyZWFtDQp42sVbWXPcxhF+56/YR6BKi2BuIG8JLcuKTVGWNnmJ8yCJFLUVipSW h8WS89/d1wADLPYAeKRc1hILzKD7657+untmvx78fXHwlx/VTNmiNLPFxwM1K+E/NbOlKXw1C1YX 1Wzx+eDf2SKHP7M3+dwUJnv5Sz7XRZ3hh3KFz47p7t/yuSp0dgQXJpvjhcvK3MO/AR7UFu7RBFZm e4HDy6KM357eLvO5hcdP8wpm/z3/z+IfB88XB7+CXGcHzpazoMuZ8bM5/L86Pfh48BU1KOHmoBbO wTd25msQ0bIaup2z8LMimFlh3GzVm50nx698BfLU9C1+9l9qZkr1XqqsnYWyRvjojdcIlc5Wy1wB Kufnx+8+56jjEaoKOuNtm33JFSLwOp+7QjVjjm9yhUDBtVEuwFeHl/ncw+cNABiyC/pXnqaZXLbK QaSQGZzegL708QyRDjDTd/jDIOR9sXBUDXYko4GIDp5JRXQsos+e5zUMuMhFLprkDmdVcNOjnXGi /7U474bL1+AaE9A6YuWuwVtcdosXVbZ6maOwF4SYbhBThJhP5VZTEDMpYhq+JcR8BzEzBjFaGTjR OMRCVVT2oSFDAUWfG/EsfIwALLOPx6CHz1YnOSol067yeV0iluuOWdFweRJwM3nowGvBoRXBq+ro 8x144cuILlpIZZ9ZkCMIKYle+L7n7Led9UBm9RkhjTNX05D2EPD8QyGNCxpWB05Ua4xxhzkEQB8h 7oLXrmoblSEf1SmI1sMfiY/i20hAuxNDQ3HWEYTVMIQIni7hbs0oViPBs7CCpsTBBV994zG/sLrv 8Z7LcFiV/cCRUoZdXee4Vt+8At/UuBjhZsCbyjjU6p+M6dXyDB5QgrCMPSGNDfGUZnx3h8tjtJtp 3hThlGU/7JJqzSUVvbTkyzASWxji9INjS97xE+FziF5qwk74KMilnml3AKg38o1P6WYjiuKVAfAj 4dW0lQ0ClvZxAHwDobLqhqjzO05y2FVkwbPvSYTE+KrinffwEZCW6G0Qdm8o7Iqgn4jM/kXSvjvH Wy6+7R5U7wawt4S9H/BgjTdVQ5pTLFCCBH66BVbvLkBz8EtC3WdLFE7HqVLD+AHDmI5hIKnNUbMv SEy2JXYJ0PLG5/zlgh1QZ29zVHrBqL15+YpC0ws0gUbq65Jb6/0oJ8Rn1rFc01FT0tCAP8RoKfhm UtLlKl88Uvj4kVA5vwTPMpDFA7plupA90VTIVpcYPKMZ7jCT8OSYiNihgLqOOGo6hDg4fYhOP5RO NE5P2ZqFq3s6vZ3k9C5A5Lo/8K9zJ0A2vv1D7mIwcciIVKIBJcLoehQnuoQTfZJseIPe24W4Iz2v lV6KMYkT3SROdM4V2j4Gtg/CiL4K8Nd3BiF1UP0g+a7QoicILdViWyDUGyA0dRHamKzIQnOMUksy zDleKP7QIC8xUI4afmaHO5LygK1ueLHiMv9GK/c1BeDrzzAZtRO0PGzkYZn/LmfNDSXHjqgSb/O8 +FqsS3ARI1FWim3oqJojaW+IGUSDT3ARgC4xRrGw8hp+iid9xiWZIwfXioClggcDWJ0tWePzFIVj yrMb9U0jcqp+YyvDmT9DiurfcQDRMaDsqAUHLeYxCXQaJBhrM4VG2WW0FQ9lFVmFK1QUY31oUZG3 onEDX2h5gEwcOlOLHGzil1wZEe0ahhSd4ZDlF5tiBa1pkRq0F3CAjzctvKGCcTRPnb3KsdZ/wZM+ iwvie1wK6xY1ZFGfWpQd2m3GJrEouNgK3LNvS8vV5nhSLqEofBRy2MHJQZ5mTtZdTq52cvKGLAir U5USRoVZ22DEW09Dd9b2ITKyiwuo3g76hpBna0DQPkHIoznf5tThe5djznl9wzQC85TKs487bqsM BrGKgpjfFMSIZoy2aMHfMnb6su/0E1VqEiMWCRe6TCmuj1UA8k45iXdsqIqy+n/wzhXXZYyivAb1 izTzM0jjKpxpkUtIxNnFNp/IgHtQS6l9PxI54gEJRKKbSVW0SZgeQy6EW8csjovk8WvDA1BPuzRO KfX+Sg+/whvYjVQWMJM53yfIrjCd9XgNGZmykZ6syHfG4y+I/3liziPWmr3e+1g+6L6DR13xiZ51 bJdDnbxkmCfmrm8WGztO44xiQ6H0U1klffgqxwxWMgCe8oxonNW+oqWimNZR2Y5f8hRiEg5X7P9r vTfvQmuMkCZNoV0sm/OwrjVQRZuyXcPaoWVtfZ9S2kLaGPy9WZsLJpngFuSrI3nHHhCXSjIHfmhn 9+5uppUcRCMzvjs3rUuhk2p5PLTIitUjQtsWdr7GPHIAy6ZBt6FTbKtSsNywkbEPljv3MFIs3bRY XpbFIzLsEQVZDpy3eMOnJUBMUL4IzXpSy5NtcBwXc22RZ/tFnnU6vtHtyI8GmDhGf0xKPXr8lCJv Fw+32dFQkSe285NsZyABefAcNUFyzwKPo+o18QMuIx2nT8o825R5bGMK98IHX/gcgF8r89CNZAFQ mcfpwD5lXohlXog2re5RBI8n8DCpU2V8XdSPSRlS73GnWbbAqezTyX5024S7ZJA5qt/h3kNFOxJz XCLUAw9ZWv25Pao/H2y3B97sTW7Tct+ST5ZTNW05AW/ap46FNFDKP34nBxUoAhU+jtlTVdZk5PVC ow1y9fZyg4pAFZztplCSz0YdfUdHuz2FGl4PFAXWi417VOLG1I+a2O5HURT/vNAGZ/0izDGlRz9T Cx1jO9qpX6z3C0IXxe0VhHWlYzP9SQ0klU85KR0zkDZ6+zhhC8NGd+zVVV5zDYywn9HefrxFdV9J zKI2nJk4w4KwbE5QJOdPKG9TziXdqfKRtjNMU3yPJQnq7JoSWG8jTyQCqlRAI4FcgvI3au0Jtp0D KTL0LR8zk7FfSR+M43xqqooQvG+TYfJ6pQy+f/tG0tpeCHl/VevuuZU03V1ya3Bwf3RP7ClbNtM3 pwl8XeuieiLsP3CEEaaWVSNQyybrEvf0lNKmbZseLigrSjMnxZkThT7kcGbkGpKlPQOxcTUe2kmU Jy4PwuWSNM8VMRRGwWUnKksXq9++0rS6t9fkw+0rXkEm5najjQiSGz3VinLMaHn1gUKRHM7oJCbL C3J7XinLa9qquKO+hpTty3brFbtMOvnexfdZSaNkzu4GIGXNTuhc1fGIgxkdqzbvayexyo6OVXXA Yxzaq+ZM4v5GUgETMXBbHvhHjvXVnJxnvnfqoGvc9m0m6dRfSUk3bpcHM2gVR1wSPf1OJY8ULR/P CC5JMHAyTa3JZoOLGzRw/ZvWnpdQ2VtCur+Edje1WiHBFwwnwmivEalWXc7w2HY8PSZNVlYx6dWZ 7K9crhk82W3SrTJ8YezhSY+PG2qiSOwWkq5UeLik5zePtKxwbX1An7WS2Z5y4KPvTPZfyrd42AnL 4iRp5rfKl1aEv+juL9J2oYpIf5I2ALzWtoUth56mysWm/LLd8zStsifcg240S8RMbGikwSEwyndR ukQD29XA3dcxlE1Ca899jXRRxAyHPA35r9/eFnU8fJRnlWVzrI5typLeRh+AqWPH2ErDZxl3XYQD bZu3imWISHRrDc6QpVMhH22CjXdGZLUKivGRm674jn6J7RhidLnDj5gLWUpOK6GLkzzJsb5h/ukr 3rdos6cyzZ644ZgkT17OkeDPC/RmMti34djfEkZHioLvuek64Uywcmb0+ac90U4eaU6tyyN8gqBz +j/teYQ2aYw9DyHp5OgBZ1abDvylx8/WDmJ3FHPriqmxZuj2hKeYwVSjz7XvYQaF4SI9m42rUyWn xfgA5itiSz6TRt7O5LjfkbS0+V6XRuqIDb333b/RiEtB9U5HbLbBYKUxxQYQY8cej7//UviJu02H 1MWoYejmCDSwfSSlcwhrWx4ivGpPdtSNjX2aktoNoLeOb/ZKV+2EHhOVBKoMD31cajBZ7LAtCm/i 7qf0my5x1kBppaLOoF4/GOKrqu2vNwNo6rVeoo0XTIXtduyWws08VGq8WVs5L7Tt6Igb347iyiH4 5gh5t3ZQjEZvW3PgjCVKn/7uDtBZ4CNV9g4bHnVcaBSlsKwjMGv5Gc/WnyyVAwWZacu5od3mPwF4 GU0mCmVuZHN0cmVhbQplbmRvYmoKMTIgMCBvYmoKMzA2NAplbmRvYmoKMTQgMCBvYmoKPDwKL0xl bmd0aCAxNSAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQp42s1bSXMbxxW+81fg OFMlINP7TG4KLclMiZaiULqkcoC4CWWIpAGKNuP4v+dt3dMzwIAASCqulEHN1t3ve/uSXw7+dnLw l9dqpOykMqOTiwM1quB/amQrM/H1KFg9qUcnXw/+VZyU8M/iQzk2E1McvS3HetIU+Ee5iS/e0dOX 5VhNdHEMF6YY44UrqtLDb4AXtYVntICV1d7g59WkinfP72bl2MLr52UNq/9a/vvk7wevTg7+Aee6 PHC2GgVdjYwfjeG/xfnBxcEvSEEFD9dS4RzcsSPfwBEtk2HaNSd+NAlmNDFutOitzovjLV/DeRq6 i3/7m5qRUr1NG1inahA92vCn0k5UcV2OPdB5i7AZIs8Uf4ULg5fT+RzhCfDe7LZs4D18wRVf+aMl Pmzg4SkiaoovgJ2XV04Z8Z9xXfwM/tjiDF4IxQsEN8A/plelMoD2Ga7j4CM6jCquaJ35fYtIRphe JUzbamLrDnG/Mwm+wGOHYoFsbIoZsXyOrFT8R4OA4NGnpSW6Arz1nsDQ+BFwqXjF4gJntbjeonRw 5Htc38AqComBAxV/8I4BUMCtcEFLCBkGgOlHcme8/y0jdF2SnKYT0qHwa1MQ+AqWlLtLOB7+kkh+ o7VwXRdvTbYFTFmQvVBPapE9OoqKBG9GySL3UcWO4QBeDnBDNANwdQv2CQBl4gUTdEWvyWn51imy XBObfETmGp4EefmoHDs4E4hIA+xtio/Eh7QIn/USv/P0BUPiCeoGlGqMJ9b0FsidMqaCTTPpIB4s 4HkdUZ7n5CPdtqXbwFGIysQwko64NVMhT1BENGqRYjY2ICLr+GMG+OPBnvnEHxLIGXFhPn83/Ury eszkiXbdoDbZ4j0iptI3PxKbDuHNxlVw/+MVWbjl7LJEavjqnNWf9dMQAJrRQGWtDPKDQKuyldvT lGArfbQK70tUZXoJROoV8AtITyqlEK17RgQZQ4yod4TGhkldPx6a10T7fIri4yo09wROEHBUDo7N wPEMjmFwKtRvAad6SnDMfuDAJ04/HpxXCzx4Uyyu+f7iEI/nosNgNHCFCkx3s4dYqaZOuvjEyNn9 kAOnVNnHI8eHOcErF9+Um0LLDM0FutdjsuhptbFuSNXoWzAk30h3ZV32rp/YEM/xkRN/jWKoa1FR 1fRUVGfHz09qCEVNyJNBI/gQcbcffBWIh38q+N6KI1zeMhZiZ1kv6Z0QxWu55PDjqFSIOEYTQfmN MonarBBAw9toPhcAaa0XoWyBNC0huEUFXoEOA0Q5ksz2/FZEs+6B6gq/F6iuBu/4eEyPyEszAAgG 3DrnsIbAc74GOn7gb9j7CuGKDd30kgT28AKBVyjGjnwzu77+ql5YYiHu1uTjm1aMZ2RPggR5aIIh uMRlbeTn/IzW+kSyy5Lu+Zl7QNQHzIZvjVoU+FbUAsdyiF3Yy1G7UE3Cc/OogfePhRcQMhlgGeUz HqOT05e03Rl9yr99RkjMXQ+bW8SiySQbgyw6oVlFr2su6v0k27mJtt8BNpSAEFOLBYZoZCoSVP8k or7Rvz/Tryx9z3HcTfR0TeVgubfMBRJSQw9r8U3iGRe3vD3uEQb2CAIibVG3W+jWCOkeqzpGiCJT 5lTUSEvn6Jt3pTMvmTjW7MExj1GFM5BNDdr4TPEUyaaJKn1Dyk7H05s512QGnXU3wsrKKh9HcMfa BkwlxV2I6Yhcoe0i5zl8yb73whwA3AcruqGbCJhZqxtundUfcqWO7actqv0si4ZvnyCSuyQrTAAk /0cYhwZDslW7rzt23+Z237cZsfhi5JlesfiUVwk4ZN5NN7t/TXDNzqmqIMo0YPG3RMz4auSqetLo tgSwwk09pD50tMxZmK6zUCsxpnB2v+TONgDrM7I2uQvL7sLUvKIn//GSktphd2GG3MUOgZDuBEIh Mz4iWprT42pH4AJEKvXzAvc+6gNVJoTvIgUpxoxWXfWsOr11z4WUZNaVMmjmc9eh+WBh3W4u201c SFjZrI4s6bsp9iHbKg24YOtBIb+nzpj9dAayfqX/BKyH9KJCyvvsjJFA2BQJUBHKNq17V5u8Teio 1oORmKiW3Q9fozb49u3xPfxCPmO65HBgOVsenVGyOiDBq4EW+KUA76/D9/ALBQ1TNlSQOSwR3AcU Uj9SR8CxWEgodf09lcTtx8SqmtTPxENwI00VzZhew5cQ+aJjRsesZ6lXKF8xb9Obg9rN/mQYNkNp 9u5uxdTuSfzxu5K6RovLEu3/9IoipNl/uCNA1qDBBBjD0qtMYm/yyoQ0U2YXM3LTEkpJSWh+F+kT qA7pQQ0xGSbDJ2xTGlhXUQkey0Mfjn6i7OCNZBZqf69uYhiemiKZkuV2yHM6jXKyGyM8KNYTGCGm mFtRv7HACAE/stuVYJQTE26FzU5/ZpCZKiJfJQcBBNeVp44iGeZDZLWU6mwsT50wAloSPqkBIgMU +oU3WGj224dVJXWWUiVDsiekiW2ISsog0AeBvo7NqO3Bx66KH4GKJyf7X6qajUkK+bdfVhwyeJWE mnK6O+7hiOiIJE8/0/LzczYIdpt012WQOGpBpRyTy6caUd7P/RltUi92c2uUzM0xt5ymsytuIKcs e4qOp8noOsudzvKUG6JC3E3rBlWbJqHoXjE1URjl804rIrVfyUor+VCgwTeNSkEoJXIuFZ7JFNW8 o46EXkUAL2ZsW0Vx6CMtKfpkB0yxv2ggI1Oi0Jwbxp4ytgOVaRP8Lk6Rts+dd8DnKNsq5VkESWym KPU3WmkuT+M1ocTFdjKRfdS89Knp4YOomTWo/cYpcMILBMC2NdQxcdykSjMnWL7tJFFdc3pF4nPG H9eoyfh8+9aucdgL1wEATsHyxha46bXAB5q7eCfIWndcwuW26QleWLngTil3Q9f3eSU8INcQRV0a vVZmAWxAO/vxipwoNr1N/IAavSE1esnyZ51ekzXm6sbFIFvLwd1DINh1He6MZC9UJu9HTd8FxfzS 7k2lkz925ZhXWT/+2ThGiekH/CQwgIk1PKKAuyVqz0lh31GELac5y8YOFtRp0dKVdzwRQgpDTdKV rjyG6bj9Cq+8T04xdeUVYZ1mAuZ0sTKNYJj8moh1RGyd80oiFZsa9GnluuWY3sQxM8wxiKXsQLC9 rmK4Jm5xsaiPXt3iwdGTUGMaXMiUHSa1pylZ7TS0VO4a2iarQOsHS2drRNAEjS2MnKDf4+xJBlkY ZEZHcRIz7siN5mM0+aBEWBmUENu4Mx+Meg4mvFpIiSBm84fXnISfsUs6p7raSu97cGpgYKRibZux raVbgpNmz+Slu9LR8bIAUGLvCoXf7ml+QH+d/j7m5y176ynaDB1thniG1Oflmj0dgS0TOgIb3z5i JnExxvFYyxZzQS73FnnbV4WmFnfRSr3uS73MB3X8hXIrRuiOrFw+IOR6cu9F7GmEzFHIvjPDcGDF fhcPL2AzCcgZmY1TiTPEkyW2yNAw/MAmIzYUUCpjP4GsBDP3kI978ZUC694e5ObTJuSmhLM8BPcS fv1DQUWd2sv0QOIFYeMZUfuJOMbAyIN2sM7uYEEhd1K1XTd/mHmcmVS0WvOphliz4su2NaJ+9+yH BUpB6q2fw5AelbozJqC6wwfwvhg4SSHz/jbfp46FzjoWoR0BqdM6ZFmtC6LHrWG1+SAMGlbbTSCT YeXzcvKzWuHI0+wHRgWG1VY5k00L/EnU1nBzViXtYQt1exQzM0OlKifa0RSf6Vdk+5619Ub0BowA znW9pYBb6OEVZEr0mi5EokV305inoeIVZ228U3qrs1OQOc8Xsea0YaZTbZzpHIz012tc3dM4Lrbs WHIUWTD14Ijnc6tct7d+y0Fy1lX3nqfoe7MOWb+KLPRtGr3KOxyd+QW1pmzUrzKqNsZBfb7jXLAz 5bda8W32C9sV8Kp+lrCdOku2M50mjXZFtiJrtKcWn1T7OwNWek2jveoOR2gqpuhOo93GqnuqTGQT Vudcu8hmq/IpQrJ/A7NVdovBE8FohXuDw1ZGCpXV7oVK4WIVhmYjnouJax0VdtbD6v3IoZiX9drs XHpavuAql93UUhqkZVhVOmBrFcdQ9ppEZ7QbPTgZ+4xorxmrsitjVZsb8DFT26oD37dofsP0Vmwr dvr8Mr61YUJRbVHPlve3C0cs9ZJVzC/3U6bgByd3/1/sHWtPBbwtm+w2Y1j2/zDaMNH11JbMrAH/ f3/C13AKZW5kc3RyZWFtCmVuZG9iagoxNSAwIG9iagozMTUzCmVuZG9iagoxNyAwIG9iago8PAov TGVuZ3RoIDE4IDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0NCnja3VpZc9vIEX7X r+AjULVCMCeAfXNkWXFKthyZ3qqtJA/QadRSpExS1ia7+e/pawYDmpJIHZtyymWCAGZ6ur++m/qy 8+fxzp/eqJGyRWlG44sdNSrhnxrZ0hS+HlVWF/VofLXz92ycw9fsON81hcneHua7umgyvChX+OyI 3r7Kd1Whs3dwY7JdvHFZmXv4rGChtvCOCFihdoDby6IMT8+/dvmuheXneQ3Ub/N/jv+6sz/e+Rvw dbnjbDmqdDkyfrQL/+fnOxc7X1CCEl6ulcI5eGJHvgEWLYthe5qFHxWVGRXGjeYr1Jk4PvI18NPQ U7yuHmpGSq0cqowrLEBXNoggHbpEtHQ273IFwEwmOWxqADMCqL3KHUDwDiUHCHCpza5zZeAdPTSw v4ZnX/GmyeZ7n3OFS9vFolsw4m+BsM/OCNSP8KmyG/isshP6pONV9i/cr4A0PoNzVF3WQPyQz5ic 5QYo8Vs4Ai8tMqqzBZ1ism6B59g7zqkH55T9OWgMP6D+a7j/DVXeANElv0gwga0EiedzVXaVW6Aq wCAGPmKwPwXqZQQW11d4sDZIVIHNWVA13VbZf3qdb6Q634Cl/sGa2zWmLuHbt9qoozbCLoW7NBzC igBsG4WaFWzVPdg6xrZMsTVhfWATV/hsn9dPUxOaI8S6hAcMscNbBYS2hriqi9q+BMZH88uc0Gin AKHKun/Dpc7aJdKrs26W7zrgH8XyYsOMstA+FVu/6MjWT1lNY3zpM+KNgNIG4+BRjnDv0VvHiHla C85viHqZycvjt+8J8gNxBU/qMiVZMd7ery1gumGBHa13LHC91hX80BVc5h/tCh7E9C+hJ0SjoUBv s1/Zupa86y+kDtCTj1EEF4MqT39hNUz76KQCNkjJZAsKaygy8VWhbmpYtJ+jQsaMeHO3Zqz1IKJo Rm0j8opScspr0zQukvMY1I6KOfFxSrFVUb9IajlGFDUYPeSuELq7r8l2MNNXuL8JW9puQie3J+xt k44CGps0CNyAMurgPvOb3JD9Eh4c1X7K0b/aCdvtTe+KlDSsq0QfawPbUYs4e7QBT4L6e6OZFbdf G81cVnM0a7ZXCKjR6f+VQvbwCBcchhNyH7Vtjd96BagY8FkDPmoAlUMJ2zp0lg2ySZKpV/FXKIJD kO/KJjri7yWbNNs7BEjT+JGrQImC/+8gRQnFJ2qbP1ON6A34F5g58rxmKbiQkoABtk4uMDnfmE9r oRh1hZaUx/FMNCb4cgD7kW3QsjkAg92US+cmyNEiL3Q46YfLsSoY0+IUr2XQ1nUagDrOXjOKdkTW xWAq2+XCJBe4BC1ggV6mZGOMtxTMQoRuL8m1O0y6ps+2XECKoHJklV10bBQS92mTzi7ps9gCUywh nGmKyocehfTzmR3qnKN4nQJkECCsQ+ec3q9Te4TaAFTUI9PJNyUYiRiB3Do+9bd8agdONmDzNy7E l1zLzcHo4Cx+NqGbCd5osFFksc3R2a+QRSzYWDL02+scjfA1m0P0Lyx2lnO2WvIvlEzxlxI8i1zM Z//Q2rP3Kaxx0P1YvTdEdcLsnLHtYVwGTyOLMGIlGo3gmmsr4vCSDbZj3qe4wcurJRdRHUe4xP4s lTj4ULadEcFiU2wV6BddCxqZpo+/AdU6UE1QVYSqoVMdo9oQqp5QdUNU31B9KBuZ71uykbc5ij+l tcwz70aLLi1mwk/THLugRV4F6RRDVImSWIlnRMJQ/NOMD6Q9X1VUICLboEz0mWggIhEtDRYCPbh5 PhPZOPkR+LYxeFmb/Ab5WX0bX/0wvga4lSJzJG+7RZMLBdywGaFSPvgwCKJcre4rysHY9T2ln3Gc 9VQoUUyfM1gQ1xfiURCXJopSBFmb7fomVeNLxa5Ybw849E5l/dKAf5SuAuu4EM6RUKmRMFHR5BJR QMU2SZnAZnsXHPsltR6DUmrJcfIo2azkzWphhDx+7NsbhZzUfbZKpgpNKDwEDPVAIxVxsav6U+aB cqVCR32k6jzmghfW3BscDoTKXA1TuqDxCxcJUhV2TEVOxgLQYi+Tvo1KE2ofc0UVCYLfXnFLzTje 50nmSdXX2oFE3+5S1WQerRnoqZR+FtUcgw1hD9glwzKZSQh67yk1MG5U1ivnG84ZuHjRXVIRO02b oTM6yHD415Qvkv4oTtTiBKAjqN0DnccAZKqa7h/72EfjC7Vi9XTTJ+c8ZBDaxZIt9AC3V5KfB0Ua z3dE2i/JKIH7zCvsT3HSvBcoxBbKD3v30GsxtoYjncZEXcOigH9SWKJUV1RjvAsj7bTZezhbxN7I bZ2Y6wa7UVuWYXb/O9dr9sHmFJiqKbSAdd5QQz9Z8hzlFc30J+0cgwupSmvUBZuyUJCIgTPNSsjw 9z3ePmYMeOYpe5gAd2qSlX+mnvcD63w/DIyTcdnaiIJr2kHOYdJsFrJpZazXpp0R9Slc1qEU2P0o nB09IlFDeja1i2VRbPe0SUyBPbpbUrkipidCtRM83AeTxDgHeFdU0aGRkB1GW2crmvCPJiK7cK85 KZQhiosBfA6dWLwnVhabCtjQvMM4i9OPO9puUWbi5Yk/2Kw7oU6x97we+YsZB0apmESidspdt6gu 9p9pntls7gJHAzi2r7i3Uyx0ciFTxIYzNJi65CIDdZa07t+06MibFJdJi677Fn3YMHekzgq+XZJX hlBnpbutt2ibUQR0XXuHCDQgXW2ZhzMFZQZNMyjLJU6jG7S3KWNsUhOr+p78glO/CBrUNSxk4lyA UKCe0vSDriGLfG44RuKATGOjVInzVHc4D65f/LgWTLfGDxz6gYYOSPW5jQbANFDs+Abbz5Jbthos kltmQvQqV57LXvZRWnGyxwPwK2zrgOkJ19rytuWINT2luTaKZlUgoYX6awp8n6j5O6RiBKJow/5Z YW2e848Xln0Cz/4ASbXmeI0rXtHe9whRLcsxENNg8JbeCTtLHlRiQHGcw0miwOVZyx32kvrl2Zxn BDQIb7gsKjGUc0Kf3Vzzjy+oTYfbZhc5etLG+lAe6NQjDVk5mcc+WiHn/PCabn0UCpmG8N2yO6+K RhIdEEZDubBg21IOb59PiDcyOpjdcn9Gnxf8TPQwJlsRKieT3IVkpUiguhcIchZY5tby2CYmjEeJ 9IEiZtxKzIxzFXSTMo3h5HmYNjRjfrIeZO/XgcmP0S8hVVDpeCKeHiFXNmVfnGNr/iEnmWd0htdk OCcHdHmyhZeueIpBSISaLRE5nLOhL4pRd7RZclcbfmL0faCdTQ8wowjEiqTYNPDXyL2qfDp7bugn FVLvOUcwzcerNcEc70SW6SnnYAnmNvCHYdBS4uUyRewCjYVfgt3PpmTVIh5bkA0rf+A46/pwjBRL TsoUtoXPCrJp5FuqRyAuo/IAJwmA4c73CFKoNjQXJWvtmLAoU9CQ1dMQ9sPpHTmrRHvJBkOb0o6d O/KhArRGnop+5XKTeJfqlR5+IL6rTlqnYfiwVfGMaf24b+ejPZ4dkRtNebootCSHcISeYemq1hmO EsPxveG848LpiMe+9PmJsvwhtWH7FN9jEbCLF2Y8VAHUSx2yKcdSwFIvZahPRpb26WdF4DepBBKV UyVQJZUAhmKqBGIYDPmySkoBeRBDSbR+KgLKrYsAZUw6Jv1uiwAFbZzz/1d1gCrp7/K+rzqghtrl +60CKpv+ycgfVgT8FybiHFQKZW5kc3RyZWFtCmVuZG9iagoxOCAwIG9iagoyNzY0CmVuZG9iagoy MSAwIG9iago8PAovTGVuZ3RoIDIyIDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0N CnjatVpJc9vIFb7rV+AIVIkwegXgmxN5ppyK5clYtzgHWiItpihSQ1Ke+JD/nrd1owGCMqiKamok Y+nut3zvewv0x8Vfbi7e/KIyZcvKZDfLC5VV8J/KbGVK32S11WWT3Txc/DO/KeCf+e/FzJQm//D3 YqbLNsdfypU+/0RP3xUzVer8I1yYfIYXLq8KDz9reFFbeEYbWNntV1xelVW4u/i+KmYWXl8UDez+ Z/Gvm79dvL+5+AfI9e3C2SqrdZUZn83g/93iYnnxB2pQwcNRLZyDOzbzLYhoWQ3X7Vn6rKxNVhqX 7Qa78+Z4yzcgT0t38ffwUJcpNThUedATTIeKyaEH1KrJd2SKFV+s4aKCn3TxqTDwc45GrfKHQnmw 33Ux83BzC4sdXK4KByZZ4vsaLnDxLb9PyxQcgvdk9+3m10IZOhOuVb59euwU/4n8rimbhozmNMv/ 36lrWzCYB+F9wMyshcPvFyChVSDNLYu6BRVRm8c16qZZ6DYosinAdCZoh2sd4mkPmNB0KXc7U+35 HdHWhKdzWFHLuu1mzpD9ugZDWnxFwdUlrqzAK2L7zR2KiscfWKZ7FMYGKXR+R3s72lUFGdGxPpj+ 8QAHuM4RYcM/wcdtuC2IuGdVRf8NC1P3zo5Po5Lf+PaOobB9Klo0Ja/1QRHGWhRbTHsLUjdB6id8 R5GVmnCkWK6c6vCasO5NXRrByudCwaayT/8kUYQAXeU/4Jlp4WhUDARfkLduA5hdMFYNNnyLRnRw //NigVQx9Hzd87yKnqeN0QWKbtKzr2w+ibwIL15C/neqOyDFmwpuk1NbEIeMP6JmtCiqqZHN3pH/ ryjS4wby7uYRvWjD/ueaX4EFxPwfCIp81nUB9IekrK0HDIx5RoQUz6SGTl8W7ckkdhBt9ploa5Jo C1buwsxhrpA9+2HN3o9G+lCoGt55R+pck2qolKtBJvgH/nqRWUujstJBErCYAN78YkcMrDPndQT3 e7CKye84za3wlw8m3IIECkxiGQGKOEUR0UOSw7t/ReR6ehH1nmn6hUYTtTeFC/uhLmMYMKOc62xd OuFcxYHwpZi6XlVNb4NrUoFEskBaEKSoy7JQqPMWkxKwywNx3PyAjzGaNoUmPZoQMmglLTGoWwqd BlZscQGC5qssgKdYADzJyxCautsAHjq4/SVnS38me8pTWYoIwMv1igC737Nv5hx1GoyuKjI6kTFK r4Arw9kgyO6L1hqlBIwRNaKH8fUanIOLHlhleZ0VPbD3phsZnWRgCZtYv8hH3frPRQwWE0Q+8NVq i+zqKZcoFN/xWSWYp85NvMAcpjmD4COPuNEaUyLYw7NbMQOhtvM9W7POVxsC7x1Vb9EiyjBsKdEc OLGyHHWQow3yyY4jwLHnAqdqiZPIpeyw7x2nE6rE3wguR/vUCGhMH/MdwYUVKc/xItCVBIp5kRe7 9a/hRT3wIplBSha26+rAwUS20fluRZQ2J5byXQxyQH4jd/NPEXR/QAsqEdGJA/dvpxvBl63ObAv2 F0N8YonWd3TOW1bB5W8KTEQ3LPx9dDvApgl2miMaWqBYOMZ2T4VNFkXdAanKlwJJfrrD2zUWahti brHOLS7y+f7NOU613sUEPKRPRJuo5EElkuCGCxPWaSXkE1klKLUIMXJMjrYLDyJmFYi5pxuWpErF IGOwo4bkwOkqAuwtlLDSzNiXwD5Z/xqwN2fJAo1oq4fQo1yjeq5CwlGQ8+mVOdv5lvPLfchNuy0V OJInLaJJdoqER/Q4CbltvlvwaZyiwhW5XgWboTeFbxXhQDVSWWnsSX6LqVlRh0HiNAFzO9KjDXoI VWJf3oacaOT09Q9WqgkEEnIf8uhOHvphZcA80gQwh7id6h/jsHu0wO1W8HKFmIgRtaRw9eHyLqSX jzw4eA9qaDAByGbQChuysnjXgxGwJkAbcL2FAbGf33K51gNhLWYmtNX5WXRgWihUm+l0kCKsGiDM T0FYSiP+J9yYIszLlTsfYTZm+hgKhLB6DGEMbbwdHdeHWLRBr7yiFY4bRRTrGGk60TcG2mSogXl8 ZuomJOSrwnV1IQPNpcUoUdIY0DwCDT0rQHPDaHsVpIHHnM4MlO71yURqNA3bJN2kTNSChjsiT8zo SAI2BRRBo5U6m4DTq/26LBLQscJDzWiZvFr+4BN8H7L4rmpPBO+xTY/WUnHTB4XkvwOnlUh+ieyR 5P7Dp4NbHkcy0mrJhRFXprGGSFjNd/KLZITXmuVWwdudFWJyO4dKsOhvQmuvYhYfC9ROZJbmkgOk HRjS96n5iDcQszSFo6IDlAhFuE9qPtmJnK5OOB2lsbHNYtucx6OVilngWR7t1VMRsIzvWDgdehk4 qC9yJU2lQRImwJheUZhUkifVVs9infD6kYcmz2K9HikeCGhcwjY9mNsuVRzD3A5gHoXuwdyOwvxI dAZBgo9TlHYmyHXjkInJz8/SSIJvQFQJlnRYESYtgj8up3dk20agrKOj+g1qwyfrSVg+p3LWzoUv Dy+om+Pq16ia7VRJ6hanQwgNdyrTeF8PA3ElYwM31tgAJF2IMqkU1k/HwwVJLzqkCAb++sDMupoV isq7BO+UzXAAwbEQ5xHcCZGp2kBgNZW9sb5NahKNCVImP1KXMeDn2AzboxGVTBp4OPHvBVdCiLeo /H7ylAE6SV0B2z3fUFpX9btjP6RyMji+3XWSYpQpBn+giYrkMtLapUU38U2itUetm65BEmwKo+jx LqF+vh4YdfYVfzKKn2Gobg1xKtL2ZlBJYPy+4O+MnaMNhcZ0xyioFptpxdaporzvkbHBZ2e0FWen 793HGarcIs9DdqhDLaZxCAML0RBSik9KiCKbnZwQG0mIrgPLfCeHVCc8mgxZxopHAdKSCaMaSX9d 7oSuTnpA8XrC2DGR9tvbikp7H9AnM8O5VPiX5/jfm/gxQDL5HAM0ZiWR6TIMlIe118cCvyq956T5 G/urGUEH4hcog8LEjQ7B2qOBllJdHRK7suORLZe+pjqePR25DWoGFb4K9ktjzTSCOE06PzyrHs+0 viPdo0J2OEQe5NtDKGEEJjGej4QmmO8FXWumfGGKmDOb/vSA+oOhVxzlSPrbhmZYXZ4BFmzNBCzL FTBgZ5Nn3OOCe/y4e5JZUtpSR/fIJpLwTozEZWXPB7GhltHwkg/XAehPdPha5sdAx/C6p7myShpl ng9HwqBJP/1dQsi/nnJpGJ8tqL14JDnWqwUXtGflSgURZP//qXJ8hjweJv0Z7HqNE5uGJjYdWX9j lZHUvxc+xeupxpoym/Q4lr/rWSwf6dBYEclcUswt8FowZH9CiQTz8KmL6qKOEgV3+sSp/NHtGv+M o+K4iZkvUp/przVdmz+J/Fj/y/DpydIfNEyvnhEZle/+eomcn/YCvbZlDJ3+nJYgFDRJJqPYGSMj OyiS4veZdMSUtIgutUOSUBR6ziVWNlUI7XrQ58lVRwpOugn6iBa+Bd11ta3tJrliFVHJpHQwqM6a fpoZUgGXgEfjENG6P5h8ARdAs9Wo+LdH/iXtVrL+dRou+ToXWlNuaNdrQAe8+yn+2YAKXzYrSU3c nzNNXrH3uNcQYB/Rl1Sn0pBgLLkBJEJf0tnnf2xRmAQKZW5kc3RyZWFtCmVuZG9iagoyMiAwIG9i agoyNzEwCmVuZG9iagoyNCAwIG9iago8PAovTGVuZ3RoIDI1IDAgUgovRmlsdGVyIC9GbGF0ZURl Y29kZQo+PgpzdHJlYW0NCnja7VhLc9s2EL7rV/BIHkTjTTK3Zup00mniNtGt6UHxK2rlR2Q3qf99 9wUQpCRHtDM9dTKxTQLE7n7Y/fYDPs9eLmZHr3ShXa1ssbiY6ULBP104ZevQFo0zdVssrma/l4sK /izfVXNb2/L1L9Xc1F2Jv7SvQ3lCoz9Uc12b8g082HKOD75UVYCfDUw0DsZoASer/YSfq1rFt+df VtXcwfTzqoXVv1Z/LH6eHS9mv4FflzPvVNEYVdhQzOH/5nx2MfuMESgY3BmF9/DGFaEDFx2HEfo1 61DUjS1q64vNaHVeHF+FFvzp6C3+Hhu1hdYjo40pGtXVPrDBY4bhDAJuytU9PjXlTTUPtS43q0oD Ust1Bau05QuAwxrA4d0543FNHy1xVJVX1dwDKOeIpIKP73ELTPmJ5shbxW9tMrTGAdXCDl1swJZm y7iYg9EXPRiPx6Rhl7whMLThuN6DXUV2wdwpWrPJODpso6lrdM2DNY97a8u60gb8sekJhkw25EvH ODQxRIFpvT4BKBR8i963kGbwkaNcseUtJdSPiJEqPxImC/zal8uPlYV3gMSBwcIGBt9i+kvi0zKy ZYdDptoiWFsb9228btDtQEhpjMzn2NgBNoSUoaGA84zRkBTfGSiAX8HUE84hnvQnr0gBuEEAprwb gVJbXdQeqsthZR29cjtB9i0EL1Xyhl14TRG/RBw6WPeYwjljWysupHsMpoPtsFhAEJ+OIxAzRLZm EHX5ocQYHQQMow5HMYxLNKRLKYsWMcdJf1dQsVhiOIg4eI5UgQkL5u6Y6DzZNfyVAVtIhg888UO1 MzXM7thDUztJsF+XtMwlBsYAG6wbDcTpgD4nLApsrSTdTioMeo1rakDQEr1MWEqHWrbm6NCMB3II heugA7R5yr+tNKaaJOGvGB73CkNBI5xSFUh3ATb40Apr1cAcryh048E6VsZbypA3XEPJ+DmnG/Nr T5kdTH2IJHxKKZFILOOj5eqaMoR+0cZhxtl8Lu8jJHGXuB6fAyzC1CtzN1JsOpnDgr2Sn/Th8prK 8mwSLA20CiFqNIHlcXdL2zEI6KxKaDjw8EALXYe564KqnWRb8hGXO6p8DwaGbRoiN217PAXJ1QUz 1ikLB+p0qbMxLfqeFm8IOSE5zhzaAihuancDrMEotM5b8os5b706Xd5zhY87FGKBJW46LOSSeY/b cmrWFICj3TZY/F+xR5vUaT9NRM8Bi0mFpU4OBhLDriQISIC7O8iNNnor1LtaYr7amMpnscvGouO0 D1JyNq0cs/6SCFTwE5tAYXPsKzWUi8OMXkDLoJJA/rhlCXO6XK+pSDBqAfKKXeMZa1ZvmV7JSq2N ftjeZXBiGnawTQIdx4kGXYTxa9X0YG3+wuRpwcgxh9Y7F2I7dol46Pt6ojN6rInG2BuMXOhPCmV5 mcOeaqRnMO1oK5/DYPZQBks5bQep7h+jMHg2/WsqE2Gybh+TqclMxgDbrk3qnZM2axeN7P0Gm7+R /BqyQEC7eFjp2ck8wk6e5FSL4BA5uUROwjFMS01sNC3HP1ZGsYq5Pr6waMn2G3Bs99CTCGgjEG6z 0zT4Wps65IDRVCKCnNB0RmhCu+LUp9TW0MOenZizgaPm0ecmQrZizHwM/BskZeJJZkBSJvZZMc0k 1SBJoVAKRFKGSapLJIVqFZxbr6lZPEzEDNSZQEZb4Z5PcILxUv5ywEfI3kIL7zkWt1VpCJHqZyFq 9YRzjPVQ7RNlHH4GvjQjhqUNpBRRhx+CcC0FG2CeIiVNdOE/0JHJ1v8issck0KGfYIk3EiQi9baI bCL2G5QOkukHkW4YSEIrrGsij+aSUA+4V7sMly1NaIWv2xF0W6RLtyIZxSd5aMby8GDoDMJmAAUt ScWKEhrRmvy3GfPSnu9gXuKNvcyrsf2yLmxi09rShW3PuHkiq8cTeZtyc104JX1QpQ3vUB7QsBoL SaPAh9UVi31hWGZdMc/JPirudIzvxW9IRGuRLVxPzpk0bMbSMAykYbuH1qdJQ0gB1RYalEvrni0N vcWP9hLTnv0MQ9efqA0TMbleG8Zqfw4xNU/VhJhZGiRNvDjaqQgZOiqEsMU6zyOm4VlVDYkp9Jed fOoOEnis3S+w8zajSvGoZ6Rm3ylVS+I/QQcSZKhokgq84eurXfpPCQu1I/2XXzRnp1NziP5zeZ3S ksNqGDb0wZlsvwAMUQA2uwUgkcsUhLxJ3W5ERudVx/fv6ciYyz1/gNyzJPdMLvfkNvG7yj2NrBlv FXmPMzqhetXMFZpNzCmjr6kU0rEz5ZuEwygsN1V2RTMkyQEMm4M7ZeMQ8TZkl5ZMxIKkjqXHN9f/ cFVIOmYa9F/QVLiVCmVuZHN0cmVhbQplbmRvYmoKMjUgMCBvYmoKMTc2MwplbmRvYmoKMjcgMCBv YmoKPDwKL0xlbmd0aCAyOCAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQp42u1Z 227bRhB911cQflo+iOFyLyQD9CFx7MJBGru2GiRo+8DYUiJAthPJl6RB/71z2yUly46Ywm3QGkFs c0nu7pw5c2Z2+HHwdDR4tKsTbbPcJKPJQCc5/NOJzU3mq6S0RVYlo9PBr2qUwp/qMB2azKi9F+mw yGqFv7TLvNqnu0/Soc4K9RNcGDXEC6fy1MPPEh4sLNyjCazM9iO+nmd5GB1fTdOhhcfHaQWzX6e/ j54PdkaDn2Ff7wbO5klZ5InxyRD+z8eDyeAjWpDDzbVWOAcjNvE1bNGyGWU7Z+aTrDRJZlwyX5md J8chX8F+ahrF36uLmkTrlUXLIinzGtGjBfdSnZXqNB16sPMDmF2q2Tit4ULGxgilVWdwy6sLvNCq SWFazVeFmp6nQweonCGIDiZYvE81wn/OM1zyrCd8W6u3dI3z6hqe4ttn9HP6MUWgLwn+cYvFV03y NXiPLZJdweKFsbDn6QnMWbAdBtbRJhhi1HTyGXeVw8gIR7yag22wxzPawaI5Rpa0j6PdNtgV7d1D c516hisa+GOCjxXhsTka6uGxn5g8OzzlAb6Ni1wjuXI1vcDxUr3Hxy2ME/46oCd3px9SJPiMN4I2 mRwwnMzOU+S5zLVIgbZaZX0A9DCvZwRfphbeFsdf4xoYKRdAehdg/MQgX/RZwZZZdT+sI7zOGa8J 4lqF5wzgScRa4GNloIOmELbCujDjBPwbmOLIbwW+scAp9G1s5vkbdvkVurimGQoUjoY3U3RIXjHJ jQyJCyt1DOa7sMhJvEfTyLTN7DI14gN6ZyrGm2D8HI3zAb15H+8YsPnvRdAS4JGaMjpHgACnM0Jf AqtcCizzDYFFDmrYt6aNsBqeOghvUVBoXqMIZLorzDyHWYGcJCsMr6zVjEhnw5QUZ4X6DXJHH6hz CCcJNeZ+827Zr5qSUoHWGPW4x9Su8kEG99mSlqgCtbD7E/A/RtbGS9R1ZqvElXlWyjJbnEZRMnIK KsfawOuRNYKSkPIjWRwUPkZ5qY45O0fSn3UePE3RVW3iQEI9QniqyC9iFko2rubCbEti4VuxWKV0 R2ZYBkxch+W7Iv3zIShcZzO028WYKdEqisGYaCO06YExCLFzLiukKCBa29VMMIRdVh2lgDUWF1z3 TM/IuoYerddEV8t8dhq8umDAiIomeCZD8zB3SXZ8T0CRmBbo6m9yrRa82Z5T9EwNcGrTppcY2vSm QdkgFttV2P9od+uCxpz3ZLOps1LCcYlhrMjNJSvWOORBTNRYuZigAlIyfOCSAW+i4jdzGj0n5jIm LP/sMUHWd1Mhz+FJdrSwvlzL0YZ+5+t1029egFF83pKbqq6GV5Sb+uEKBbUQmKLNLHMiJl00wSvM IgbtHHV86VfyhY9v3ZEvvDoJOEzOmVxCp/KOTFHgnpZKsWolRzCOfjlH6G6OmAX+kS9Djsi2+gh4 DieLon8ZhmM9VdzWUGrbBxW/TxW3ZZXl1YOK37+KWw+b+a+IeHueyW87z/ABkFyIx6ZuJCwp7O2R cPNY01aLeQRxUyf4rAa6wxFPi3rdfWriupdcHS29Qg6RKToIH2Wf2w5R2spY1T1FDXV7HDpp6Ugz XaUuHqP8hsco1x7gLxjdvswEwoX64iERbpoIbZ6H1t4B7l00zbZ9I83HI9djUlO5mPLu5XxU1niy M77GaOiepeccg7PZPmU2L7IgOUH4wMIxIiWX9HuQOsr5dMHvHI65ySky8zkt4QmZqNM+8JLHxU66 U0BYiydl+OlzAnWH8/+2JIgh0kczA616k1bMDfTCzqZQVDX2E4yzGAMExVGKaveG8eXiRjj+BOO0 UK/JFbhKaMZxoAqGrHyvCEiMYc2t2M33YxMDtX4QKIHsCXWDXzNHh9QAwiGrtrelU3eUYvo9ggtj PQbRmNFqEOaa3rGSZ/iWj9I+7olWYWInmNGKALEiIDN+OaKsk7d5lXVxPuduyYq49IIHqk8txH2G /tYqYoC72T7cw8h2TAYd3MTZb58rmpf91LGoYwt/K607srfU6qpljTb5gmofN1jM5bFs4ly4kiib tusDqlFJ9NjQdKTmlQ55iruHpItCd66sT7lctLGNWC2nTZm9XJmloCwq2p23ahyve9WSRQn7Eu5+ dXWqGDiHS+aIqzOSUeqZWicdYOdjSgYLATS2xl9wwLzidGhiAVkSSrbtF74V+RGhjrV9t7POJafk k9D77pxtbCyx+tHJQ76SCNolzjazxTgAJBV1hz9Drh6qtpbSy3LTCLouMlBS7HpwgwB06GUwgwbi xHQfTzoRCMzPIeHKQ2MGXsqYjDaw1U9SCpCsIMCHOxxbuygUFYe2lVEvhz8UPbRXhzPh4e42O9zj VzIkgKXupAvpF27qztFJNOlGYxfNi+Bhg9OqnKfY6qVRgOc6gWJnc3Jg/X5BiyFRv7BnazUBMrAe xNrvz55wahfb5I9TLKMfo9mV+iGcir7wzPnNzI+ehsx1muK212V+ccgZu1uS/lz662UoeEqWrHrz rUPloysbP/n16StICD/qVwBpKICKh/oHiKKdia3y76D+0aaKX/m+w/pH4wfR6t+rf3RehpblP1T+ QPWT2++//FlnU3HTpsLWmH07Rl1zx25KKWOGjNP4CxfFTqCRszskBTpcGvpmaqkgMfIhVVvqZFtq ShmpJwr+WIqRPNkUcWPxSNnZ3LoU7vAaad2zOit9/Kb3vyzO/gKxBKGrCmVuZHN0cmVhbQplbmRv YmoKMjggMCBvYmoKMjA0MQplbmRvYmoKMzAgMCBvYmoKPDwKL0xlbmd0aCAzMSAwIFIKL0ZpbHRl ciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQp42u1ZW28TRxR+969Y9WlWqpe5zyxSH4IbKiNuTVwE BR4M2MSSk4BDuAj1v/fcZu24BnlRVahAKHF2dnfO7Tvf+Ty8HtyYDK7dNJXxjXbVZD4wlYZ/pvLa NTFXydsmV5PTwWM1qeFPdVQPXePU+HY9tE2r8MOEJqp7dPegHprGqjtw4dQQL4LSdYTfCR60Hu7R Bl52+w1f140uq7O3i3ro4fFZnWH3d/XTya3B4WTwO/j1chC8rpLVlYvVEH5Ws8F88Boj0HBzZxQh wIqvYgsueg4jr/dsYtUkVzUuVKut3XlzXIoZ/GlpFT+3jbrKmC2jbdt4yJxuMYFk8yYEq9V0eTHD eNsmqcVZ7SAZLygLi+fTN5jOTGF7dYG5ahujaNWqE3gqKXoGXg5qWoNNo87wMcz9uDZwXy6TesaP owUDFuSh1QzLEdUrurv8AOvOoHG0ZhKsibUVvZnAC6iMVaf1MEApFm/w9QwPZSrPECv8gvZqarzx 0zqvn09PhhAslATAwNk5OsTdAmTJYA4O0ZCX1aju1lBCNTrk4A3YIVQd3RzhSoQnEkLGK084C3jh 8MOiZYUpxzw8x9ccx+jUAjPo1DnH1mXOwBYeAEtb9AkIIJZykwViv+K2hgOJUvwHNRo8gL89NY0N Ea4/cqVbNQdwoE+WUus05OGvngmN0JeRHbgOcWT4DZFn9Qva0ODPR95Zd4VekE/L5T2stFPT0xrd vsPppBJ7gkssNTmrjYMc0/tGrT7wzpg3yhj1uIFo9nY9gd/Oovvk97U+7wFmtST8MfHNM2omqGmE GJcCfMML2C0d7sHnFjuQHrAlHdh7Tr3n2KTXcgHMOT5MXXFC5TwHVCbgJ2oirz5Awtti+rLASd7l 9pXWbwsSTza79CWxgZS+VU/75EFDO0jd7yPwrJridn5t0ZSe2H/XkKCuUpV7jGPIKDp5HTfTPUrV onshgGNSrX/Ab4r4i8A0mNNd8JswQTAz5W1m4l6WXSUFTFO4I4ysGc+sNfMhiJk0XxV6pCCTunGr xpuHTDIjNJSK+SH5O2FaegQGDFvDTu/VqsHBCJCSHROcHrEF5DpTzB1gs1n1kDzEmKQOI7qfwGgL i5OCmeMaO29CID4a404tjVeLC08Uh8fWxkTYf0KQPmTYA+4is3rMvCU6T/IbCTGqyPh5UrMD8NmH GQOMfam81PaA2vUhEzNm1QoxjkbCmRzMMVw4j53FwwsmH06clt7x0Eg4DMtc4xGqATj9aqFBaNjN WnTpt1RtTN8fx5jIiCCV7r0kLK1WOLJCAStTzJte2fEttOrOucHejI7GiO9QoCbwY/QKaO/ua5GV iYdRpUWZyDQdYxwRbVjnMJnY61rkSUk+tZ0p6kSrOcsQYb0VLid4V/j2EuEb10Qqj81ZbbhPqBSO q/MDi1BU0pYzJFsyQZ4ycptB+oBVgWNdA+CPwgXI4A7R94yH2N44MUCwGbIWwcpVAgPe6gbLxSnG F6+wkSkTYMaQYrn0c9Fbd1jqipqTwbPAIcz4yshw6HNQS4q6FVs8LTpxKNNmzvphuxxjhqjA522N lBlxX9xpLf5Y+nQ3CtdgyQOn2BdgTvbPnK28T42R/qJi61LssMO1jCS07ZovsuKTBAibNIzgnirU w/QuTPztyFBXAp6eEd11CdvQp7Z3qOCkzV9VH+Yv0Yde6/INtI88dDl0vMpjVRx+h1FrCL6XfnER hFT8oV8ISg6+Vfv8vegXB2qtMNg3KGAcfC0pZxtfQ8A4EFAm/qcCxrbdodQP/bKvfrEJvLblKO9z fNSd9MjX4g3t0oCT3hcWCfQlNuIj3iXhK8jJe95gQRsmzmT4d8UMPvMWM5ahu/uBJ5ruoGY3TC4w yFRKAMXOxCNhSx0l6V+ZdpInCeSCMhVKN8aNQwCLI/aUQUbaT29ovyGC6GrC/I6EmWL1ZO/gI84v C2RUmHt+zuVZMeIIy0CoDgx9VphtJC1d7S27Prncod6krzoFtHGOKHLooumpaawz34V2wyP2ckb2 f9JuJvvuDLyPeDOAwj2PtCieIZbdlsXYxxIwbFHF2+dcvQRimzq5+SX6cOPoEcmtq4PwxDHjWhan 8skzXAaJ+YQEFLVVxB8aErWGhmJf7ZdNp4N7SD8hwdVlXWZq998afDA+XQLp+atj7W+xC43xCmVu ZHN0cmVhbQplbmRvYmoKMzEgMCBvYmoKMTYyNAplbmRvYmoKMzMgMCBvYmoKPDwKL0xlbmd0aCAz NCAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQp42u1aW2/byBV+968Q9qUksOJy LhySC/Qhdp1mF3bSOmqxRdEH2rJstbLileQki8X+957rcETZXTMt2j4YQSxrSM6c853bdw7949Hx 7Oib12ZifFG6yWxxZCYl/DMTX7oiNJPa26KZzO6O/prNcvg1u8inrnDZd2f51BZthh+mKkL2jq6+ yqemsNk5fHHZFL9UWZkH+FnDjdbDNdrAy26/x8fLotTV64/LfOrh9uu8gd0/5X+bfX90Ojv6I8h1 c1T5clLbcuLCZAr/N9dHi6MfUYMSLj6qRVXBip+EFkT0rEbb71mESVG7SeGqyWawO2+OS6EBeVpa xc/hoW5izODQpi38pC5bxI+OPEedPICDqPyAmhoAB4HCJZ+dnJwiVCF7D4st/Jwa5wP8trlmCLt5 jmDjMz67yltY4ksh63ZoiBIAi2r9qnSVBUTAFizd+xyfn+E2lcg4A/Rd9qf3aLNQwilXeJjLHuBq nW02ubFkoylKv6bF3YjzwSB1UzRikN/l0woAiRCgNCcX3+UGNf8DXyTpQgaLcNQ7vLPO3j73xBZO bCYhgN8GPvIrhvUVO6/Njj/kHnb8kE8DHL4iaNusW+N19MbFqoOTTXaDgKA82+u8BnkQe1fSLw3c 9gG/4v1kE5ttHnJyatymhQ0vCamfcBM0JN3lsltaxZssRoI4yylY2aL61uJlwsFGa9+yII0Cs0G0 6qzDD8vWss93CVOCQ/i6aMRfGeY1Rehyx3ZZ0t5BVSOoDJwLqgW4mc0mFzuEo3n++WAgsExwFj0z jZju6pZEWa5zTDoRIzEUnm5r1Fss5fnBSjQ4xtUavt6xtN2awqi7gd3EfatehV4za50earM5w3DF 0AcVwuj9aL6KDQOu4NkGRtATQQ8sDV82I9EBRUqJGHEGjFLMtXAwibhFyRoQ8bI/xyt2N4yQY1l8 tmGP5uDd5pCEHcNUZkvUwKl+8iFozen+YmTolRBtEnoXOUaCyAZhRMlwpxGCjhP6OFp0K5KS5GMZ AONBIFWH8NJe4gqSVySS2kecG0wN5gNJB34VBl7Nhk3w6OO1Sl3VeMXLj0WqaoKmZUnIsKs6K6je gB5YbeXiOStVguU8h4GDL6l/O7AYpQrMbnjPJSn+d7pYa14XAMmBWtBxGeMpcfL6QOc+RznXm6G7 JClWYggoUVirbNnAIhcQNnsJoo0Dpy6LWtAhCSkVdxzkLgly3JsNHGONYrzJtkv0pDp6OuV1pwav nsjjrH0nXqpBoD58xdVis6SKfon2ihcj+IsPGLN1n23OEEIHKcqgVc9HIlFB/Esy0FrzVDyDNbes dqX+vVapehTnKHbo8xXCYIi4iTedLO5Yg3NYdQrsPR0n3pgY3oBOBbEHuPwK9zbqXaU8JAhFQC5e n9TMLT2c4LMKAbLwMQ4Z1xa1pJokaxBtmiZZTXLcEBBDypV89NfsWY0SDpQ7RLkZ7+F2Hm6X3YIW yQXnZdu702Mh3e3Yj25VFkF1Q3mn7Yv6fgxKXhZdt2Ct6H+0OVSFcQACSRfPWs5j1U1oXqqvyARZ WgrxXvwkDIecK6bvM3KsPc7FPsHJqbv6B96JB+w523bLJiSPTNiACPiZakcCE5xxH4WGwG3SeA6x ZFesjVc2V4/HDHJbK4lpsdxQHdjuWLwIQhKgjZpL05CUIUZvmLc/cbLcr8q3nKAbSn/kXOIuSpzP 2IfPmB3U2ZveBgjhnEI1iUGqd2/YeaJNRALuOGSVUzirsRuHk2+BDnvFSXqb1VyZyUcUGejZ6iHW LyrkSRhBOFoIUmE8wufmGm8RInSE3xD3jklH+6WYLrFMjDOEEELxMNiw1SeN+tuaQ5sOMSyPFaxu RmIFHVIpfHy8WaQt6Rf7yJVY9eo5TpsHrWeIiKHIafr8qGUbw7Jiqmkw4BVWlkUp50fK4EP8FhuK AE6Sd0qzBwxjHEgBApkxmqfcWnRQlZkBa++0pFIcsrWG0MXxhlId9neuLxgx/Se9jtWuD64P6Oab FLB73fuEFuxj5qkHwDODDDT6SBy3GwkJ9HFGctGeg7ANF8sbgN+QPE2cL8xV3DuWtvvMtUgC6i51 MTFcwHCtUD4K15ikC67nkTUTLXLZavWuQ6ME3eyARgip1TwujT9HojzzHucOjUaX2lM45UiYwI+V JyQs3zDLj990b+XFscUaxMx+H9MMeeRrOoGHPVj8tLM45Y3ThsYhHuSxJum9d5RrkvaEKNMnPnWv rYxUZtVRFLS9UIO2cRxecKCVdNRH/14yrTXsiCi2In0j6TgSYu4fEbyvxo2sfFnqKPLilNPta3YI avG8rIbsLXh4meFMDfU2Ou0BgsnABRxGIj3xxEMqZuIVXkTTqzH3e6OeMKJue4TRM2F0oxTyE9dU sRruz8DYXf5MgaNOg+dhxPysLgO98ZbrS+R6v4wD1AXYR2Lg2xzbo29R8yb7rY44fuadHwlmbjC6 uxzFlmmNmJiDWWyyXxA3P/HOdWYZsZJb+Pb5okMD6CqPLklyfzPmOegNNDW+pSwoEgvDAu19hWo/ f9MW5xoO0+GgGzvMep56p0OgeNb6mQHCViCiJdTisayXZibTwFdpUY6/J+p0yh5/MuMuf0rC8EF/ 4cjhnuN0pMMAzzV7SVN2YzTjCNlgFf2BXLZSZhp4Ghr26z37OJYQw83MmACybXw38X84Ybd1Xbj/ 4YjdBvPfHrFbgFQD82XEfjBiB+78H56vS95HLmWFPzbaza6jztRzDzfspITJyJwNHwYj8zIZKVKL 9gWza/QL8ACd7A8mvIdD9iataHv2SwawRJ9FNu4neN/b4dSPCDtn1WRm6mxPbiPRPpya294bn2zi TdI7NjLBrods5zG07FOTfgs8Ryf9M/RJbDUcGXbqdY5mqL0MNPmhpqxFdT2lKeNYLQ4MK2FgW44a bsGe67aB3gqlIvFM3qbTNQqqAYV9bHBsnhgcs+v9ejwkb3yoKLZJQFA6oTlzS3Mj8um990f+C2fy pvHxTe7LUP4AHSCRLzN5BKJy8e3EvzmTf2a6QOjD/sE4xmjJqTA2WmlQwNo5+s0NR8UJ5xEc6LO/ smPyvBSfp6zj6CGXXdLSip+5Zm4HTX6oWyJcU0e54JlQ2eZA5Pv9l6KSsvE1YSON0EnNdhm0a+Os 45r49v/lvcAXvBcwkNL07wNeXgw8F7SyLvzLe4F/yXgAJujjIrtgbZaablAMyT00pEQxPnLa5py2 Yn0eKEtds2StuNCC5W8kfL/W8TU/uaZH5vx3aZEaMdXibLjma76nVkSmNtwwcXrkXYhtIWmuiViS SLLhTv3O6qAV8f7EOiwpO8ejRRTZgP6SgBwX6f0mheSOba9iOkn3QYHjlxs348xQh/hXGm+4hNyr uCSD5jHGWk8VZvlAJ8rikgvIipmqOKNn/tYDuc3xbc49Tev4PH0nM9U8SMYUOLbssuWA6Ao8vCXi KQ4SZGmuRlxseN/k/UN5aPeI2D8BPFfFrQplbmRzdHJlYW0KZW5kb2JqCjM0IDAgb2JqCjI2MDkK ZW5kb2JqCjM2IDAgb2JqCjw8Ci9MZW5ndGggMzcgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+ CnN0cmVhbQ0KeNrdWdlu20YUfddXEH2aASpmNg7JAH1wVLt1mq22UiRI+qDasqVCXiLZWRD033u3 IWlZRsUghdMiiGSSM3c5dzscvRs8Gg8e7NnMhtz4bHwysJmBfzYLxuexysrg8iobnw3eqLGGP9WB Hvrcq/0neujyWuGXLfKontPTHT20uVNP4cKrIV4UyugInyUsdAGekYAg0n7C7SY36e70/VwPAyyf 6gqkf9C/jx8PdseDX8Gu00ERTFY6k/mYDeH/cjo4GbxDDww83OhFUZjcZbEGCwN7YdGoGoxqJOcx y0uf5b7Ilms6WAXeihVYVdNd/F5X7TNr11TXdR4AP1MjjKT6GFwuwbMhgrPS4LdVV3jl1PxcI6oT ujRqfqGHCOo5whMQ9UfL+TEsseoUPh0LCep7fF7Cc1gf4eESQS5h4xU/nzUabQ1O/0yY01qjLpPs Ed1w6poWn9Ma3O8NXC41OFYmfZOjmbYgHqMTwAXQVoOoSQvmNpjEGvKAITnSNQRbLDonA07mpzqA L9dkyHLKSXScrD1jYycfOY5ztM/zXSMunKFdkL3qPaII5i2uCV1BPkdRuFqwX4IMuL1YPJ9gTGIS 9hTyttl0CZIjJC3B8BHcj+oFSscIVmCf7DnUNsEHj1I42axVT5TKKq8kaQ+1S/aCVHS5uUqyKRRW zekvNO9m5FZTLDDON8iFSsy+wDhjve2Rhh2Na5+A41F07rLgWv1Bej7hesSDEhbUXWEYopqDqzVg KZFcMsQlFDBpnXUzH5PaFXC9mFAR1K1RBKkDmCtqIv3wihDjyHgRClAYZRPjCdpbpqo7Qz21WM9Y xIQUV2muEbzvtjYBsApZDFCLUuwHGlHb5ezd0zZdBHWAmIK+Z5DmRo122XkLymjtwd6I0YvQMyOs D9gRnSrookDw0OYU0CPc5dlPn8rhgv1rkLa016Agv71TFeCaRQh3IdX6I2f8LsecU+Y3Kp6UOKgP q+ZzSpuTyWKFNnHLgpZSqb966AfNEeJopA4egh8VfILnlfoBdWA0P7PkDQWN0YaueqbR7Kfofkhh 5oKWkJxr6wF6KanlJ5ZcKseIGQa93t70Euw2EE3JR8nrCTbv0PZjy+JjD6lFFVPvfM5hWBzTRHjI lRnUg62l1WhfUYKjIvHuhhgAjE34YaV66IeE2wuAuQGR9xxMmS6srilZFtglLFteqF/SkBFPHj0m eHZhjVejMVfJkGyhi0K9psbwIqVhrzwqCgjBjX76moU+o3EjGnYwE5x6RZnMvYjMWOIIiQkh7mec +jhdLFOWPnVV+DovJT0E2R1iTa+4rtFvJ3U1GknJHVIfOYQLHyL8labjBJtWTXuCzFR+FJsZNO2J FnC1G2A1+DgKB4b95SGiFDFDpAvxMFoucQoWKVN4rF/1Q8cA/dvYddia0cE+dpUi5YJEaZ+6NqVT CXHtNT9CDcknLksrZnHMiI7pc340wWFhm7GKpVy1/XdGVdG0OggC5jtlv8Xsp8J3ia6d8Ky2t3c7 bGey6hJTshlPS6jJDm9EFMJNAvWwp9/AM4wMrSFPHtd0Asx6CmQIFZH2IWpYo5Wpu0nlzxJVk9Vi MaZlB5oOuwIYV5w/nQYJX28VcYrVW534AdEJoMeLBWVeQ0saqbTFdmkI0WEGdsKDqKGt7d5W5zmt BI1bYmgN1kmIsIshTHM5ZT1BkvcMCfAI69qQgA8GJynhSBSmM04l9WdtllDydIKCPWOWqEDqZ4gF QHJENGVTVLxEJXBUmrsCcROVhuR1osLOX+jQvkrE9VAJFeNXiQ5ari/3gjczxMzbpp8yw0qkVjhY uim0C7VXRG+JOmxNvrzr2k45cxcF45K8TcFcTwoWsCSrL6FgxCtv1fIX0bBgTDoIuCcWZr+Ehfmq aLr6gz77ItSFpBMTBLFYWhB4Hwp0uyfd8gVl6/+fbnngN6mHfQN0y+OBQPhm6ZYHvmPj/fEtVzfH fF+Xbrm7Zpwry9y7RLewqe5jWHB2eKJb+DnXeIhwJEc+OnCX5bdJ9HjFLcGkuzPaNeWeW6mTCygR qCwUbPkLuRedV37QBfEnesSHA6e4D+Fe4l3T6sCudE2iRdQVcZkVjwNDg65mNlfycUYypk7G1DIN L+Umz+AhXohfc4TWs3klWVT3oXKZi1bOiyAxx39uRV5s2dn2ZgPrK+q2G8y4PW+mfWaNYRQtwxBK UnPd8dFuIheOSdnasSZQDEo+5hg0XXowPwRbmF+iqpNVOii9i/OVvTmfg5aQOvnXIH3O24bx2aKk 94NE+QTC2JK9jQScoWya5tbxoOcdDm5DS81vxoLU3Y7FOZNP4TzN4XELtqnFjTWU+pM9yFgokHQi tZnp6ZqpnW3pXofoYUozz4MMCd8Qz3NAsdJJ173xPAt0Ov4HiZ4Fwub68zzrq+bU+J9O6Wg6GPUW cp4hqMmtMu2gM/H0ylVtSBB6K5a3ei6Cxac+toL6dLy8fvjXi4RaU+bh3+Cg5Jn8BiKvi+/IT65C /klHfiq50YmbHwzWuSnVcJecOjHgNW9kA3pyUz6t70tNX/JB0Gp+qtsuJl7yjwae4XK9qh46fXE/ 54B/A58PTL8KZW5kc3RyZWFtCmVuZG9iagozNyAwIG9iagoxOTM3CmVuZG9iagozOSAwIG9iago8 PAovTGVuZ3RoIDQwIDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0NCnja3Vlbb+PG FX7XryDy0hmgYjhXkgH60Dje5ra163WABE0faFuyVciyV5fNFkX/e89thpQso+ICRdpgsbZ5mZlz P993+H7y5fXk8zemML6sXHE9n5iign+m8JUrY1PU3pZNcf04+au61vCnutJTVzr1zfd6astW4S8T yqgu6Okf9dSUVr2FC6emeBFUpSP8rOFF6+EZbeBltz/h8qqs0t3Zh4Weenh9phvY/Rf9t+tvJ+fX k7+AXPeT4KuitlXhYjGF/+vZZD55jxpU8PCoFiFUpS1iCxJ61sKgUC38yjuXsShrV5QuFOuDM/gI vBUbkKqlu/j78GhXGHNwdNOWwRZ11aIZ6eh3oHIFioPhAlgKTXQNajr1wzs0TqzAjLconlM7eFqr 9VobS8aAJV6t6Oa2l/w/CuBBdbA5H/+VnobSqHM8IYowZ1ffaINOuuSHJFxUcBNOusA3a/XnUw9s 4cCmiHVTNmLsz3RLSpLGDyQ+6mJa8ACdaFW3xacGnsJ9DyEhIqw7kMGwPSytslUSMMDTlYa3a7Xp blkf2sapxRNuW4OtYAH+gapEdaeNk8MHhqSDF/OFRpPPeIM1yhFBDtgowuM5XtcgAr1uSQv2iKvg rfliTbbaaIPinewcU5myAWNFSKbIxhKDYEhgBsEBmCE/K7BhPv0J1UJNbrIxQZ+f9UgX+RoPp1NJ cHvEMlaVFJVw/cKBFlP2A2Zqq7rlDl3hk01atZ4NRZZQXmmoJ8nId8k7iw3+1cATfm1FVeGOfopI 88UrS+cjlQZzBkkFEW3Nnl8uMQdajvegukcdQL23qJ5PUjxjAAW2hFcfwUchOWyrUf5HDBesY20v +mZHSbbcciJdcKR+xxnQZOVrNe+WG5TBJi1LCqrPRqQ6qBYhTivJvKtz9tkbrCANJ72XuxFS2mPy n7MkBg4iza/enHH0RyzXqL2n2h3wwuEvi0erzQyrtUnFKqUeauAUJWDbJ6CBLTw0AdpirEaQJUHS 4wuNWfkFntyoP6R68E8OuuqFSy8wrh0707xwJhpBbLJiz0o1WP+Dd66VZYktXmN0/OtU0WtbhBp2 kFhDW5t08i8ofgVanLpXi/qHAHHmj4fuRYeKYvxhOTymJ/eYj6zfJZgjK/vIJe4dx4iE3ntKRI6Q HSWihPZeyZEymYP6y2819u9zDqQzKeJTbaSiOfUTL2QBzsfFQXBtWcdhF/2Jw5uNm1sqeNKqHyny MDN/4HKyWdxrDNdVr4CjGlMrx/ayo3pqABwj3hB7czP/kbOClcZbXp2d5XaLMQR93jgfuUZysUE5 WlrjIZ9a7G0zXsKdsQKBx9mqAuRkfz3E4VsIBP/fgBz2tdLuAXJUTYIclkFEAPkftJPANljSL3F3 ozqNib194AqFCRK48TtsZ/TwFkPeppUm7bdGd+MGBsNrRTmywXVhf92WD1pwCXnSiGuwIBpHmpLe d5oRCSqPHa7dW2Wh7+HG+IZxgksc+oR3Q1hi67TIkqbSmwPBEl1jNcOtsojbU60q4MRHkE2wyTUq FgiWGJQVYInsSccLLolQJNjiGEQAS6bet9gIkyp4e09ZwhiWOis64YGeZTU+MJhj2y7Z+LvsU3pF XDKjdBNpdrSLKL/KEiEMPNkCmOIecJKRVBKvbLgdJDFYlzuRGo9gtzUHxxL3Cdm1Yx3hTC5/YjdR bkH9WSyz5N0vqDNQjDqs3Vhf3gqEQks/k7QU0dgWsC5d5oZQM8Wz8rZj13lRVw7acsngg75j4B5e WGjeUaTKGolBieaSseNIOOCh49jmtwRwfFUlev3/hG9cE3KN/3zMuuCxXg/pTndPwCHTQsNi1WN2 BXSQ0lTgyBJT0p6OsyTRHNYw0UtQT/eRBwbifLm701TKH1PZG3Ahl9qn6wmUtLUVrxpwWuJLX+nQ 85vNliEisR5DIGBw/BMfv0pkWa7X3A1q9TXzXLn9nEKUgcVTkr1nWluWIQrogFJ7+4AJ5bM4p1sQ HAHQw8RUL43hioxh+zvtuJZY26Zgdokoso4CQEPP8DrcwvSrNosVFbB78u1SQgZA1hN33Z300qRY T2vFPjFZNQOttnepnN4zYNi7Pj4F8EKFF5uR8WXbPE176kF1VH+nw5OfJFV/n9hhh0JXyS4ADG80 9WCR7YMOYjyaSDwzkEPb5UCQOpZoKc8qsl17HrpmZCa+5zIiFx3S3OYFC99sucF0a+bQYneyswNP jYgeW9elkzT+lDgmTm3S3CTVbCD3VPGrxHb2Etqnuxw7OZ8vNQNDCom3jFFMrsEdN3cZnTxyP1hs Ngu8EZJfVqOUjyZPzcgfBtP5ICvjkLzEVF6CzLgkbF5JNdT2qDP9ILAkEFoaY9TDdpIvOjF12Eu7 3g9NOmWQdXOebeRiNcYuwJZSx9iL+4rivu3j/k6iFSczm1v2sXTLm+E86W6vdpqsXUNjRRo6pslg niWytbFGjezv1pnfElxBMpRmaL8SXnGfglcswKw0GTt9HvM6IDeNz1N9QdjMUT5qmxgcjVcc1SnH QxTUwzOnaRKHXLJWu8wgwpASHZBYG4RSON4lHjIqTPlIDLFmhtiwJwwN2AcMEUAHIHHMFED8EDEL BmNc11AVL/d69jqKkZvYps8OwlQI+PtEA57pINy6FemFZ2T5hkRS7MnS3bN5bL8xvpIJO9ELpEVx aCOfOFiyjtBpl7hMNrL3KMbXrPUzL/K8fbIFO2vP6GEojRcL3mo8jyntQIX6lbZ4zJixbGNhgsvT RCFZW6rPmWq9FoOZ/+3FYBD74HJn+hnCgEqHFATSB4TF+tAfk1djCNkXPkLVJbhPHmBZ32B5Gep7 9tT35zqDs2Z/ENlDO5vAtUDLIbbz+9ju8AtPrpsPpO3p2E6c5Jr8JWcf2/F8VkQYlmj6wuK9T5/I 4uALC7W0G84ZjjqiGILzDIGiPZyHzwbEAlNbMECTAUWbZ4vPw1Go4OwhZA49KMhftugp4rz+Smx+ P9JUkL7p89MhiMPIPYBs9ggHCxTTKKdAtiCDZflAsw/ZXA/ZaMeYwdqAUZ2qgseJvKnqNAIWHCnG Nj1mY6vepvncwez5ZPjW5JFwOILbCMkk3NaoqxmX0WdmmkPM5rD5nKHS9WsIuvd+Hu/Pn7hdrUfY x/sCeE7qt90NsZeXQVzR5MwM+DLCNhwRE2iwQ9jmXoVtUgRMmpgjSBsCt/rTgFsd84en/33o9m99 eCRcCmVuZHN0cmVhbQplbmRvYmoKNDAgMCBvYmoKMjQwNQplbmRvYmoKNDIgMCBvYmoKPDwKL0xl bmd0aCA0MyAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQp42u1ZW28TRxR+969Y 8TQr1cvcd7ZSH0LqoKAGqOMi2tIHJ96AJSeAnQBR1f/ec5v1JVyyRS20qhC2d+d2zndu35y8Htyb DO4emML4SrticjYwhYZ/pvDaVTEVtbdVKibng1/VpISfalwOXeXU4Q/l0FaNwi8Tqqge0eheOTSV VUfw4NQQH4LSZYTPGiZaD2O0gZfd7uNyXen8tn0zL4ceprdlgt3flr9NHgxGk8GPINfzQfC6qK0u XCyG8H/ZDs4Gr1EDDYPv1SIEXdkiNiChZy0MCtUou965ikVVu6JyoVjunMFH4KuYQKqG3uL37tGu MGbn6NRUwRa1bhBGOvpbACLBJ2ia1HeIh66M+h1+OITgEhG1ajkvDYC3WDwqARmnpudlgGlHiAsA hJO8egXoRTVCXby6KI0DyGi9Uctr3rkGHWGJUw6fUec/1jp/XPQaIKtTlQSyu33WaTB55HWPy2EA habPSyeSmwbEMCxW3WPXkCKYkTZ9hDpHtZjBphbA7LFJDaDYniqlGnwItBAobthoikaK6rz0APj7 bDTBh6DegT/HPOESHoJ6A+6gYeUQv8ZtWcOOrygqFtccZEcww6mXPGMGQzXv7QCFBkwtIydo4ACD gs29BwT4iMNvHyWsWQ4PMYnxKQ8/gxyWzWRg+m0hIccOrqlqMfQxiKZhN9L0IUBhstp76JpWPSUJ Qz45quUViBgznC9ItSeE6XRxVRrOALeXxxcBcovYSEDeoxz0FJE0oja+8mp/f8Q4HZcYFcfw4HyE X8uWEZsi1A2t8eoUkA4yFNWUJNa9hEOwNGQzuwlWhw8KOQE7OPXTMaIU0Z1O8TSnrgiX5bI0lgAh o13Qy8te6PgGHELg+T6bWzBAafbHh6VB1cUXxErwMntVDXa95YkNnJgKDwlES+K7Axi6rDKZnrWB tNfIIRfk+DP6nJ9OMUJ0dvYV4oL+fsnP7C5TlNjSO0grCSOISsgrGl1cc9aTIDHqDOfVFFRUYHIM wkPCILTWwbL5iqfVedmVoE2HyFtLm9kEwyeborBlZhyN4EYXoCjG7e1xg/LiIyDPsEl4X1Ee2RbB 3BABDzP58Gy6x/iIw+xnsw2QwaMbkHkl4MZs8x84ep7gcZh9CBE4qCbEPB5vnYeJJyRWl9XFNkvA AuRgc64w9dic4uaX7EiMvHgzZ7Wqp2/5ujISTgfkwNPFqs0AzS+oNGz40hB/tST+ti/l1DMVdEPn jZJR3w9uzgYbruYMHtZ5T64TtHITiABQMRApT2oZ+BlX8YoEuNMvv3g4Pifj8Yjj7ACzRsocgd9G ys4Q7yPW18BBlPLGB/ts8IhEDR3AE2sLXKsDDsLRatVyPpUEJUafo/9ToUL1OvAMbOFzue+rEchi vyxvin+FN3mtM1/uQ5tcCl2C5gIqAr/tQVRchECM/xOVbU9ywWPO+FqIigPelHPXV8hUHJTBfFX6 EkzFAVMy8e9gKvZD1cQ23RX3GbAA9sI9zunojhCZaomWwlLsAO6W3bhB9hC4/KPHLHCOpTlYbYY+ YBY5ZDkvaOUMPQYqFM6kJIphI8svW7IilhBnOa1hJX1ROjqCw1Fq9TiXNEuhaJDDLHhTKkboyi9L fEs0oYYfRyXnOqyQb8rA1QhVxPSNeX+1Jky4kFWVE8P2bg1EMiqJUrlONbrf+52X/SxRQ2qxmfx4 2ODTUmRsdqQg2DURIJPYnkwKHDEgnLvEV2hN45hkIkAdChPcwCMdQoiIDiG8czbytpUssSKL60+y 9bEr0hlR3GcTmhWz1fMSjSO7ymayqBXORi5T9UQymu76vsd1LWWqRHCJt5AUxOK8d8yHP+LR6PUi LKuRoWQPOmVy3PmqIXJjBVVn2JKG8mh2Hy6/ZCIx2QWbMGz42A3rCp5tyeULxzbc3zIn6QxlzRrb JUi67TJi+HP80luWcJuW8OI7FU5o+tIZC2k7F6H/BkEDe/772JkFdqb9VnfK5O4kmn1IlxfmNoZ8 OvXY3STf9frWbSrC2vRggw020AxwOfuZVO4Dtw/2Bdl14zYcqS40TPSM3KdDvuTgKq+uOWdiucXr j9x0pe5u0jm/RecCIdu1AD6Hzpngui5eDzon9tin8RoObYTjUQ+C+RWTm/HhQyo99/ne69Qzxerx aah6Ur+MsL6jFjCKYerZgfj2xp/sQJHd9VnJAsB3HzpkXMKmwNfKFg2k2pS+HFs0uq7+2bYWcMWc QCQzH6IWkZiGw1o6nUnbR7osNIlC0OTugwYKY8z6XrRkQhPXTSfj1i2flKd1LaxPtXxIDjSB3W35 sDArLrnNVs/H3ez5RLkASs/Hw8HG9bnxGG3QP+rY/U2ga4x0baJarSjjxK3M1DX7WnYovlR+k/sr kramDOM7XjHHmsLexS09h3MWLf/Fh896Tr2h7jonhfCMG3i75jhkBxXv4ewYmflttgq5jHYDOdWg yUO+wYpfTtbI/QnRksAjCmVuZHN0cmVhbQplbmRvYmoKNDMgMCBvYmoKMTg1MgplbmRvYmoKNDUg MCBvYmoKPDwKL0xlbmd0aCA0NiAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQp4 2t1ZW2/b2BF+168g8tJDoOLyXEkW6IPtOo0X9sZ11MW2TR8UXWy18mUlxU1Q9L93riQl2625QNFu sdhIpMg5M998M/Od4x9Hx5PRN29tZkNR+myyHNmshP9sFkpfpDqrgivqbHI7+pOZ5PDVXOVjX3hz dp6PXdEY/LCxSOY9/XqUj23hzAVceDPGi2jKPMG/FTzoAvxGBoJY+y2+Xhal3l08rvJxgMcXeQ3W /5b/efLt6HQy+h34dT2KocwqV2Y+ZWP4f7MYLUc/YgQl/PhsFDGWhctSAx4GjsKiU43xneUiZUXl s8LHbHOwBi+Bt1INXjV0Fz8Pl/aZtQdL29JlVdkgiLTw9C73EOgccYgQ4VluHXxc5uNYWPOYR4Aj wI/eFZVZbRGYCr7hLYcev0fHkzmZIPCVOc0bAJMuoinQVjJvuqD+tW91U0SEBfLBzl2dsqG3aKgG 47BWkLvJfJcDruYEr2wDzr7hxF69PcE7CZ6oMGsBnMVUR7zw+OFwZbNdYHKtmeFr3uzQqDer3OLV PcbfmDuGpYL8JDBkXxtJFSiSqi5qSfCvcLEGPhIE8msEtITLv6vvtLozG1geVl+v309zIGAyt/k4 ga8X8JoH9pGLDzlGL2Dc5Qi7vv4V/S3hhmvZTYn7h67zzasjAPfh1SiZQKwtOxCA/2PkzOttQV5T loA4paDxcrgBvL3gtMlqHK5QakN8rc0Wn3cID6ZJkiZWL7hWd1CriRjcMIzWXFHKI5mszBrfCuYr ZwaID48/aB0Qrytz/G2ODUDAPsFVK/VlTM7LxR9gNadlczqQ8aVFgAiZD+BaCdbIKKMuKxzl1sMS P5CHEb69WHpErQ85lucE3PLm6gwtNdTXHN74aDg8Xg1Dr80fIcgQMQr4FbkSEEeHVQxP8r9YBskk rqSPOTsAn68PN2SxTlrfkugj6ss/cDkiqo5uAd4np7wEB/MBLnxI8G2z4FqfznNs9/hOgEJukCEL fmVKbCiBRYNyESvIsOvnooXfUbYRvt9/QCATMla6x2di1GbD3VOYq7U5CB1MrVTJb5RNggF6c3J1 hrRtO/SEe+EZpUdI+92zK7qnKzawYp1F3xSV0O8Nzb8zKppLDBIhneaY7nmOZTKnprvBxCG2GO2W i2rLI8Ga5T287vEZbD4BemkAm5/p9Z3avM8t9tUlXlfwwycqa1wJceOVaDTjSIJIy86dI571c3qD vWr9sVithw5N0EBEUYCp+h57IT69Yhq3j+3wd4ut3zlQGeLS4rVgWqjiGtAEn4NKE1g3qHOMIse2 zSv44ZbFyorrbAf0TWa3IC5zWAW6ghCLpRvxiHpUDe9XLWZfiB1kyqJhLCWEvKJVYCZE6HcULyeN /bjGW5VGfsOIp34Gne1nAIgCHXUcuQmwAljRqBEUS1QyuEri7Nea6Bl2YMcrOfIh6MX29QhDfZag wKQ+X2ALQnP5SK0zdE4SxuKlU0lTCzlneeiw323zRH0Pi+AjWB3WQUIDHAw/cwEjoYCAKev/Cy0W Erj5s5ViASB0kghq/M5Mr0mZLNhco3VXD7FalrqLEi2xxr7jhio7n8CB9NOVHY7UL3jLCrpipKfd SpEAO35siuKuoqlbc1E38Ehfs0XOSmzlkao1XEzk1WUeKXuDasLHgENzqFiTOb3Bnpw0wBtizPfk 2XT9Obe8xxyiFzwMb/u/K6c8TtLw35NTHsaFTf8JOeVfklOuac8mpAse8WmEM8f3VAX3zOj1gjf9 0ztWJNEs11At4MU1tzqLfbESuviSvtSkneCStzhcbJ/3W8EnAuorz7qg3ZTJtuC2VCpZeNdwyUKj 0r0T47/eMVQr3jaUgGAkEzWKLDJbmxUfICg/Vvcstu5eCxoOdVdVhRcSM/R3VNkrdWCKSWrL5p53 cxseLbqLkR+pNdSv5ykkzafMJdtu1QWZ6eyGXKEAfQecZG/DyrVq0xcUPI7gmI9Kou49p3dUW9S2 hdKxC6GLDLWnLOrMnGGYMbpJnbD9BhIZe+AH+Iw4WUFPHH2SflJ2w9CBLqE9T9BhJj7iRc0S0+sB katJPLfLBY1GaO3UpQ1nlbb0lrf0Xts9p76SdcTOnIwWA+vRW1EwORaHmFLFsdOi4eOCtrSW0zWV ohw0LFQm7NVWfAou2RIiSKeR4mqeoTYgNkXdHw5YlQ44zWmVq/0Sjn2i2iC/g8WhMEGH0tMe6dE3 OMSixl73h7MeDd7qZknS9gzLA2nzEiWXFC5j+JcFN5BW89W6jcBZvhK55/tUT32I0ReZ8YJw3eL1 iXrSWjyH4UpUa7pQuMExCfD0cxhUoJv0JEv9hALngve9gkfbnO627qjeQbOs+ChJ2U6N32v64wuN nmk2Fc5GqQdl9IzHCUkvByBb3/04V/G8pP5cdZ3nnHXjMfqDKR6EhK1De5Ksw4hHGA/rfk1b6A4c dlS2t5K+Q3GObqeudyEMlhS0cOpkecsRPBHi7cFcL/14sEW7aAyVRJntOPbQh68FBPYsFZ8wBNpo RN46xoHIgCaWauq1EJJV495ZZbfF2cPDUmyWV/4lE6tWPfLQVgK6zXAfmsOuLNaSlt2Se7Pr2PRc eQuGrfbm8r7o/v4BTNvyxp0y4jsDq+1AjKJvz9pW89bW4VZKgprJomsdvHs10pM5RKC2YZ8TefaE F+f9ExXmdPZXfBIX2CMUx+j7MVLPFQe/0LSY6WkGQfbQOg3FWe/3LR3RkaMJKumq4aD5GkcygbZc bajzkxZzZQdCrwj7Z+UvDFbftQc52t8/UL9hgVNTiyMGCUlUPJ8zUc91j/uuywFCOKdy7NUZTbh3 3KDanIgHvO2Qu9ymOYzdQJxwINSKk2xw1nMOxbNyaWjXpUVAc6VXK1BzDmuQD4pkss21qFqIkAi/ yOXckRuLbpralnj4R4t/nwiRTMIwMNjom1b5dsf1K/OY/HGC1fVArMpKzyyHZ0W2Jt3NrnClVIMS RyRfN7IQEEuFU3c9UCczVmXs/c1RUWVfVFo+UpM+hG+5yfksd0+e7o3RxTCMYFenM3/el9ISg4bM m4X93VAyd1pBV8cb6nS4x/PdUGhbfG9r43TnRwe/e/ryXR+wB7V9cs9nrM+kpzoAniVj0n6uvJ0O g6RK7Z+t9vjBKVyurulEhA9p9Ihhrt7esrPTL6xapJxu+wxrp88jnz9zsbYtuuCJXf6EE7tJv4sf 7GjwladnTk5yyvGk/qH1PwEsAepKCmVuZHN0cmVhbQplbmRvYmoKNDYgMCBvYmoKMjQxNgplbmRv YmoKNDggMCBvYmoKPDwKL0xlbmd0aCA0OSAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtDQp42u1ZW2/c1hF+169Y9IkEugzPlWSAPEiqXCu1YkdSiwRNHui9SNuuZGV37dgI+t8z10Ny tQJEvQQoAsOSeDtn5pvbN3N+OTq5PvrqlZkYX5Rucr08MpMS/pmJL10R60nlbVFPru+O/p1d5/Bn dplPXeGy8zf51BZNhr9MKGL2lp4e51NT2OwCLlw2xYuQlXmEnxW8aD08owW8rPZ3/LwsSr27+LTK px5eX+Q1rP5r/vP1t0dn10ffg1w3R8GXk8qWExcnU/i/WRwtj35BDUp4eFCLEMrCTmIDEnrWwqBQ Tea7lYs4KSo3KVyYbPb24C3wVqxBqobu4u/9rd3EmL2tm6bwgF/ZIIy09RWoXGY7BM5kbY5f6NVH eFRlW8SogcsV/VUDrBt8rQI44DWfbRcIk6GvTAP47QCmkH2AS4eovaIdjnN89w3AHmXPM164yd7T Pl/wfbTQ6j7H5VY7BCVmq3aXN2AiWC/CVxvcJcL7v/Kut/QxieKye1wywPW63eZgwqYT6gJ2dqrZ pzzArbsO7uegFhvwFAaNoDAVbEQL2mzTotAIFuxqYOVpgM1ZBQYkKlxzErjIEcG/PFeCuikCuExV F7W4zCXCR+ga9Nkz3MnL3Zh9l4PTZadnrL2BjcjrL1+dMnwRXd/DB57iIOCFw1+WHEBNOsPPBDUw DJrdoSFQuYS1gSU8ujAuMUYjP4kRwjayQn/DZQ0rEsVp/pXjhuo6uB8a8Td1nGW73qJMlrB1JeDw v5GI+qqoJRK+Bj1q+Ama19k3uAea8jdeuUyWXpFM6/VbNLXL2rscxb5gOMXGDzkaQWxynxsHGIvr bb7wylVmGbEGrzH6ny16BXJDpARxxq/GfFeCGwjg6CNGJaZoKlF7DMIAXgpCJ5/dzjhBifIP5MIC SOcVGJ7342Iq1FFjSlz0mHO3zU4+gHyVrrtesAQtup3BtLJcQ7YCBW7YDw06bQUi79hgcT8Nqf0+ 5k4MZYbJx6KxxNW7rGLR9mLdM0pE7/AuPr7gqsBpcq3pipNkCf4caIka8aNla05tZdbSZZmtKJTC E6DZx6AZMB+4a6jAfwS2cxQCoxG9luqUzTBhRr7AnO45hBEsxLShHOrQrlcgI3h2m2P13IG6PgS4 fZGjwwK8eDHLUclbuNXokpzrFgx8nbGh0qK4oef0gF/yYiRmnZ0wdh4zJFZqFu6eFufvbvBFdDz0 wg2bJbD4VAOsQbRXHDus9ZySneg+Q39xsphovWCfKnWZW5K/zdUtIJmEniisEaTtW6IDKsozbSSO DUBaSdWIQCSjVFB5pkhM7tizgkq9ZUUtuKOTLWMf7Zrd3JJxSadNZ10vAG7B/x0jWytC8rYozqpA bKN6xQiNIEkHB/JHZV1TdI3bzumMqmBYxUrwXPPDj6KW2GGodVKGxdsK66KsT/W75rDueUCE3E82 WqeVHBE0cslGYPyyh9ltkoL8lj3zjPPOO93oHMUvU0Bhedyt8J59HEq1emhFoWT6oWRtRZkDbc9W ItdU7xsYlxUvRubOEtioTQaxFKVGYaBqeJD0gGSOXRATKyRUCsSbXL8kjjK1JboUZV8jSfI/C3at xApqthbGT4m5jXB1mmlvyYlTomVZemhbS9SI3m3fU2Jci+QQv8Qxm04VIaMLrlPzcVD5BjxKolHl xNghEucYCpO1nJ3vJeqpEAjdrLPtCut9pbCtqPrwczB0eKLacB1phYUGIX+HqiqGvnHdw7nSq+UH jqdEfN9wZJ+gPGjicUgAhSyF8CTuSnX0Xtg+sRpBZLVltUNX3kWqDkVhCvICw2AobMSnTpd3rAF7 gADLHEL8tmd+Q5kJ1kZVj3Ft0/nYQx++BAiw2oobQE9UNHBOCCORieCuDAyBYHWfPgl+THd6JNgx CbbZX9mxaug/p5gbHlIkoNgM9/5ymExktahht2QuYTtvOhTegiGGd9OF90XXsoKnbTl7kkVctwD0 MeMwArpstAeap7WoAj2mhDPZdM0xUg1jpMe1EtV0JXXvkd7qsT+2+3sKzHb2X3wTNxg4FOvo+joS dxMBP1MPNtM6SJB1PFb61l7eaoVHBtbGK6+sxoMGsmrhXK421PgRIQTxEgi9IKzV/zTV7NiLGD3R NqUHIe4CeVKBSHJNKY48SJzk8hzfC5xDLPVUDjF43aP7AOGcwrEXZxaZ9WtOUMkmIsEsb7oEwWma 1diNxAmC2daK04ILxXrOqjikFchd2/XHVKmorvRiBWLOQgw+l0xH6v362/bZ1FwJ7IpmFkJEqsPc pVS6smH20Oe1j2mZMvRET5mVPRMtW0E1jwO5qa9IAbdZ5A0PIaJaMXAXGlOE8gc3Iy1Uljp3G+8L 0pV1N7t0IQnCq7u6/QkTT1UeaKWUeZUPYC4IvZHMZsGdGMsiS6w+UWnYj57lJu+4nOTOali8F+Mw cnVIVGPen02JEkMDDDvBmN1r4F6ebCjBYn/rulqUKot4fYrNHT/v+laKjdd9xB507dMPTEQP2Kfa Q76dQXamxEBlROtwOxKTCMJIBhx4CBtxubrJvcwbazFfyOYq7h1L235mtiSZ7q7vY6nqfZLwoySR SkPBTOHADKdFoyQu/IigRM6bWj1kDMCJGB2q1C+vciPDRpS0Nz+N2chq4YLHX3/OZsehBs2p+aOG s5WdOPQ+P34eZ5t0kvGWIV3PKd6fv0iDAz1bQY2xQ1r/2Mm9Dq32BpXXOebcz4x/zxi2I5WRjkMa bYy8cpTh8Et0+IcmE+G/J99Kp93AyqfXPKKekni89Y9co95xm302boZro0lTcfZeWY4HnMJ8qJWw 2Q/khUEZUeR5YBymfB47YxIxzKHHzLStjymABexjOnn6gYNiSs0eh9zpqYy7OX9cwYWDz5uUBNs5 def4jZfUqeVNS8diJFrO9KFK6NhkjH9eUftVKl12YuTNBo8awj7jH4WNCWlsPZz3szSnyk/f8UOx 0TnFozjTd+MygwXOUvrBiJmX47o3p5+rWYtpwHTOTWTP9cfBsWubhGBtERdDzo95zO61bebx19SQ yFsPgwn7ga7QD6vk1+P0NrVPZ3xTzst2MAMnQ3pf07HnFHfYIw+Hx9voigqborXLKx1uG/JLqtNp uC11PHWk5HG9do3ovaz1U8b7bH/KVQ7tcNZrHaq9H0fMTAlBCHS/0aMG3aRHoqhsSecntbRK+9Rd wrynV0g4OhWSmpJqnO1yychxngkuDfWnqukSmmdDE5A0kSAPlMDotc7dOcXQZNXTJmv6LBRfWcmo SUzWDEzm90xmVemnTGbUZJFGG5baBd813B2+opSSlR6K5mUHpcbV6Vzx/+Kg1OCwtH7JQSlp9Sju X3RYakro0f6Ys1LHoJUvOSsFilW+gJpV8cmTUu44h7NcDlDtwHmi+5BaKwyGXovHvScfXe9z58EJ pPL6kKY/NXUjU24Mkja/A7jSfvwKZW5kc3RyZWFtCmVuZG9iago0OSAwIG9iagoyNTgwCmVuZG9i ago1MSAwIG9iago8PAovTGVuZ3RoIDUyIDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJl YW0NCnja5Vhbb1NHEH73rzjiaY9UH/Z+idQHSB0URAI4RgKVPjjBCZYcEpwEiKr+985l9/gSAz4C FdoKYcfn7M7OzDcz38y+7z0c9e7vqUrZRppqdNpTlYR/qrLSND5WweomVqPz3u9iVMOfYlj3TWPE /pO6r5sk8Eu5xoun9PZB3VeNFgfww4g+/nBC1h4+AyzUFt6RAJulPcLtspHl6eTDtO5bWD6pI0j/ WP8xetwbjHrPQa+znrOyClpWxld9+D+f9E5779ECCS83WuGcbHTlE2ho2QqFSiXhFpIbXzXBVI1x 1XztDD4CH/kIWiV6it/rR5tKqbWjg66CTOhDOvf+4sAv74upsaAxuIo3/lb3XaPEAPX24gjcJsXu cL9W6Ntn/HKEYHgBD5sASPTx63DbAxMcGCsfYhOzj+5t3KrvblUQJKtb9xG+JN7V8EK8gc8kpoC/ Fyd13wP649oCzNeoogKQNdhwBcobxOSag+ct7Z1gZKCoOUrktRbXYpjc0JIZv4FtWgZYeQGyozjF QAtFnFoSpx38wYsuSTM+nw6Qq5pRFOq8+B2HritP299LCofFCacXtYPon4HZgT49ycFoBrACSzHZ RWe4C5OFXnrQArJJi1tc48VORww9pKZnIProP/Q4uge+5ugzR1rCaTt4LMbTFNXQgBRm4/RkfM2R RMsYGhWLEAOW6mypSmDQAefqDT2dXXNmTfs1fqFEX467uuZqkU8bl6UYxAa8A6YncqtCfx+UEsA6 XNUJvsZnWf8IKL0WXFquXtcYPBI2fcTIkGI6mzH+UhzXypAKW/pQSYuZZ0MTc87yMQgfxK7CQEGX BnIDQIXe0RF+H2e3oGqktQVjcElRT4Inocyp4g9+m5FpOoJswCt6ATLZejqe1Ri3dIwuSnwZ5fB1 lDWqTnBYQtlnlD2jHLPEJZQJAzzNbEDZw8uNKFtG2TLKhlzpWve3KKc1lD1FDaGcpV+X0DxubaDo WHY/gxPYWgXuxzPubQsClHWvwOW2Y1mHfS76UtSpbms21y4SSnFpSF2EOhCUlXnK/pq9IbS3Vw3y y1fOpCbk4lFqBkCHlWz2dIz+8+Ic6lgoAZGdeUlxMQLEjPjELj2AomeKkA81Jvc543NEteEEsG4h uyxpSjH0hD0wpYqhETMyKoqHjyn/B5z4uyOOYIhCPGPEgfyqxih+Vghze8KFfHIas5+sZ459xTIP a1sI1kF7o9CzL6nUI4DZ40WdARjG2lC0srXsmuH+IZHAo059gJPQBuWYyW5/QL3VS0wEhfbDgQ+I G3d32x5B0eF9ZSymyHzCThtjtibaYwkDl195wRVBbl8s2Wk2QfiueK11FCrJlr84olyV3ARgQDFh zOcInltPyi7usdB5yPiP9knWg4TSJiUykiz+OjWGZWoMG4sm9kdKLUj7bunU2CQMj8mAnJ4s7oy2 twVvY6ItlcQkZiQ8ZW6O4hdmASk0rsAnJbgx90OxM/t3tD2rQpgAp6ocxavpPmcC89j/I39x2SbD bCYXNKwlzo7FOkcpdJelsg0HbMYexl5ka2x+6inZIWoGjKKCgyhxhnu7TP0exxhMQkszjeNi5fCl QpKfcFbmMM90erfL0dgGKhBhS8XvahF2djnud0BORKrHdvLXUjX/LI3HnVKOaAI5n9eOKvXdUp59 QsTqCkvOb1lyEIY1NtxbJPFXB7KyUjaxO3Ga6Noyw/U4K5zbgY5MZ5zFTP6/Mp0Boi/Z+BNRndGm HdJ/QqozwMTK/ziq06m9iPm+TKc/x3Q6hMboQnVYLUco265O1Eh1hphOWZp3y0zejtGGYDD5NmBC SURzPBaXVAZilQfitTF8MT23U/eQA/CYls9RUCqT+ZsyU9ucZ6TgEc7UqdxAlAsASzGQl8x4P5/X KkeEGMrczmP+lMb6kxpPeNvRoV619yT50oFvIN6TZ26WbktWXl9xqVULZr5AiwJbZJZvU8BzV3yj oOiOIy7uOFDEF5yH+BCCrfdQWoOmy670pCEXS4H9bxCuNurfx7Z4MVtuCrrQrYq2vbb8zKCqWS1J Lt3pItunMgN/07SqTGyvurpz+B7VzBnGiS3snHuJ3VM2NVf3MWZKu7RtnnNFXaPqlUaZi9534GsF 2VxupLbja4+3VUeYcKno9py/XuSfOe9QYcpJrdPCqj2+W7GFRMixChzLA0NeRTGdb4dMuUriGQPd qza5V7XuHdDs9I5opeB324kQlQzNt7YLTMRLd0ewhXGjOUzl/u2E73kXV1VUbabHNJnMOjYSwOPy B47MwWP6fK8+4m+XuXrqCmVuZHN0cmVhbQplbmRvYmoKNTIgMCBvYmoKMTcyMQplbmRvYmoKNTQg MCBvYmoKPDwKL0xlbmd0aCA1NSAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQp4 2u1ZWW/bRhB+168g+rQEKoZ7kuxbo8ZFijqHowAJij4otmSrUJxUcuoYRf9759rlIdkV2yJAgSJI FFK7s3N8M/Pt6NfJ4/nk0YnOtCtKm81XE52V8EdnrrRFqLPKmaLO5u8nP6l5Dv9VZ/nUFlY9/TGf mqJR+KF9EdRz+vbbfKoLo07hwaopPnhV5gH+rWChcfAdCXAi7XvcXhZlfLv8bZ1PHSxf5jVIv81/ nv8weTKfvAS9LifelVllysyGbAp/t8vJavIrWlDClwet8L4sTBYa0NCxFRqValRoJRchKyqbFdZn 28EZfAS+CjVo1dBb/BwebTOtB0c3TeHAf2WDbqSjv8ob8MocHefVFdhfqfUO3VLD8w2+tmrxLrfg js0SHQMS1Po6R3+fs2M3n+DJqAtyHq6BFSSiKTSsaUDQh3waQMI1yV+tL3PwifpET9tFrmGdHLWG lR42XONRDuTRTq3e0dpfSHolQmmLaY9aoPgG9EhbHaz9SDuXLP7QYUHU2rXef9iJusToAWzYg6tc oxfExC2eHkCcnHGVjrcl6ESODmq7Bj2s2mx4tQOkgisrgCruOUWLEBBnJyi7VjMOiEPAOvhwhF4v /04RwcWx2jMEQoAABjbgCafEAs/SMahXeKTH+HzIMSC3aIHm2NM3urVQW0oOMXEAGpTqlECnUdsl W8ph4SevdktMNQORAFlhP7Jsv1bgD5AhMsXjqJkpYde9UNMEtRqif4PHaQl8BYvGOc1VRV33nMbH iL5b1CuoO/QEumCIjHGHgQgvEBP5V+wd8XRDGZegvaKk9DEBUxacIj4C6NuAhBdotwawgMsQpJ28 D2qN6vrW63JqN/vhWCt5u8uhRho+rrOpb7OkOH5Z4QlcN7hSrM8l6LuCs8CDOjWZGQsJWblag1/x wJuRDtRVUbqBA1kdrVu/LRnYZVe5ipSryEqyq1SLrUC43M9sAjZt133bdOsXqWMrXF7B7j0hBjvO Kef3QmJ5A/4IMaIMtQUfQ1lq243f5VjIxOvv+SNK+XqE36AmhBJQIKUh6vMMsshGRcSZX7MpNatU EuIManEKdcnGBHmBb02vLACIG4ITljYKPoDD9XtQG/1DeLph61ONIkPbDoSV8jML8NzNdBWz1A3j tsNKVEbbxK/rFRZofBwFOV+H2BVOSOp+pbLolCMqVdunNCembdeL1ZzS13nyrlbbOwZEFfGWFncy IHSMF5humNpI7b9pMwPU7FcSN6wkRzqoMpmvQDFxz6Mx+7wvjOu6dS3RLe/pstxcFpcEfwEH1/6G nen2nLkQ0lMz4nRcsKEQNtGftznWsd03Y9S3TVFJPj2jGAvWbtH3pTpaVg0YyzzwVfHFdxwCSrSg XpFnZmdPuYpLfIRvPKUKKiTj2UhQlwAN8z9b/Ads0TVwj3D/YbroAqjxP1sc5zNgi9r8fbY4dc63 xXgAjAup4xhlZn6VPEkb9lyu/UPEL3RTmFr5gRTuUj7kRHXLifqVssf1fL8nCx+y2O7HORFQFItn Kjt9BHX4IbgM21jPZQCaRngqLd/jaR2aB11iSymfeNUh7zcHbWOup+vYqBPXM/cQRonPYs046GBD x9Z7mPKNYnMO6oWpew2DK90eSRQIDClfHcmqpjWQWFWX8WmUNYSasSkv3YHUZhwITvZoH/l9JTn3 qcvYRY0+7dP9ViLMIAxB3fK+cfgryzhqIqKoJcuk7jFPpN6G+AlqtWFV+9WmiusTK8PkG5Qbrt2J pnRam7C9aYRJkItBZHthwPZCr9h2LoyJ7jGhlFgIsFCmj+8u4rGHq8jx7MfWPrW+MaTPeof+P0j6 9umdvd9vvcUJX4aaoT6okDmsENA43d7HsUpgjUbFSNYGHzR/GGjQ6NJFjqn0nqeSpznHAtH+Mcc7 0AkBSjZ+yDWqe8skY8YvVxyoS77DP8XvsFlZ6gAogsWBZ7SvPKx8fU2vdzneqNYshHZXso038GYL igdwxRQzHZO7KhGkvzOfqHpmmgNmWjLTkZm2a6anY8K+mYaKTw1WYmubsf9Wl6RH6pGWSzgfHWD1 Hd8hDc5Jmen8cXwWZ9ZYGbSqaT7/5SjOpqvOtjQ+kKr8mcvQTcRSZMBBOnGISVRgQ0LXMBEZ3FrM sOY9COsOiUl5Xid6Ze8R2ZsQ7bBKIbXgmvUx71zLh1dM3DYmzU2TRvJUJAzb0aFyAjMzRmhVFVZS 7jmXv83F0fsbnGKYAEW1H8VEpp8vcIQVALiYHlLbxB9CzuaphRmZWTAfEv79+AeK1RO6Fc2EU01z jcdIX3vLL18QLX4y4qrnwX4XUg3k691bFsrXSDnhWyzyRr0haofoeIUKNDGfXvLHa3l8RpepGVpe 4xJsW02054TpoevdO3S6A8uqxfscy1DXYYnN7hNdGkqMueHCxaE3fOJLzhvuXOBcOAxfOTWbpasv avcKHix4rJHTBcui31QKstxaGroBUE+Od9CdjH7e5TIRGRcrqN5xXMuxSuExdGVGHvX6FTm4jIdH Yr3dYsh8f9J3M85rQFTKLzsY0LX7Ej8j6ZqYB+YPV8O6ZYARp3xR57AmtnO25N/vuK4K/7zjFuJG jgpoZnlx/J1f4w8FOjRxHChg/JjGbzJe0PG6YvbmCwcuWXrsjwja2zRyu+dHBInZYMTgY8HtjBgQ RmcnM14QeLhgabjg4ljB87uRlzyNA+L6vzReoBF+bHTSoq/iJCmB8hyrbEeZM0AXz6d9BOUdW9Kj 9+2EIE1z+TpUjw5/WRXu3/8JCa93fu8SmMxmorlbnLM7/w2GIQkFJCPWuFGlxrcDDBq5puv+A79W +agxD9iHd/2REK9C+k3liDEGBt2NHmOE7q9V3TGGPjDGOPiLV3eMYf5qjJHs/xM20jReCmVuZHN0 cmVhbQplbmRvYmoKNTUgMCBvYmoKMjE2MQplbmRvYmoKNTcgMCBvYmoKPDwKL0xlbmd0aCA1OCAw IFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQp42u1aS3PcVBbe969QZSVV0eK+de9U zSKYhPFUjIPxsJmwaNvdcVNtx8htPClm/vuc19WrQ7AIsKKo2O6WdO55fOc7D/Hj4ovzxecvdaFd rWxxvlnoQsF/unDK1iEWjTN1LM5vFv8uzyv4szyrlra25fGramnqVOIv7etQntLV59VS16Y8gQ+2 XOIHX6oqwM8GbjQOrpEAJ9K+wsdVrfK365+21dLB7esqgvTH6vvzfy5enC++Ab3eLrxTRWNUYUOx hH/terFZ/IgWKLj4QSu8V7UpQgINHVuhUakE6nSS61DUjS1q64t2cgYfgV+FCFol+hZ/T4+2hdaT o1Oq4e5GJXQjHX2Cprlytb2tLJi4Rw8asBR++fIW/NGUK7yky8sqkQ+Wxirw0peVh2vvKgd/31TL AP5abSs4Mchjn/XWPEWpkCAQY52+BuGWdXFZs88wOA2cSVqp8gpDiLE+gYja8gWH9zV+i7Gkp2y5 uqi0BQ/v1ng9lvc13tBQyMnSa1JZjEvlBg0xYB3Z9UAX2z0+a+FWOrEpyWUGNMCDEBuu/A8L8OX2 nvVsWAM3OEAnOOD+Dj6rbNslS95uwIH08emec7EITayjy/lA5rTkHbCzAiCbcnW5RyjrkgJks123 2ZJjOLbpDCGVOIakvBbFrBjZsu88i9G9GHH2Nfo69M68X/PhOz58zXeJzXsQ6fN3V1nSNJgejKhn esUBSgTk31YaeUHMvgFYNT2QH1m7dos3mYwzQAzCaycR64y9IL/8QAo3khNoQygx4ibBM1txiO4d gvcSJEzsIZGPQLe4Xp9VC77W9NkgC3VeRiFy83u8mYB9RzLu+CKZoNi1YxNAskXF5rkQjvCSk332 gyBOBWYNYtCUw7lC/bSEXJFPdARd3pR4HbhEnBAJbU1Gm+BUFG8ZbRdDPHbQ4GS8pWsjxAosQ/68 urzmOhAnscOz/Cj1TI7Umwo/hlnchY6CTFeSgWNe8uUK0RF7YsUMEr6863PM9K4SVd7NVEFBqgRW 4bFCghQvDhid4PQTZhNw9e6hsr2zutM37/B6JG/q0KuHGA6kvkf1jcWCSOHXLjOlPiQ7iQtJyhAB cDRICzlfJAG3ux3fqSRQXUZs35Kqt8grTc7ids2hYhzVxGDPnuqzmBDYPoZccs5eMHG+xAyKzDxO vg0lFiJVHuG3vkGVn0E2QNfwkjL1iCGN7QQ2FY5+eqxhhn/Z2Yo1qm5Es7+BuAg/l8jnf+co6vJn 9o3K4ZFg73aniG5w8k2FBCSVVCJxx9GKpWX6iOX/nqoXaONtqhtB2OdzngN+kNxAP+qszSMqgfz+ a0xgKFFiV4wIoQKHgJ5xAVECFJPg8ikXDaHL93xIJBGB6cmUb6mhofrtMEGp+2K5vi9nmcfNNAek hkui9pW/TwDgkacH3BVeQWMp8f4StdCMwACVCwn96OwYFZdSqLnKBynbp8ysX3/wRPNLfOES2C5h eUbuPUfZmLsayyO1vJqTVLNhVFOoJcPCAs0U37JmLyV+xGBcHGc71vAdJwCSDXYYjpoezDSRrNAm PAAlg6evcz93ztFo+RAInKceFISa/sgzLsMoEeHNWiHXUNwxyNygXtDBPzBJrRE4LisohnWGsh63 JOvqqT7VyhQO2jAlDQeemkQhNrfFBE7ivz0gNWZ/sYZ84D3DNSENeyy0cIsTrGlCoJWCp/GAzkch i9PZ4Tu2JwE8kMmeM8ee8JOaHReB7ghefG/AeQjpIjPYgMdmNl8Omi8tgJYuTjqDy2yIJFmLhvpM Bu5DzZO2w7mj7+gnzRPlJFeFRkorf/LSjphMGYOKaxKFnHp1mzvNzAjXmS8l39rVZd87kDJnFEiu incjxmlyBt8Oi3z7ngm8GdTZeY5F0ULCHSuN2+0BndpyI3PdoIsii6gwBNAR69hrThY/7F0ohzu7 ZZpYXbI/JQbTaYILMSAWETMarHLv66fhk8A5aeuE/QdNCQUoO+uBCFgaisAErqUL3F6ueQtwPxer IMvE0fg0xdxm2xLV3u85fG7c2QPMkmjN/cpUr2Y4Hoz7+8mQsGb0KJZhJZhim+7bNOm3NoxcMxUy a/J2StV/wjZgGSJm+gnvUmC4J0YX2YPpnkakKRLlqR6vxhwOUnm4RxDpGZQV6hQKC9o5N4FBDgl1 zozC5gPrAEqpyTqANJN9QJjuA6ZDcvzYQoBmZQx76hOSIMRDEGZl6puUYRtDevXDfccKmZNwbM1L hzzazcOODQmdJ0VvvFU4ADZvPoSLd7xNG89fv0ZTflZcKb0ttK25FP21B/hNewBrbLeq/GsP8DFH QR+vw++9B1g6jxce2ZU9PuOQPwZjvXZ9OvclFAOiuuE5+2iSo3m6x4AP5p93lCkyf02G+1kOMqnb 3GdwUsjdwR5itBQwgXr4cYE8XArow6WAmbMVgGHVBN3tUucMucYFtI+ey13kWxovB4EAw2xpuD+3 uT9f0oRrKmxoPKdzk6uiVP890V8OHSfFihiggfF3XgAgD/JK778E0CWxP/8cLhOAoXdEQKfsUsno GyrxQsWCnvacC+8KQ5QGRBYaKK20qzCDgbnbVRyIVzkjeP8rrrvLKd/57MlrC60SFnUDHU7ez00X JnhuylsDWpvw8YOtCQZhaDE8za1Nt21nvmVqPuiSu4JsZNWO+FwmhU3Kv6SGb3klcTumOkNGIzIE Nd3bj5+5HOmPhKyzRvC4zxlLqsuG6xemE917WvZMbyAJu7cjW8Ze97bjYLlicv/Ko1QcLG2eHLlY 6Oi691QHe64VItEfbLhotJ8E6x/EFDDluuQPnK6GTrcDp3t2unl6ESCdoSEyn67yS9JpBxwC7I/o ZaWbGUiZo7S33b7xU7R+0SKZJxzq6fv2iNdWQl19qVe0vflD42Aj9qefbNIo0dejFBKuykjfnVRN P7siaSU7HKJ53z5aJX4nVP4gM3qcHTh8yRl/LytfsZ9XNOZmjgiyLW0553M5u+c+7xiZz1OX0+jw 0ZgiTGmstnyMYb3m2aua2n26ucdVnmej0FW3KUK7fIiguixiB72PRV7E5KLSbsujTa6JS4QzU/uh 1CDewi0cv/lMPRC2MlTeEiAw7eUtbdc57K5I1ndE8KPXNn6e86D3Un+083CVcyJOgjJowZf0v14E asSf03FXg5596qFZBkF34cOfYNBrWW5wi4ndGAG/M4KX9A/090X/qsLgeGZpDyy8lxRu2F/JhvaK QMTvNl7TFjS3eHs+fvhafnpGHt/f84uhu2FTPnDi/wE17JcuCmVuZHN0cmVhbQplbmRvYmoKNTgg MCBvYmoKMjQ1MgplbmRvYmoKNjAgMCBvYmoKPDwKL0xlbmd0aCA2MSAwIFIKL0ZpbHRlciAvRmxh dGVEZWNvZGUKPj4Kc3RyZWFtDQp42s1WS08bMRC+76/Yoy11Xb/tPdIUaCpoKKx6qXrYhiRdNQ9I Ai38+s54dglKg1BUkKoou2t7Xt8347Gvs3dV9vZI5coKafJqnKlcwk/lVhrhYx6sFjGvZtlXVnH4 ZOe8MMKw/gkvtCgZvpQTng3S6gEvlNDsFAaGFThwTHIPzwCC2sJaMmBba8eoLoXsZke3DS8siI94 BOu/+LfqY3ZYZZ8hrknmrMyDlrnxeQH/5SgbZ9eIQMLiThTOSaFzX0KEllAoDKpkcWNZ+FwEkwvj 8uWWD3KBUz5CVGWaxfe2a5MrteVaAS6n8yBL5DH5XiNnmi0broCe6XRQcxDybMYLLxSw5mF6hEKG XQE/np3xwoFGp9iHScfmiboJNzg14iVIr1YIy4A85mKB9iRbcggqdMp9joNLGNgQ4OsEidZsepns XCWbrbsFxZP03WN9D/oo92bD3jMkyAjsg5+nCJhxzPYpxmIJuoVYFNZCCkY96BxOUlGloGInmnCH EgvsPYkvwOADZoV2DauRK8t6Y9RVRLdkh1SeuKaIR93yaKGO0deQqnlNGWlQ23TkzFN+juApWYPK kqg07AtHpXp6AyNPgbo9GQtRRPt6lJXwavVrwGhMJItYfvXwgCMDlGh6AjkFJr+rsv3AeCDFvy6Y sy73kBpNIp4UFdYtJoCQXHCcuknf3+EZOqk7jECmbRDQuFLGgMwJFdDDJoHAwi5v7pG3tMvQzLaz 2FXSHTa7cuMMkezHqQ0ixv+A00IHibthmydqJg7gdb1oTbttw8++XcRobKf/DLn3I/WCekWtd9Ws +hi0eypb+q9sQb8JIL8LMhhHXmraKIqBca6eKz79AvWggpD2lciB/lDKbi/oHYBDB1hTj4QSSpzu m2EJVL1AoxjwdKNYTjju6Hqe+ntzz5Hiek3Hf7PgeNDNH+WFALWWh9TomnGTmmF7EFS46Nn0Fu8y 2PgH1Bd7aSHCiVKCIRwYCU4uOLqq4CZj2Hn/E4QDF569KHHRv8TRSa7xSuXYb9rBbSf6QB2tPdPo zoHSQNjwJ6GdU4ZnHC12LQJwR9j4nhgIrIecByLI0snq00jD/SsRLGnRJSYUdobjDRN/AOU7R3gK ZW5kc3RyZWFtCmVuZG9iago2MSAwIG9iago4MzQKZW5kb2JqCjY0IDAgb2JqCjw8Ci9GaWx0ZXIg L0ZsYXRlRGVjb2RlCi9MZW5ndGggNjUgMCBSIAovTGVuZ3RoMSA4ODAwNiAKPj4Kc3RyZWFtDQp4 2uy8d3wU1fs/+syZOZM+M7szOzuzS5JdNgUIJCQhQKghhBp6MwktoYbee0dpISC9SpHeXXoV6WAB URQL0ougoNhQEZL7zOwG0U+993Xv94/v/a15z6lzztPO8zxngwEGAMJgIrDQonnrhKRz+xIbY89X iNyu/fIGcqcPbwZgagCUyu86fKhrcwSZDxC+DiBwZY+BPfvV71HtJ4CYdIDQNj37jupR7mm/VwGS FgHIb+R3z+tW4WBlHKufhOtVzseOGfHHLdjOx3ZUfr+hI52jzlfDdiFAvxp9B3TN+3k8jsDuc9hO 65c3cuAm6ytRwLgDsdPVP69f94LsrjexXQYguvPAAUOGAhIOTP1pxvjAwd0HRl5XvdjeCGCJBJZ7 yMwBCoF0GU3GGW/4SuZX6MEUEZFwlKUczxLuBpDiNOCKwf9p2trlgjSAIuBTi1KZvIBlzFkXMKuM MfYIbWvsZmwMBBjzBQVbWCMRwJNgo4MB/8jLH/Zv5b//sMx9tjLbms1gNzHb2BQSQkKJnd3C3GTu MXcIsIPZIexQdhg7nB3BjmRHsaPZMcxt5ha7h93J7mW+ZasAh7zzEACBEATBEAKhqGkBRJDAAlaQ kWobqGAHDXRwgBNKQTgR2WQisRXZSswOeBVegykwFabBdJgBBTATCmEWzIbXYQ7MhXkwHxbAQlgE i2EJLIVlsBzeIDJhiMImIv2lIRriIQlaQzYMgJWwAlbBm7Aa1sF22Ale2AV74Bi8A8fhJFyCz+Ay fA5fwhfwPXwHj+FHorEH2fpsI+IggcQJD9hqbCpbndnFnGR3QRnoyB5mt7H72P1sM/Y4e4Q9yZ4g zdi32RZsS/YYbIRrzEPmAXuAPcpmsrvZd5hnzHPmLko+AtyQBZ3hBiGEY35kfmK+Y75n32JPQTGM ZdexNZnfmN+ZdcwWopMg5gnzK7sZdZ0MkZACiVAH0iEDLaMdvIIctoW+0A/6wFlmH/MOc5Z5n/mM +ZC5wlxirjKHgHM0xDnn8GzxYNSCUPrj2QGosfFsAVvIvsle4KZSmUYLtcPfi1ge8XukLTI8sl5k 08hXIrMj20d2jBwXuSfyVOSlyCuR30f+HFnkklylXTGuiq5KrmquWq4MV2dXV9cg12zXAtde11U3 dctuh7u0O8Yd705yN3N3cr9Wmi+91hPgKedZ5vkwakjUz9EQTaJDo6VoJVqLLhUdFV0+ulL0pOjp 0fOiP4jJi50Qeze2uOwf5YrjuLiAuLDyfcuPiLdXtG9outGx0f0HVwTFvhNicOKC1Wh9o9nXkJPZ 7Fr2IjedRiEnEF4UsToSIrVIV2TDyBZ+TjpHTozcF3km8nLk1cgfI5+4wGVFThJcSa5UVw3kpJMr zzXQNdQ1x7Xaz4n6gpOm7tbuV91zSgeW3uAJ9VT0HIjKjfomqvhfcvJeTG7s8NiLsY/LQtki5ISP Cy2fW34ocqJsaLLRvtH1B5icMMVPi58Y7BTrxrNoe8nBU8uEdvj7YXxifH76Z8f05jsAdx4bz9u5 AN9tNfp+vwnwsPPvi2+hH7ql31p2S7iDXu/3zD/fejT6Uccn680a88vqX1b8suyXxQ+vP7z88KOH 5x5OeDjq4UCAbyf+tO7r2vfqGLO+Zu8V+d582N94DmkzpDn64UYvvMwJBj1ngCOgND7LB7QK2BSk GN3BMSGHQn8O2xB2MexLIUqI900WKguDhS+FJ6IkOsRaYrrYShwMIM4xxsTZvpo4R5yHz1O+N8T7 JZQbNfG++I102RpqveDrkzlZ+1duTCYlNWuR8rMp3x/Vn+2hAHbJrhptu/K/wN+x6G3QW7E10R8l EQd6qVS2BfOMPcDcY6sxZ9GXbcNzP4HZxR4nTvQsV9hxbEvmObue3cBuZB6iX4rEM+U2vWYZ9JuJ 6DmT0eek+X3OJPSjbU2/kwXZ7HboiH7H8D4DYDRMhgfoXVeif12NHnYder/t6F93mh72HfSx6GEZ Dn3sZfSyn6OH/ZJ9C66hl/3e8LPwnKHo+zywBqJgLcTCBigHmyEOtkAF2AblYSskwA6oCG9BZdgL VWAfVIX9kAoHoBLshmpwEKrDIagBh6EmHIFa8DbUhqNQF05APTgF9eE0er8z0ADOQiP0ho3hXciE 9+B9aAIfQDO4AE3hPLSAi9AcPoSW8BG0gU+gFXwMn8JEhoUcuALtMR/pAFcNrw25cBO6wG3Ig1vQ Fe5AN7gLPeBr6A73ZFlWIB++hd7wCPrDDzAQfoJB8DMMhl9gCDyBofArjICnMAYdwFgYh0dnAkNg PMPAN4pL7i33UdxyX6W03E/ur3jkAfJAeZASpUTLg+Uh8lB5mBIjD5dHKGXkkfIoebRSTolTystj 5LFKBXmcdb31kjxeiZcnKAnyRHmSUlGerIxUEuVXlST5Net26xV5ijxVnqYky9OVSvIMuUBJUSor o+SZShVltFJWGaOMVcYp4+VCeZZSVZ4tv66kynPkuUo1eZ5SXZ6v1JAXKDXlhUoteZFSW16spMlL lDryUiVdqSsvUzLk5Uo9+Q2lvrxCaSCvVBrKq5RG8mqlsfymkimvUZooTeW18jqlmbxeaS5vkDfJ m5UWEAProSxsgk5wXd6itJS3Kq3kbUprebvSRt6htJXfUtrJXuUVeaeSJe9SsuXdSo68R2kv71U6 QE+4D73gobxP6SjvVzrJB5TO8kElVz6k5MmHlS7yEaWr/LbSTT6qdJffUXrIx5Se8nElX+ml9Fb6 hIQqfZV+8gn5pNJfPiWfVgYoA+UzyiD5rHxOfld+Txksv68MkT9QhsnnleHyBWWENlMr1GbZltve 0GbbVthWaq/bVmtzbG9qc7V52nxtgW2NtlBbZFunLdaWaEu1Zbb1to3actsm7Q1thbbStllbpa22 bdHe1NbYtmprtXXaem2DtlHbpG22bdO2aFtt27Vt2nbbDm2H5tV2arttXttO2y7bbtsebY+2V9un 7dcO2PZqB7VD2mHtiPa2dlR7RzumHddOaCe1U9pp7Yx2TntXe097X/tAO69d0C5qH2kfa5e0T7RP tcvaZ/oSfam+TF+uv6Gv0Ffqq/TV+pv6Gn2tvk5fr2/QN+qb9M36Fn2rvk3fjtnEIX0Hc1Z/S/fq O/Vd+m59j75X36fv1w/oB/VD+mH9iD/XuIp5xyX9bf2o/o5+TD+un9BP6qf00/oZ/ax+ztHW0c7x iiPLke3IcbR3dHB0dHRydHbkOvIcXRxdHd0c3R09HD0d+Y5ejt6Ml9nDHGCOM+9yG5nzzBfMaesw 5iPmU+YIt5nbwm3ltnHbmRvOBGdF5ijn5XZyu7jd3B7rYG4ft587wB3kDnGHuSPWadxR7h3mOvMV c407xh3nTnAnuVPcae4Md5Y7x73Lvce9z33AnecucB9yF7mPuI+5S9wn3KfcZe4z7nPuC+5LMp27 wn3FXeWucde5G9xN7hZ3m7vD3eXucV9z97kH3Dfct9xD7pFcXa4p15Jry3W477jvucfcD9yP3E/c z9wv3BPuV+437nfuKfcH94x7zhVxxRTsh213bHdt90ghmUKmkUpkBkkhlUkVUo3UIJ1IKRJOIkgk cRE3KU08JIpEkxgSS8qQsqQciSPlSQUSTxJIRZJIkkgyqUqqk2ySQ9qTDqQLqUlqkTRSh6STuiSD 1CMNSEPSiDQmmaQJaUqakeakJWlBWpHWpA1pR14hWaQjySOdSS7pShlKKGu7brtBOUopTwNoIA2i wTSEhtIwKlCRSg6vY79jp+OAY5fjoGO345Bjj+OwY6/jiGOf421qoVbMIRVqoyq1227Z7tuu2G7a vrbdtn1lu2q7RvaQvWQneYvsIrvJPrKfHCCHyRHyNjlEDpKj5B3yOplD5pJ5ZD5ZQBaSRWQxWUKW kmVkOXmDrCArySqymrxJ1pC1ZB1ZTzaQjWQT2Uy2kK1kG9lOdpCT5BQ5Tc6Qs+QceZe8R94nH5Dz 5AL5kFwkH5GPySXyCfmUXCafkc/JF+RLcoV8Ra6Sa+Q6uUFuklvkPnlA7pLb5B75mnxDviUPyffk MfmBfEcekR/JT47zjq/IMfKz44LjquNDxzXHRcd1x0eOG46PHTcdlxy3HJ84bpPj5BdygjxxfOq4 47jsuOv4zHHP8YXjvuNLxwPHFcc3jvccRx3HHCccpxzvOz6wv6Ox9mMaZz+uUeIld+wnNN5+Uguw n9IC7ae1IPsZLdh+Vguxn9NC7e9qYfb3NMH+vibaP9Ak+3nNYr+gWe0farL9oqbYP9Js9o811X5J s9s/0TT7p5puv6w57J9pTvvnWin7F/YvtXD7FS3C/pUWab+quezXNLf9ulbafkPzaFH2m1q0/ZYW Y7+txdrvaGXsd7Wy9ntaOfvXWpz9vlbe/kCrYP9Gi7d/qyXYH2oV7Y+0RPt3WpL9ey3Z/lirZP9B S7H/qFW2/6RVsf+sVbX/oqXan2jV7L9q1e2/aTXsv2s17U+1WvY/tNr2Z1qa/blWx16kpduLtboa aBkao9XTiFZf+1z7QvtSu6J9pV3VrmnXtRvaTe2Wdlu7o93V7mlfa/e1B9o32rfaQ+2R9p32vfZY +0H7UftJ+1n7RXui/ar9pv2uPdX+0J5pz7UiDRNqndGJzuqcTnVeD9AD9SA9WA/RQ/UwXdBFXdIt ulWXdUW36apu1zVd1x26Uy+lh+sReqTu0t16ad2jR+nReoweq5fRy+rl9Di9vF5Bj9cT9Ip6op6k J+uV9BS9sl5Fr6qn6tX06noNvaZeS6+tp+l19HS9rp6h19Pr6w30hnojvbGeqTfRm+rN9OZ6C72l 3kpvrbfR2+rt9Ff0LD1bz9Hb6x30jnonvbOeq+fpXfSueje9u95D76nn67303nofva/eT++vD9AH 6oP0wfoQfag+TB+uj9BH6qP00foYfaw+Th+vT9An6pP0yfqr+mv6FH2qPk2frs/QC/SZeqE+S5+t v67P0efq8/T5+gJ9ob5IXyy3ltvKr8hZco7cQe4k58pd5G5yD7mn3Ev+UJkgX1Qmyh8pk+SPlcny JeVV+RPlNflTZYp8WZkqf6ZMkz9XpstfKDPkL5UC+YoyU/5KKZSvKrPka8ps+boyR76hzJVvKvPk W8p8+bayQL6jLJTvKovke8oS+WtlqXxfWSY/UJbL3yhvyN8qK+SHykr5kbJK/k5ZLX+vvCk/VtbI Pyhr5R+VdfJPynr5Z2WD/IuyUX6ibJJ/VTbLvylb5N+VrfJTZZv8h7JdfqbskJ8rb8lFilcuVnYq oOxSGGW3QpQ9CqvsVThln0KV/QqvHFAClINKoHJICVIOK8HKESVEeVsJVY4qYco7iqAcg2HwGwyH 32Ek/KGIynFFUk4oFuWkYlVOKbJyWlGUM4pNOauoyjnlXeU95X3lA+W8csE63brPOsO631pgPWCd aT1oLbQess6yHrbOth6xvm592zrHetQ61/qOdZ71mHW+9bh1gfWEdaH1pHWR9ZR1sfW0dYn1jHWp 9ax1mfWcdbn1Xesb1vesK6zvW1daP7Cusp63rrZesL5p/dC6xnrRutb6kXWd9WPrBusn1o3WT62b rJetm62fWbdYP7dutX5h3Wb90rrD+pX1LetVq9d6zbrTet26y3oDRsEz627rTese6y3rXuttdYg6 Qh2mjlKHqiPV4epo22+2Z7antiLb77bntj9sxWqh+ro6W52rzlLnqKqqq5rqVO2qQ12gLlEXqcvU hepSdbG6XI1QS6suNUqNVD2qW41Wt6pvqdvVneo21avuUHep1dRaag01Ta2u1lZrqnXUw+pR9W31 mHpEfUetrzZSG6qZagO1sXpafVc9q76vnlHfU8+pH6it1E/VL9TP1CvqZfVL9XP1K/UVtb2arXZU s9QOao7aSR2rjlHnq/PUFeob6n51n3pCPa5+pF5Ur6lX1UnqFPVVdZo6WZ2qvqZOV6kapAaoISqv BquBaqi6Wl2nrlE3qG+q69W16ka1rFpBjVMT1HJqvFperajeVO+qt9Wv1VvqPfWOel/tovZQu6n5 ale1p9pd7aVOUMerBepEdYY6Tp2psipRGRVUzn7AfsS+xb7Dvl/drK5SN6kr1S1quFpKjVVj1DJ2 r/0t+071kHpQ3aPuVg+oe9V6aoZaV02377bvsu9RP1EvqRfU8+pJ9ZT6sfqh2k5tq7ZRW6vN7Pvs e+3b1W/UG+oD9br6rdpUbaLmqp3VPPs2+1bHcMcIqlHdMdIxyjGaOqiTlqLhNMIxxjHWMc4xnrlH I41voAhP3Y5JxndQzBPHZPP7qF8drxKN6CTQMYHdTKPZ047XHFMdE9mxzCx2IjuJncy+yr7GTmGn stPY6ewMtoCZx85kC9lZ7Gz2dXYOO5edx85nF7AL2UXsYnYJu9QxzTHdMcNR4JjpKHTMcsx2vO6Y 45grW9k0xzzHfMcCx0LHIsdixxLHUscythWtRFNoZVrFsUL5XIlQPqM5tD3tQDvSTrQzzaV5tAvt SrvR7rQH7UnzaS/am/ahfWk/2p8OoAPpIDqYDqFD6TA6nI6gI+koOpqOoWPpODqeTqAT6SQ6mb5K X6NT6FQ6jU6nM2gBnUkL6Sw6m75O59C5dB6dTxfQhXQRXUyX0KV0GV1O36Ar6Eq6iq6mb9I1dC1d R9fTDXQj3UQ30y10K91Gt9Md9C3qpTvpLrqb7qF76T66nx6gB+khepgeoW/To/QdeowepyfoSXqK nqZn6Fl6jr5L36Pvs0foB/Q8vcC+Qy/Sj+jH9BL9hH5KL7Mn6GfsSXYr/Zx+wXrpl/QK/YrdwR6l V+k1ep09TG/Qm/QWvU3v0Lv0Hv2a3qcP6Df0W/Zt+oh+R7+nj+kP9Ef6E/2Z/kKf0F/pb/R3+pT+ QZ/R57SIFvPAMzzhWZ7jKc/zAXwgu5sP4oP5ED6UD+MFXuQl3sJbeZlXeBuv8nZe43XewTv5Unw4 H8FHsrt4F+/mSxvfhPIePoqP5mP4WL4MX5Yvx8fx5fkKfDyfwFfkE/kkPpmvxKfwlfkqfFU+la/G V+dr8DX5WnxtPo2vw6fzdfkMvh5fn2/AN+Qb8Y35TL4J35RvxjfnW/At+VZ8a74N35Zvx7/CZ/HZ fA7fnu/Ad+Q78Z35XL4734PvyefzvfjefB++L9+P788P4Afyg/jB/BB+KD+MH86P4Efyo/jR/Bh+ LD+OH89P4Cfyk/jJ/Kv8a/wUfio/jZ/Oz+AL+Jl8IT+Ln82/zs/h5/Lz+Pn8An4hv4hfzC/hl/LL +OX8G/wKfiW/il/Nv8mv4dfy6/j1/AZ+I7+J38xv4bfy2/jt/A7+Ld7L7+R38bv5Pfxefh+/nz/A H+QP8Yf5I/zb/FFpmjRdmiEVSDOlQmmWNFt6XZojzZXmObZIC6SF0iJpsbREWiotk5ZLb0grpJXS Kmm19Ka0hj/Nn5HWSuuk9dIGaaO0SdrMn+RPOXVnlDPaGeOMdZZxlnWWc8Y5yzsrOOMdW9lTssp/ J9QR0oW6QoZQT6gvNBAaCo2ExkKm0ERoKjQTmgsthJZCK6G10EZoK7QTXhGyhGwhR2gvdBA6Cp2E zkKukCd0EboK3YTuQg+hp5Av9BJ6C32EvkI/ob8wQBgoDBIGC0OEocIwYbgwQhgpjBJGC2OEscI4 YbwwQZgoTBImC68KrwlThKnCNGG6MEMoEGYKhcIsYbbwujBHmCvME+YLC4SFwiJhsbBEWCosE5YL bwgrhJXCKmG18KawRlgrrBPWCxuEjcImYbOwRdgqbBO2CzuEtwSvsFPYJewW9gh7hX3CfuGAcFA4 JBwWjghvC0eFd4RjYrQYI8aKZcSyYjkxTiwvVhDjxQSxopgoJonJYiUxRawsVhGriqliNbG6WEOs KdYSa4tpYh0xXawrZoj1xPpiA7Gh2EhsLGaKTcSmYjOxudhCbCm2EluLbcS2YjvxFTFLzBZzxPZi B7Gj2EnsLOaKeWIXsavYTewu9hB7ivliL7G32EfsK/YT+4sDxIHiIHGwOEQcKg4Th4sjxJHiKHG0 OEYcK44Tx4sTxIniJHGy+Kr4mjhFnCpOE6eLM8QCcaZYKM4SZ4uvi3PEueI8cb64QFwoLhIXi0vE peIycbn4hrhCXCmuEleLb4pr+Pv8A/4bcS3/rfA+/1C4IFzkHwmXhMvCF8JXwnXhlnBXuC98K3wn /CD8LPwqPBWeiyCyIi8GievE9eIGcaO4SdwsbhG3itvE7eIO8S3RK+4Ud4m7xT3iXnGfuF88IB4U D4mHxSPi2+JR8R3xmHhcPCGeFE+Jp8Uz4lnxnPiu+J74vviBeF68IH4oXhQ/Ej8WL4mfiJ+Kl8XP xM/FL8QvxSviV+JV8Zp4Xbwh3hRvibfFO+Jd8Z74tXhffCB+I34rPhQfid+J34uPxR/EH8WfxJ/F X8Qn4q/ib+Lv4lPxD/GZ+FwsEoslkBiJSKzESVTipQApUAqSgqUQKVQKkwRJlCTJIlklWVIkm6RK dkmTdMkhOaVSUrgUIUVKLsktlZY8UpQULcVIsVIZqaxUToqTyksVpHgpQaooJUpJUrJUSUqRKktV pKpSqlRNqi7VkGpKtaTaUppUR0qX6koZUj2pvtRAaig1khpLmVITqanUTGoutZBaSq2k1lIbqa3U TnpFypKypRypvdRB6ih1kjpLuVKe1EXqKnWTuks9pJ5SvtRL6i31kfpK/aT+0gBpoDRIGiwNkYZK w6Th0ghppDRKGi2NkcZK46Tx0gRpojRJmiy9Kr0mTZGmOhOtvGJXLiqaoisO5SPlY8WpXFJKKZ8o 4cqnymUlUvlC+dJy2fKZpchS7Pjc8TXzpvE7KGY9sxWAzoJgfLYFCeJ836RzdqyX/JrwiK9e/Lh4 hfEs6S9q9Wcd394JYWxNCDNWIbbix+QGSMWrX57xT34BeaNkl0A/OKORDuP8E7q+KAeaZbt/+/vM E/B//3MB3oXD8KpZPwK7YZu/fxvshSm44hG8FxifbGgOr8FqfLbBnhxoBG2hE/TCkUGwDtb73+oC uZAIxu8ma6FEC/y978F92Mc8w3nL/2H/+bjLYDiAOy2HxrheLZiL3C6ArbAKMmEqtv78XDafN0ge 9IYhsBG8+G43yPf9QhkmQUPogLTVRykNgv64ew68BXugO+yEpdh/BFrBSv4oBJKhhqaKfyLVin+C mfjuIjKUTCKz2YkwFMbCSrgGP8MceL3oxL/X3n/xmQNLkIvXYDbqNIetybZgc1/o9j999qO8jqNs RqJWNqA+VsIcJhqWwTQYx4TCCjjCJP1FOv9PPvuhENf+6+ckHES5rUf9zkaJDUG9bELqW/z9VaYM E4x20xtyGAGeQmf4/+IzEG1hJFrcZNxnMHKeBT3QuoZhmY8Y9oKWykwtmI5aX8tUgDvYnw7joT/j ZirCGZjOaDAa56/A3gVwiKmIc4fAHqYM3nkHQnvk8h8+6A8kvz8wzyVecy4YZ5N9ap7ab0r8QcmT iYJzL/sDxsOEob3thy24/xpYzjgZFn6Bm1DEJDClUHNl4SPEGZTbITiO8nuIMzT4jGH+My34xkza nSvxIP9AC1r7rL/4pkl4Ut7A8zUObWgPnvXjMA/2YVmIrdV4ghbDdrSBDWhLE5HWP/fNgWR89jSe pgwEtAx4se8xo7/4o+Lz5r7nX/jE2S/qn+JpvoLnuQX6iv/z+T+f/8EPCXh2m14njahImeJvuS0B XFF75hccWI8nfj4+x+B/Pf9FTH7O3qdvFX9HDxWlUwuNKhpUNBZj2WfwBXwIp+E2XELLfg++Ziuy p9mb7I9cLl4tz9M1sJeLhxGw6O/rcf25fK4lt47L4eJpLLZLYaxqBa9grMrFeNkH/RrQOQGJ3Dza jnZjf2Sf0iX4Wl/0e1PRN82H8Wk53bt17tSxQ/uc7Ky2bVo1bZLZuFHDBvUz6qbXSatdq2aN6tVS q1apnFIpOSmxYkJ8hfJx5cqWiY2JjvKUdrsiI8JLOR26Zldtimy1SKIQFhoSHBQYwFOOJQyUZzSv VjerXm+vXjfXG+rJ8Egub2izx00TvGB1uj0WV3JCdgX/LC+N84Kc6VVaZO2EtKrZXj7u71Oaedlo 6Uc3vtzU6arn5aLxx9M4r5u3TKsst0e67Hwxno3veB11s9xup5dE408jHMKfxnmubl6pBfa7nb6e Rl5okWXgQPGtqtgJVd3Z+GyV5Y0oaWZn/zMiD6JnOvY3MpsxBdLOUL1uhheUnRB6yws2Y9rjqphN 1PCWiUNCJKyZq0GCl1F+9DKyl7E1RZL/uoXx2o2q/0QG9br19tTr1gsl2i33T5k+9knU7SpwFbTK siRj1SQ603uuZdbOkOC6nrrdg7EDzA7YGRyCPSFGBy4xcCcTWosxKyS0XrWdBALDUHxWg9x6Bnp7 02bmYsWTgXLDEfnPkQPFxwpfHgJ8raQm+2o+Irx8XW+AjwhXL29anhdmunaWP1ZQeECCLrlxod08 3fI6ZHnZPJywE9joevltvKUyW+RgF26FyM13GerOMB+G8lz18l0F2Dbm5uLTk2Eo/S/93fK75xpm wuR6MnAsqG7WNPcxp9eKZT2vJc4bhtPCRt9xsgX1tF4uo1lQMM3lXY3kvjTqNp5oBBqSXlDPg7vh YvV6pxsqSXihNtMaG3UzlZM2M8/lndilt8/28gpL7N9dIHlDn7hRO6gffNN80S/Kbrm9DZJ75xls 1uvtKpjZ3WS10GQN7dVVr3eGAeNFtH5oi2/nZNXL99T7c0NkHCts9N/fdbu9epzxYkFBPYPEvG5I vY9kHPiTfuNMOOMYpKeuN62NWUAbUwe4Y1peRra/yz8hx3jNGMnNyM52+/SOU70B0dNovMdVYKwY EO1V4iT3KRw7VqF8ZqusehlOk3svqZtV85HmfIT1zBYvuhkN5xQkPHL6ZJTZ2pPZ0mcF+SWP3Da+ A0xeaB6n+uebq57XnOd99Q5Z9T31cwsK6ntc9QtyC/IOFE/s4nFJnoKdoaEFA+vluszjz2D/oZlO b/3CbK+Um89UMzVkLOcybK9+q0yv3LK9oar6rvw8n+Oo7XFXdbotL+a0+FfD/jOH1o9nwDhzBdJD pC0UvZPTVd9wNQfQQzi9UlXjyCJBbbPwTHQ17dd84FlpjYs7jVPDZkfX69XaLyy0TL/xGD6wpb8X F3G7jfM080AadMGGd2LLLF/bBV2cuyAtIQ71mGuMHCsZsbU1RiaWjLx4PdeDetMyW/8H+37Ztgss HqsrNcGUv+l6u3mPtUEef6vqDazqV71cN4t1En+NOFmjFhyHrqyG1x5nvmjIBD1mgeRxXfR4pTgv rZt1zFkj2yVZ0NUxOKdhnHGC0KNe9LzLGH4UFMnL1PAyqtEP6FdN987aq+LgC0Ny1SvI9Vvay2z5 g0G3/H/OG86RPMie0zffYvUYHH5guje/146ub5wrp9s3o3G2VzB8s1d4aD6QXmfdLBd6Ijy5Lc2K q54r31C215WbYbqEbOfL3QeKb+RmGC4QSTamOP0mjk+faP9qaxXK/7eGPhENfVJhdn41XCWtHHLg SsFtzdPSJssvpapO/4ky9mpksPLX8RdSLJmDyseD5/ZWdLyroaE6tEfZ/0zkmW3+0nppM3Os6gvP 0CbLWz+uZHFfu0Gc8+Vmw78NNyoZRvcxzjnaCCME0nd6mOktd6Yx01vnZB3Ey4xrepusXYQhdXPT s3dG4VjWQRdAmtlLjF6j02i4jAZkMrjaLhJoznceTAOYaI5yZofZ7nqAAbMvsKSPga4HiK9PKukj 2Mf5+tLMPl9WUU/LRxFkeVDp3bxpLbLGZucX5GYbwgbVZ4Bo2Z5a4CWeWjsZwod6gz3d070hnnSj v7bRX9vXzxv9AZ50NH88HC7jqBfkevD4owPOAieTbZiwYS4k2nWguBg96Hn0vG4vH90BgQ42KC7b hVbcGOc1MJCL3Q28E7vmGXQYZsoavrxR12xv4IsFcUojbxCuEORfAWfUN98xogC+1BWNNc9jVrEb D8fEbG92nLFpVi9jAZcL86GGnmpePsa3Jo0xNkrILrB6ksxwwkd7g6OnGUUQ0mY4QrPHiU3cLNsn pIBQpLyrB4e65rpQ2hx0bY3GyMUYP8FOX093jOpcTHcTwU7/IPhOUEhYsDco3ohVAWY9JB4XxJ+A 7Gwf8WZrmn8C7i15Q5CimJdE6X8BpYNDjQxa8GcakmpMPW4s0/IAtPKMxDNoEG2uFIDD3rDoRnno cHzvh2CPp2rJy7hWoNllrHHK1xtgcB5qJrRtDhRv9Ixyv/SpUN6D0TnLMExwYg6ZBtkFf+/wtkfH Gfj33jCzu6AgMOyfv+CTV2DYi9LodNXrhbYKLowpKEY+plHezKrWShVQ2kfxLjKVtoEyUB4qQiXI TIu2JVQqU7Y8lA8PSYyvVD4kPj6kfCUupTKUjauYbJVlQdPiE1mofT4pAX9qX718PsliZeypCfiR zkvnLcnS+STp6pnEikxKpVqkSi02pVKMp7RAAjwplSsnJ0UQm4INgbXZ7DZPCmNxWwyQKrxaLsoe 4xTr1HJVjNKDcmvMqFu/a61SYlSN8q4YW4B1DvPsOc/mPavKfK2q0eVSYvWE5FRPZislKilickR8 eHL9sjG1atav4C4fW6YU3//NN4vucMv+6MH9+nQbMognm0deH9DuEAmlYVxaRmCQuzQNCXaVFkrr WmmXuzRLBeqIjIwS7HJgSGnFFcwGz00TXc1dxMK6XJqVUSJYi9WyIQNUgXdSa2mNg9rJCfbkOAvY ky3WVC0Bb2iOR3EWK6SmVsSkMznZmooPi9WeaklOlqYdO3bMQKI7pRZBqcTGugN43qaodpsbZVOF SWYiiN3GuFm2VFKiJonRRfGlHVLN2kVtq7aOZd5cybTRoitVeLabWXM0MViLiyrdPHFSl8ZNImtU DUpMDBqYz7X+Y32zVvEhiaQUmYL+bUTxY24JclwBRqc5ykTHRCPtMUwQGxMTSsJpOBs+N42hsogx PK2sYGsogtRCypUuSlwQK4WG2ljb3FDOFhoaKK2zWEiFCS5Xgj4uMOEmMnUzFWFBrqD2ozjQpFPI eWpc7WSDe0j2i8KoJlaMDojleU9psFSyRiUnqXaLJ554SvNoBlY1OalyCgoiJjbFbUOL4Co3a1Rn dofnxVDI8Ds7buvV1dm4Z/N+69o3XTJg+GC5YhVmQVSUHEBtzcrEMO2Zdp8y6dttjqJHOd3jCou+ P36q6JtZPfvUyGlRXkhMDI2Mr1sLZTAKVR9J24IDotKsNDAgcENGgM0qWzdkyCxMCE24CbUNOrUE P7WKoQJTQZZK8cRPGLMlyFY2viinVrmwYHtMPLOhfKw95GndWlFaaGKiFNuwMZtXr7bHFpaYGKK6 0+uBb19Own0joEFaLARJQSSUDQqyQ0johowQYGFuWoiu2tUNGXY2OGhdYKALJkg+0SaVUITCNG3J FCaS5k6qxVVJZv+BuM0MH1etrDvCqXRXno0roXF9+WgttEOwLbpG+/ZF/f9KZajsSm9oUDkMgDd+ W1EZeqRVr6SnBVkb6npydIgQy0ZFR23ICIuGxOTEDRkpdiebzOpaJU1kmlaqFMk/Uu0prNVa1eFM ZiMnxiXctCch7fZkg4O4ZDQL81ggEy+djjiUL4MEW16WsbWKh8H/VOtfu03uGMbNhxmiNqXfObW8 FMRbioYOKZpjoUFm3/wSbrsznZnJTCsaZSrg2Sq/boSo+i2ZCYuZlNRnbvb7mkXHNhfN+ydqe5bM nkcPYZyXk3heJHBBXJodFFaZmwZyUCm21NwgLmycppW2jKMJD5DHBz7Dr406SqxIS8fE4IG2ontD PhTCM5IVTduaUomYro/MHnl6VtPpzzfu+mlMYXFR2O5t/ZY0yV7WI2dS21ip+UaG23udSdu4oujD K98UHV1N3i86X3RsJhO6+0smcnKb5V8hZYY1/YZ6SoAa0D0tpZQTEhOBTUTqoHpAVBAfwG/IcMcE KPKGDKU6W32uwpaLjHTGRDsZbXyVKrWiE5kJYWhZCRb/sbX6jy6ygA7K0JRPRSXeCxX1j+pIUm0K H2BTVbvdHMJzGxvPelhLcpLpz5BXZkuIGvPSQfn+m/uLF9d8JSUntmq1ikXfxmS4s8okxyUm9h/0 St8OVeq8NjCHtCza1rCO27DKlzWyZfeMY5UD9Y5d1jVsUiYwMWV07Y1NGoaHkE3Pd+j1x7XvPD4d rTcdpTIWpeKCtmkVRKsFD7WFFSOZMDYy0hKkg87qKCGWrGOF4EgtPXKdy+UOnoBadFuMg2YgjpF+ vOnT45+OK9nvDGQ3OivW43khCi7F4gtl6Vy1LmpcxSpVJoQ54xOLqmD8kUPGJ9SsFCd3pW2L1rXr Vkl9BtXrl7WHJCYGSPaoWjU4sKb2aoG6zC9+zC5Ae9PBDSPT0l2yGuG2sJZFaW53iAoNXNf173UC uqS79Mc6umJd5VRWXZzGqSERbMTCtBAcsVvBbZVedTg81tcCTE5+sKZetqQ69PM+Zkqe0mXkZ5BD f/Q39UYL6IRjUir5QrLdjVHI8MZVWNM5B7AT0/pMbHrh4z5nJnWf3TaBfV6QMiqv1at1+vDl2mT0 HBOypW6TuF9/WHhnbNqAzdOtw99sX7Me07bvjEbrlxqRtjW6lgc0A72cDu3Sytk5nduYodssWyRJ 3JghiaTrQJYR2essEdnOWLAs8yqRp5BgvEztRgeD5bHdEpYJcXGnbko3IaHjoI6Pahvs3K3tUw2D uQOLuYXPNKskW5B+VBEz4UCPWLc9jNMSKzyoKVVILhpJM06cePoo1OpKr8/sSWuWYA9MCXqe0q6u JyzR8IBy8RMumD2CWUHPtLSgijLTNKhikMA0CZBEiWkSaD6DXOZTUyU5gmWA2ZhBwyyqk4IoC0FB EekRES5dCwpyu1DINc2oj86OkW6gEvzZgVYbaY5j8LzFxTE2gRhBX5YrVzayAMOLkwB0ggYnzNb4 GDlM2PGBIlWowQyPLVcuvOit4UU/lHLHRrNHEkMUl9NZPbaIZ+5WrOUsVx5PTaC7QdpzJ/m2aWqp QJOj8OI/+PLIUTScSJMECeUoGg/JeMCB4vtp4VhRXPiwGA9BEo0ZojFDNGc8TrMYElAk42kxn+Z7 NUUde13G0+J7KtEsYwOrGOyMYAMCAzZmcGFaqdI0UIyOUpRwmTAWi2wFCAwPjw1MQCM13E6yAYtZ g5fEg1WUkPlBMRlyMkuG8bC+SOfLlGQm+WW5sSg3NqLo6czH9khPLDOzWtnQ0BUMM+tLr2CtUJnp WKqU060XXZ9Gvn0ukXsNq4cHY/CLjTVESFj+2VPmQUy9iHLxxiEVw2umPXeh/Poyx0kN0gGt15Vm JQxL9uBdkbGxDEcZKFPNcJm+PA+t0J3iJjWKKjIXmePLDcufhGf7EUaQMChlRhA818swggRqrLYs kAspVJQIoZD1uZ6/RhCCodA4jFaLRMzwYbWURI/yn1+qM2xd3pXLd4tqjJowaliNPk3qdUzVJKYN k3OACX2rTdGOoi1FK4sWkg+KDhV9yEQyFe4x4WNbLbuK3OwCYC8gRQ6olRZhVTHrDuSDAoOWZgTa OTsIqhrEQxAUCEIpp+kUz0hnLMkJWIXaphc0/UayERAw/TWdoHHoYgwnEcsk8zayP8xdq1PT5+ED OifZSzldw18pz3xShWdoterRthDSqBG1lK5Vn40rE51erSljz92CNE1Cmt5FmspAl7RkV7jVGqRp amC4yjrU5WnhXBBNk+SGtExgGbbMqkBdtwbRAN5VaLWW08sEBWmz9YSbyQkGYQk/XE46b5SQYPq6 M3HJKM4kf9KEcc5qeDoMTmbWhBl25Solgcp/G8GIhjbEB5CjiTWibFJby7N34+ZNHZpctYpWsWvm 4TqjRl1qc+iorUKTDoOOZq8OLVUhoeirir2+WjgxvWGvjgmZQ9IvHktNXrs8JfuVbj1HvrsIeZuD FvAe8lYRxqdlhIVGx8REs9HL0mI4NWZZmYqig7GwDlRGRAU1gtUjlqWpMleBZSos57jQwJiYchVn AzgCC8uVc1gL3e4k52yHz1hegqEaZNI0HR+vyKyZb8PLHl72MWjEbAzaEaxRosuPTUk2Pb1xK/P4 7iGGLlcNfa/ToC05GWO61ByUldL94sJ2Z1uP9AzpOnmKd0vOtIM5wwd1Gl6Kq3a0SuX6r7ZvOyk3 Pigkpc2wzKF78mNdn+R3mj1z3rKswKyCdgNG9uiF56ApRmY37YCMlobOB0EsPpaWEBTaUBQDgwNo cCmKGdVyTMdpoEPDORsyHK5AVpSCrTNKudyBHKVRzoCEZDOh/CHp0/PGNetPWywJ1b6cEhWMTKS4 U5hkzENQx8kBHpsvXuPprFQZ00vCYTry/BPS6HVbtSS30CT0sZk79i76jpnGc8FFo8zMY10mO+TZ Wktc4oV1vgyRKf6904Pqz+cbPnURavVTuhhiYOF+hgmlDikcr03H0mIspRqKoeGhbOgbaWL4qvC3 8FLFhodbaDRl6bK0aNmCOcgq1ZiqIf+qhcXkyS06ZqIzdhcGBpYhs5k/lWv8wirTG9YqJ2unQ6ma nYrZGvJ+Ia7ET7y4DDj85m5JNaSQkFixyp9a9R1Ni9snC7flTyvwlF40KmJU7pTpDUe3zOhStQWJ LR1hDW0mPj9eaXTNEQe6Dfxk7vYqn/TIXb2q98xaFmsCmRdid90vaqSqebuHTz3WDfU6GTPkYLRu He+U7dLKR1CetwQFOVjHG2lBQXqMzrBMms5ZYtiYZRaZenR032Gz4uISPIWKj0VkKdk0YJOl836W /LxhSDAiO14OA+wvk236xqgqTGnjH+/6rsz+lJN9fdl3K1zBbdZ2HrSqRbePll65PvACIy0qKk5s 3yImlA/mJ07O7FHbOZrGJ75WDF6uRtWuu0dOPjuYkZigXUzlr6cEPu+jlnOFhMpV0985V6n9mIYL 1hv6XlD8O0cwsxQgM60USyqGhvLEuCrxLL8qjGUICaWCIIWFhCacP23c8f/U3EGgxferZltN1ZmW qtXGhkN6F1ljPClMitvMIGU3R54fmkucRQ3LJrpVuZ3C5tDop58kcsNEsVR8BpNh/AWLAWh3xSjv cJR3beicVhkYycJV93gwyV+W5rEHetCpBCazycvSAmV7HBu3zM45Z8XGVgmNmCXLoVxhlSp14gtD X8j+puWvkedPl2E3XLy9ROIxZmpYJdafIZrdGACIccL8Nsb+pSkQViODhg78dPaUdwfUyGtMPhv0 0YQ5p7r2fe4tVatrw9aDqtQZ3Hj8lJCIOj0atRpWM31k88bdazvJR2HlN48Ytisve+vQVya2Lh3W 8VbPNR1aLu3TfxXDV89vUqHOuFY542rMePZjnUGtKtZ9LSd3ZqP4Zr2MSNsNJfOtaYnx0CYtLhIt MchaYomxus8SZWssG7vMylEPw4TZZnk8FcvPCvurI/2XdhidYpyg2BJp1CJGSFYIFyAbAaUkjpip HJNaeH6czW+FNYbvHP7xV2uKvjq5MaZeem09SAisMqh1Zn6diNGxiWN/Ou2zwZw3RzUoulb0+Pei +e9bycIwPVYNdJSrMONkV8MIF64z/+IA/eVktnfU8M5ijV/AGWj+S4KD95bUNMqz9fPH/FzpYab6 g/a9+bcifH8jBRGwrCgVwJ7zc6Xn69Qf/v73UZzNMS8/av77pJM+cM+A5+7AKG4ijKCZMJJbhvVM xG1sj4dRZAliKITTIF8/PxWG0cGIajCCmwmjzPI3GMX+BgO5o5BOEyCH+wTUgM6gcvPAxs0BK9cU Opn7/Bfgv8ODhjDo+TsM+mhLSDJp/E9A+l+GwQudbvKTbPK0BCIRDCINkYJQ/P2jaKjJc1gJzy/Q EsK4pzg+2C+DwX/K4j+gu4GA/j5ZlcCQ2d9hyLAEhiz/GxiyfhmmzF+GIX8/THoNGS7G/e9DCy4P KrLToBc3EHqxX0M+6QvN2Z+hNtcb5ZIKrYkbKJcEtUl5qM1vgtbcCERtnD8EGnG5kM82h9bsQOhE 9kI01wf7AkHmkyCcvQZ2rCvsWmhp7PPfgKc+GPT8HbTvnzT+RyD9L8PgBVEJ+fGYPKUWFyEuYT0S YcP6Y18/8pZj8Fz8o8Ez8tna4JtVTP5TyUgIYwn2j/DLwQ86BRqYMvn3aG+AL0QeDJmVAGX3d3Cf Q3NSA/WwHKINuZJLkGLK9r+AIfuXYejgZZj68IPLR/prIW15kMh1LC7iBqHsvsf2FuiNt4N89lPI R5vphecnn+QhqkMANxz790M+PQzduVPQjXsVx5NxnlH2xrF1SH8qpHLzUSYNQOHXIQ1OtEkVVPYK 2puxz38BPsIHg56/w6RvF2QYNP5HGPS/DOSFe2Tyk2LylAcyySu+h2UlRFkE6+/P594weWZKeH6B 03g+++O4wf/LMGTw75FrgB/lk1UJDJn9HaYMS2DI8r+AIeuXYcj8ZRjyL4FJryHDDOTxe2jC1oeq ZCt0ZJtBR/IddGS+hUzyK9RhG0Ed5gQ0Y/aAjdUhjTmIZ+kKNGNbI8rj/BbQAN/tQF6DZmQ5tCOl IJ7NxD4ZYtHHJJD7EGXUyTvQlP8ImgfVhOaGffOXsZ6O9fXQPMCC5Szs+x2xEvuDsb0Y+1loTidC NqWQTRrgGWwAkQDP7yGuYn0mYjBAUS6iItZ50sD4W0PPMao93/NS+5TRhvvFb2P7SwPYXmIA58Qg 7Fi/g/gU605EKNa/QLxnvI94aL4Pz7fgWB0DWC82gGPPEE+xfghxAMfOGkB6phjAeg3sf4rldGzX x/pvWI5i1oGGcmqE2IL1fjwHv5NN0NdEIziG2GeAzYMOiEwDzGnohWhQUrIMngXmzxLXiSe3UN59 odvLQH/4VzyEWmQ6/MoBxmlEoB+8H2whLCTpsJR5CrNZAfYg4kpKch7uIF6UaA+dEX+WfaAZVxr6 mQDI4vagjynJLxojTkGyGZuNODTelzuY8daIs59j7PfnFmjLg8242R37McfgukBFMyZ+VfwD3xCG GnkFXxeS6AD0xT8BTzdgzjARE+ZlmBpiPKe3sV0NcwhjfhiWS/CcDYId6IfGcELxXfRXPdhZ0JtN xnOYVfwHxrExXCd8tz7s4qpAQ5STiu29eE5C2Jp4Tgz//RHG/nSYhbR1Y4egzC9BKNcGk7Rd6AvP 4hm+XfyEHod6eFHoZuxnrG+sbayJiCL1iz8218F3SmDOLfG7B5HGRIgw/a5xPm/7fKrph9D/cPWK i0p8LvsM8kx/cgr70feyN6GC6SeSi5/Sdhhn0N/SpVCGu4byMdY3/GCJD0c/5/PZxU9NXDPP1TG0 y/Foyx+jjc5hfoZFJTDslJkD9RHlTF2+j/ow9Fkf9VYTYz7qM6ALllkwiM7APgPJiL4QZerTr+cX ujRyOUOX5yGar450oS4pyp8SSAjojWsh6BVI58/j3LOIRTAgoJOZkwnGnhyH9Qf4/uswwsyX/Pme P3dLM3NVPw0BYyAqYBjmrLxvP5TNGHoG8yqDnsbgMvOfNjCBS0BbmI/6GgHRRv5A94GV3YJjB7DP QCvEKHy/C9K7D+uGHmdgiTmQmTvZUfYYW+kY1IWR97xuzinL50NvA9xjSKXPsAzHfU5ijuMxx+3G nmw7rDeDZOzPN+O/P4fx5yMuM//y08A7UWZdsI65jBnPDRqe4t7VkIZBaDvVsTT03da093z2YywX QZShf34fVGbvQUcO1zaxAnEMokyb8tvaC3syYqxhTw4oQ3Oggxm/38e9hkM5/jiuhaBJkMo3wfmN cP4f0JF/FetzQDP2xPiVT1tDKvsI2puxzB+LS+zPzCP8NPDT0E6O4vxOvv2Qht60MtYNenZDBNrk Vb/PXm74bIy7K+huGGf4MPRltTFGAXMX5rLRMDfABjMM8BegvwH0DzH8Z3jGcmAsDQAPVxk8Ztkf EYq2UxmmmGV/WGPqsRrUxb7aZtkfz9jY4iXcDYxFlSEGy5rYl4z66s/2hZGBzdFP/Qz9cWwMxrY4 dgcksl70b5WhBuYIr3BVYRL2NcR2f6x3M+YhdiIGICYZ8xAbEeMRs815laEn7jGJ3IXy7A0oy95G WrqhP/oGdZADI9kvcb3++H42+m6ch9jlL+cgmiIWISYjFpjz+qOvSEdflQ7jEV0RQxDVEFMRPRFj /f3tED0Q+UZJ2sE8RNL/xLtIY3P+IYwPiIDxWA7EslewE3XRH8YiJvjLTUY8MtrwTdFgf5+B9Jfq JRiE8bANFw2xhg1wHaAN2xPq0zqoc4w/ZszIgb38BGhPt4KDawFLMW51+G/pNe9HXsyFFmLu0xLl +wWW7REKYjm2n2Du9D3ia/Qlb2GfA8+cUf6I+BTHX/GXSzHPegpd2A6o60/wHrAA3LQ9RLA9wMN2 Q5TGnOx/aJ//qfzvBT8WxAz0RwY/Bp9PfLQa/Ji8LEN/U8JLW8xJDD7uYN3gqRLyYfAyA0RuJLQ1 +OAWQFXMN2qzk1GPrWAOWxF01g3tyQ68l/bH/VuDyNaB3rj+HLYW0hYBbmMeuQOlyFQcN/h4HfPj cjCcHQw5ZBnKYDe2q+IekVj/HcvKmCs3RFr+F/Bg3F1YDXJJWdiNSGKbQh8D3BPIK6mbKAOtEIMQ UYhqiAqIKogeiGxEdcT/a+ugfx+AeUh5BObnRTK2hyAKffl30VBEPURZRDj2FWEZjeUfMKXoPNar Y/0jP75B/ITogv2FvnzczPGLfWs/v4JY578bnPTn93v89wIj93f6MQGxG+DZCSxXIbrj+52xxHhU 5MFyupHfYz3bP/+e7z7yfJCf3tX+vX7HutWkFZ4X+HlagWjno8v8/+aq+3mY6V+zpN3Zv+cBP20G 1vzZLsIMtwj3LpqKCMG+H/20/eyTkSHDIsw2je8Fnxt3mSdcc4xFIyDIyI/pRujJd8bcNhsamd/l GblNTRjKDsCYlQmj2OGwnD2LZ3cY1OcGQ2nMlUtjfhOGc2awEzE/xfzEeI/dhP5zE9ThSv4v5v4Y l1HCjPF3nAf7/z+oHLQ9A9XhV2KBvuwg6Iu+pC/a536CVHOfwoiAGtCGVsA5hZhrz8XcLwDbKmTS AlD4gZjr7YUJNB3z/7egAT0Bw8xYXw3zlOmY54XDCF7GXOsXnPcx5lJrcc4AqEXbFn9B6hY/MO8Z mMPS6jAYY2tb5K86jYXO3BmYj3SVxthenv0QY3k89A1oAr1oKp6Z5bhuBzMndXAfwgLM+8sY4MZC JD8c95qF8roHhegnO7BditvRfCikUyGE34Mx5B1o6S9bYA5rlrQqTEPk+jHNGDeAeYuBvICxOO8e dCsp+W9x3MBT/3pPwWusY9zl+EXYvwimB7jxXTf0CpqG5TIYwq2BHhzWEZ+UlFTBcioM5UfhfXMU jKMtISegOhzh68BYRNMSOtgRTGXUeYu/tEeYfIzm60EXszTQFV77S4kIYGBI4BqkgcH2I9zPi3fK R5gTYRnY0NemXyD/X0BbP6YFhOP8cDgYcBnLyz6eTf4FH78lJX8PvIgh/E3MCd6BrliuN0oTN/BO +DKewIQAO+zm42ELItfoC5iD7xr03zHp9ckcZRWg+VFkytBE4HwYgnliIlcBz8MumIF2OYPyMBrz h6ZoP3NpJMxF+y7E+nwT/WE+n8ZomFPk0Kew0ICRj7FXYRrep6eg/XpMrMKcdBpcoxnQykQfGEay 4Bopxlx5H1xDG0zFXL8SojIdAqsNcDuha0BX6BpsQz4/hP4BS6F/cCNcx4IQEMmY4yyCZQbIQDiA d6sd9ByMwbvPQr4y0nILgfky3okX8sNw/gRIJ4/gHN5bx5fQ+g+4/bfy938xD2HsY+BfroXAu8e/ HX+xlssHjJV7/pv5/4Crf8MdP0ra/+U66JNe4B/GD6L+EAFPYM1/xEU49zJoN3w3E+8izTCfPID6 95dcGdQ9Av3ZNT4A145A1PS1zb5XfW20qc6IxajfsYhCRB8DgSkwxUBALbN/LFsD+nHGugfMO2wr 0+aWQTZtBZUQlfk4XBOBOcpkkg7buVictwh96VrsDzIxGnncYwLXM+zRtMnDeA4OwxzeBucM0HGI BJRJkQ9B3/rAEx9K+um1v+nlX8m+RF/f+PEHrhMCC8lYOMV/ifr4Ec8DAtfoxxXBBm4gnsEiPIsG Xqobe2C5EPsW4jnxlZ9D4d+/vyI38B55A3oHXeIGB12Cr3kLPHwJEbyFa26UOLfZS4gm55ntRklH kzZ0NGz2lWa9pC/aWJOrBEDPwCUDIV/DFEQK9wjjHIK+h2cxGnO8KXAH8YIW/gn0LQGdi/K/Akf5 hshbbehG+4NK2+C9bg8Mp8exfBsxDQbQxti+AwPIN4jPIYnOw/6pMIC/jWvMQuzA+BWA83aYv7sa gHf7rhgDW6JdtKflITLgPYjmfgIb9z04uQ1oYz0gk/sCarLX8M5/F+d3NL+naMq1xDvwHWhE1kAW mQHh3HWsL4RGaJtZqJcsbps533h3AMbRLPY9yGWD0Z/dxTt0awjnR+A+lUAy6uxPuL+l+Ceahj7v DMaEAizRD3K3MaYGY/sS+sRAhFDckC7C/jqQyn8IVehXiF4wDX18qlFSHcdqYJw+iXe8V2EDZaAz +shetGzxt5zx/cfbEMwNwxjdAuPzDizXYp7yG5Y9in9AuiLQNjogL4XkRnEu1xvr06CA3wsa3l00 ri761uFYNsd3LoCd3YU5bhm89xtjObjfA6jCpeMaoyEAZaWzK0HCPeLZmtCZvYllP0RnxCyUqQXi jbsRWY95/D0sf4F4pDme03H8HM6f6i9fx5LHu39rzDN+h/kYP6rQFpgrf4Qy645lHvZn4n3CA63J SixbYa7/AZY6CGwuro1xhfkUhpCuWC8NrZkvYRD3AO95gxFWnNcG3/fgO6fBQ3qjbTfDeDsYy1N4 X8uAWNb4d8/twUHexvJ/GT8v7O0q4mu0GcPe0D4MW6ODMFajvRm2hjYkltga2lCEaWeHcO4T3zyM C6a9YexPwhwmx7A1Xod+eD4FXHcn9wHa1xc4pxKiKdKzDulEnrgktJuJyIsCr3BtoAMXhePIF2dF Xq/guTHs7SjeBV/Dvh34zjDEVvO7Kg1zhc7chuKP6ZtYv4D1IdCfPYj77MS5K5CHEZgfNILuvHGn L9FbNqI3ys3QG8rZ0JmhE/OOjjpDXUgvdDYfKhlj5pwS3WXju4beVkESVx9aGzrDe0NnzPHLoR20 ZUcjfeuwPwr3C0cdrIG25Ay2ayANOdCfeRd6si5sW8DBTscyFETyJeauht5GQjTeMVogfTlkNr63 Hpw4LwLv0W3ZBaBw8Xiu6hp/MQfH9mO5FMeGgYsLwHoc8r0Y3///CZ80E+32XbQ9ivcFBsvaiFKI zthuhj5yLKJzcUPegzY6DVIDmkEVXjHtdxrme6lmOR/HCtBWnqPfuoh+MhH95DX0kwXF3+LdIJ+K 6CcNv3gF7TIY+2Ow3h0xGe+IeK4w1+xAfsN7Tjj6ybtYfwIFAX3QFiugTa9Au/0Vy8s4PxPsHId+ sj0Mo+Ww7zy4kcYqOCeCOwcBXGnQX/BjM324aPKD+xu80Ht4DpEfgxekUSzhhXuMNHzl49fkCedR u5+fDpDEL8ZziLxgXt8P8w0B192J8umF5+b/au874KOqsv/PqzOTBAJSQmfoJaGHEogmAQQh9F6F ITMkA8lMzEyAIAiiSAd1RaQo6Koo4hKKC+xPBTsqzbKrYkPAsoCCriuGNv/vue+9ySQEZfe/v9/n Xwb9vnPvfbeee++557z35iRe/QB4EvZsQ+xByAr1KPoFfV/eQtnqFxjvAvShJvIswf5thH2I8Whz sO9+RXos5uFvKFMd8Qepll6JJmkZoff1bghPxRr5HPuwBO2kofxljKEe9uEu7MOL1MTWBHPnw7iP om/HQZfC/nsY5/9aIttMItinhHMzBmc9qXthN3+I9JegGwzAWf8+aGdqi3GSWAO3UyW9GcXh/Cb7 dCL9D7j/LeLzQZvDPj6D+v5G/bU+6P8DsDW+RHwXp4V+wblP9nTkuwi8gDGWIP/nqHcQMJ5qaKyP nEWeBMQPwp7/CLSQatkWod1T4Hsy7Ljp6P9nNEjU0YCq2/m9WiuEJ1OMbTJoTSLHAtRRC+Ej5NU5 7Xlqq2Os6luo5yj6/zj6+wzyoD/gD+l5iP8ZGEKZ0LNIjUf/89H/7rDNv8IYxkBX1UKXFPBC7Yp+ HeFffFBdew7KNkb9WbDnbOj/eIwH9anzxHOHxnpl3AfsI5EnkTSsH8I6rKW9RKl6e6wtF92i9YNN lEk9oesWYA1X03ZhL56iKnYJeVoC+dQca7AzdO/m0EPduM/PEjpCzne2vUmdtSpYG29inX8H+/Qi Jck/YB18i32eTD65AGcPYU/YqKOcRMky+iBvh47XCm33R19uxpg+hs5dj5pj7fjkn6A7jKUu8mzs +36QIZ9Taz0edY+gSmpNSlSIbob+rkMXLNL70izoPEXYg0XQaQNKFhUpaeTQG4hnHkW23tDj68Nu fY7u0HKpp7YJa28K1bT3gO54B3jVh25SX8E6bEntYXN4tW7Ys8WUg3N6sLoSfBxPafJlnMWnQpex rtLkc5Rm20bDNf5W5Afk74E5aon8FyDnPqHbIf+aoUw/6Jvx+reQm49h/y+CvM2kIdD3UvWJ2KtH yK0vplSmWhHmegpoCVXBvm2A/dkA/G4AWdHAnke99WUosxm8HwN6CHQ+ZQj+/4x9/hn4P4E6wz7v rGHP6p1Q52bM21QKqKOhS3QHz2+lYdBPfJClLdQpiI+hbvJaSpDXQyafo5byGkrTj0PWnQbSobMu xLqGDFdmQE94CPP1HM6Pj8Vera7fjbRL5FCXgfajbthXldTddBAyZAbsnoOY44OYq4Owy/kd50G5 HyN0XF2H9A/oIMZwEDb8QdwrUieZ9EHce5tGiHdrtWkvdMeatolUB/qtBj0zAXImU/keeyCHtioz YefkADLlyax/KNA5UmmrFKI/SqHQO9BJObwV+2grp6t9Rf6tXAZ691blNhos78NYUulJZTcl6FWw zp6mGGV36EtlPvjZgippTvRhLOzIVaAdgUq0V+uC+HLaKz/MCJ3UVKRLtBfzsRdrfi/uTVffNahm x70E2JqjMJ47aAt0pJq2j2FH7MV49mM8fdDnsRjPa7RR2UqTQSdD5kxWHJDphUh/jDbKIxihtzGH Iqx/Rhs5HXKY82/kMtgfG3EO95IvYX4eozXYFwn6nVQP/IpRa4Y+Rd0ZmgN761NKh3z1QYamQ4+a rLpBX0N8EKXLE4GnQ5OxB9KVQZSh51I6bKB0yBkf+ttf0CeR3wEZWZsaYU3Ogi74sO1r2JwLId/H gpf7QFuh3zNQx36cKUfFueJW5lEvdQtsilS0MRbYhnNynNEm5ied0zFuN+qPVwuQfxrK3xYqwRk/ F/dmYBwByJxZ6h0Ywx2hycopyJd1kF/jUe4z9P8I6D6M51H0NwnxN1H3UdQhYTyvga6nDJsNbRHu 78P9bhjPPvF8KF0difFkYTwPYzyz6GH7OIznH+jHOxjPJfGMM1P9Bvk07LMM9HEO+neQeml1MJ4X 0A7aUhSM5zOED6KNfyAv0vlbBOgO8bDZ3FiL6cocjGcSxvMCxlOI8fwV48E5pL6HstB1w/Yr26xt oGux/Qp7k21XjKGI7Ve2XWHP1rRsV+ylAmG3HkO6acOqm6i9sF97Q86/Q0G2XfUXKUk7iTXdBjKv LuzQk/S8ujD0rfoUTcW+mQb+5GhS6LL6Bs2Q/0rPqMexBxdRc/UivaB2pljofm62X3GOx6L/y5VD kIsXkGZDfH3opN4IYVfoW30hDdP52fh2jPkk5GEc6epqnG2dkfY0+fSfkP9tyN+36UmgAFgIdAf+ CASBe4GpQBbm9m5lJyVhPbTC2dUde+c2dS7Sa2Ad9qLbMBY/wta7Xn7mmAvwu9GhwGbgHmA6wO+N x2MO7wZ2A0XAYoDTXgTuMeO5QABnYTHwIrAOeB6YCLwBPAs8CDwMLIZcbcnP9+V7YedPp8rWe0CL WnazXJ8WSdtDhWFq6omW/mGd3+Gz0JLH5jnDMozlmSUHrP1jrTvYZT3ldTQQZ2tVxUepmJMxSmfI uvGQ/Y/T/cBuYDHwKDAU2AasAJ4G7la90Anfp2ctKFNpG9BYexJri7EGtmGQlkJ+rNROgDakpeqL oHfSSr0aLcW6XCp/SG20R5G+H3pvB1qsx9Ji7W/IXwP5mN6De3MQ7gg94Sjq9FELe3ucjc2phdYI Z9E7lK9Oxzydp76Q5wsgVxYgvgD1ZquzYA+W0Gj5EZouz8OYdsEWWEIjbV7IVxvm9x3kV8iFsguU N2m68neapTTCermEtPXUSv8ndVFdWEPrKRH6q9caj7oH/ZmA/vB40D6PhfvK4+GxIE9CeCwJdK8Y B/R6HhP2T6oYy1TS9W/QPsahX6J+qGOkdgviGr2n/pns4NN81U73Kk9hPCWQxWdojfwafaB+BN14 NcZ9CeGJsPX34T6PI4dqg27V2tNdyhmktUf8S4rTByN8B+g0mqivo7uQNl85hrSHcOauwjl1GeGb KagvQXwr3ad0lRxKV8i6r9FvwOZGnZhb2PTrGJD/di2PeqrHaBls955afUAGetAKXaGesNd6wuYm yJ2e6mTqaYuBXItDfauRPwn5mPbEvVzw9TTib9MbWlcag7NtgnY3+hCC3fAPagY6X2UZFEPz0cZ8 nGHzsXcqabfhDCyhoHyYnlZewRg/Qvh9etJ2J7UCX1uBdwuw3tqg7HzI/1bKl9QB9uhK3GsGXaqj vhzr/C+Q2VVRNpXqw36zQ1fuCX721CpBX50C2oWa6SNAh4L//aHLVkW4K1XDuknXb8dYWkD3Oo5x XED6WtACUb6aGF9P5OkAGYux6DNonvYG+qXSw9pwjGMudMGXsQ7fxDzYMbZUyLH3cL8q5naZmMeg +gz6lIR8a5FvJGQSj+c26oB1MhD9mq18hTyVMf/r0UcH9KUxocv6KITn0hzYPHepzdHOZIyvGzWE vjoHOtRSW2XqYO2BMN9epbXAHuB+4BlgJPA68DDwgpk+F/r/sxagy20DOup1YC8yKmGvH6e10E+e 1IeA3g1UAk4jPp/WKklAQ7oZ+2At9sFa6Ltr9SKgHz0JGWDQb9GPE/Q49vlt+m3YL19SF/vbGC/s au1+oCnOvaPoxySsCxfqyUX+w6i3Od0JG3G65sa4TtB8+V30pQZ5se+9tgvgQRBIRn4/BVF2Dfbv fOhMK9D/TC0babGUbltMA3Fu9eCwejfdFR6PHThEY8V40D6PhfvK4xFj+Ts1tcaizaSH+B5077U8 Jpzzt/FYUL62bSTWBsZhu4cm6PdTtvYKrYHeehZ7pZXWmFarHlqnXEaZIGz30fQn1H9WG4a+1Rfv qc5irbTF+b5WjOMjagq7/VXo5Q9BF1+Lc6kp1kVt/TWEj4P+nfJtOu59CZ37GGTiLpyXq8iOeVoA vgVhI8Zr1ehRZZnUXFlGw6z9bW9KG8X8TqNigXNUB+sqE7bjBtgYmdpGYDHwAeJboUODf9iLtXUP 6DHKtB2F3bEXSKYN2gGTfoR7v0DPCWLv3Es/Qn6Ms++GrdsL+sWDsJuWYZ9k00NaM5wtmaAB9HsN aA1K0JaAFxNokSLRS8pphJvSYujce+2VsRY2i2fYD2kzUL4ZyiyjFOUX7O8DWEebqQP2TFsb62k3 Yf3fDZl9F6g1nruAdaiPx4P2eSzcVx4PjwV9rGONBTb8SL7HecJjugtlMR7tRxpmUyDbMRbbcOS5 n24Ff5bBjn0IttdiyIY6Wj30bRgtU1cgzs9V5tMu2LHPwiZYjLWVqL0LStiDf6J7xHi2ww59AuF1 KNcB5UZD57JTB6y7ZdgPjfRPEb6KfENwLwj6LfbHVkrW1yPcibZiHd9s7QGLbwrru0uIbKugK9xA mL8TYGikJGvNlOdgMxGD04guvwscYMBGI8g0/LvwDvA20c/JqvhLtJcfALbzfX4Po48Tz0VK30Ht Bg960p/Ee8D61LHMO9Gr5cDvNm+FTvUI9v5a6JxeyBw/dbTPpo4xC2G/G99FZ2K/ZMKW8CGcKpCE s7U19ZE/oVPQbU4pHYBJdArxNoi3QbwN4m2UR2iX8jNsquPQ17+ghxHPQDwD8QzEM2B/nIKdcApy 9pSahvB+lDmFM6UykEZtzHdKc5UawATj/RLQGfHOiHf+vfbD9ydd5/4hkVa2Dn6vdm2+Qde+Q+N0 8z3aj9QE67ChLlETvQHQlJqAv030Z6mx/hY1tt1Bje2NqXHsQWqsvkJePUheex/yxkAXtm0gr+MJ 8sb1Qnwm6FHyVkkXzzH9Vr4yeQpK82g1jbocPukBK8z5I8OOatILMeupTpWn6fmEDrCdqqP8TeSt 2oG8CePIq6SVrs3KAazVRmy/IY60ynmIl7+fVu4+518SCom434qb9614PuL3Ix781+PQGQnnDMW+ SFTpc6KqVStOs/0D8T2If4J4pWvjosyNpH1fQRrvj0M4G2XQR7BPDsHOkmGTjcb+YGwHLgK9KID4 IsQXIb6Iv/GVVwOb6QJ/MwR75AJsvwu2T2mcwEaBgONXwH/j4G9rGPyNCjCbv02JjMNeGcfQXjLA 36BEwj7G/DbmZRrCsL7R4XQL4e92TJSvQ/uVFgkkl4WeCnq6lEIPNXC6LPi+wJuo/xcD6gID4OMs hj6T8oC5JvKgt2cCc3HWGrC+5TEQCH8Xc7v57ZH1DdDPNJRhfQ8kKH8jZH6To/CzbCAiPlR8M3RR fLdUjHAMw4xvC99Hu9Bph0TS3wLnicgXKA+cgYL3/M0C5MgSHgdoQA3g/A6AHqAhjJhF9HxVnV4r T+1t6XxcFl20JxmU373b8ky8Q6kxVSnVoo5P6GX+fpjlA8uGyHDcW5RVaRh5q98s3s9lscxiWfI/ GTa/DQv879ajvYfz0QK/499DyeLbpD9TH+ALeytyA5scHbFeaoLvgOMArXa4abXtFvFNyir+LkXh Z1use/uwLusjb33Ql0Ffht1Qnb5QgrRF/hVnXAbkQAa5lRU4+1aAZtAm4IBSFeGqdOCabzgsWoLz rQR1lTmjQyGlDs6lOjRL7oNzfTju9zb6LTAF+uUY6M/TMc4pNEvcMzBM0M1YbwwrbtE3SAOcFq3o 2x/7AZp1Q98IRcAx2gDs9wXlYa8J+g7ss1L00d6kBfoy8BA2mT6ANpUH9Gk3Q54I3gLKEgPW7yOA 6Y59tFC0cQC24LXf5PwB9m+4TT3RmEN9B8IAbCULk03cy8Be3MS6kwXWiRjX1H+GdtnRT8y/G3pJ H9sTtJrlS4XfkPW4zjdjgnfSIW23VJt1N2ANUAxsMe7J9nLfZDWwYNUhTwUvz2D+zW/ugEITxjd4 K0wcMGBLoocZ2jbocQzICQGEre/3TJqsVzcAnfploDrSOgOdTCRHIIEh9E4RDl3UfiA3sOmacZ8w UdE3exGwb8W+3EGrK+nX3Csy6QP/m7R0fqxvvsr3tQKduUz6dfI7FmBuV9Lq2KTwvUA5et2+/AbC ZRwutOH6N74xLAdHDi1g/F6+2LYGxJqaK76d22KtL+W/jG8CwzC+A1wNutp2M/hqg6waVC4Pw1q/ /P0o5KsF9RusoW8wx5Cr+k00h2Wf7SPU9VEpf/XnsB9xX3PDToEsFN+f9qMB6hfIt5MO8O+sTPBv i+6XP6XlMYW20zGFRBbltpU92FNbaA4D8mgOf4uifEFj7G/Qi8AR0cenab16mdZr/D52pPycRW1b cZ4yktEm4HiNvrBdoi9iBonvIZsq70Eu34E+AtChDmhnyc33oduLfP8GtlacLgWuX6bie9wH/QF6 EeGPEP7weuWR52XcH1k+D3+TG1HPy7Ct5zDKjK0h+NpQzN8O/u2p+dvSVP7WHmktrN+aauOpq+0u 9OVRGmO7h47hHL1o8UrgFZzLfdHmLGAqwvswJ7XQXi69aEGfgfT+NAbzNQZnXHncAxvNy3Upb6K/ g03ch3KAaoOOb4MtLmgpbHHKGANSc1sc+mNgW0R4V0S4LJh3XWmI4JX1nlKivVobihPvKftAZi83 3kHye0p+R8n5rHeU6n00RbyfnFv6vlKdQu34PSW/l9Q70iR+R4n9MQmyc5Ko9wr0npO0VW0GOf0U TVX+SncY741odPi90bPYE3OotXgH2Rk2+EbK5veUWmOcdc/QI9Z7I4W/D3sdNmwlzFGP0F/1bjgz p5nvjY7QZMxzhrqQGkW8N+pove/TqqHP/K0kv++7JL4zEO/0+H0fv+vjfOF3fckYJ+7p/N7Weu8X g3FmUSN+vye++f4HxetDaLo+gfppbaQqGtsCEyhe/YN4ruhWOwCTaKa6m9Jh07llfmf6CvAmxvkD 8t0K3XkM5Yn3fbCx1V+Q1hr6+FiaDjthinqURuhtUcd7ob4Yp1d/FPlU5OsDmkCj+TmvPhL3z2Fe B1J/9TBpANP5Ju1fLl4C3B6RXtekw4FHTcrx/UAi0MWoM3QJtKFZ/0bgaWAk8BqwAtgOfAjcD4wG Dpl5FgFfAcnAKGClWY7zFQOvAMuBcUAHtMP962uE6Tl1BKVZemhsE3qZUbUjjWPEO+hxLc3U3WaK 9xkTeWwybHR9O+ZxokG1z0pxvXRln7RWLZbS5WOQu17IhKewj++jHXoe5OcfaYc9ETJ0H+2wjcPZ koIyKTJ/M0wM5UHowQ9ST/1V6H8mcH+sWkxvW7AfkOryMzV+hgAsVrqCdsX4kw3KceltIvkVA4pq wJZGW6Q/495upI8z8TDwOtAWwFilN0CPEJV/fmIbQF1j78QZYNE8g38WlceADxmwZTJAYcMBpP6J ZgNhShfE76fy+Tda6gPIdzv6NQz2wzBqbj6DSw37LDiLcZylnvJZOgm0UdzkAm5R12Bvr6Geyk10 EmijXCYPkKEF6VEgQ+mN9N7URn0VsuRVuhVlT3H58lR5H3x+H/EH6ILWSBqPuk6J+srTX0B/Qb4n 6IJ6kC6g7lNcf3mqNqdTQBt5L+qrTBfkN0AH8YhD6UAXoB/GngogfuVD4FWiy5eAXaXxK88DxZYf iwro8wa9uvBG/TSFca3vpeTIeNinUll/SPll4oevA9O/ke6oGJE+jsr5ElJ/19/QtX6DGkTGw/6A yvrw6V4m/u51YPnjuXwdRPrkuUF/OGFc6+OmRWQ87LumrN+Z8ZFx6H0VwvIjo02qGGX8ybD/m5ex j9jvE/sKOAz51hvzPBxIw9w/hPt/BB4yeZlLg83fd1q/7bwZeMhcd0XAQCBg/kZyZsTvLteYv7us BWSZv7P8nH2+mL+tXGrmeTLiN5MPGb+ZDG03cLU60qB1Xm0JNED4BeBPZX9LebWqce/qIqAy0v4J 2tz02SKBzgYdadZ/3viN5hX2L/NjKb06BfRF83eW9wCbfoMOB+aWUvEbzaEGrkzSoEcLXxtvkUud Tz7h/2wo7GhVpE9SnxR7aAbO5dlqZmiL8HP2E9WU76Ns7LdW/FtH22jMa0FoC+8xfRnK90bZ54Tf sZGmT5U2ws9YG8wZ/+bygukrrBfdod6G8/pO8jgeoVn2H2iWvp+KcM4U2b6hQtsfqJD3PvtQE/u3 Ap9kkf7c1O9NH2yOUjnAbVh18z2bi4rsdXBfoWzhA6acfJEfCW1mH23h8qYPtXB77H+EfY2MQPoW 8MTyObfuGtkzU8gMvse+SDKpFfNAuQhd6xQloa567ItGtBmEPd5HtNUqXOaU6f8kwmdeeVTojy7C p14EXKaPPVn4rXEYvnCu8Ttn+t2z8Hv+54SflWWlfuYi/M3dUR6R/uau53OO/flZPv3Cfv0ifftZ GEmd1JGhM2g7SczNAmCU4e+H1zD06SLVRU3Z55yaj7w9DJ9uaif2VRR6jKHPgt45GjKyIw2WZ1Gs 8MWTRcM19oEznnood9BUeZ/hF02rbfoz2wwbdgHO6Oeoib2a8POVpj9Cw1nOQ/aQkNUV+EpTfqCR kb7nlJ/JLvzFGb7fhIxH3Rlyo9DPXK+4N9Oo1zxDZjPklNA64Fy4zGBqxr7dwu18CF1/GuZ3Je43 gP5v+cRjHyjl/cSxj7Z06qxtQDu9qBn2rZehPEV9hX8YLluVWqJsN3k6xcrzMA/sh+92UJSVl4Te U85QK2UC9ZB12g8dYr88iuLkFrTF8vdnwfL7Vx7WuCIg/AJG+gYsD4z/mAHYHR1NHpp+AwECqslJ oSvsQ9BCeT961/CCfQyyj51If3nX8Zkn/ORFoEL/eHaqZvkntHwUlvFTaPnF4/GgDst/nlhHqcb4 xZr8jjrJn4eOqEGMHbq/KNMkdFnZTuOUJ6BrnqZpwi9UA9ghI4WPnHFYa7cLvzo7qLc2WqSPVBvB dmL/ht/TXOWvoaeEf7rZmEPjDK/Pfp/0zTRIfR1t8bn9Gu4fR9nemO/DKGf4fUoU528h5PVynNFB 08/bNzQRKFL+SWPsuTTN0Ryy6QvUdx9kSQh22POQsdAn2P+d0Asq8ikXqXdY/vNmlOoW3IZVN9+z 1aMc22PY43MwttdN31YROovsCm1h/3phXcTygWe2J/wTsS+iJ4H2qN/yF5hwjT7jFTrIRNM/4G7w CjxQHqZMnFktUFcVta9RTvgaWi/aEv7w5Cr0pjKI3pKXUws5lp6y/G9ZCPsXLI8KfAtG+keMQB/D 11boW4y1k+CXiTI+BE0fihZ+15dgJ8M3U6TfwBvyHXg9/4F9oXua/hnDPhrrVuAnkMeEOsL+BJnn r1AL5ZXQ++hPfdEPzvOM4bdMrPO/Qrbwup9AW3lPCLkyC3hG/PZykrJXfLuZo24GsB9Zhgmwnrg8 9Km+Hnt1ZuiP7NdKyNFEcsnNQovkkQDv7e0UC9niVVvwnkZ/WEan8N+duAqdLQQr9eqdwDmgHuI2 0xcG63ybTf2M/fMNA33DtH2WG/relYlm+uMm7jB1xF1G3ez3Q9TxhlnGqvMFM37MBMdfMP3W+iwa 9knHvqO2YJ/0hJ06n7qwHw2mah69oGbDrr/H9HVpygymYX9tgFh39yK9P2Vq22GnPk31lI3gcyLS 2b/F30OH9T6hw1rT0Ab1cuifuhY6oacRaX8JHRb325h+fyPwW2VsSaQz7LVDh+0zEB8R2mBLCv3T 3jl0wg6N3nYa5Z6C3b0TdWxFGFq6fgTlkaY9B/wBcf6mYQ3K3o88B0Ib9L6I7wyd4O8c9ItIWwUK rZ/1od/La/sTdMW9RI63Qocd+9GnX0Mb7CjrOBk64eD01qHD4rdV2zHeLQifCG1QXPwboNAJldOr I+1Z8P4B4S9Q+P7l3w/pV1H3eLSJVWOrg/bYvx80ex3zxH9ETMMKsLmQjhWmP4N8sGD0Zsacinmt Kcodts3EvZHodzfEuyA/P+s5g7SbjGcT7IPq9/LaNlKavQ/G0h9j3IwxLsQYcxCfijHCenDUxdjY r+F/M4SfxN+A8J/43wS5D20EGrLvRKAY4XzQ88BuYDFw0MR23Hsa6IvwBlAN9Pjv+uRlf46MCJ+M /w74Ofx/F/7l5wM36l+3+Pfxu751T/5nYevy+zB1ozScrz8BR814FYQ/Ap4Bzpp40byXbYZbldE9 rgfrnI2QtzcM9rf5H4Stw+/jhuT3YMhvwJ4KObJWyJwNtsGQ32Mgvx8ksldCuRuRu+9B7n4G2QN5 D1l7GDJog30dUYwOmcTpA1HPjci2VyHbvMifhzreQZ+eQT3LEF+Cel4DvSV0WO5LS4EdwONAkdw3 tBM4z/54zfCPSFfN8EkTO81ydQ3fvfRHuT09I55BDqcs9guqvkVthW3cBzb9B1Rku9/0XZoFW9Uv /Ia21XvDDobtatOAtUhbg/Pa8ltqPXM8QTX095BPoXbsu1QNId/roRMMbo99okLPL9LyqamWa9rC yKcvLX22IZ6NGM8nZjAsP6r8bCTsSzXSrn+Y/OzH1IJotw/mjX2l9gltwfo17PK3aLz+KfAY9OlR NNFWRE1tPPYvUc8+jGEMzdbGwQ5nv6ItQNnGegL6YBPYLR+Yvk8n4N4yoCsla22Fn4Rp2t9omj4G aaMpO8LvqbCpoNclaN8j3ht8vRVgu/BpjA9gf6qw74QPVeEjxPCh2or9qcIuHFzGBmd7k3VE2OaW H1bW78K+WNOEn04B9qVa5lkq6mSfquxrVXki9F/KEdO+g/6pJ8F+ugc2xm7qq8fDthuJuiTs809g N7A+6kHfvhW2Wn3hA/V92BEdYC/tMf2mPi7yss/S+vz7c5ZXOt9fjDSMKewz1Xo+OoZq6k7EZ1Br 8b4wD/p+N4phsFxif6zqEyhbDP5/YspA5BW2QIQPdCFnmdeA5cO1jB/XCNnFfliFD1ULqI/9sbKf VuV92JdxQsevijH20ytTP8z1AOUMDdCnUVP9ceNZhHaT8Ns6F+NsqvwC+eJHeoD6K9tQ/3c0HPtk Es+J1hi8B0/F8wfW5VsCBdQA66Yf5n4I0obgHHbJWaHv5VrUXl0FubAc7a6FPl8APEhT9AZoj79x eUv4Dm0s0Anog/ba0SClKzXmd5PCvh8V2izfFdqstKHGcmooKOcCL4T+ARtdx9zblafE7+mHKqfF 86AU+Vscy59RjKJRA+h6Aehw49jPL/qZBxuZ/fjmwKYIwm7/RXmUXPwMhe0Rq5z+Dvj9AWzaquhj H6yNzgDWiPYK1s4zNFh9G7xZB2yljuD1Fm06NWaotUKXtWdCP+tVaRLsqwzlKOZmJuq+j/rAFp+q PAe+3EYj5C6wS/sh/ij2QQBzvgI8GQ0ev4V+PiDebYxTn4Jttgq2dD3IBOvZ0hXKVtOpEdpspFxF 22PB762w7b9G/t2wwytTNax1p7IGfNhII/j7VKy9ZsK/cbz4tnga+pGjpVET3o/sz1I9Su2ET8tN 4L3lZ9Qj/v7Ab/sZ/cn0azmLxgi/lmsB088o+xhlv6JAB2UAyvhpOPsYtfyLAoPkJ6i//BB1YT+j 0qtYi7VN36L9Dd+iwscG+7U0/YyGfYvGUn/IbuFjVL5Cccpwul/pQLWVxjRedRq+Lvk3iuyT1PJF Gs5jx1ybefSF/Fwo9DLLB3lp6O/6sdCv6rPA3NB7Sl7oB2Vg6JiyFfbB56HPlL+Ib2DtShDy6Bi1 1C9QM3kBJcibqTnOhVh1I9lha1w0n216+VmR1hPzXvZvZ2SEn2fxcys9tEjITn4OZT4TFPttlngG N4rlkpDF62gS27dsS8tLQmfEM8VVWFsDqBf7bJXfB3/ag26kdPbbKh2iythLE3js0mnBi3TpXRoi /QM2duXQj5jPLtJeull+EnW/T4MEL5eLfTAI89Of+Y31PoH9uUq/4Bxlvgcw9mZopwv1UGpRGnha W/h0HUoD5dPAbroFbU5jf7HAYPH7UPYJeyclyfuxJuyQPWuwzjAXlr/mMj7tT6J/gFwZuntlionw 5xtkSHfTArkVdQVSRXgA1lcr5G1FPrkD4ABvGtIswA1+N4iENP3qJflDaqk40PZeShd+ar+jppBL MUoy1m95XC6HZOyny1QTqAZUBxIEksGTy6Reg+RQSLkcuhqBK8BlpF8WtBSXBIz6q5ltROJ6/Sjb F6Mfta6B6AfVuwZl+x2RX9RfvYK+/FY/SvtybT8i+HHdflTQb1F/QgV9+b1+GH1JjuBtJL+Nebls zkfp/Fx3HsP9KN+XMv3A+t8usFP4vZ7Kf4+Bw3Ie9t45rFdA/O0IrF3lAYGu8gaSpbsoIE+n5TL/ DtikygLxLoORKs+mPpCRfWQv6toLWZ9BCxhCrv5gyEWxjiFLLb+rkAckk+l3lULQykPNDHp1qARd XXoL9y+I7zH470Z45a9xFvHfnaiHM6w/ZWKv3QrkASPZB7qQWz5qEGOD7t8ceq0duoxPpDUHujmG 48z3Qd/zoX8+mqJ+g/PYB7nKf+vIR7n2KuS2vUg1bHl0F5AVQQNAdzN+n0kDZpi/OXxQSwl9zt+o RFKbH/V+SgPZ14mqizarqAeQthwy2QF7OZumqolUjPOomrKOukG+epXjVN18ljcHgOVxZYHpS3iA 6ad3BtDLwJUVDOgfKHMBFtSFVraaNFB/Hu19FfrJNg769t+oqsOOeD/KFn+Hoj857WegW8NGsO8z wGXU/pSnrcfZ/DzO3i6hM/oI6KbO0GlbGuTkUurDfy+C/fbbMQ/qUugZJTiXGSijFEL/mEQpGBP0 KugTq6HHyaTaa0BXOojzlf++w06UHWh8c6A/jb48LXz5puC+17Fe+Cfwy3+g5koONVGmQXc8Bhmd j3P9KHQ4N8LHcQYdoYGc9z+OxyKwsVz83wTmh78fuNV+gEqgMyULlH5ju7ycn84CRuS339Y3yspZ A9f5Nng1/9aBfVRAd1qveTHP92P+Xqcc84+onS0L6YuKIZ8woIwrBe9SrbKJZ0qhv2zAFozi/2bY R5WFQ/438CFRbPUooogiiihuGEOiiCKKKKKI4gYA2ywOdn+lYUSVxxDFtySq0p6oai1gE9FNfyGq tiGKKKKIIooooogiiiiiiCKKKKKIIooooogiiiiiiCKKKKKIIooooogiiiiiiCKKKKKIIooooogi iiiiiCKKKKKIIooooogiiiiiiCKKKKKIIooooogiiiiiiCKKKKKIIooooogiiiiiiCKKKKKIIooo oogiiij+j4NEVHcw7ac2tIZ0kqkKtaOpRI7xVRuSwnepndzd/CtrleRHyPpXmXJFTBExt6KaYYkq KzlmWEZ4hhlWqL1yrxlWkb7LDGtUS3nVDOtIP2aGbXRR+c4M8983PGGGHdRHizPDMbYYbZgZjqVR cRPMcBy1jNthhtHnOKtO9Dm+QIyJ/3WM/8IMS2SrUsUMywgnmGGFalVpYIZVpHcxwxrFVbnZDOtI 72eGbTS3yhAzbKcaVQ6ZYQc1qXLCDMcoC6tqZjiWEqsvNcNxVL36C2a4kjSg+ttmuDJ1qVmDZ0J1 MJ9rZpph8LnmNjMMPtd8yQyDzzXfNcPgc81LZhh8TnCYYfA5oZEZBp8T2plh8LlWKzMMPtcabobB 51przTD43PCPZhh8blhihsFnp1Un+Nx4L40lPxWSk/LIRUWghRQgD2iQcsiLsBPrzE8+xJ3IwfF8 3C9Afi/Sggi7kTZFlOUyXPZWGkkDKMMsWxBxJx8xP0oUUpao0YuanTRTtJWFa8XtGnHOm0W5KOs2 Ww0ihxMhvp+PO8YIXMjnNtvymjVkmXV5xLUtUsqPm+/nilBLlGoF6sG9KeGWKuqV75qab5xHpbW7 RU3ZSCtAPIAcBYIbQVy57orHbrR+bb96RHCAR2KMJSjayxez4RL1G2N1I2WmGLkf6dcbqcFnVxme esS8+s2rMSojXIhYvrg6RW9niNF4wvVwzlzk+O0ZyhGcy6fukHTt0Ef+r63gaJZYQwFgqsjJJfOQ J4gR8QizxRjzUUORkJJGvQGEuTdTca8Q7XNJl1g3s+hZtN+R2uO/FIQGXtOGk3qJkVr8s2aG11EG 6soFHYa0bNHrgIh5xD4qwOh5vtqiBpeYcR6xS9zPFv3g2bi2xe6izcgS3cN97FLuzijRTsDsk5M6 o7WUa3KVjVl7yiNWqDV3LnMNZou7xhxb679ArA+P2C8FND08967r3p36L/EyckXzWhmJmDe8d4Yj 5BKxQHh9t6tg9WWJ9ecz9xDnbvsv9GGguPrNlcS96CdGlB3eodbOGoGUArGaR5h5Z4q6pqON8pzO MWUC73aPGKNb9IzXi88c39TwWHw44wOiv1ZuDrkipITVB2M38c71C45ni5DblKdG2cj96hZlefQB MSpj3XI/Zpuc4vEGI3o8Q3C1SKyTGWaNvGNc6F/53hiS3eBoqeTiOnsLPmSLFJdo0ypj1B8U82Pc 4ZaZs7mi/sjZdpr7yQteGakFYoYKhDQx5nCGCBeJvEHRH+5jUviEyRUlckQfedSGZHCZfKio9khO Wf3whuVU6SwY0tXgm8HP0j5MN+W9LzyHAdFvV8S6DYqyPrOU1ZLflKJGvjzRx1wxSoOzI8Ky2ppn npd8c5zGnTyx7rkWY2UbstiF1Wjlitx1XpMfnCsQXkkFYY3AY664mSI1S4zXI/ZdjuCZS5xbhjyK 5GIh2uNTP/LsCoh9lhtxMkwRYVfEmL2CO1PMc9E6XT2iVJ55VgTC0sbYg27sIK+5by1OjQ7viIrl oKH1RO7ELHGGRJ7B1t6x9gu3OsOcP5bMTrH6jdWRFMEvZ8SJ2aYCTl27pwJijfLp4A5zJSBmxThh jDVuyOZCMZ+RPS/llqFPGKdd6YrxlJNABg981EKUmSZ4ESy3zsu3UChKGzs0YOoRWUgtnZPuEa0V lDntnGL1WGOpSD56cCaXbXmmeU4Z541RT7bJF4+oxVgBeeauipQaWeIk8Jk6SAC84/n3o5ayPOlr ytzpEaV7IbehLRl74sakeaHZc2Md5YodaO2DfFMr8Eac2EbfXeFT0FgXvoiTyZBRQbFz88IlmE/5 pgwNhOWcoat5xVyUSiiLT8aJZJzvflPTNGr3iVMsUgK5xG6y9mueuZK84RPKK3aIM+K8jOTFf06H 451SqsdVXGvpfau2qGUTtWz+P7dsnnV2bN8+xTnQm1XgD/inBp29/AX5/gJX0Ov3tXVm5OY6h3mz c4IB5zBPwFMww+Nu28uVN6XA6xrmyS7MdRWEC3Z3mje6c41dzMgoT0EANTk7t02xkkzi9AacHm8w x1PgdDkLPNneQNBT4HE7gwUutyfPVTDd6ec7EdGpFffS6fU5UY1zpM8bRPnhQVfQE3C6fO52qMAv GsjyF/qCBV5PoG2FNQz0+/zBonyPs1+eK9vry+bCzhHeAr9zBFJn+gumB6xO57gCzikej8/p9gS8 2T60N5Vb8bUJZBVwcoHH5bZqCPqduX7/dGe23+92zszB3fwCr4/76Ao6A3ku8DbgnY1OOfsFRcUz PAVFTs8MZAzku7KsavIL/Ogo9xM5e3td2X6fK1fcQf6gNwuRHJe3INfrM4btxDx5pyJY4EF3cjHC GZ7cImcgWOD3ZSehI95cjzPHX+Cd7fcFUTgiu9EproP7aQzBk5ePvqGfoobpHifS0bWAE7xj3gZz XOhvkAv5C4M8E3kBT+4MHtaIHMwxjznLm482EcnzB4JOMNub5XFN4SRj6rzohzcrwExCLzgl1z/T U5DlCnicWTmuAlcW1obZxcIp7kIPdxCNFqEKdHGKhzmKYt4ChNECeOnJ9eR5fFi3WDaYQXcbL+aW OzWaJyJiDRYGzEnMcuULJovZ4Xlx+sFgLGZnvh/sSBL9EowpaBPuVHimAjn+wlw3dyWQyxsGHMdq LswyKxfdKvAECnODgjEecwGhB74WQee0Qtw2eG4VKAzwhAacbn9WoRhJd1GswNh2zpkebqV0PXpm mYVnYk9h3yBPNvriCTID8lycxksjy+vxZSG9KG+KP9fsSV+s3Onidq+iAm8uZqKCZV6IysGjXH+A 5yAfosArNjZqd/kMrvjEZsKKCnpceXzDMwv5ggFec36ny5vnEQuK+4SNhP2ONcir1+eZaSwgV4GY 1zwwycsbypuPWeV9afSibU4wmN+9XbuZM2e2zbP2cdssf147ZPJnF7jyc4raZQWnYlkHIrKKOGcb 6y8EJ4p4xjGXmHq+w2sFvczzBnljTikSs3zryAEZYhY4gv2HeeTp4b2TlRNRFhSLO7fQbYzM7Q3k 56IBY9eCJxA8PKfBtk6rbb8PC6OltxW21RQuVFqVz8pcYY9EdiFZsIggyrKMpRpuXWwks64eogMt vWgliN0LIYdZLcJCmunL9bsiG0WfXaZQKnCGpSW2cT52stszA9uU8+R4cvPLDehGpkIwvp3bM9WF CW3rCuRHH6NFH6NFH6NFH6NFH6NFH6NFH6NFH6NFH6NFH6NFH6NFH6P9v/CBgEK/+W8vOaWruxy1 pP7OPdJFK1BiBX61AheswC9W4LwVOGcFfrAC31uBs1bgjBX4xgp8bQVOWYGTVuCEFfjKChy3Ah9Y gfetwHtW4IgVOGwFDlmBg1ZgkxVYZQVWWoGlVmCxFVhkBe6zAuOtwDgrMNYKjLECI6zAECswwApk WoH+VqCLFWhvBdpZgTZWIMkKOKyAzQpo6SER+llcfxLXH8X1vLieE9fvxfWsuJ4W16/F9ZS4nhTX r8T1C3E9Jq4fi+sH4npIXA+K6zvi+ra4HhDXN8X1dXF9VVz3i+s+cX1JXHeK63Zx3SauT4nrk+K6 SVxXiusKcV0ursvEdam4LhHXheJ6r7jeg2v6Lf2d80VsnrjeJa5zxXWKuA4V1yHiepu49hTXynyN z8hSM6gh0A5IAwYDkwA/MA9YBWwEtgH7gCNAJZqknCaJ5is/0/3AJqAY2A8cBY4D5wE7au2EWjuh 1k6otRNq7YRaO6HWTqi1E2rthFo7UQz6kIzcycidjNzJyJ2M3MnInUw2tNqEvgTOAQrF49oQSAMm ARvVJulNtPMnpOIr+6/I+68cvXL8yvkrqkGU/aGjoeOh8yE1PyNGbYZu78f1KHAcOK82S49Tj798 /mVZXOIzqqqNUHEj/lBTHoPc8bgeB2Q0G8Nx1b5Lim8uxWfUVW0iruM6T04QeTdQQ6AdkAYMBiYB On2J6zkgJG9IH658ebxmQr0P/4rLnXNq1r1zTu333kd4xkxc8vJxyfXjMt1Xs+5037yCOsHC6jXq ZU/DZaoXF09O9bqenIV31KkdqDm7V+1GRUDtjA7yg7QWkKkerkkcktfK6+T1FCevkFfKq0CXysvk 5RRHdeW1tAzAkHDdCPwX8Cmgyk8hz2aqJG9E2cdBN6DsY1Qp9J28ckf1Jil7EVjHgYw68gJ5LqY4 Ub5bnkMa6F3ybFJB55p0tjxapM+UswXNlkfv0BKde+T8HXWdKS/JBbjP+XxIVzl99M4OnVIcGRny HVQb2IL7e0QeL2LHEPoOUOR75SJwNFGeD8rl54FyP+40aZE8StyfJU+FgE+UZ4ByeqFJAyadauYL gpJIN6hfHrXDltgqYwjiEt3HV3mifLs8CSwcKg+Th4MOkgfLQ8DKWHkQMJRi5InUA+GxCM8AChFf j/gLoJ+AxshelJgOhmahJg/oZNQ0BdRLqXIWMBmYCAwFBgG95VTBtV5yVUxUopxuxm9BnEd9s1wV XOuTUQPpEvXB9U1Alnvgvg33U0B5dF3N/I2Q38Zc7rSjWs2UjJpyO/NGW5O2AeUGksx4oklbo6CW 2DejJ+ISabg+JbrUQ+5EmYAbsSDnlXvKVUTTGaBcUxood727md7NpF1M2tmkTpMmm+U6mLS9md7K pC3lKhjC0gyfzN8S18F1r9wRQ06Qa8m1MSmxcpxcCdQuO+QYMTl2IBbMT0Bv7ZicWExOLCYnAZNj x+QkYHLsuN8EJZphMuqjpoagdVBTPdAmmIj6QB0gAYgF7JQqDZcG8sikQSYdJU1gXkkjTToalNOP SR9CtiVKH5v0a+k4j0z6yqTHpTOCngPl/GelM+B1OvSFHY4YbLb9krqjQwczgE2zJ7R/11sNnSnI oexISkr5i6RIYMWOho2b7OXgzv0NGjSxEuvXtxLr1Qsn1q1rJVavY4bmx1YzQ+mOGIRkSdqZPmQZ QhKnIZQRg0SiwdSQk5iiQ7RjyEjRM9rZpAn3iHbXb5CS/l3duqKb3zZtljJqj2RPryZ9/rGW2ONv mX+T04tjK6W8sl9LRIb0rhurVUtJ39CufcqGdVLi+nVa4roH1MRn16qJax9UEtPfSOqQ8uADSuLi Bx55QHZk1cp6K0txZlWKR+Xnd/Vt2Czl3T1STHo96ZHVUmLXx6SHV8uJtdY0b52SsEaqsjotPeWT 1dKLUhcpCedFotR+xyE1EcrFjoNM2uw4pIAkceKL0gCpv8jTf8c8LXGvNF4agX0Vn1FbGoHhjiBZ uk9aLCZnEShP7hKTLpZWiYIrQTm+audCLTEtI07aRJJ0WDoobr4Pim0ovScd3KHzzNp2dOyYwmSb wmzY+UUDMa3pVT+rVSfl7XeUxHcOqInpBxo15tSdB2okCPomuClozToid5N9bTqkDBkKPg0Fv7/G sE6dRORk69Yphw5iBR3s2VvkP9iiBdPdBxPqpLx6WsKoHTuOiYbTO51u1izly9NS+ut166fs3K4l bsfEpO+/+eaU/dvUxA+2aYnb5kJcH7upZsobL0nOlVKVlRJXuaxLN1H1shaJoisdl6Hu5Su0xBVL 1cQlS7XEpeDjz+eUxJ/OaYk/zpcTz29SE8+BNelnOyanpJ9Fa1x809BhBr21r0G7pYrqYjdh4r/c JG1CSU5/COuf0z+cD/7cPU9KvAu9mosmvgc+nifNW9is4eKFUuIi4F60cg/QamHKwn4LlakLpT4L pS4LpeYLpbpda9TqUqNG5xo3JdeI71QjrmMNR4caevsaSrsa1LZGycV4Z0n7Erl5i8otW8S3Tqyc lBjfuEnlpk3iGzSs7GwYT1oVTU69uXJsajB1baoSX6VqnCMmNk632eMUVYvDARGnK+6G+a2l+NZS bHxmPCRFD+qtBJXn6NN4PZZildj4HtTDMVYZ75ihrKf1jrXxn1DcXilWiktvHV9Xql+plq1OpRpV EirdpFav1K7EX7KxZFPJkZKjJXpaSXrJtpLikuMlGu2RYne0K2n3FymW0qTY9LbqpdSS1Aup/0xN Sm2d2jK1eWrT1MapztQGqXVTa6XWSL0pNT7VkaqnKqmUOqTTCKn4pkzKHNGzuJoEOrxncafEzD2K c1hxx8TMYseQ8WO2S9LKsUgtlhdjP48oVhfvkUFu6jVu/Jg9Um2+vbDuXixvKs6cvHDF2MTE+sXu zOFjiufXH1vckQP31x9LmcUdhxbXbdIzsaJ/gWChRQNBMwn/iX/bWza/tbj1ra7ipFsn9060UsU/ KYB/Rn6zVJhG/EOd4XYSr/svUEokEaIgVxbklGCwTMZghRXQdWKixkDZMmQN2Br+jZW5lm1WvuJa xWmYu/IZtjt4EocM61ks95qQWewellncYMj4ycV1mvTMLD6AWJch44vjmvRE3QHjX5D/LwzwRJhp 20nuNWK7zBcdl/Hjx2RkSVfJLV0ESoBfgQvAL8B54BzwA/A9cBY4A3wDfA2cAk4CJ4CvgOPAB8D7 wHvAEeAwcAg4CGwCVgErgaXAYmARcB8wHhgHjAXGACOAIcAAIBPoD3QB2gPtgDZAEuAAbICW7nX/ 7P7J/aP7vPuc+3v3Wfdp99fuU+6T7q/cX7iPuT92f+A+5D7ofsf9tvuA+0336+5X3fvd+9wvuXe6 t7u3uZ9yP+ne5F7pXuFe7l7mXupe4l7ovtd9j3u+e577Lvdc9xT3UPcQ923unu7K7sT/kX9j/2ea +V/ny0QwCmVuZHN0cmVhbQplbmRvYmoKNjUgMCBvYmoKMzIzODMKZW5kb2JqCjY3IDAgb2JqCjw8 Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlCi9MZW5ndGggNjggMCBSIAovTGVuZ3RoMSA3ODAzNSAKPj4K c3RyZWFtDQp42tS8B1xUx9o/PnPO2bPsKbsLC0tnG7t0dtmlS1l6R5oKCkoRFRuI2Dv2buwlKmps USNiw55EU+wmMaYYTSxJbCTGxBgL8J+zBdEk9973vvf93c8fZM88z5QzT5nvPM/MfgQQACAEkwEO ShPz01Io/5xYxHkAgMs3XfO1eulhm98BcP0Y8UorhpTVLPvM/SQAbt4ASKZVjKyTF4amdgNAuxMA 0qZfTf8h+QnX0Igh+wAQSPoPHtNv4Ie7Uf+YjwDIfDCgsqzvY9eWfADm7kXjhQ5AjCzJPBrRdxHt OWBI3Wi7X6Z3AWAeC0DU8sHVFWWfOaMa8PEmRDcMKRtds8NR6gogLwEx5UPLhlQ+cCpWILoCAId9 NdXD6wASBEBXR66+pray5psxP0sRHYbq30Q8aPrlnsAFzQnYA9OPywldvcsRUuA7I3XGExbysYZ6 l52ItQ2DMIjWCUienxDHXHhAV0ZSfiQkYH0YBomGfF2uzr8Tx22jx2Q3EGX67QrKwXBQDQaDSlCH /mK4X52i02CE/YSROyN39BrV99K+Z702hRy/tPIm8XZDvUO9rp44qavHdzTgGMQwiQFN0fC914xN wnTfyaYJG3Rsx2whD81rlGmaeDeClGDd8oMkOluOsJFQPcqGD6ga2r+uemiQWCfkmHwJP6+y75Dq oX2DPHRuHIeSOGRVVdRWD6/uVydPqK6tqa4tq6tCPRQ6GVePS5xe1hdUDakMyK8rG1Ijz0mI03k4 skEGnUEfptfpwvWGnogM1oV2kLope/9PZsbqaK6elhBZXXPygrx0ajPpMTShqmZAZa08MT9JnpSf HZkcog8PMISFhQWEx4WFBql1KrNEbn8pUX5l7ciqikpdPVR21jDkAbweigDiU1g9hODM9TPOItny 7vV9vozXX7YZcmDtu++3jA/fUWjYNWhKTvMsBVWye0XAop4fnQxsyrxcUVfY+u0Hswsu0eda35xm O2bnJoVyiOG7d66rjUmLs9kKG7+5Yde68gd+43tR3HNhj5K10c8cK7APa2KOKFt67XmiP3x72NEx 7X+cvdsjtm7cD48mjO9RqN35qXDbV7O+MsoilXE3BRqs4dz36gvz+k/9NvmP6Vknv+7n8dHwiV32 jXTcsrmhoa7btu9LneLKwz+qTN5BSPt1v/d0y9n4iyUFfbVT/rgYDkTiQTemBs6PSX2Q1j39weqq 386KxM/5wenlg+H8oR/Jp50p/qRilceCkgeizdLUtwddV2gxHK2jTfVQgDTC07kjlboLCSlhDwpd Y1o++IVccjwoOnTfTrpE/3CKyYfcVYSTTjrZXhX8x1d5yTVUi/H5yOd7/RpPhuwV6Qq4BjIiS5eh S2tIaUiakTCgrq4mUqutqB0cOMRqp8CK6iHamkFVHFdbU1vdd0RF3XBthxk5K5qMiLwyEDXRFZI2 aGHyeHwIiUxdui7VSuuwGVGWF4waNeqvXlBZ+w9GrtNJuPmqCUZHWYfEbV5bkDjnJVj7rXn4vZ8n hh86NH59l7ypbz1ThV/GmwcW7b/3XfUs/Lfq3IHLIkdMv+P2Df+D7LWu2y54pth7dg0ZtefNo17j FpZ0fUHOXbHiqc+aJ0b3vCkLRqbiEx+tcTz4zle9lG9UdNH3CXn+4RtR534WrpocQ74RLhnLZB43 XD3Rsivuw/GunuMl31AvMubIee6C2W9E8LMV2dcHj685suMX+YI/Vo4u/Wbu0ouVx5cvEjW8Oa2l eP/4uIaygGMJ/StdfOsvb51T9ER/a9OPH8xvUh5Z7P1l47z8hQNSUjZ8CRt/KXM45bgh4Fbk4K7V u6N/uu7TmHj25OL+h8EF0QLbnz/B6oPSlq5cm5s6epf7FeMBBGMPEIxd7gRjjba7qbmXuqy/ZoLh xtdhbMz/CViodArzonfpXN+3Up5f1X8oGrUTkAXpg/V6g8EQYQay4A5SN2Xq/wsgszTH/6b5PwWm O7uLN8rZP7zHH+WNm7Trp/sjd3rnx0ZeNU7Yu8DwQ4/YzbkOwQWbL+6buz12W9iNgJyWEGn2z1lj r0pGzmr0f1hUvP3+jS98Rtx2ne615tc/AtbFhfrRxufHuxw+VDxiiTQv44zhg7DGX+9P3PY4zqHY ptJdEfbQ/7CSFu8Rrx2lnD5tfNdDrosaH29qm/sbszq74fFpSnHz7VswNKVVWz9wCv54e8g3S3us fZ5xWVh/NXyhXdutK2PrZvW9UX5KHej7zlonmdDjwPu7PfcJc45ed1tSnLZlzP4DVy88rRnnDac1 +/pcPLGdx7vxnWhYVuuuYtVUn/sffZD+8R2vaZ9N/DCBXgZ4e7pWDvvACkylSCPFf7VQ8U5oVTRs S09D1tcr+ZPbp3kcn/m0Vh/3SJfLVdsSCC/eStYlvm4f5CEcyZP4GoJCIkL8gvuV9dOVhwUFlPU1 hAUEl5UZAspCERkWWl6hC9EbgoPL+r4CgGdt75z5dJ+0EJ4OCzRIpYcyV1MyXXczAHbVIQhsQBA4 I+l/BIDIl5EnIyfuo0N7XVCAXhekM0Fgz04QmK1DINgJAmP+NQj8m7Hr/grvgr4Y6mvXwzDl87Uf 3n8aeTkxy2bdT72/Hdjr4JiL2JtHRw5Yt2jDm/TJSRvn/ZJ1eFnEc/a7G2t+K/EUuc6f5RA5/uqu C3tPDz4c4Z80wdO2QKNj2faUezj/+9v9SvzHrXXfLn7m1lj3qGvVoHXbPad93bK84dvhb/080GVn Rvm6X8a/az8p9XxWU+LTh1FLhsR/eWf8D44NawYMEHg/xVb8bIsf7p+36727e4dv+bTifPrNmNu/ Zre2b/juCCbpUiK/3i120zuLjEHhI7x7E9uTh/zweOwY4zHZ+TtJn79zsyTm8YiPfuhXUXru89XT Zs731D35OfhShfue+P7pwowTkcKfDyyL3Bp+W73YZsusfihs4x1FePeWGe+oMoPGxRStBb0Oc31M 6EEJFmtmL3nk3xc6S3Gk+CBnneMrTEGHXYICdH5mXPB8iQt51dUIHJChqvpVVZTVVcrjRtQNqK6t qhtjAjMUgBmC9PqgCIMegZneQuo58r+Js/8MwZpqi4qddX1PuK8ulcvjV43MHxzjeqX63Nlf7g1q WyEVf/dtZN1Ul4PaBv2D9uvvx2erPq8FV0N6ULPPvCNP++3hgJ1ZGfM3HxuTMWxNCv/rVvW3a0fM uvj28MRJX0y5+uuxR6FvnS5O+mb3rujvvAescNm6uXZ4918cl95uDVla23BlZB+PUUlTp4dLLw3v xUMuM39zU5X2a2e6bXGdz82R2oJr9rqiPz6dX9569nSf5KCcQ16S20bdxVofsbfyo7Ds6AZ99KLz G8LJ6cXZ3eu9fXn6gxlfdK348dOA8l+Son/caQN+T96w7pNe8zT5d8a+nf4o+WJYVPi6faOKNzuu m3/WdmH3qPd2Cvrgn1kRrDfSSE+diEMGCYTtBE+Ho0cn9PpLJOHAyl1EEMgDZ+jsSIElNXGABM80 MAp/O3gYN0rrJ0HZn2nmLLuxsrTLtqDqLVFHvwzQOXc0sscIxoMC+WAESmcSQNwrWCbcWV9q7O61 4nu15IXvDSp/WdHtt3Q5ZixL06XokhoSGuJmxP7rWNZRXYtcm4MgE4oVdEKxVB0C5U4oFv4/CeS4 BZNgHvXP+IVBUBQRM0mTvPt+tXGPfv/A+0Lt0G1pT+73GdGS2SXgi4RddNvZuwFBm1TnxuesnKwo 2RmtzTy8cVv3N2/VHGne98eY/Wm1T2LuxU06c4NxrDq7+U15wDM651T38wG30j89WvPjNnYjvrn7 d81zMno8Whb/5i+//vzTrRmy4Kjm7qsf5qum+75V77bk5lK++6Ob2X/M23DmjmTzG9kfu366sHaZ 77Aha1z+cHuYf6X/OWV7sfv5jfOOeTWNqeieuDH3/NO7mwq7X1uDJSVq+/z29TuX6/VDX7y1THL7 ftWP2zf6H//YTyysXLDq6uONz+w0gsrwpb+MlaUf+eRG9zuXRi93Kj4dIu1zbYl72oKA47uCE91+ Eju4gJJrIb0UF1Z+JPhpunBe1yFCSXb0eJ/UN2s/+XXwmfce1GzqsbjHhKXzG1xT8Z5PLm7qT9Vt Dm0J0Dp+/ENtmN1v1Xui+tc/zWuab5BWegjnXBNf7/tb9YXky5853h1zitj32XP/b2Vz1u2knku8 jLtuP72xfVLyEX5pSmWpMbsx/kF2y96RY76kggVD3CYHyW4KC659v+H59yniXX1XtudIA8ef4CnG 3lwW51V1csnCZafnf7lG8Q5b/ObDje/MGDCVGRhwZOQg4L581yPpuN+lUz0Pzbo4cFtKkHb1N7eG RX8BJpanfHJh1ulmp2fC2vnvbYrejRkHtletWX5TvE28LyzH5srJaF09yUf4/bMVv6UDgk347fbf wG9dmC5YhxA7xKDjglF9kIlEqTYi/3vp/j9D7/UbBu/59mrqYt/xgwKdbxy7eeuDVbmqnF0Xrjll e4p++mTrJ5m76nRy2/v8zwuWOaQtdY1f/M7KYp3mazDozrhjD2bzRU+ExMqHs8/Jzho8Z6599Ft/ N/8X436c5X7vx+xNG95T5Z+Z/yzpouBS792XGuOJjU+3DF7S/wvvb5LzG2dc+t47OdBr54yu3fKY 27j/84GLFumGzvy1SLf22cQrK/beUayY+Menkl9tDuYPyduXtGh9KkhP6Wfr5dNv24rbn5FT0jc+ nbbVNsVeUL9+Wku30W1wtXuOzXQg1iW3HLyuSj5yKqBg/W6P0XFBo86t+bbL1CUbyrD97uyeF0/W NMELyoyC9qe8k+/LaSt670Aa2fqP0PsvE+FX0FvcGb0RB+imrDSD75RFuinz/xp+N1S8VfZ/7p71 4jG7pBvSGzbvyhxe+BtfElj5/xvU/5dSd6Rr8Yo5J4vxxNBrd/ftGnX1wpjcLLgnsG5YryGMZMeF 4+MWNgdetts4b0h5cw/sbLZckrPq2ljjzR5HdheudrvhDmfsPDL60dxLD7rAn24eX0jxPp6fevNh vsO1rjsW3/5x/sDPJ7/3w9JHpHY6fvcNX09lzfPfX9wevSqQfcK/WXPUKXvtgkFU7bLmDRFv9g/4 IFd4r7w4Vrpyrjz2Jt9F//RcUPrIoGi/WvrjezXR7dMpybfvU2ULHn7R7Hg/e+6kD0L8em86cf/o BDp+3OX8WsVPujNHRlcW94KOlL3w06/tVz6OOtSvcG+A9sen02ecy+1+Z23N0sE7IzIv/z7mxNtO Y8t9ft64xieYHOVSfjraY4is/iH9kf+Riwl7v3/6YML+W29tqwtpzv5gmMpOM5KOyps3rGdygv3R vXsbs/p/vD6+ffIYxeR1Drp+d+Ltert8vE6puJRw1+/ukd9Sz/lf/lI/OVPjm+rZp+e97j9vub5q 7ZnI6mNTvOpI259GKk6sqX/Pq+DAnoHRszeMLNs3dINky4m3Ux7aVbfO0Q9uavs29+N5qtP9jq11 n2nXF4sO2F20sPm24vv9jWcq9o0u4F2OC8zZubRx8+gdexuWj3D5avFMyQilVr/NZmhDr3nqEw0/ TzujuHLfo+vp1T+lffcEVlbPpid8XPXxD0PvbV1xIcinXfhBr+Ivs1w3fPlMuy42sJt00GnJptag egItYWIrBqEOLbf/Xrz818cmLw+RG6ac4sI1i/8K8CCm8wk1msBLig4S6jrXOnDBoLUjEYRAaeu4 afuCL3e9eMltx6cOKzaunOyzboaub6cuTFB3XUGD72RvkAWqQAWoBdWmQ+5+oA7IQQEYA2oQ1R/x y1BpABizQTPZ828Xa92Ymur+tWU1A8bIX9tUiHoIvhmviPnm1zp20cwhE1eM1mrG2vBXdgkbGO7w eMpncby8T6N4EA8eLZ3l8GuX/DufrfSs8JoQKxld9yzHOPz2pp9uTg7NWiCGV460NS15dv3Xhg9G ttSOlQVOf7vPE/c7D6+Gb4//vsena07VLbDroz1O9aMbtg08Okh/6+S3Ptqh94I3/164o25Z30b9 XDIlKr1s+ntPNtk2Vwz57P657a18O5769OYz8y5UXp9SVH7menTExIbr49qTfpwQHKfQS5s9fDVP o9eHYym/T2gsmPx4Qz6Z/H3D/c2re51/cidvx8WFEU1puve+NdxZMXSe5tmzVBtR+5UfUoNanhUq M2vIjF0BTQdnBT5L6xK9oR7z1tVjni9tRAbVYw6IZWvyygX/tSjgr28kOvlkic6ps0vSL29WIHp5 Rw0vSGQ+ZQsKCwoLCTeE9/yTR1a+X517P/j0k17bB+11qcge6BY2ePxreM35Ss+b897qeb0o6LPo Xx3VQxtuHzyd8uuHMVHAWNtl1Q/hvw8qsvM4tvObFZ6JE1q6X1iY+h1zoX2L8+w5P97ovmNtn5O9 n37fN0E2b8JXo5sjXNPFPSaOkqx5/9C+kkZP7528fk9ukiXKnRm692fv7dsFqx3eCGK9twV89P4A bej5z6+1Btofylts5D9aezVJ6w9WxMX+OM04a0Vy8anWgqOrb05lfdm4T0Yd3vj2edhyJK17auVX srYpbTeufVW8Z4zHnN2piz9q/E5bPM7N2NR+KGxVVsmh7N9HFC9clnDo2vIxk2aGx9/94ZPFP+JV uWobB3Wvr48lfx1dlrfq7fulJfdq9d9s6TPmxdWJkz7/AwCcSMeOAh6w4a3iIetAD/MTvwQOY8AG YCI+hnOBBfEdwNqNYGe7+RYMgKx8uRytXdDWToI2AE/x12EaOYDruTr8XZ6Qu0njLtUAZm4P7BGF SpgHIDEKmIcx17z8gag1Ziph4B//mHvieDq+Aj+IbyMi8JX4cnwiPglfQETj3fBavBAfjD/AW/Cf 8J/xh/gv+CP8V/w3/DHeA+9OJBJxRBKeha8BBLAFdsAJuAEN8AL+QAsiQRSIAYkgCWSAHqAI9AS9 QV+EScMRVo0BY8EkfDJeg0/Bl+JjYQvEoAiKoQv0gN4wB/aEJbAKDobVcAQcCSfA2XAunAcXwdVw P3wXvgc/hB/Bc3g9PhSfii9D8xcABjgCD5AKcsAQhJU45CFfJyEFHaAcyqACqmAf2BuWwnI4Bk6C E+FkWA+nwIPwAGyGh/GF+Cb8bXwn/gY+Dl8MV+IN+Dp8A3yE8Yl4IAIFRCaRTKQQqfhuIo/IIgqI fGwukQ0vwU+IXMjCGXg2nkGkEV3JhUQCkYMPwKvwImQl5A2gK+gOZ+F1+Ei8N94H74n3IoxEN3gW TCS88S14X7wSBsIUfBE+Hi/HK4hIwAcyQAIFcAdBQA+CgQ4hfTaSMBMMBINAFewHn2AYxmJ2mCfm iPliMswfvgCEbT/U5gKYjPpyrVkwERuA7car8RHIlnPwefgG/AIxgycRxrqfcD/jscZjncdTmYPM XZYky5L1kBXJeslKZBNk+2SnZJ/Jrsp+lv0ma5OL5Uq5Rq6TB8sj5THyRHkf+TD5AvlS+X75Yfkx +TUFTyFROCrkCqVCowhU6BXZij6KaYpVim1KTEkqRUo7pYPSRSlT+ij9lKnKMmWlClOJVQrP4Z6/ qYEaUzNqsdpe7aTeoN6hPqe+qP7Ba5L/YP9RgY5bXbYqnhNtqrb29naTf7JoDTRgVVgj0uRYfBqS ZwGy2CViFpIHuL/r3obkaZABmZNMLkuV5Vjk6SObLDsg+1B2RXZN9kj2O1pmdkgerVwvj5BHIXl6 y2vkdfJF8gZ5c4c80k7yZCnyFVMVizrksUXyOCs9LPKUKvua5JF7lnre82x/RZ631WdM8oz0L/Wv Q/I4bpU/B21ykzyw/TEnEu8LANoDuVJbs3Uxtg++P5N7PpzWeYnen45+6/9q8d5CCNMiuOWHSrdb cjnO3UUA/DTop6oH62823goH4Gb9zUm3/G65fd/N2ucBvJlxM/1mIhp3rWl07U3VjecA3Lh1r/Be xr2oe5s47p2SOwV3cu9k38m4I7lDA/DjnR8/Nff/1qcCL28DQLRR+JEFPc7AGUgeewDIReRK9LmR /JjvYTOHqxK8KWgEgLpDr6ZP0RcYJ0ZpHoXxZfoxF5h7LMEKWT0byiazyINZk9xsvfmTo9gDL6Vl r3QqX2AvsXfYex30b9wf+7uFetSp5T227VWtmWvZR0JC6GbmWJ//P8dBHM8wodhbOLfy38D4+Dp4 CR9ApKHZN2AsvolIxv/An8JHRB6+GB+P+eJP4Cd4FeFP+BJ6PBvhFYnwx8aEpiKEp+4IUWUIi3QW LHJF+JppwqOuIIeIRfFmlQmVhoDxoBCuRKhLINwlEfJSCBUdEO7KTcjbG2Evh7zuCHsnIvSdjJC3 njDCGQh9D3L4C0/DOQgTKWgDaCgAQsgACbQF9tAOSKE9cIAS4AxdgQt0A0roCVRQDTyhBqihF5BD JfCGucAH5gFfmA/8YAEIgL1AICwGBlgGQmAFCIV9QTisBGGwH4iA/UEXOAhEwyFwKIiFNSAO1gIj HAYSYB2Ih8NBMhwF0uBYkAJHw3EgHY4HuXAqyIPTQD6czqE56AXngxK4EBTDBaAPfAOUwsWgHC4F ZXAJT8yzBZVwDegP14LB8BAYCo+AangU1MBjYBg8DmrhCTAKngIT4BkwEUyG50E9vAimwAtwFTmb 9xnvMjmH9zk5l3eF9wU5j/cl7yve1+R8cgHvKu8b3jXedXIh71ved+Qi3g3eTd4tcjG5hFzKu837 nlzG+4F4gzjB+5FczrtDruDd5d0jV/Luk9+Rq3gPyNW8FmIV8RHvJ97PvIfkGt4v5Ju8R7xfybXk OvIG7zdyPXmTfIO8Rd4mvyd/4D3m/U428J7w/iA38J7ynpEbec/JTbwX5Fu8VnIzr43cwmsnt5KA 3EZCcjuJkW+TO0ic3EkS5C6SR75DkuRukk82kjbkHlJANpEUuZekyX3kfpIhWfIAKSQPkiJSTNqS zYCFNBBDIegGZ5J25CFSQh4m7ckjpAN5lJSSx0hH8jjpRJ4gncl3SRfyPdKVfJ90I0+S7uQpUAGX gX7wTdKD/ICUkR+ScvIjUkF+TCrJ06SKPEN6kmdJNXmO1JDnSS/yAulNXiR9yEvkJ+Sn5GdwIHmZ /Jz0Jf3IK6Q/GUB+QX5JBpJfkVpSRwaRevJr0kBeJYPJa2QIeZ0MJb+10dh42Xjb+Nj42vjZ+NsE 2ATaaG10NkE2ehuDTbBNiE2oTZhNuE2ETaRNF5som2ibGEGKIFWQJkgXZAgyBVmCbEFXtgsbJcgT 5AsKBN0E3QU9BIWCIkFPQS9BMXwCXwhKMFbQW9BHUCooE5QLKgR9BZWCfoL+ggGCKsFAwSDLru+P IgCZYLBgiGCooFpQIxgmqBUMF9QJRghGCkZRBMWjSIpP2VACiqJoiqFYSkiJKDFlS9lREsqecqCk lCPlRDnDh/AxfIbxMLHQgDlg3hgtlGMumBK2C0OEYcIIYRdhtDBWGCdMwCAvmZciTBImC1PYt4Vp wnRhhjBTmCXMFnYV6oU5wlyhB+aHBQjzhPnCAmE3YXdhD2GhsEjYU9hLWCws4ZXz+vL68QYI+whL hWXCcmGFsJJXy6vjjRR+LLyOrRU+EPYXVgkHCgcJBwuHCmuEtcLhvOnCOuFI4WjhWOE44XjhBOFE 4WRhvXCqcJpwhnCmcLZwrnCecIFwkfAN4RLhMuEK4SrhGuFa4XrhBuEm4WbhVuF2pgc1iBpMDcE2 YKuxN7EgbB0WikVgUVg6loPVYzpMjxmwYCwEC8PCsUisCxaDxWJGLA6LxxKwJCwZS8FSsTQsE8vC srGuWDSWgQ3HxmDjscnYEqwWq8NGYqOw0dhYbBw2AZuETcWmYdOxGdhMbDY2F5uHLcDmYwuxRdhS bDm2AluJTcEWY3OwN7BVVDlVSRVSRVRPaijVnxpFFVM1VClVR/WiqqkSahjVhxrO9mUHsZXsYLYf O4Ttzw5lB7DVbBVbww5kh1H9qAHUQGoElU9VUH2pMmokVUD1pmqpKqob1Z3qge3EdmGfY9uwT7H3 sb3YPmw/dgg7il3BDmJN2AfYGewtbDO2BduKvY3twN7BdmON2B7sANaMHcaOYMewE9i72HvYSewU 9hH2MXYaO4udw85jF7CL2CXsE+wz7DLO4CwuwsW4PS7FnXEX3BV3wxW4ClfjGtwb98X98QBciwfh wXgIHoqH4xF4JN4Fj8Kj8RjciMfhjrgTHo/b4rF4IO6By3A57ol74Qm4EnfH9XgYO4mdj32BJ7KT 2QXsFHYhigUWsVPZN9hp7GJ2OruEncEuxY7jPtiHuIGdyS5jZ7HL2dnsCnYOu5Kdy65i57Gr2XHC n4Q/C38R/spOYCcyvZj1TDHTwJQwG7DtuB3Tm9nI9GE2MaXMW0wZs5kpZ7YwFcxWpi+zjalktqPo 5G2mP7ODGcDsZKqYXcxA5h1mELObGcw0MkOYPcxQpompZvYyNcw+Zhizn6llDjDDmYNMHdPMjGBG MoeYUcxhZjRzhBnDHGXGMseYccxxZjxzgnmXmcC8x0xk3mcmMSeZycwpZgrzAVPPfMhMZT5ipjEf M9OZ08wM5gwzkznLzGLOMbOZ88wcFC3NZS4y85hLzHzmE2YB8ymzkPmMWcRcZt5gPmcWM1eYJcwX zFLmS2YZ8xWznPmaWcFcZVYy3zCrmGvMauY6s4b5lnmT+Y5Zy9xg1jE3hTuEu3jvCXcLG4VNwn3C A8Jm4WHhUeEx4QkyjPyRDCfvkBHkXTKSvEd2Ie+TUeQDMppsIWPIn8hY8mfSSD4k48hfyHjyEZlA /komkr+RSeRjMpn8nUwhn5Cp5B9kGvmUTCefkRnkczKTfEFmka1kNtlOduUDMgclaLl8jMzj42Q+ nyAL+DyyG58ku/P5ZA++DVnIF5BFfIrsyafJXnyGLOazZAlfSPbmi8g+fDFZyrcly/h2ZDlfQlbw 7cm+fAeyki8l+/Edyf58J3IA35ms4ruQA/mu5CC+GzmY704O4XuQQ/kyspovJ2v4CnIYX0nW8lXk cL4nWcdXkyP4GnIk3wuMgO+DkfAkGA0/IEfxvcnRfB9yDN+XHMv3I8fx/cnx/AByAj+QnMjX8nX8 IL6eb+AH80OIOmIjMYLYRIwk3iJGEZuJ0cQWYgyxlRhLbCPGEduJ8cTbxARiBzGR2ElMInYRk4l3 iCnEbqKeaCSmEnuIaUQTMZ3YS8wg9hEzif3ELOIAMZs4SMwhmom5xCFiHnGYmE8cIRYQR4mFxDFi EXGcWEy8Sywh3iOWEu8Ty4iTxHLiFLGC+IBYSXxIrCY+JtYQp4k3iTPEWuIssY44B8bBj4n1xHli A3GRaCAu0BhN0gRtQ+M0n+bRAmomNZeaTc2nZlHzqDnUAtqV9qDdaTntRsuozdQ2aiv1NrWF2k6r aC9aTfvQnrQ3raF9qV3UHmo3tZd6h2qiGql9dCQdQ0fRRroLHUtH03HUaeo8dZa6SJ2hLlDnqEt0 Op1FZ9Jd6Qw6m/qc+pL6gvqaukJ9RRfQhXR3uifdjS6ie9C9qBt0X3oA3Y8eSFfSVXR/ehD1A3WP ukM9oH6k7lN3qRaapilaSStof9qPTqaT6Fw6hy6l+9BD6MG0mLan7WgpbUs70BLakVpKraSWU6up ZdQqagW1htbSBjqIDqF1dDCtp0OpZuoodZg6Th2ijlFHqBN0DV1H19Ij6WH0CHo4PYr6hXpM/Uo9 oR5Rv1O/UX/QQpqlnWkR7UQztAu1mHqDWkQtpJYwBUwPJplJZ/LpcDqQDqMD6AhqJ7WDOkDtpw4y mUwGk0Wn0al0Ah1Pp9CJ1GXqM+pT6hOmK5PN5NAVdDldQhfTeXQ+XUb3pr6nblO3qJvUNSaPyWXS 6DF0NT2aHkqPpb6hrlI/Uz9RD5lUJoX1Yr1ZH9aX9WP92QA2kNWyOjYI5VcGNpjdye7Ca9kQ01nE aDaMDedOI/ByNsJ0MlHBRuIL8UX4OPYdIpKNwXPYWPx3dg/+DH+Ov8Bb8Ta8nQAEJDACJwj4HcEj SIJP2BACgiJogiFYQkiICDFhS9gREjaOjWcT2EQ2CeV1KWwqm8amsxnEJXwLm8lmsdlsVzaHzWXz 2Hy2AD+Ar2e782MIP0JHBBBBhIEIIQKJUEJLBBNhRDjhQ87gRxPdiUKiB1FE9Cb6EL2InkQxUUIU EDH4eKIrkcn2IOLZIhEmchI5i1xEriI3kbvIQyQTyUUKdi/bm+hGfMITsIfYw+wR9ih7jD3OnmDf Zd8TOZKT+KHkZHIKWc8P44eTU/kR5DR+JDmd34UfRc7ix/KN0I87oYHhMAMA/jqUrS/plEpOQb9v gh1gPzgM3gNnwGfgV0iBUjAdnAC3wD3wCDyHAOVDDtAN+oD/2E/bVN4QwOLvonzNEYD2Z+1327a3 30U5uLATZwmiHAnNS067XXvL67y2JW3NbRdIFIOb+oqxs4j7ELa0P8NiObo9lKOxmVzZ1OMhf13b 7rb1r0ynBtSCEWC0KZsdByagvGYSmApmgJlgFpiNdDEJleeCeWA+WAAWgkXgDbAYLAFLwTKwHKwA K8EqsBqsQXpcC9aB9ZY6jl6HfpebarmajWAL2A52oucm8BbYDLaCbYh+G2l/J3gH8cwcM70LcRrA BsTdgrhcK463G/02gj2gCewF+5DNzLSVagbvggPgIHoeQtY8Ao6CY+A4suO7yLLvm3gcx0r/fUvz 50lwCnwAPgQfgY/BaeQZZ8E5cB5cABf/rZoPOjgcdQl8Aj5FvnYZfA6ugC/AV+AquA6+Bd+Bm8jr Hvyp/kvU4mvU5pql1Q3U6ntwF7VsQS3N7cxtvjHV3jGNcBn1/Q7cRjn5Y4iB56AdlTjrLTdZaJXJ jpz1OOu8ZdIzZ4/diOYstLXDNruQjnche3IUV15tscY7qO0epEGr/v5aaxcs1jHr+yhqw+mCqzlv 0cVHFktw4xzv6HvWVNdk6vd+x6gvNWqW8PNO2vmmkw6/Bz+YNGPWnrn2pfa4FrdRG07L3Biv6vYm 6mvWPteX43fuw9V9jei7CB0eIE1zz/smS9wHP3aUf7TUt4CfwM/gsenzIfgF4cmv4DdE/444DxH1 Z+7rnCfo9w/wFDxDFnwBWjtRra/VtII2ZGMAIcQgDtpell5yTX/WMx4bKIAUZCALhaYzK/5rNXRH je2fapi/qBOYOHZQAu0RXjpCJ+gCXRFuukMP0wm+slOdc0eN+YTJE6otdVJTT+eOvtwZlGOntj5Q B0ehTw7VtagcBINhCAyDEYgTgGg9oiNRnc70jAc5oBwMBs94d7BzaHx7hCp7jMl9epcU9+pZVNit ID8vN6drdlZmRnpaakpyUmJCfJwxNiY6qktkRHhYaIg2MMDfW6P2VCllTva2YhFLUwIbPskzfZ/E P0mVXCpv1JQ2EhpVamoAR6vKEKOsE6O0UY5Yya+2aZSXmprJX21pRC37vdbSaG5p7GgJxfIoEBXg L09SyRvPJ6rkzbBnbiEqz09UFckbW0zlLFOZ0JgIFhEKBeohT3IakChvhKXypMbkkQPmJJUmovH2 0FSCKqGSCvAHeygaFWlUavRW1eyB3jHQVMC8kyL3YMCG5V7biKuTyvo25uQWJiW6KhRFJh5IMI3V SCY08k1jyau4OYO58j3+786Z1ywG5aV+TF9V37Liwka8DHWagyfNmTOz0dav0UeV2Ogz9rYTErmy 0V+VmNTop0KDZeR1vAA28tRilXzOY4Amr2p58CqnzMIh1eLHgCtyInaoCdVbywDNDc0QyadQcHOZ 22wE5YhonJxbaKbloNy1CRi1fkWNWClX8661xqEbVzPZWtPRvVSl4EyVVGr5N3KAU+PkcnmAP9K+ 6Z8a/UP18kZcU1peMYB7llXOUSUmmvVWUNhoTEQFY5lF1qQ9Oi1qX1aKhKji1JBb2KhV1TTaq+LN DRBDztmgKr/Q1MXSrdE+oRGUVlh6NWqTErl5yZPmlCaaJ8iNpcotPAQM7d/tCZa77jWAYFDEzaNR moCMokmaU9i3X6Os1LUv8s9+8kJXRaOxCKmvSFVYWcRZSSVu9PkOvU5heqOpF5LttdbWxpzkfLWN vBBzxYs4ayGGPBl9qOKjUIUYmctEchaNj5IXQldgbYbeYmnBlV4ZBxG4OiGVq8K5rgmprooihfnn H0zJ1TInnrrRptNYYsTomJP5PX87NXNrbkI+8qTKxE4TfGVQnmWCltH+ep4YpwvLi1EPG86cqdYq XI1WLuJhaBgTi7Oik7wR5MgLVZWqIhXyIWNOIScbp2uTfTPyVRm5PQtN1rZ4ScErlLk+3Ew1AgWq thJYAvLBZD9Xq1lNdIqJ7iBTX6tOs1bL59ioMvLncIOrLAMCOVpBSGhSk1Y2N9wuGC3NZIRuquQy lVwsT55T1tw+uXzOHqNxTk1S6YBIbgxVWt85qvzCKFfTXPMKJ7iO5V5lBzJgRkF8gD/Cnvg9Kjgr d48RzsrvWXgIxbLyWQWFTRjEEkrji/Z4orrCQ3IAjCYuxnE5JkfIOYIbKQ8RNqb2roeMAEw21RIm homuaIbAxLOx8iCoaMbMPLGVhyEeYeYZTTzuBxnJaQBSMYLbJHlfzjzjiwbMKS3iFheQIlOif7AR qmJAI6aK2QMxkmmkVJXxjbQqnuPHcvxYM5/k+HzkGGgvRMrhMGlOqQrhFHKoQuAKza6Ic0PKm9vb CwoV511bihTI1YrRX8/CRoEfwn6eOh21S+H+ShE7pXFyRRk3D9CtkOvLV6dVFCG3tQ6ImqQ1CtAI AssIqEWyqQ/njqhTBbINMqCp/2RENE4uaizy415aWFVkcmdxI0hVRSKzm8fkabgXaYvm2Kn0prWJ lgKlnsk9BGhuIL/QzHFFJHpZkVlJfAbNvEKFqipK5UjbBKjIR65uxlLK1cypRJBIaCpNf5SrpRJw YuFqmqUaBYFoQPSPK9OB3JLkqflFRebJm6iZlgbo3eJGGs1I00mVlg5IO6gqjZsL+jcTTZVr+h43 TG4zyFONRsjCTdo0Eh9VN7LqtDIE/ub+NOKowq2dbTiMoC1jnDJz+ZzkDNI7ri5obt+qGqPo9BPg r+I2B84xgesh5NigaM7rjMZefgH+Nq9zWRN7zhwb9q87mPVlw3Y8ERPwUFI6HL+Kkkgc8EGE6ZKw 4Chg4VqUaUbCs/sSE20C+McRiQE5PAtsUES51ighMNbVNVYVQs7Dc23TYvnzsAIQ23r92ofo47xd hPY81F5rudIibv3QNkLbcrklSAdtFbamP3shxueTpEoZiIV4aUINBn0MFhKsUSmFmIkXHBoWgxv0 Hhhub+XEYBwN8asvuuJJrZ7YGEWX/CAe9FM7yiQ2NrjMg1Ub5KKMLFWotwuPsCFxng3fKzRe1W1U uvIC5eTl5u7lRKGnuxt6tr7PEz57xBM+70EkPj+K3YkojPEkx7A0xhPYrPX2cPAMcovOYEUsT+jq 6OLGt7EVUr6pZa2rXNSOFOWodnFTc2OpW7sgjTi2PyNO8uyBEmjADbSKE7qhbdaz/c4+WgQzVc3t d4weXEnNsConFkihUKqhKZWSAnJCBW1VGnUz9DV6GGnAQDucYbzcPVUqD4qVApXSiW/nnmfXjdcN OMXGxto5RoTbGmyRZlEIa3DJatFDZ23vEhen83rDhJmnTkGnU71LzMUgHfDzc311Gvu5wv/mbUE6 P78itVRqtpsXruALcZVSowkNg2ZjOfJVuILYw5DS8CBDhAdD9GhzySNY9xC/wGB7koELSbEqxtAl 2cuWfB8ehNXlnr4OPFwgZiHRKpTQBOnoqyLG2zrQOE5LJR+2fo38cT4ARCjyTA/gB8LBeqt+ZdiS /S60gwMNmrE3m/w1hmZsTBPt4tUM8b1BQXzPZovgns1QbRSIc4OdOCq4Gfo0GfkFSEAkkF9six8S ryUCalv02hbkpHYRyEld9/ybwwTpipBjEyqFUhNiGxxqUCCVOHCe7oHD4EBMpbLl3FzyskiEahJK aiZlt21TBAQoYNKozcOinAIT/MJKkrzbdjrp0qKnL4lIDJAmeET2TH3zeFhGmAxOS6rpHuMt8fIn Bvh7eeeOL9DmJwaLKX3XgfBbrxgfaVujqza29WlAis6lbZFjQAL3JbGu7fcJhqdCK3uuWX9NbsDv OPYREAInWAYUQGMRU9MMS5sk+QTKKg6G6Eyy6ppheZNR0N0ka6vf5ZZY7gNp7DJyMtej/+4ASFdq e6EZAILtQkOR+5AOlrXOoYCDvQfGqYhzK4LBSUoa22tE4vQry3MK112bHtq3W6IrReIEJRSIAtMq k7PGdPPX9hiXldwvTctSjA1xylnlbOfoqZDmbfpt42YI3ulp565xtXPTuHn4ujAqP1XsiC0DarcO DlF4y22c/Liv2nGexn1lzw7IwDCznk4ACbaG+y8usMVAAJwsQjo1w0CjQJjrapLPtRkWNBl5nZwB msEOLb9/tYfZc7BXPIfXyU/eLXnn6c62syYvydz1y+bubQ/9+iwbM3324KUVQdjqptaGDLND5K6/ t6l4XV3ci0Xhw7YhyyOZ8HlIJpT9mCXifBtbbBQJJHKJHMnk4sSiGbkchj6cDQ+wMEujIZ2tbu9s mjeb62WaN1oVgU1G8lW39+PkRQsnQqsVcxDheuA/MaTZPbA/LSWVwva1IhKPEglaR3K6wWYIhBSP h5yiTQ9nCkRcWSRoGwM/5cr90QZAm9VEOXt5oG2AbjtFO6KNQeNItS2hnby4tTK//RlegTTmBQ5Z NMaXNGNLjVLWHXi4871FMIvvxLAwky+mUfEw7AEk7Q8PoLJE4kw2t3+3F7UgTdIKYSbZDHvtMypz nU2YyoloEdCP09op2wiTyoy2/8FxO3yps6asu6hVl0hEGmmpCM4XCGmeqTyckem9NAYPFumxjOMS Gz18nJi2tygnbw8Pbxe6zYMW0ySJPohl/l60sy/SVlr7PWINzxPEgqtmbe11cxM5IQ9rAl6iI9gq lGSiNcBN3QlNfS9rej7cy3BP6LVPqYzQxhyBWhSBUBb/oJBkRkFEvr3JP+ybYZ8mo7a71T846OC2 JLMCEQa1IMK61P5vXmPV5yvAFBpmi3Y+U1Bi0rIth/svwxQCKUXACtjI0umFvVcOjuwycFlP/+7q x3b2nHPC/WJnCeUQV9q/KmTN47d7ljY+XVUwp3+iK0Mkufs6U56+nnGjtlZWb6+NtLeH/gGhbhpH mpbK7FtbPQJc3Oypou2/rl7fuqe3o0LjZjD7LDEJRSBacNG6P2rNDqO2OI6n5UlbnpTlCdBzH3qq mGZsSZOjJ40eKDZw9M3zNCnG8wisQLEjg4IYe44WMTIGY1Dc8EqkYAoR/Eyag9rLLXqxOVbgflyN gn97LCsImBy3sw+btwUHxLMWiUmsh17jZXBn29wYD7Mfsx4GjZfeg4G3WXeDl0bvwXpSYook0QdG tz62lokPraU2NbxqLZu1CpchrToAX6tWAbZ0v5ES55knC7Vomsj59loZr0zYOjW4jLVOSKbnJvRy Gi9fbUEeIga9zwDKrbuPDluKNlcKW4ImocQ+3Ovv7yBoxs4ZhUbg4JWnoMSueeKXmovgtI+mxDmu uFXPTc1I/1WzjnlqNF7wL/RqCecc7Ek+hFIpEUPLQn3iIpz5bWP+pNxxfHu53ss7WMbYObethVOl Ai/aliYpNGq/1tUdiHGSNktKt36FaVhbikBcytbTq03betDH1bJTFSDpXUCGVdsOCHZpIBDlOZj8 x6EZlnTeK6D2vEnEv23w6ibS4TQc/BWgjYFq3a0IsMjBwhWIwRvq4ePKoC1ihdUuz3+mnX3MtiGH oV0hCnxlnp2RZnU6R62WCnRycmnG+u7zDGIYChUOAs/QXGeGdjoCA5C3B7Y/3CdWYZlBCI+Mcq7k KOY+WfOno1YXFEjKvHNl3TqWABd5c0uHC7n1evOKsjWIuQ/biGitwWBrQGLv/8++5RXXVUEusEch PlS9snOYYnxo4NzDpEtyGO2uU3vq3BisbTZhJ9MplTqZHd62HKM9tIjvTocG7AyM18kZ6ERAJSvz CVfvcfVy7rQC3J/fRt6A8zgfcXt+q4M/xRAqUkX4vmjFoW+kp0iIelnXSDPPDkSD/WY7HPASUYEi kX0zFtzkEahHj33AIzzPh1OEnUiDZfp4ByoZMVdiaFLUDCccRLs/t3EGovJLbzEtDJQCRPgh3I94 iWNaW7O6m/4DY1p1bFYtWnsqqdThzwqWeOCOBk0nlyWaxa5qSY3K4Oft3HbcLdIRIwjaNdBTFehC hXnP1wT7eEpeSP28NXYQxxm3QE9loDNV7IhQV6iO1WMloRO6pC7MbO1FmRcjRczValmPEK82L7/8 /Bzv5JVJWB9KzPB4DAIiDOS03+U589RAgmKgjjjYHnsfxcEe6JMCzi9DuWK0+vJVTuYUk1t9vO5/ FQf/qz067bXWhN8UBndKCHjOOevurlpxY3kGeq5ecmNFVtsDedbk0rL6HIU8c3IZ98SWb2jbU9J1 47Mda5839s7e+ORAv62j4tLGbuo1cPvo2NTxm7loH3kSjla0G/ABky2Rnid5BEGtLXDH3jMKgK3a NEuUMPvtJUlG1dyRS0O/fUaHXKYj9jJFCpzHWCLg/1lHq9Cq16M0onMKgCfWH5s82LKVMEHeMCgw v25UgX9biy45y6dmZGy3UDd8+pBtw6PaKjpW0Tytlu8Y02dSeWKhL92WpozuZpE8C0keChLBWrPk +8SBtj7UEexDZOMwbE2TT6wtFw+4BYqtcxejBHiv0egYbWVEoxz4gFGR62gFlA55TOn05RZTBBXB pdP/3iidEMkLD8T/pB6powduya4dHaVSGKzx0mis2sqy8YjU++rdGaLOwTvI6JtnVRxKoLoa4l2z J/QIVBh7R7kbArwlQ0RU267IeHtDwMgZ4QXhbkpaRKEVZstARVCmwaVN0qHPFf5eBE6H9hiVFTeo IEYi9I5IC2zXqPC+xkI7Htn2hmtQIodSse13UVqiBmngiHUvi8NW7PfUe+oZV+68AjCBHHCHAQoG HLANQ7/SKKtKopphgJGJc+X55EtNfiRthoWdlwkHKn625oRL3MK5nSn7ajGl44H/oWFfrkTCuhLN Z3SBpIV+PV0n8XmZ9e9UJAwv7OJCEyjhEhpyqtN0mSFuuqzyAeVZuqQR64sCi3Ni7Pk8DOezNK1L Lg7zM/o5aLv2HdA3Wwen9VvdP1gqU7oEBcp8XWiFt8LRN0bjHxvkp4vuVpdbMr8kUOjkYS90VLm4 e7swbgpXB3Wwu5+5fjjSO4Nyt3vIs5Wgm2VFAxLlbnudbEk7qx7sTJmTe6dFqIfaU63nOUf9h61e 5lUvY1IrTpliinumZPMoF1FwEVLbUcqcjFL4Ii79JDa6+zgzz1s6nEnCOPu4e/g601wqhWY/r/0u sQtFQH6gh3n2R4EcW4RWpBTF5AylyRPndZwfFHe2XKwVaI30P2jUGVtfRkMWVO202exKnvVx/dj3 Z6SY8kEUGmlSKqJjyhPVDCdYEAr5bo46Wp8YPf7QeLxjZbQSWcPS1Zq0QYk43TmmlSKs2YJk8gT5 lpMn4IzCpawDRk9nOePsyGXWtJF1luU58ewsUbQdimOdtU7mSNZFfM0FPZBwB19rw+GDKUwhuL3U dIJkDU70UinJx215Ys8YvXeEt7OtgGibxPCco0IDg91oHuwCYQjBuIdqAw0SPhPIHThCwoaxZYlx 3IkkQdmLXrjgN2wdGNORJJLDr/0Z3x7JEQUmWeI/gZZiQJROx6CYI8tIRTGOTqxapWKUzdgyo53R iQnL883TqWj8tTPV2E7COWsjIuwinMSXTWW7CDNeGkV/27VDZgSJKtwapHVILzFILAexlhKnB963 pINvvCEiyduOdxE7xbPzSgiLRATZ9rUAc44waMPcKPwWfECwstAAXYRMSPyG3cIpt2Ctf5AUFyQ4 uYt4PJG7Ex784pyju9hUJqo8faQ8nHaQvFDgX0qcWB7BOtm/8Ma/ETuyPJ7UT432mRSEgiPxL1A+ Y4Q+FusLHIObsV77gJcXiGzGkoxiW9wR/uoIHZuZYPgiGAY3t79rFHDHIMHBgXG+zdDJ6PqdEuIT lPOVmFGZoyxV4iKlTIkxhFJJuKPs1ShkkLe7O4lhlvuzwHRuZzEKEBF928hkEcBJa40t/MypZUlJ nxJTbu9XMqylZBhaOqciuJMrs+b/y7Mx7Xnc8ToK/0Is1yPcwjSEWKIgC4cwLVW+GXml3HEEPtLe zzfAxzZsfveUUT100WP2jeph6xWni63INIhNCZlbcu/qLlXLSv2flEZ3D3VOiQ0pCpQJxXy+WJjS JV6dNjg1e3iGZ6hvrK+9m9JN6KJxlHm6qzwkPt1mFH9t52lQhBtDg7lz0okIpwCvBviiKHy5xa6U IvQIVoqyVD9sGgqdHKjQEAXB01nhVNcMM4ysJt01WZwZYYKniGaYjuApqwOeuKM/xwhLEMUZ48C/ O0YnoPNy+DPimVeINazk20qlpogBBJcv7BWQnZLkieDYQ+bjTDEot1Hr3BllYmKqd8WcHt5tz219 EwzOOkOoR0hZSFBigD18MOr4jFRbTaRPmSlmoEQ0T2UNs9skKBsSdp2xd0TEwLwgoTLUu+3LxBR9 Tj+EJ6nt93AFfgWEWCOwJjfgdRyrM53Iy4Cs4+LGsxnKmiTpxGGYCoKQN9I0zAryN4nv3wyTm4yC LOvBul/H0fwpveVo/n830itn9NY9nzRv+WTnA3okCo/vFJneI7D/+sFhCaPfKvfOSgiRCni4vdhW E5yqLx/gYsgyBGeEa1gBwycaXVROIkeFi9g4YV/djJOTY9C2LhU5qZwjtcj1VixOHZqulmlklKsv 528ZCEfO8YYADYgAyyzaol0jjmC90d6oxWqNlESRTEd4uRJCX6uzoLWaZhQ4pXfc16TtMwqzeJnW 3dzsKeaN07z0Bf/uGJ0z585rFgWoHU6HazSdc5gw/Bzl5OMh93amk1YU95tf5G0oX9wnY2wUbXI5 N+ZZaEVoUIqfg51PYrBLkCFUrrS6V0V6HvKoCs7torvAW1Zfaw1OTA3KqwwJH5ivFynDvDm9pSO9 HUD46weCIc9yOiuRKPybsYQmv2CimdOcAveX+GOu/icJDuocWZgFCDGBZeYQpQTWQDQSKNV00zab z1a5p1GO2mhva9KdfgdCsRCzxYUCJwZmCZxQA8FTo5vVifwuI3hrsSBdybDeJX4tvUu4zOCa5cjW KPh/+24TLJAqRSe/dXjVuzEHr1CTnfj4AR/P1huuXUri4vum6UQCxgbHCBs2smdd/Ki9o7vEjNw+ sGZ9P91veK8+uhStMwafBfpHlMQpJY4Svp3CWSqTioROjrZRYw9PGHVienL8iIbe8oFjPKPztWjt O7c/w1byRqNYYrjFKlIxQGlBn706XzXVDN33hqa4aJpf3qjJDhh1qfJMcWpHhqSPRcv8lKH1lOGU Kb+m/sVOr59lO1iO+TonV9ZzbYP1LBtbSdhQJN/WWeno6uXCbOKCWXvJJsZN7+kZ5E7XSCQ8xKr2 zBqV65XsLRQQxCN3lYTPt+Hbqrv45VGO3u5h2tZAynwdQ2GfasPcvR2pjF6zewWyItbZC+DAtW0J vhH/DMSAbNAHYpYYq6tIx8fDVemG9JPpuCwdpt84zUBkceZ0PvTIh075MP+X8w7Q0QECB7EDJnJw KA3Hn0al+sr944/GYyAexp8PTxf1gmK81zmjvKt5o0C+EdtSUoJCSNPOy23CiCy5YnqY9g9XY7fO b6bT4T9/+ct3R8Wfi8eIeCj6h+/v/XIGr0ygxLqDIaNIpeb9S+NFIryVOloyXqvLhqEoITjU9GnG G5QUw2BNR1TA3TVrvLyEuIXCN0rFVVJJcNnsAr9sB0ZiCPwqc1SuX2Td7hG1G/prbRU6mZ821E/l G1Y+K883SwFdbR3ajuWkqcPVdjkpmnC1pEtq7F4XmYSsLI7I1tnjpbpAp2hF9ph8Pwch6yl1V2M2 uDqhd1T8iO56T2NRiCIqTO/o2FXbpcxLVZ6WPa5bACXwb3uamuPsFyFL7OrkG9baPUCH8SQquYdY H+yo0XI5w0SUxX2K4gs9GGLNnmmsT5Pe174ZK92LEqbOxwlZRoExIN0z2TnTDMzWEwTzGQR3cPev tX/16N60w/H/4mTcHGg74J8ybkGe6iA3RuIZodGVh1hjBeszbmZarwlZSqXV6WFrXHqIe3JC624r p3OcYIyNGjC3gsPsQe3P4HxeNgqkFCDJevYmxU4AN+CA4isKyOC4/UZncZp59lfQ5F+esv257i8v JCTcHs55DnIZOPb1mUtiCrp1ie5WENUxd3ws2nfQTJEUuszI8LTMLhEAa7/atgQ2oJl6Ah3oY7WT GjvR5McAhGX7nJ2BPrAZjtvrLUuzb4aJKFCz+H/slRZbg4ELU0zz3vtPGr6UwXISIX01YX1FnPme aUPTfSJdKALDbSgbnszORePEMG4W2Ti5OPmIqvqiAJqxc3R3dFNLKZ5YFRaFL/mzmBZvPIK8Mfjl rUwQsoQSMOhTClTYgb0BAVKqGTvI3cpIlTTPO80t2bbDvVBO98qtzG1Tnv5XzTofeP0LtzL4Edpd 7+1jUNjx27543YrQxsZeEaRRG2SMSNT2HAYytIISCXgE92WbK23ef/bCF7/ACsbOxKVFSknbl20B 9u5m+eFYJL8DiLWgsoh1gCh4pCnIAkgTyNql3KVYslkUy6WYKbcpcd1rZf/11difvE/554mZ50AK UCSTA3ZYznWSJdx+6eGhR4rv05QT48VlH3og7rTQmzLSO399JwuZJy49JjkgPC0g07mz3jsdV0dc 5r4FxH2TBy2n/9Vg/wRP/g5gHCyZvMXUpIBzXY3OnbZVhagDikORnjw5PdkqQz0Diztgh3Lxkcl9 Han0JTlhhUl6W++sjAyvorEZ8g59YrYBrwHQnzn4eGupf06Oo1+U2i/GSxLVf05WByojG+jBFIsN fCWc0j1M4Aw8xNyFO0opTGDLWMGWRmDr6+yZ1qEjO7OGLKflVkX/T3r+a0jt8M+QukNlq/L/CVK/ ohakjjKE06koByaQNl67IxlhuiMZ8eodiYtRIErvuPFw65yx/s0dyT/s8S/ckRBE1NjmcaMa68Kj xx4cN7pxeHhbq4M+Pza8INRVGlQQE1EQ6gLv1h6dlR4/sXlk7bGZ6XETm6fEV+cF+nStTkHPAJ/s ai7Tb1tGACRl50xfEUpZM/3p/yjTTxN3/V9n+v9sjM6Z/l+4wN9l+ijZ6u0VFx0l7/AFZx+ZB8r4 vTKy87XlXKb/zNYnQe8cxGX6pcFBSf4OsGXUiRmpIlmgrK244x7tutUxqryjfeyzZjSNiqjKCxJx mf7XCWn63H5c9tq2DD9n0aE1e5XRflz26gsMXA7moE6jo/1khDjQqoBAU+bpkh5uEj7clHmKs0zb 4t9lr//uGK+cCpsPFK1e5Rjy9+mrZUelPbmzEU5jwX0Xl6oTE9P8aWdvuYePE/WnFLbtXave4DZF kOlgxJTGilCSUGZVZNuXljx2UJ4ljzUhD3bEdI5YY0EejQjtOUYGuIgoGaWlcBanuDSR5r7XAvON lNEvXSNykKc5ZJrPis3I0YfLP09ZMIf65+1fS5b4f+dhJHYE5YaUjb2zh52DbwCCmtcgRhUTHu7G esidaB4KSzI8A10oLjnyjPJvvfxnkKnWx2lEOF9AMQ7mb1jdxR4h6dPA3Zd3SYEdd0mJRhSJEIEw 8HYY2pCpH23DjByUhsnDMNx0ASSKglHcxbWr6RLoNncBlC4Vc2eaQArFhPRRx7LivndjvgUqMV0D 9SnxE7eUoH+vXDEZ5f/Hb/s3bp6wRxEDFuTre6XqpAxhwwhoP2O3UGWIl706Ois3K1qt7z2zwLer 0V9iQ+A4n7ERaCIydEq9XKyJ6ZrbNUYDPTLrsr1Ejk4OAf7uKge+s4eL0MXbxcNP7qb0N/aMNQ7K 9GXsHEQiB5mjq9Ke7+DkIHRR2ct85W4Kf2MRspJj+wNsAbEHRIIlZisd/P/aOw/wuIp77c9p27Ta XbVVl1a9etUsyZLbukvuTcbdllUsYTVU3MA21SEOxuAQOtghQABTjGyMYgjVlBAMBAg1EFqA0DsB y7vfO/M/K61kAebe5N77fI8MP71z5syZmTO9HSkkJHh0FksZwccnkcEj/NVyBGbmB1Iq4oP9FsF8 WS6yoqBHmtbtMeqJg8p5VHQORccLjxSG+M+4jfiveEL9pTr05H7gEoDTvzAiXxgUmpJXGjejpSJ5 XVg4L5anBsVTP/qQRcz/H3aPDndFhxgNQQZtc25eGMbO6XM2zpf+RLP7x1DZNQ2V/TGa/3tXVFYa zUZjRCpSaxNf0VMexVhinV6jgzJoOS9RXuWxh42ozAjSoiv1Y2MYDQxaeKOjTmj8RNtnOxnnQ63S DdoFKyntX697kncJSWjGpl8xf/mWWUni5VGlQ9MwiKgu9a/TJQeODBp+WS/3WXhNU8UwQp7nt6Hd MOUA3jvXvz/Z7UhK7JHPPeSJSHIZklJ65BUeq4e5kjIrk4JiKoNm9m+HxUS9Nng/bJAjvd4Y+87u BLTkYZGl+s6QckBSNNX7lRaSMamkeFJ6iOb9CvOJoLiCtCy+Xf5ng+FxJTguLz0tL8ai7NFsIU5b 78t8J0yzRjiUjHCXzYCXUTVziPX4adHR8i5rCKYVFjtvqVN832vP4f2msMv0WhAXH+rOzXVk98iT PEHxjlE2h6qUlzvG9Mg5nmCP4phQWVTpyA+yV5T3+J45AM2FemzcUO5QItMqI2eaZ/r3v3Jycgbu nokdM//2Gd9KE3s43M8hntZ3QA1G/76ZktFv9K+hDEirAKP2nMH0ieZIGltQMC7FoV4qyztUe+q4 gsKxuPrIrKF8pGUWxgUpd8ryjUpwTF5amjs2SOlW5Ftk0VfmxVqUvUGuhP60lBPM5uNv9adsfFIQ ZmiqauEJa7XyhOXJbLccbwrSr1SzHansQinaiVTOYxf494mT5R0siqXK2R6zOwr/scgga49c7bF7 +PcmijPIlcdSUoIwWbqL27mCsipTgkLiK0P6B9cDShlP2pgox2topHlpC+0/FYC561DP8url9B/W 0FO1NEzp35ns245UlPNMUlx5/ojSRLt6ww2qLX5kdu7IKMn87TtmKaasILc4wabtuVaxxozIyC2O lIJeH4kiqCnmYIs01vuwJdisaDZniHS3dHVotM2gGIIt3hekbJPVpKq26HDvOl7PMOY6iBRKZQ36 KTHJbLaxGPSXEw95UmNclpioHrkDSWGLSayMtoRVWmaoc9gM/yzuxP1n/jUTf3nrkM7x9kkKNSql YfxMZfrIgB1ZvmThDDfK5zSZ587KzI+SjRuCIzTv0eCosrycwjib8VnlAUNYbmlOWazJeyTaaXRE hUg5hmibMjIlLcKkWKMjj++Tq2NCTCZnmjgFF+n9m3SjlMRiWcSdDsy/LzwQGhQZxxzPH0Wr+GhB fpr4vMqfC32fTt1oCo2L2G4MiUqOiU91SNpmR/LItJTCJHtP5oTy0vgHLDYTWipHkBR+bXK202h0 ZmP8utf3pXRYuUPMdGLvZOE9cs/dloQUTMvsFWz80fEIsoifeho8JwkZ/OHWYVtSSVZWSZLVSmob fK04s0el2u2po7JzylMdjtTy4xXZZdyiLDt7NNfR/N23ID43SpksiJm7zcpMRIG/b8AS0I0TFi70 TKha4LlohWf84pWe8XxdrVYpV1ZrG5FipSz5zlik2YruoNIMyF1xhmRn4TQ2vuhoIVLv6AvHkYDS gGVW/VM04xC2ImPftScWuJLcCcFGR2zYNqM90hUV47JLmle2J+YnJbnjbfzGmfxGZIzLoapjr0rO 4umblZz