From roll-bounces@ietf.org Mon Sep 1 04:00:33 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22BF53A6847; Mon, 1 Sep 2008 04:00:33 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64D63A677D for ; Mon, 1 Sep 2008 04:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.676 X-Spam-Level: X-Spam-Status: No, score=-4.676 tagged_above=-999 required=5 tests=[AWL=-0.901, BAYES_50=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2WNISBQ2dzx for ; Mon, 1 Sep 2008 03:59:54 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C9C783A6847 for ; Mon, 1 Sep 2008 03:59:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,306,1217808000"; d="scan'208,217";a="19287245" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 01 Sep 2008 10:59:55 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m81AxtsQ012499; Mon, 1 Sep 2008 06:59:55 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m81AxwSe011083; Mon, 1 Sep 2008 10:59:58 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Sep 2008 06:59:55 -0400 Received: from 10.61.96.157 ([10.61.96.157]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 1 Sep 2008 10:59:54 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Mon, 01 Sep 2008 12:59:48 +0200 From: JP Vasseur To: , , "'Tim Winter'" , "'WATTEYNE Thomas RD-TECH'" , "'MADHUSUDAN Giyyarpuram RD-TECH'" , "'CHEGARAY Gabriel RD-TECH'" , "'BARTHEL Dominique RD-TECH'" , Message-ID: Thread-Topic: Review of draft-ietf-roll-urban-routing-reqs-01 Thread-Index: AckDxCXVl9keGlV0jkulakQaFFRIHQAAdXyAABs8CCAB+7tpCw== In-Reply-To: <20080822092327.C8E7E2FC284@castor> Mime-version: 1.0 X-OriginalArrivalTime: 01 Sep 2008 10:59:55.0593 (UTC) FILETIME=[DE11C390:01C90C21] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=96383; t=1220266795; x=1221130795; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20Review=20of=20draft-ietf-roll-urban-rou ting-reqs-01 |Sender:=20 |To:=20,=20,=0A=20=20=20=20=20=20=20=20=22'Tim=20Winter' =22=20,=0A=20=20=20=20=20=20=20=2 0=22'WATTEYNE=20Thomas=20RD-TECH'=22=20,=0A=20=20=20=20=20=20=20=20=22'MADHUSUDAN=20 Giyyarpuram=20RD-TECH'=22=20,=0A=20=20=20=20=20=20=20=20=22'CHEGARAY=20Gabrie l=20RD-TECH'=22=20,=0A= 20=20=20=20=20=20=20=20=22'BARTHEL=20Dominique=20RD-TECH'=22 =20,=0A=20=20=20=20=20 =20=20=20; bh=72rpNQHwZnER1LMjUGDlRjMlXhplHAv9mn0Wn0qUomo=; b=wy4vUrDurtpgvJ5gdNeHeLv+ywFtW1ek6PKE3GqBqLIBKXgrAx36jiayPt 3koYJS89itT8fD3zV8xupJ8fuP4ql6gx1ryy9z9vXLVlzPN/PuFN4Sn1x+Fv a8pEtSYlQm; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "'David E. Culler'" Subject: Re: [Roll] Review of draft-ietf-roll-urban-routing-reqs-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0913663904==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0913663904== Content-type: multipart/alternative; boundary="B_3303118791_75957491" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3303118791_75957491 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, Thanks for the quick replies ! See in line On 8/22/08 11:20 AM, "Mischa Dohler" wrote: > Thanks, JP, indeed, for this in-depth review. I propose that Tim takes ca= re of > all the small typos identified by JP. Some comments in-line in addition t= o > Christian ones. Thanks to all and kind regards, Mischa. > =20 >=20 >=20 > From: christian.jacquenet@orange-ftgroup.com > [mailto:christian.jacquenet@orange-ftgroup.com] > Sent: Thursday, August 21, 2008 11:02 PM > To: JP Vasseur; Mischa Dohler; Tim Winter; WATTEYNE Thomas RD-TECH; MADHU= SUDAN > Giyyarpuram RD-TECH; CHEGARAY Gabriel RD-TECH; BARTHEL Dominique RD-TECH; > roll@ietf.org > Cc: David E. Culler > Subject: RE: Review of draft-ietf-roll-urban-routing-reqs-01 > =20 > Dear all, > =20 > Thanks to Jean-Philippe for this thorough review. Please find a first sho= t of > personal comments inline, but I'll let my fellow co-authors further elabo= rate > accordingly. >> =20 >> [CJ] [snip]=20 >> Abstract >> ####### >> s/ for a wireless ROLL solution to be useful the protocol(s) ought to be >> energy-efficient, scalable, and autonomous/ the routing solution ought t= o be >> energy-efficient, scalable and autonomous. >>=20 >> JP> You may want to use a different word than =B3Autonomous=B2. Do you refer= to >> the =B3self configuration=B2 property ? >> [CJ] We chose "autonomous" because it was generic enough, while I think = "self >> configuration" is too restrictive: it's not only a matter of configurati= on, >> it's also a matter of making (forwarding) decisions, self-healing >> capabilities, etc. Another word I would suggest is "self-organizing", if= this >> is more specific. >> [Mischa] We had long discussions on this and finally converged to =AB >> autonomous =BB. Let=B9s leave it. >>=20 >> JP> This is fine, just add a definition of =B3Autonomous=B2 then. >>=20 >> Section 1 >> ####### >> * =B3Section 6 discusses the routing requirements for networks comprising >> such constrained devices in a U-LLN environment. These requirements >> may be overlapping requirements derived from other application- >> specific requirements documents or as listed in >> [I-D.culler-rl2n-routing-reqs].=B2 >>=20 >> JP> Please remove this reference (ID abandoned) and insert reference to >> http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-02= .txt >> > > ,=20 >> http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-0= 1.txt >> > t> and=20 >> http://www.ietf.org/internet-drafts/draft-martocci-roll-commercial-routi= ng-re >> qs-00.txt=20 >> > eqs-00.txt> . >> [CJ] OK.=20 >>=20 >> * s/ Section 7 provides an overview of security considerations/ Section = 7 >> provides an overview of routing security considerations >> [CJ] OK.=20 >>=20 >> Section 2 >> ######## >>=20 >> * S/ ROLL: Routing over Low power and Lossy networks/ ROLL: Routing Over= Low >> power and Lossy networks >> [CJ] OK.=20 >>=20 >> * Schedule: An agreed execution, wake-up, transmission, reception, >> etc., time-table between two or more field devices. >> The definition is a little bit too vague. If used in the generic sense, = no >> need to add it to the terminology section. Otherwise, it ought to be mor= e >> specific. >> [CJ] Schedule is indeed very generic, but I think the sue of the word ma= kes >> perfect sense in the context of U-WSN networks. Being more specific woul= d >> mean elaborating on use cases where schedule information is taken into >> account by field devices to perform some specific action. If this propos= al >> makes sense, I'm not sure the terminology section is appropriate for suc= h >> elaboration and would therefore suggest we (1) keep the "schedule" defin= ition >> in this section and (2) further elaborate on a use case that illustrates= the >> use of schedule information in section 5 of the draft. >> [Mischa] I don=B9t see why this is vague. This is very clear to me. Let=B9s = leave >> it as is (I guess we do not need to find the maximum entropy of this >> document; the routing solution won=B9t get better due to this J). >> JP> I must say that I like the proposal of Christian to further elaborat= e >> (one or two example are sufficient) on a use case. I can see at least 3-= 4 >> ways the word =B3Schedule=B2 may be interpreted. >>=20 >> Section 3.1.1 >> ########### >> * S/ pre- planned location/ pre-planned location >> [CJ] OK.=20 >>=20 >> * What you refer to as a repeater is in fact a router. What I would sugg= est >> here is to reword this paragraph to indicate that some nodes are simple >> routers whereas other nodes are routers and lso perform sensing/actuatin= g >> task. Insert this paragraph after the Actuators and Sensors paragraphs. >> [CJ] So you're suggesting to (1) remove section 3.1.2 (not 3.1.1, actual= ly), >> and (2) indicate that some nodes are routers (not "simple", btw :-), oth= ers >> also perform sensing/actuating tasks, right? I'm fine with this suggesti= on, >> but I'd like to hear the feedback from my colleagues. It's also worth >> mentioning that a "repeater" has a very specific meaning in "classical" >> networking environments, remembering the old days of FOIRL and the >> like...that may be another reason to avoid the use of this notion within= the >> roll context. >> [Mischa] We had this discussion before and the reason outlined by Christ= ian >> is exactly why the thingy is called repeater and not router. >> JP> As pointed out, the word =B3repeaters=B2 has been used for other purpose= s ... >> What you refer to as a =B3repeater=B2 is an =B3router=B2. I would suggest not to >> adopt a specific terminology for this ID. >> =20 >> * =B3Actuators may generally be mobile but are likely to be static in the >> majority of near-future roll-outs=B2: seems a bit contradictory. Don=B9t you= want >> to simply say that in a near-future the majority will be static? >> [CJ] Not quite, because actuators can be devices used by people who move= from >> one place to another to check how the sensor network is doing. I think b= oth >> cases are valid, and would therefore stick to the current wording. >> [Mischa] When I wrote this I had more in mind what JP said in shortened = form. >> I personally hence propose to change as suggested by JP. >>=20 >> JP>OK >>=20 >> * =B3Similar to the access points, actuator nodes do not suffer from any >> long-term resource constraints.=B2 what about battery-operated actuators ? >> [CJ] I'll leave that one to my colleagues :-) >> [Mischa] This is a difficult one. It clearly depends on the application, >> which even in the urban context can be infinite. There will be applicati= ons >> where acting nodes just switch something or reset something and hence ne= ed >> minimal energy allowing them to operate on batteries and hence be =AB reso= urce >> constrained =BB. Other applications will require actuators which need to d= o >> heavy stuff with loads of energy, one hence needs the mains. I propose t= o >> change it to reflect the two cases =AB Actuator node may also suffer from = any =8A >> =BB =20 >>=20 >> JP> Agree. >>=20 >> Section 3.1.4 >> ########### >> * =B3pollution data, such as polluting gases (SO2, NOx, CO, Ozone), >> heavy metals (e.g. Mercury), pH, radioactivity, etc;=B2 =3D> please expand >> acronym when first used. >> [CJ] Hmmm...I don't see too many acronyms in that sentence, actually. Th= is is >> chemistry stuff, unless you're suggesting we provide the "lettered" >> designation of these substances like carbon oxyde, etc.? I wouldn't go t= hat >> way...=20 >> [Mischa] J I agree with Christian. Let=B9s leave that basic stuff which I = think >> is part of SI and hence does not need to spelled out. >>=20 >>=20 >> * =B3These meters will be capable of >> advanced sensing functionalities such as measuring quality of >> service, providing granular interval data, or automating the >> detection of alarm conditions.=B2 >> You may want to more accurately define the term =B3quality of service=B2 sin= ce as >> you know, we used that term of other purposes in IETF documents. >> [CJ] Agreed. Since this is a list of examples, I would suggest something= like >> "measuring the quality of the water provided to the customers". >> [Mischa] I agree with both. >>=20 >> * In addition they may be capable of >> advanced interactive functionalities such as remote service >> disconnect or remote demand reset.=B2 =3D> in this case, they are also ac= ting >> as actuators. >> [CJ] Agreed.=20 >> [Mischa] I agree. >>=20 >> Section 3.2=20 >> ######### >>=20 >> * s/ between one other/between each other >> [CJ] OK.=20 >>=20 >> * =B3The network MUST be capable of supporting the organization of >> a large number of sensing nodes into regions containing on the order >> of 10^2 to 10^4 sensing nodes each.=B2 >> JP> Thanks to make this =B3MUST=B2 routing-specific and move it to the >> requirements section. >> [CJ] Agreed - would suggest this should be the introductory sentence of >> section 6.1.=20 >> [Mischa] I agree with both. >>=20 >> Section 3.3 >> ######### >>=20 >> * RFID: expand acronym (Radio Frequency IDentification) and add to the >> terminology section >> [CJ] OK.=20 >>=20 >> * s/battery-powered nodes/battery powered nodes >> [CJ] OK.=20 >> =B3Sensor nodes are capable of forwarding data.=B2 In other words, they can = act >> as routers. No need to repeat this here. >> [CJ] Fair enough. >>=20 >> Section 3.4 >> ######### >>=20 >> * =B32. packet errors due to medium access control;=B2 JP> It is not really >> =B3packet error=B2 here. >> [CJ] Do you mean "transmission erros"? If so, I would agree with you tha= t >> this wording is better, but then I guess it should be used for first thr= ee >> cases, right?=20 >> [Mischa] Collision resulting from poor MAC yield packet errors. We had >> discussed this section numerous times. I propose to leave it as is. >> JP> Just list a few potential error types. >>=20 >> * Some available protocols may cause packets of neighbouring nodes to co= llide >> and hence cause a link outage.=B2 JP> You may want to be more specific =B3So= me=B2 ? >> [CJ] Do you mean examples, because the previous sentence mentions the L2 >> protocols this sentence refers to? >> [Mischa] Yes, this is a L 2 issue and I am a little confused here : at o= ne >> iterative point you insist to minimize if not delete all references to L= 2 and >> here you ask to be more specific. I give you an example for you to under= stand >> but propose this not to be included : reservation based MACs can guarant= ee a >> collision-free schedule whereas contention-based MACs, MACs with common >> schedules and preamble-based MACs cannot. Therefore =AB some =BB. >> JP> After reread the sentence, I agree, the sentence is fine as is. >>=20 >> * =B3if ISM bands are to be used. For instance, if the 2.4GHz ISM band is >> used to facilitate communication between U-LLN nodes, then heavily >> loaded WLAN hot-spots become a detrimental performance factor >> jeopardizing the functioning of the U-LLN.=B2 >> JP> Please expand acronym when first used and add to the terminology sec= tion >> (ISM, WLAN, ...) >> [CJ] OK.=20 >>=20 >> * Don=B9t you want to say a few words about the varying BER leading to >> potentially even higher packet error loss ratio? >> [CJ] Expand the acronym ;-) I agree, bit error rate considerations shoul= d >> deserve a couple of sentences in this section. >> [Mischa] We purposedly don=B9t talk about BER but about PER =AD they are VER= Y >> different, mainly because you can use different channel codes. For insta= nce, >> a BCH code which is capable of correcting 5 errors does not care much ab= out >> small BER variations. Large changes, however, will effect the performanc= e but >> we are effecitvely interested in PER. I personally think that all needed >> information is in there. >> JP> Just add what you mentioned, and we=B9re fine. >> Section 4.1 >> ######### >>=20 >> * =B3Pre-programmed MAC=B2: expand acronym >> [CJ] OK.=20 >>=20 >> * =B3the autonomous organization=B2 =3D> self-organizing? >> [CJ] Much better indeed. >>=20 >> * =B3For example, nodes in urban sensor nodes SHOULD be able to:=B2 =3D> Sever= al of >> the requirements that follow are nor routing specific. You may either wa= nt to >> change the SHOULD for a =B3should=B2 or just focus on the routing aspects an= d >> move them to the routing requirements section. >> [CJ] They may not be routing specific, but I think they do affect how ro= uting >> policies are enforced. I woudl therefore suggest we stick to the propose= d >> wording.=20 >> [Mischa] I tend to agree with Christian. >> JP> Looking at the text here: >>=20 >> For example, nodes in urban sensor nodes SHOULD be able to: >>=20 >> o Dynamically adapt to ever-changing conditions of communication >> (possible degradation of QoS, variable nature of the traffic (real >> time vs. non real time, sensed data vs. alerts, node mobility, a >> combination thereof, etc.), >>=20 >> JP> As an routing solution implementer, how should I interpret the norma= tive >> SHOULD here, first bullet ? Here is what I propose: >> * You may either reword the paragraph with a routing specific approach. = I see >> what you mean here but you may need to explain what it means for the rou= ting >> protocol to adapt to changing condition of communication. Note that the >> SHOULD relies to routing engines, not the node itself. >> * Change the SHOULD for a non normative should. >>=20 >>=20 >> o Dynamically provision the service-specific (if not traffic- >> specific) resources that will comply with the QoS and security >> requirements of the service, >>=20 >> JP> When you write =B3 The node SHOULD dynamically provision the >> service-specific resources ...=B2 then it is not a routing requirement. >>=20 >> * =B3o Dynamically compute, select and possibly optimize the (multiple) >> path(s) that will be used by the participating devices to forward >> the traffic towards the actuators and/or the access point >> according to the service-specific and traffic-specific QoS, >> traffic engineering and security policies that will have to be >> enforced at the scale of a routing domain (that is, a set of >> networking devices administered by a globally unique entity), or a >> region of such domain (e.g. a metropolitan area composed of >> clusters of sensors).=B2 >> JP> You list important and stringent requirements here. Do you really ne= ed a >> routing algorithms capable of computing a path on a per QoS/service >> specific/... Basis ? >> [CJ] I don't read this sentence as you do. What I meant here is that ent= ities >> that operate urban sensor networks specify their own policies (routing, = te, >> security, QoS, etc.), which may be service-specific. The requirement sug= gests >> that the devices involved in the enforcement of such policies should beh= ave >> accordingly, that is, compute, select, establish and maintain paths whos= e >> characteristics comply with these policies. But I agree this is a strong >> requirement, but not stronger than, say, the self-organization requireme= nt. >> JP> That clarifies, thanks. >> [Mischa] We only need to make sure that this is not a MUST requirement >> because there are solutions out there which don=B9t need all these >> computations. >> JP> OK. >> Section 4.2 >> ######### >>=20 >> * =B3After the initialization phase and possibly some operational time, >> new nodes may be injected into the network as well as existing nodes >> removed from the network. The former might be because a removed node >> is replaced or denser readings/actuations are needed or routing >> protocols report connectivity problems. =B3 >> JP> Just to avoid any mis-interpretation when referring to routing probl= em, >> you mean that it may be desirable to inject to node because connectivity= is >> not sufficient (lack of enough redundant path, ...) and not because of a >> routing issue per say. >> [CJ] Not necessarily because connectivity is insufficient (new services, >> network expansion, node maintenance, etc.), and not necessarily because = there >> is a routing issue, indeed. >> JP> Could you then slightly reword the sentence to clarify ? Thanks. >> * =B3Differentiation >> SHOULD be made between node disappearance, where the node disappears >> without prior notification, and user or node-initiated disassociation >> ("phased-out"), where the node has enough time to inform the network >> about its removal.=B2 >> JP> Again this is not a routing requirement. Unless you refer to the abi= lity >> for the routing protocol to advertise to the rest of the network that it= will >> be removed in order for the other node to re-compute their path and avoi= d >> traffic disruption (e.g. Similarly to what we do with the ISIS overload = bit >> for example.) Is it what you mean ? >> [CJ] This is indeed what we meant (at least that's my reading of this >> sentence, but I'll let my colleagues further comment on that). >> [Mischa] Yes, this is what we mean. >> JP> OK good. Could you then slightly reword the sentence to clarify ? Th= anks. >> If so, please clarify and move the routing requirement (SHOULD in capita= l >> letter to the routing requirement section). >> [CJ] OK.=20 >>=20 >> * =B3The protocol(s) hence SHOULD support the pinpointing of problematic >> routing areas=B2 >> JP> Could you clarify what you mean by =B3pinpointing=B2 since it could be >> interpreted in many ways? >> [CJ] Fair enough, we need to be more explicit. Maybe something like: "th= e >> protocol should be able to convey information about malfunctioning nodes >> which may affect or jeopardize the overall routing efficiency, so that >> self-configuration capabilities of the sensor network might be solicited= to >> facilitate the appropriate reconfiguration." >> [Mischa] And I would add =AB This information may e.g. be in the form of e= xact >> or relative geographical position, etc. =BB >> JP> Agree with the proposed changes. >>=20 >> * The following section also requires some clarification =AD you wrote: >> =B3Furthermore, to inform the >> access point(s) of the node's arrival and association with the >> network as well as freshly associated nodes about packet forwarding >> schedules, roles, etc, appropriate (link state) updating mechanisms >> SHOULD be supported.=B2 >> JP> Are you explicitly requiring a Link State routing protocol or a rout= ing >> protocol that provides information about link states or ... ? >> [CJ] We meant "a protocol that can provide information about link status= ", >> indeed.=20 >> [Mischa] I remind you however that this is SHOULD and not MUST. >> JP> OK fair enough, but again a rather solution oriented requirement. >> Note that a requirement document should stay solution agnostic and stay = focus >> on the requirement. >> [CJ] Fully agreed. >> Is you requirement that any node needs to have visibility on other node >> characteristics with no attempt of aggregation? >> [CJ] Well, yes, presumably depending on design considerations: cluster h= ead >> vs. clients within the cluster, for example. I think this is typical Sel= f >> Organizing Networking capability. >>=20 >> Section 4.3 >> ######### >>=20 >> * =B3The protocol(s) hence MUST support a large number of highly >> directional unicast flows from the sensing nodes or sensing clusters >> towards the access point or highly directed multicast or anycast >> flows from the nodes towards multiple access points.=B2 >> JP> I think that what you mean is that the routing protocol MUST be opti= mized >> for Multipoint-to-Point traffic patterns (from sensors/actuators to Sink= ). As >> written, it is not clear whether you refer to it as a routing requiremen= t ? >> [CJ] Agreed.=20 >> [Mischa] No, our requirement is stronger. Multipoint can be from many =AB = some >> where =BB nodes to one sink. What we mean is many =AB geographically close =BB >> nodes to one sink. This is an underlying property of WSNs and our routin= g >> solutions HEAVILY rely on this. >> JP> Which =B3routing solutions=B2 ;-) ? This is a requirement ID. Then thank= s to >> clarify a bit more this requirement. >> This in fact what you wrote in section 6.5: =B3To this end, the routing >> protocol(s) SHOULD support and utilize the fact of highly directed traff= ic >> flow to facilitate scalability and parameter constrained routing.=B2 >> [CJ] Correct.=20 >>=20 >> * s/ More generally, entire routing areas may be avoided at e.g. night b= ut >> heavily used during the day when nodes are scavenging from sunlight/ Mor= e >> generally, entire routing areas may be avoided (e.g. at night) but heavi= ly >> used during the day when nodes are scavenging from sunlight. >> JP> Doesn=B9t this translate to the requirement for time-based routing (so= me >> form of policy routing) ? >> [CJ] Correct, but I don't see any harm in providing a practical example. >> [Mischa] I agree with Christian. >> JP> I just proposing to generalize this example and make it a requiremen= t, if >> needed. >> Section 4.4 >> ######### >>=20 >> =B3However, they are not very stringent where >> latencies SHOULD simply be sufficiently smaller than typical >> reporting intervals=B2 >> JP> This is certainly true but not a routing requirement but a data plan= e >> requirement unless you refer to the ability to support QoS aware routing >> where each node may want to be able to compute different paths depending= on >> the traffic requirements? >> [CJ] This is indeed related to the third bullet that appears in section = 4.1. >> JP> OK then just clarify to avoid mis-interpretation with a dataplane >> requirement. >> * Move =B3U-LLN network devices SHOULD support unicast and multicast routi= ng >> capabilities=B2 to the routing requirement section. You may want to leave = the >> sentence here (without a SHOULD). >> [CJ] OK.=20 >>=20 >> * You use the term =B3anycast=B2 that has been discussed in the past, in >> particular in the context of the Home routing requirement document. I wo= uld >> suggest to define this term in the document, refer to RFC4291 or RFC1546= , ... >> [CJ] Fully agreed. >>=20 >> Section 4.5 >> ######### >>=20 >> * =B3An alarm is likely being >> registered by a plurality of sensing nodes where the delivery of a >> single alert message with its location of origin suffices in most >> cases.=B2 >> Then you provide the example of toxic gas level. This is one example whe= re it >> might be desirable not to perform data aggregation/fusion and get multip= le >> copies of the same message from different source to perform =B3triangulati= on=B2 >> and better localize the incident. >> [CJ] Agreed, but I think this example precisely illustrates the issue. >>=20 >> * =B3Routing within urban sensor networks SHOULD require the U-LLN nodes >> to dynamically compute, select and install different paths towards a >> same destination, depending on the nature of the traffic. From this >> perspective, such nodes SHOULD inspect the contents of traffic >> payload for making routing and forwarding decisions: >>=20 >> JP> This clarifies my previous question; you do refer to ability to comp= ute >> different paths (with different characteristic). Note that the path sele= ction >> process performed by the sender and potentially routers along the path i= s not >> strictly speaking a routing requirement. >> Move this requirement to the requirement section. >> [CJ] OK.=20 >>=20 >> * =B3for example, the analysis of the traffic payload SHOULD be derived in= to >> aggregation >> capabilities for the sake of forwarding efficiency.=B2 >> JP> Can you clarify what you mean here? >> [CJ] The analysis of the payload of several packets should help in makin= g >> forwarding decisions that will spare network resources. >> JP> But then this is clearly not a requirement unless you refer to path >> selection. >> * =B3Delays and latencies are >> important; however, again, deliveries within seconds SHOULD suffice >> in most of the cases.=B2 >> JP> Clearly not a routing requirement! >> [CJ] Agreed.=20 >>=20 >> Section 5 >> ######## >>=20 >> * =B3The network SHOULD take into consideration that different application >> traffic may require different priorities when traversing the network, >> and that some traffic may be more sensitive to latency.=B2 >> JP> If by priorities you mean different routes with different characteri= stics >> then this is fine and already covered. If you refer to packet marking to >> provide different QoS in the data plane, this is not a routing requireme= nt. >> [CJ] Agreed - the former is the correct interpretation. >> JP> OK then just clarify. >> * =B3An U-LLN SHOULD support occasional large scale traffic flows from >> sensing nodes to access points, such as system-wide alerts. =B3 and =B3A = node >> MUST be able to send its own alerts toward an access >> point while continuing to forward traffic on behalf of other devices >> who are also experiencing an alert condition. The network MUST be >> able to manage this sudden large traffic flow.=B2 >> JP> Not routing requirements. Unless ... You require the ability to comp= ute >> multiple paths and use all of them (symmetrical or asymmetrical routing = ???) >> to spread out the traffic and limit network delays ? >> [CJ] I think this is a kind of causality effect: the routing protocol mu= st be >> able to accommodate traffic bursts by dynamically computing and selectin= g >> multiple paths towards the same destination. >> [Mischa] Agreed. >> JP> Great, then remove the SHOULD, MUST on the previous paragraph and ad= d a >> routing requirements related to it with the appropriate SHOULD and MUST. >>=20 >> * You make an interesting reference to Smart Grid and DR/DSM. That said,= you >> wrote =B3The network SHOULD support internetworking, while giving attentio= n to >> security implications of interfacing, for example, a home network with a >> utility U-LLN.=B2 >> JP> Don=B9t you mean that the routing protocol must be able to potentially >> interact via potential route redistribution with other routing protocol = used >> in the Internet, should these two protocols not be identical ? >> [CJ] Correct.=20 >> JP> OK, just clarify. >>=20 >> Section 6 >> ######### >>=20 >> * S/Current urban roll-outs are composed of sometimes more than a hundre= d >> nodes/ Current urban roll-outs are composed of sometimes more than one >> hundred nodes >> [CJ] OK.=20 >>=20 >> * =B3 The routing protocols(s) SHOULD support the organization of a large >> number of nodes into regions of to-be-specified size.=B2 >> JP> It will be difficult (or too easy ;-)) to be compliant with that SHO= ULD >> with a to-be-specified size. Or did you mean =B3configurable=B2 ? >> [CJ] Configurable is indeed much better. >>=20 >> * =B3To this end, the routing protocol(s) MUST support parameter >> constrained routing, where examples of such parameters (CPU, memory >> size, battery level, etc.) have been given in the previous paragraph.= =B2 >> JP> Please use the term =B3node constrained based routing=B2 >> [CJ] I'm not sure I agree here, because "node-constrained" sounds more f= uzzy >> to me. "environment-constrained"? >> [Mischa] Parameter constrained is the right word. For instance node inte= rnal >> parameters (CPU, etc) and also environment parameters (avilability of su= n and >> therefore availability of energy due to energy scavanging, etc) >> JP> Fine, leave it unchanged. I need to work on the terminology ID, we=B9l= l >> clarify then. >>=20 >> * =B3For the latter, the protocol(s) MUST support multi- and >> any-cast addressing. The protocol(s) SHOULD also support the >> formation and identification of groups of field devices in the >> network.=B2 >> JP> You may want to more accurately define the term =B3anycast=B2 >> [CJ] Would the couple of references you righfully mentioned earlier be >> sufficient? >> JP> Yes thanks. >> * =B3 To mandate fully interoperable implementations, the routing >> protocol(s) proposed in U-LLN MUST support different devices and >> underlying technologies without compromising the operability and >> energy efficiency of the network.=B2 >> JP> This requires clarification here. Do you mean that the routing proto= col >> MUST support node constrained based routing? If so, it is already stated >> above. The support of different L1/L2 is a given (route over). >> [CJ] I would agree with Jean-Philippe, and suggest we remove this >> wording...but I'll let the co-authors further comment. >> [Mischa] Imagine a network composed of simple ZigBee nodes and a few WLA= N >> nodes which have a ZigBee interface. An optimum solution will use the WL= AN >> nodes as a virtual information backbone and connect the ZigBee nodes to = the >> WLAN nodes. You can turn this as you want but an optimal routing solutio= n >> would never treat nodes of different capabilities the same (eg build a f= lat >> routing structure). Therefore, any routing algorithm should ideally make= use >> of this heterogeneity. I would be happy to change this MUST for SHOULD (= which >> is what I had proposed, I think, a few weeks ago). >> JP> If you refer to the ability to mix IP with non IP node, then I do >> disagree. This is not a requirement that we can meet (IETF works on IP).= Thus >> my suggestion to remove this sentence. >> * Section 6.8, as written, is not related to routing but data plane. Let= me >> be more specific: >>=20 >> * =B3To this end, the routing protocol(s) SHOULD support minimum latency >> for alert reporting and time-critical data queries.=B2 >> JP> The support of minimum latency path (data plane !) or the support fo= r >> different metric path (control plane) ? >> [CJ] As written, I read it as the former interpretation and would sugges= t we >> remove the text. >> JP> OK >> * =B3For regular data >> reporting, it SHOULD support latencies not exceeding a fraction of >> the smallest reporting interval. =B3 >> JP> Not a routing requirement. Even if you are referring to a bound on t= he >> total path metric (the metric reflecting the delay in this case), this i= s an >> implementation issue. >> [CJ] Correct.=20 >>=20 >> * =B3Due to the different latency requirements, the routing protocol(s) SH= OULD >> support the ability of dealing with different latency requirements. The >> routing protocol(s) SHOULD also support the ability to route according t= o >> different metrics (one of which could e.g. be latency).=B2 >> JP> yes these are routing requirements although I would suggest to remov= e the >> first sentence, the requirement being captured in the second sentence. >> [CJ] Agreed.=20 >>=20 >> Section 7 >> ######### >>=20 >> * =B3As every network, U-LLNs are exposed to security threats that MUST be >> addressed.=B2 >> JP> You cannot put a MUST here unless you list the routing security thre= ats. >> [CJ] OK.=20 >>=20 >> * s/ potential security threats/ potential routing security threats =3D> J= P> >> Please use the term =B3routing security=B2 in place of =B3security=B2 throughout= the >> section.=20 >> [CJ] OK.=20 >>=20 >> * =B3U-LLN networks SHOULD support mechanisms to preserve the >> confidentiality of the traffic that they forward. The U-LLN network >> SHOULD NOT prevent an application from employing additional >> confidentiality mechanisms.=B2 >> JP> I do agree with the requirement but this is not a routing requiremen= t. >> [CJ] Fair enough. >> Could you focus on the routing security issues ? Or are you referring to= the >> routing traffic confidentiality ? >> [CJ] No, this wording referred to the traffic forwarded by the network. >> JP> Then it does not really belong to this routing requirement ID. >> This is what you do right after: >> [CJ] Correct.=20 >> =B3 The U-LLN MUST be protected against attempts to inject false or >> modified packets. For example, an attacker SHOULD be prevented from >> manipulating or disabling the routing function by compromising >> routing update messages. Moreover, it SHOULD NOT be possible to >> coerce the network into routing packets which have been modified in >> transit. To this end the routing protocol(s) MUST support message >> integrity.=B2 >> JP> I do not see any reference to the type of routing attacks that could= be >> performed on such networks because of the typical P2MP traffic pattern, >> extensive use of wireless links, ... >> [CJ] OK, but does that mean we should not consider such requirement? I d= on't >> think so, afaic. >> JP> I did not mean to remove these requirements, there are quite needed = but >> to also look at other requirements related to specific routing security >> attacked of WSN. >> JP> What I would suggest is to re-focus on the routing security issues w= ith >> the Security expert that will get appointed. >> [CJ] OK.=20 >>=20 >> Reference section >> ############### >>=20 >> The current reference section reads: >> 11.2. Informative References >>=20 >> [I-D.brandt-roll-home-routing-reqs] >> Brandt, A., "Home Automation Routing Requirement in Low >> Power and Lossy Networks", >> draft-brandt-roll-home-routing-reqs-01 (work in progress), >> May 2008. >>=20 >> JP> Please update to draft-ietf-roll-home-routing-reqs and add the refer= ence=20 >> to draft-ietf-roll-indus-routing-reqs >> [CJ] OK.=20 >>=20 >> [I-D.culler-rl2n-routing-reqs] >> Vasseur, J. and D. Cullerot, "Routing Requirements for Low >> Power And Lossy Networks", >> draft-culler-rl2n-routing-reqs-01 (work in progress), >> July 2007. >>=20 >> JP> This one can be removed. >> [CJ] OK.=20 >>=20 >>=20 >> Last comment: please check that you expand acronyms when first used. >> [CJ] OK. >> =20 >> JP> Thanks. >>=20 >> Cheers, >>=20 >> JP. >>=20 >> Cheers, >> =20 >> Christian.=20 > ********************************* > This message and any attachments (the "message") are confidential and int= ended=20 > solely for the addressees.=20 > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration.=20 > France Telecom Group shall not be liable for the message if altered, chan= ged=20 > or falsified. > If you are not the intended addressee of this message, please cancel it=20 > immediately and inform the sender. > ******************************** >=20 --B_3303118791_75957491 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: Review of draft-ietf-roll-urban-routing-reqs-01 Hi,

Thanks for the quick replies  !  See in line


On 8/22/08 11:20 AM, "Mischa Dohler" <mischa.dohler@cttc.es> wrote:

Thanks, JP, indeed, for this in-depth review. I propose = that Tim takes care of all the small typos identified by JP. Some comments i= n-line in addition to Christian ones. Thanks to all and kind regards, Mischa= .
 

From: christian.jacquenet@orange-ftgroup.com [mailto:christian.jacquenet@orange-ftgroup.com]=
Sent: Thursday, August 21, 2008 11:02 PM
To: JP Vasseur; Mischa Dohler; Tim Winter; WATTEYNE Thomas RD-TECH; = MADHUSUDAN Giyyarpuram RD-TECH; CHEGARAY Gabriel RD-TECH; BARTHEL Dominique = RD-TECH; roll@ietf.org
Cc: David E. Culler
Subject: RE: Review of draft-ietf-roll-urban-routing-reqs-01
Dear all,
Thanks to Jean-Philippe for this thorou= gh review. Please find a first shot of personal comments inline, but I'll le= t my fellow co-authors further elaborate accordingly.


[CJ] [snip]
Abstract
#######
s/ for a wireless ROLL solution to be useful the protocol(s) ought to be en= ergy-efficient, scalable, and autonomous/ the routing solution ought to be e= nergy-efficient, scalable and autonomous.

JP> You may want to use a different word than “Autonomous”. = Do you refer to the “self configuration” property ?
[CJ] We chose "a= utonomous" because it was generic enough, while I think "self conf= iguration" is too restrictive: it's not only a matter of configuration,= it's also a matter of making (forwarding) decisions, self-healing capabilit= ies, etc. Another word I would suggest is "self-organizing", if th= is is more specific.
[Mischa] We had long discussions on this and finally converged to &= laquo; autonomous ». Let’s leave it.

JP> This is f= ine, just add a definition of “Autonomous” then.

Section 1
#######
* “Section 6 discusses the routing requirements for networks comprisi= ng
   such constrained devices in a U-LLN environment.  Th= ese requirements
   may be overlapping requirements derived from other applic= ation-
   specific requirements documents or as listed in
   [I-D.culler-rl2n-routing-reqs].”

JP> Please remove this reference (ID abandoned) and insert reference to = http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-= reqs-02.txt &l= t;http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routin= g-reqs-02.txt> , http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-= routing-reqs-01.txt <http://www.ietf.org/internet-drafts/draft-ietf-roll-in= dus-routing-reqs-01.txt> and http://www.ietf.org/internet-drafts/d= raft-martocci-roll-commercial-routing-reqs-00.txt <http://www.ietf= .org/internet-drafts/draft-martocci-roll-commercial-routing-reqs-00.txt&= gt; .
[CJ] OK.

* s/ Section 7 provides an overview of security considerations/ Section 7 p= rovides an overview of routing security considerations
[CJ] OK.

Section 2
########

* S/ ROLL: Routing over Low power and Lossy networks/ ROLL: Routing Over Lo= w power and Lossy networks
[CJ] OK.

* Schedule:  An agreed execution, wake-up, transmission, reception,          etc., time-table betw= een two or more field devices.
The definition is a little bit too vague. If used in the generic sense, no = need to add it to the terminology section. Otherwise, it ought to be more sp= ecific.
[CJ] Schedule is inde= ed very generic, but I think the sue of the word makes perfect sense in the = context of U-WSN networks. Being more specific would mean elaborating on use= cases where schedule information is taken into account by field devices to = perform some specific action. If this proposal makes sense, I'm not sure the= terminology section is appropriate for such elaboration and would therefore= suggest we (1) keep the "schedule" definition in this section and= (2) further elaborate on a use case that illustrates the use of schedule in= formation in section 5 of the draft.
[Mischa] I don= ’t see why this is vague. This is very clear to me. Let’s leave = it as is (I guess we do not need to find the maximum entropy of this documen= t; the routing solution won’t get better due to this J)= .
JP> I = must say that I like the proposal of Christian to further elaborate (one or = two example are sufficient) on a use case. I can see at least 3-4 ways the w= ord “Schedule” may be interpreted.

Section 3.1.1
###########
* S/ pre- planned location/ pre-planned location
[CJ] OK.

* What you refer to as a repeater is in fact a router. What I would suggest= here is to reword this paragraph to indicate that some nodes are simple rou= ters whereas other nodes are routers and lso perform sensing/actuating task.= Insert this paragraph after the Actuators and Sensors paragraphs.
[CJ] So you're sugges= ting to (1) remove section 3.1.2 (not 3.1.1, actually), and (2) indicate tha= t some nodes are routers (not "simple", btw :-), others also perfo= rm sensing/actuating tasks, right? I'm fine with this suggestion, but I'd li= ke to hear the feedback from my colleagues. It's also worth mentioning that = a "repeater" has a very specific meaning in "classical" = networking environments, remembering the old days of FOIRL and the like...th= at may be another reason to avoid the use of this notion within the roll con= text.
[Mischa] We had this discussion before and the reason outlined by C= hristian is exactly why the thingy is called repeater and not router.
JP> As= pointed out, the word “repeaters” has been used for other purpo= ses ... What you refer to as a “repeater” is an “router= 221;. I would suggest not to adopt a specific terminology for this ID.
* “Actuators may generally be mobile but are likely to= be static in the majority of near-future roll-outs”: seems a bit cont= radictory. Don’t you want to simply say that in a near-future the majo= rity will be static?
[CJ] Not quite, becau= se actuators can be devices used by people who move from one place to anothe= r to check how the sensor network is doing. I think both cases are valid, an= d would therefore stick to the current wording.
[Mischa] When I wrote this I had more in mind what JP said in short= ened form. I personally hence propose to change as suggested by JP.

JP>OK

* “Similar to the access points, actuator nodes do not suffer from an= y long-term resource constraints.” what about battery-operated actuato= rs ?
[CJ] I'll leave that one to my colleagu= es :-)
[Mischa] This is a difficult one. It clearly depends on the applica= tion, which even in the urban context can be infinite. There will be applica= tions where acting nodes just switch something or reset something and hence = need minimal energy allowing them to operate on batteries and hence be &laqu= o; resource constrained ». Other applications will require actuators w= hich need to do heavy stuff with loads of energy, one hence needs the mains.= I propose to change it to reflect the two cases « Actuator node may a= lso suffer from any … »  

JP> Agree.

Section 3.1.4
###########
* “pollution data, such as polluting gases (SO2, NOx, CO, Ozone),
 heavy metals (e.g.  Mercury), pH, radioactivity, etc;” =3D&g= t; please expand acronym when first used.
[CJ] Hmmm...I don't see too many acrony= ms in that sentence, actually. This is chemistry stuff, unless you're sugges= ting we provide the "lettered" designation of these substances lik= e carbon oxyde, etc.? I wouldn't go that way...
[Mischa] J I agree with Christian. Let’s leave that = basic stuff which I think is part of SI and hence does not need to spelled o= ut.


* “These meters will be capable of
   advanced sensing functionalities such as measuring qualit= y of
   service, providing granular interval data, or automating = the
   detection of alarm conditions.”
You may want to more accurately define the term “quality of service&#= 8221; since as you know, we used that term of other purposes in IETF documen= ts.
[CJ] Agreed. Since th= is is a list of examples, I would suggest something like "measuring the= quality of the water provided to the customers".
[Mischa] I agree with both.

* In addition they may be capable of
   advanced interactive functionalities such as remote servi= ce
   disconnect or remote demand reset.” =3D> in this c= ase, they are also acting as actuators.
[CJ] Agreed.
[Mischa] I agree.

Section 3.2
#########

* s/ between one other/between each other
[CJ] OK.

* “The network MUST be capable of supporting the organization of
   a large number of sensing nodes into regions containing o= n the order
   of 10^2 to 10^4 sensing nodes each.”
JP> Thanks to make this “MUST” routing-specific and move it = to the requirements section.
[CJ] Agreed - would s= uggest this should be the introductory sentence of section 6.1.
[Mischa] I agree with both.

Section 3.3
#########

* RFID: expand acronym (Radio Frequency IDentification) and add to the term= inology section
[CJ] OK.

* s/battery-powered nodes/battery powered nodes
[CJ] OK.
“Sensor= nodes are capable of forwarding data.” In other words, they can act a= s routers. No need to repeat this here.
[CJ] Fair enough.
Section 3.4
#########

* “2.  packet errors due to medium access control;” JP>= It is not really “packet error” here.
[CJ] Do you mean &quo= t;transmission erros"? If so, I would agree with you that this wording = is better, but then I guess it should be used for first three cases, right? =
[Mischa] Collision resulting from poor MAC yield packet errors. We = had discussed this section numerous times. I propose to leave it as is.
JP> Ju= st list a few potential error types.

* Some available protocols may cause packets of neighbouring nodes to colli= de and hence cause a link outage.” JP> You may want to be more spec= ific “Some” ?
[CJ] Do you mean examples, because the = previous sentence mentions the L2 protocols this sentence refers to?
[Mischa] Yes, this is a L 2 issue and I am a little confused here := at one iterative point you insist to minimize if not delete all references = to L2 and here you ask to be more specific. I give you an example for you to= understand but propose this not to be included : reservation based MACs can= guarantee a collision-free schedule whereas contention-based MACs, MACs wit= h common schedules and preamble-based MACs cannot. Therefore « some &r= aquo;.
JP> Af= ter reread the sentence, I agree, the sentence is fine as is.

* “if ISM bands are to be used.  For instance, if the 2.4GHz ISM= band is
   used to facilitate communication between U-LLN nodes, the= n heavily
   loaded WLAN hot-spots become a detrimental performance fa= ctor
   jeopardizing the functioning of the U-LLN.”
JP> Please expand acronym when first used and add to the terminology sec= tion (ISM, WLAN, ...)
[CJ] OK.

* Don’t you want to say a few words about the varying BER leading to = potentially even higher packet error loss ratio?
[CJ] Expand the acron= ym ;-) I agree, bit error rate considerations should deserve a couple of sen= tences in this section.
[Mischa] We purposedly don’t talk about BER but about PER = 211; they are VERY different, mainly because you can use different channel c= odes. For instance, a BCH code which is capable of correcting 5 errors does = not care much about small BER variations. Large changes, however, will effec= t the performance but we are effecitvely interested in PER. I personally thi= nk that all needed information is in there.
JP> Ju= st add what you mentioned, and we’re fine.
Section 4.= 1
#########

* “Pre-programmed MAC”: expand acronym
[CJ] OK.

* “the autonomous organization” =3D> self-organizing?
[CJ] Much better inde= ed.

* “For example, nodes in urban sensor nodes SHOULD be able to:”= =3D> Several of the requirements that follow are nor routing specific. You= may either want to change the SHOULD for a “should” or just foc= us on the routing aspects and move them to the routing requirements section.=
[CJ] They may not be = routing specific, but I think they do affect how routing policies are enforc= ed. I woudl therefore suggest we stick to the proposed wording.
[Mischa] I tend to agree with Christian.
JP> Lo= oking at the text here:

JP> As an rou= ting solution implementer, how should I interpret the normative SHOULD here,= first bullet ? Here is what I propose:
  • Y= ou may either reword the paragraph with a routing specific approach. I see w= hat you mean here but you may need to explain what it means for the routing = protocol to adapt to changing condition of communication. Note that the SHOU= LD relies to routing engines, not the node itself.
  • Chang= e the SHOULD for a non normative should.


   o  Dynamically provision the service-specific (if no= t traffic-
      specific) resources that will comply wi= th the QoS and security
      requirements of the service,

JP> When you = write “ The node SHOULD dynamically provision the service-specific res= ources ...” then it is not a routing requirement.=   

* “o  Dynamically compute, select and possibly optimize the (mul= tiple)
      path(s) that will be used by the partic= ipating devices to forward
      the traffic towards the actuators and/o= r the access point
      according to the service-specific and t= raffic-specific QoS,
      traffic engineering and security polici= es that will have to be
      enforced at the scale of a routing doma= in (that is, a set of
      networking devices administered by a gl= obally unique entity), or a
      region of such domain (e.g. a metropoli= tan area composed of
      clusters of sensors).”
JP> You list important and stringent requirements here. Do you really ne= ed a routing algorithms capable of computing a path on a per QoS/service spe= cific/... Basis ?
[CJ] I don't read thi= s sentence as you do. What I meant here is that entities that operate urban = sensor networks specify their own policies (routing, te, security, QoS, etc.= ), which may be service-specific. The requirement suggests that the devices = involved in the enforcement of such policies should behave accordingly, that= is, compute, select, establish and maintain paths whose characteristics com= ply with these policies. But I agree this is a strong requirement, but not s= tronger than, say, the self-organization requirement.
JP> Th= at clarifies, thanks.
[Mischa] = We only need to make sure that this is not a MUST requirement because there = are solutions out there which don’t need all these computations.
JP> OK.
Section 4.= 2
#########

* “After the initialization phase and possibly some operational time,=
   new nodes may be injected into the network as well as exi= sting nodes
   removed from the network.  The former might be becau= se a removed node
   is replaced or denser readings/actuations are needed or r= outing
   protocols report connectivity problems. “
JP> Just to avoid any mis-interpretation when referring to routing probl= em, you mean that it may be desirable to inject to node because connectivity= is not sufficient (lack of enough redundant path, ...) and not because of a= routing issue per say.
[CJ] Not necessarily because connectivi= ty is insufficient (new services, network expansion, node maintenance, etc.)= , and not necessarily because there is a routing issue, indeed.
JP> Co= uld you then slightly reword the sentence to clarify ? Thanks.
* “Differentiation
   SHOULD be made between node disappearance, where the node= disappears
   without prior notification, and user or node-initiated di= sassociation
   ("phased-out"), where the node has enough time = to inform the network
   about its removal.”
JP> Again this is not a routing requirement. Unless you refer to the abi= lity for the routing protocol to advertise to the rest of the network that i= t will be removed in order for the other node to re-compute their path and a= void traffic disruption (e.g. Similarly to what we do with the ISIS overload= bit for example.) Is it what you mean ?
[CJ] This is indeed what we meant (at l= east that's my reading of this sentence, but I'll let my colleagues further = comment on that).
[Mischa] Yes, this is what we mean.
JP> OK= good. Could you then slightly reword the sentence to clarify ? Thanks.
If so, ple= ase clarify and move the routing requirement (SHOULD in capital letter to th= e routing requirement section).
[CJ] OK.

* “The protocol(s) hence SHOULD support the pinpointing of problemati= c routing areas”
JP> Could you clarify what you mean by “pinpointing” since i= t could be interpreted in many ways?
[CJ] Fair enough, we = need to be more explicit. Maybe something like: "the protocol should be= able to convey information about malfunctioning nodes which may affect or j= eopardize the overall routing efficiency, so that self-configuration capabil= ities of the sensor network might be solicited to facilitate the appropriate= reconfiguration."
[Mischa] And I would add « This information may e.g. be in th= e form of exact or relative geographical position, etc. »
JP> Ag= ree with the proposed changes.

* The following section also requires some clarification – you wrote:=
“Furthermore, to inform the
   access point(s) of the node's arrival and association wit= h the
   network as well as freshly associated nodes about packet = forwarding
   schedules, roles, etc, appropriate (link state) updating = mechanisms
   SHOULD be supported.”
JP> Are you explicitly requiring a Link State routing protocol or a rout= ing protocol that provides information about link states or ... ?
[CJ] We meant "a protocol that can= provide information about link status", indeed.
[Mischa] I remind you however that this is SHOULD and not MUST.
JP> OK= fair enough, but again a rather solution oriented requirement.
Note that = a requirement document should stay solution agnostic and stay focus on the r= equirement.
[CJ] Fully agreed.
Is you requir= ement that any node needs to have visibility on other node characteristics w= ith no attempt of aggregation?
[CJ] Well, yes, presu= mably depending on design considerations: cluster head vs. clients within th= e cluster, for example. I think this is typical Self Organizing Networking c= apability.

Section 4.3
#########

* “The protocol(s) hence MUST support a large number of highly
   directional unicast flows from the sensing nodes or sensi= ng clusters
   towards the access point or highly directed multicast or = anycast
   flows from the nodes towards multiple access points.̶= 1;
JP> I think that what you mean is that the routing protocol MUST be opti= mized for Multipoint-to-Point traffic patterns (from sensors/actuators to Si= nk). As written, it is not clear whether you refer to it as a routing requir= ement ?
[CJ] Agreed.
[Mischa] No, our requirement is stronger. Multipoint can be from ma= ny « some where » nodes to one sink. What we mean is many «= ; geographically close » nodes to one sink. This is an underlying prop= erty of WSNs and our routing solutions HEAVILY rely on this.
JP> Wh= ich “routing solutions” ;-) ? This is a requirement ID. Then tha= nks to clarify a bit more this requirement.
This in fa= ct what you wrote in section 6.5: “To this end, the routing protocol(s= ) SHOULD support and utilize the fact of highly directed traffic flow to fac= ilitate scalability and parameter constrained routing.”
[CJ] Correct.

* s/ More generally, entire routing areas may be avoided at e.g. night but = heavily used during the day when nodes are scavenging from sunlight/ More ge= nerally, entire routing areas may be avoided (e.g. at night) but heavily use= d during the day when nodes are scavenging from sunlight.
JP> Doesn’t this translate to the requirement for time-based routi= ng (some form of policy routing) ?
[CJ] Correct, but I d= on't see any harm in providing a practical example.
[Mischa] I agree with Christian.
JP> I = just proposing to generalize this example and make it a requirement, if need= ed.
Section 4.= 4
#########

“However, they are not very stringent where
   latencies SHOULD simply be sufficiently smaller than typi= cal
   reporting intervals”
JP> This is certainly true but not a routing requirement but a data plan= e requirement unless you refer to the ability to support QoS aware routing w= here each node may want to be able to compute different paths depending on t= he traffic requirements?
[CJ] This is indeed related to the thir= d bullet that appears in section 4.1.
JP> OK= then just clarify to avoid mis-interpretation with a dataplane requirement.=
* Move “U-LLN network dev= ices SHOULD support unicast and multicast routing capabilities” to the= routing requirement section. You may want to leave the sentence here (witho= ut a SHOULD).
[CJ] OK.

* You use the term “anycast” that has been discussed in the pas= t, in particular in the context of the Home routing requirement document. I = would suggest to define this term in the document, refer to RFC4291 or RFC15= 46, ...
[CJ] Fully agreed.
Section 4.5
#########

* “An alarm is likely being
   registered by a plurality of sensing nodes where the deli= very of a
   single alert message with its location of origin suffices= in most
   cases.”
Then you provide the example of toxic gas level. This is one example where = it might be desirable not to perform data aggregation/fusion and get multipl= e copies of the same message from different source to perform “triangu= lation” and better localize the incident.
[CJ] Agreed, but I th= ink this example precisely illustrates the issue.

* “Routing within urban sensor networks SHOULD require the U-LLN node= s
   to dynamically compute, select and install different path= s towards a
   same destination, depending on the nature of the traffic.=  From this
   perspective, such nodes SHOULD inspect the contents of tr= affic
   payload for making routing and forwarding decisions:

JP> This clarifies my previous question; you do refer to ability to comp= ute different paths (with different characteristic). Note that the path sele= ction process performed by the sender and potentially routers along the path= is not strictly speaking a routing requirement.
Move this requirement to the requirement section.
[CJ] OK.

* “for example, the analysis of the traffic payload SHOULD be derived= into aggregation
   capabilities for the sake of forwarding efficiency.”= ;
JP> Can you clarify what you mean here?
[CJ] The analysis of = the payload of several packets should help in making forwarding decisions th= at will spare network resources.
JP> Bu= t then this is clearly not a requirement unless you refer to path selection.=
* “Delays and latencies a= re
   important; however, again, deliveries within seconds SHOU= LD suffice
   in most of the cases.”
JP> Clearly not a routing requirement!
[CJ] Agreed.

Section 5
########

* “The network SHOULD take into consideration that different applicat= ion
   traffic may require different priorities when traversing = the network,
   and that some traffic may be more sensitive to latency.&#= 8221;
JP> If by priorities you mean different routes with different characteri= stics then this is fine and already covered. If you refer to packet marking = to provide different QoS in the data plane, this is not a routing requiremen= t.
[CJ] Agreed - the for= mer is the correct interpretation.
JP> OK= then just clarify.
* “An U-LLN SHOULD suppor= t occasional large scale traffic flows from
   sensing nodes to access points, such as system-wide alert= s. “ and “A node MUST be able to send its own alerts toward an a= ccess
   point while continuing to forward traffic on behalf of ot= her devices
   who are also experiencing an alert condition.  The n= etwork MUST be
   able to manage this sudden large traffic flow.”
JP> Not routing requirements. Unless ... You require the ability to comp= ute multiple paths and use all of them (symmetrical or asymmetrical routing = ???) to spread out the traffic and limit network delays ?
[CJ] I think this is a kind of causalit= y effect: the routing protocol must be able to accommodate traffic bursts by= dynamically computing and selecting multiple paths towards the same destina= tion.
[Mischa] Agreed.
JP> Gr= eat, then remove the SHOULD, MUST on the previous paragraph and add a routin= g requirements related to it with the appropriate SHOULD and MUST.

* You make an interesting reference to Smart Grid and DR/DSM. That said, yo= u wrote “The network SHOULD support internetworking, while giving atte= ntion to security implications of interfacing, for example, a home network w= ith a utility U-LLN.”
JP> Don’t you mean that the routing protocol must be able to poten= tially interact via potential route redistribution with other routing protoc= ol used in the Internet, should these two protocols not be identical ?
[CJ] Correct.
JP> OK= , just clarify.

Section 6
#########

* S/Current urban roll-outs are composed of sometimes more than a hundred n= odes/ Current urban roll-outs are composed of sometimes more than one hundre= d nodes
[CJ] OK.

* “ The routing protocols(s) SHOULD support the organization of a lar= ge number of nodes into regions of to-be-specified size.”
JP> It will be difficult (or too easy ;-)) to be compliant with that SHO= ULD with a to-be-specified size. Or did you mean “configurable” = ?
[CJ] Configurable is = indeed much better.

* “To this end, the routing protocol(s) MUST support parameter
   constrained routing, where examples of such parameters (C= PU, memory
   size, battery level, etc.) have been given in the previou= s paragraph.”
JP> Please use the term “node constrained based routing”
[CJ] I'm not sure I a= gree here, because "node-constrained" sounds more fuzzy to me. &qu= ot;environment-constrained"?
[Mischa] Parameter constrained is the right word. For instance node= internal parameters (CPU, etc) and also environment parameters (avilability= of sun and therefore availability of energy due to energy scavanging, etc)<= BR> JP> Fi= ne, leave it unchanged. I need to work on the terminology ID, we’ll cl= arify then.

* “For the latter, the protocol(s) MUST support multi- and
   any-cast addressing.  The protocol(s) SHOULD also su= pport the
   formation and identification of groups of field devices i= n the
   network.”
JP> You may want to more accurately define the term “anycast”= ;
[CJ] Would the couple of references you righfully mentioned earlier be suff= icient?
JP> Ye= s thanks.
* “ To mandate fully inte= roperable implementations, the routing
   protocol(s) proposed in U-LLN MUST support different devi= ces and
   underlying technologies without compromising the operabil= ity and
   energy efficiency of the network.”
JP> This requires clarification here. Do you mean that the routing proto= col MUST support node constrained based routing? If so, it is already stated= above. The support of different L1/L2 is a given (route over).
[CJ] I would agree with Jean-Philippe, = and suggest we remove this wording...but I'll let the co-authors further com= ment.
[Mischa] Imagine a network composed of simple ZigBee nodes and a fe= w WLAN nodes which have a ZigBee interface. An optimum solution will use the= WLAN nodes as a virtual information backbone and connect the ZigBee nodes t= o the WLAN nodes. You can turn this as you want but an optimal routing solut= ion would never treat nodes of different capabilities the same (eg build a f= lat routing structure). Therefore, any routing algorithm should ideally make= use of this heterogeneity. I would be happy to change this MUST for SHOULD = (which is what I had proposed, I think, a few weeks ago).
JP> If= you refer to the ability to mix IP with non IP node, then I do disagree. Th= is is not a requirement that we can meet (IETF works on IP). Thus my suggest= ion to remove this sentence.
* Section = 6.8, as written, is not related to routing but data plane. Let me be more sp= ecific:

* “To this end, the routing protocol(s) SHOULD support minimum latenc= y
   for alert reporting and time-critical data queries.”= ;
JP> The support of minimum latency path (data plane !) or the support fo= r different metric path (control plane) ?
[CJ] As written, I read it as the forme= r interpretation and would suggest we remove the text.
JP> OK=
* “For regular data
   reporting, it SHOULD support latencies not exceeding a fr= action of
   the smallest reporting interval.  “
JP> Not a routing requirement. Even if you are referring to a bound on t= he total path metric (the metric reflecting the delay in this case), this is= an implementation issue.
[CJ] Correct.

* “Due to the different latency requirements, the routing protocol(s)= SHOULD support the ability of dealing with different latency requirements. =  The routing protocol(s) SHOULD also support the ability to route accor= ding to different metrics (one of which could e.g. be latency).”
JP> yes these are routing requirements although I would suggest to remov= e the first sentence, the requirement being captured in the second sentence.=
[CJ] Agreed.

Section 7
#########

* “As every network, U-LLNs are exposed to security threats that MUST= be addressed.”
JP> You cannot put a MUST here unless you list the routing security thre= ats.
[CJ] OK.

* s/ potential security threats/ potential routing security threats =3D> J= P> Please use the term “routing security” in place of “= security” throughout the section.
[CJ] OK.

* “U-LLN networks SHOULD support mechanisms to preserve the
   confidentiality of the traffic that they forward.  T= he U-LLN network
   SHOULD NOT prevent an application from employing addition= al
   confidentiality mechanisms.”
JP> I do agree with the requirement but this is not a routing requiremen= t.
[CJ] Fair enough. Could you foc= us on the routing security issues ? Or are you referring to the routing traf= fic confidentiality ?
[CJ] No, this wording= referred to the traffic forwarded by the network.
JP> Then it d= oes not really belong to this routing requirement ID.
This is wh= at you do right after:
[CJ] Correct.
“ The U= -LLN MUST be protected against attempts to inject false or
   modified packets.  For example, an attacker SHOULD b= e prevented from
   manipulating or disabling the routing function by comprom= ising
   routing update messages.  Moreover, it SHOULD NOT be= possible to
   coerce the network into routing packets which have been m= odified in
   transit.  To this end the routing protocol(s) MUST s= upport message
   integrity.”
JP> I do not see any reference to the type of routing attacks that could= be performed on such networks because of the typical P2MP traffic pattern, = extensive use of wireless links, ...
[CJ] OK, but does tha= t mean we should not consider such requirement? I don't think so, afaic. JP> I = did not mean to remove these requirements, there are quite needed but to als= o look at other requirements related to specific routing security attacked o= f WSN.
JP> What I would suggest is = to re-focus on the routing security issues with the Security expert that wil= l get appointed.
[CJ] OK.

Reference section
###############

The current reference section reads:
11.2.  Informative References

   [I-D.brandt-roll-home-routing-reqs]
            &nb= sp; Brandt, A., "Home Automation Routing Requirement in Low
            &nb= sp; Power and Lossy Networks",
            &nb= sp; draft-brandt-roll-home-routing-reqs-01 (work in progress),
            &nb= sp; May 2008.

JP> Please update to draft-ietf-roll-home-routing-reqs and add the refer= ence to draft-ietf-roll-indus-routing-reqs
[CJ] OK.

   [I-D.culler-rl2n-routing-reqs]
            &nb= sp; Vasseur, J. and D. Cullerot, "Routing Requirements for Low
            &nb= sp; Power And Lossy Networks",
            &nb= sp; draft-culler-rl2n-routing-reqs-01 (work in progress),
            &nb= sp; July 2007.

JP> This one can be removed.
[CJ] OK.


Last comment: please check that you expand acronyms when first used.
[CJ] OK.
JP> Thanks.

Cheers,

JP.

Cheers,
Christian.<= FONT SIZE=3D"1">
*********************************
This message and any attachments (the "message") are confidential= and intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, change= d or falsified.
If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender.
********************************

--B_3303118791_75957491-- --===============0913663904== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0913663904==-- From roll-bounces@ietf.org Mon Sep 1 21:44:06 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95B53A68DF; Mon, 1 Sep 2008 21:44:06 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DF0D3A68DF for ; Mon, 1 Sep 2008 21:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3316Dr-KwbkQ for ; Mon, 1 Sep 2008 21:44:04 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by core3.amsl.com (Postfix) with ESMTP id AFB9A3A67E3 for ; Mon, 1 Sep 2008 21:44:03 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so1173176tib.25 for ; Mon, 01 Sep 2008 21:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=K1EyIQvgll9TQs0npeczI9z2YhqnuX/B7WykH3i0Kyk=; b=j25fI8kF4ZAaI9FLkKDkZ/Yy0w7zi+uxjJs1tbHZJAAeSglN6qYkbXGdFUOYRtJYmO AJ2GobgwkUO0Qa3zCuCrnrnV3WT7psL3JbUfnpBc9J2m+1QYxSa9pHKj6skzUyfYAWTn pmN+ku+yOluYkCx+3pc/VLVSbtcLOGctWte8U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=WdSt5PHGUA9x/o7RbcYFS9KQ0QXM1bsKS+XXD2XdCN7mZkzOpMUtLRGfYhqMlW4Bpg aeceDd/FEYNJ7tXN8Ip63Efn1SPX/M3a4t3sR63yyd8e1Z5nBOUUd2d1rUAjyNnYCxVN q6YkoArz78Sb+ssMnWRl7yu9/2GHSdTxdqzIU= Received: by 10.110.57.6 with SMTP id f6mr8796437tia.38.1220330648918; Mon, 01 Sep 2008 21:44:08 -0700 (PDT) Received: by 10.110.41.3 with HTTP; Mon, 1 Sep 2008 21:44:08 -0700 (PDT) Message-ID: Date: Tue, 2 Sep 2008 13:44:08 +0900 From: "MiJeom Kim" To: "Anthony Schoofs" In-Reply-To: MIME-Version: 1.0 References: Cc: roll@ietf.org Subject: Re: [Roll] Requests for comments on the routing metric documents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0444386311==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0444386311== Content-Type: multipart/related; boundary="----=_Part_4182_13539290.1220330648826" ------=_Part_4182_13539290.1220330648826 Content-Type: multipart/alternative; boundary="----=_Part_4183_8347558.1220330648827" ------=_Part_4183_8347558.1220330648827 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Anthony, First of all, I really appreciate your comments on the metric document. And sorry for this late reply due to my long business trip. For the subject you mentioned, I agree that bi-directionality is an important factor needs to be considered to decide routing metrics. However, I am not sure whether bi-directionality should be one of routing metrics (probably as a link attribute) or directional link needs to be considered when related metrics already specified is used for path calculation. The latter one means, for instance, propagation delay and link reliability should be associated with each directional link (meaning any opposite directional two links connecting two nodes may have different link attributes). In addition, node degree should be defined differently by considering bi-directionality. I would reflect your comments on the revised version. Thank you. Mijeom. On 8/27/08, Anthony Schoofs wrote: > > Hi! > > Another link metric could be the fact that the link is valid on each > direction: A to B and B to A. Indeed, such result would help the routing > protocol for updating routing tables, and then could help decide how a > certain route compares to another. Such non bidirectional links happen with > different TX power, different radio coverage, obstacles.... > > Paper [1] has described the main axioms and assumptions that are taken > when developing protocols and that are often wrong. They are: > > 0: The world is flat. > 1: A radio's transmission area is circular. > 2: All radios have equal range. > 3: If I can hear you, you can hear me (symmetry). > 4: If I can hear you at all, I can hear you perfectly. > 5: Signal strength is a simple function of distance. > > Axioms 1, 2 and especially 3 emphasize on the problem that I mentionned. > With regards to the routing metrics used for Path Calculation, the property > of two nodes in having bi-directional connectivity is important. > > Let's say we don't consider this property. Problems may arise if the final > ROLL routing protocol will for instance: > > 1. update routing tables on routing messages reception (for instance "If B > receives from A, then A is a neighbour of B.". When B wants to send to A, it > will find an entry in the neighbour table whereas this one may not > physically exist. This error will trigger a new RReq. In case you would have > chosen a path with bidirectional link, you avoid the problem. > > 2. use the reverse path for RREP. For instance in DYMO-low, a RREP is sent > on the reverse path. This assumes that the reverse path has valid links to > forward the RREP to the originator. A non-existing link will generate error > messages and possible extra overhead for new route calculations. Risks can > be avoided if the initial RREQ path decision takes into account > bidirectional links. > > Therefore, when a route path is to be calculated, bi-directionality between > nodes may be considered as one of the metric, most probably with a low > weight. > For unidirectional links, this is clearly not a metric issue. > > I had discussions with European project partners, and it seems important to > consider this in real deployments. > > Best regards, > Anthony > > [1] D. Kotz, C. Newport, R. S. Gray, J. Liu, Y. Yuan, and C. Elliott, > "Experimental evaluation of wireless simulation assumptions" , Proceedings > of the ACM/IEEE International Symposium on Modeling, Analysis and Simulation > of Wireless and Mobile Systems (MSWiM), October 2004 > > -- > Anthony Schoofs > Research Scientist > Philips Research, > High Tech Campus 34 , 5656 AE Eindhoven, The Netherlands > Email: anthony.schoofs@philips.com > > [image: Inactive hide details for "MiJeom Kim" ]"MiJeom > Kim" > > > > *"MiJeom Kim" * > > Sent by: > roll-bounces@ietf.org > > 18-07-2008 09:26 > > > > To > > roll@ietf.org > cc > > > Subject > > [Roll] Requests for comments on the routing metric documents > Classification > > > > Hello ROLL members, > > We submitted a new version of I-D as follows. > It would be very appreciated to have some comments from you. > * > The document is there: ** > http://tools.ietf.org/id/draft-mjkim-roll-routing-metrics-00.txt* > > Filename: draft-mjkim-roll-routing-metrics > Revision: 00 > Title: Routing Metrics used for Path Calculation in Low Power and Lossy > Networks > > Authors: Mijeom Kim, JP Vasseur, Hakjin Chong > Creation_date: 2008-07-04 > Number_of_pages: 14 > > Abstract: > This document specifies routing metrics used in path calculation for > Routing Over Low power and Lossy networks (ROLL). Low power and > Lossy Networks (LLNs) have unique characteristics compared with > traditional wired networks or even with similar ones such as mobile > ad-hoc networks as indicated in several application-specific > requirements documents. Since typical IGP routing metrics such as > hop counts or link metrics are not sufficient for LLNs, this document > specifies a new set of required link and node metrics suitable to > LLNs. > > > Thank you, > > > ----------------------------------------------------------------------------- > > Kim, Mijeom, Ph. D, P.E. > Senior Researcher > USN Service Division > Future Technology Laboratory, KT, South Korea > Tel. +82-2-526-6063 > Cell. +82-10-9883-4951 > E-mail: *mjkim@kt.com*, > *mijeom@gmail.com* > > ----------------------------------------------------------------------------- > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > ------=_Part_4183_8347558.1220330648827 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9IkJBQ0tHUk9VTkQ6IHdoaXRlOyBNQVJHSU46IDBjbSAwY20gMHB0OyBXT1JE LUJSRUFLOiBrZWVwLWFsbDsgVEVYVC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1lcmljOyBURVhU LUFMSUdOOiBsZWZ0OyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuIiBhbGlnbj0ibGVmdCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiBB cmlhbDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ILG8uLI7IG1zby1mb250LWtlcm5pbmc6IDBw dCI+PGZvbnQgc2l6ZT0iMiI+SGksIEFudGhvbnksPC9mb250Pjwvc3Bhbj48L3A+Cgo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iQkFDS0dST1VORDogd2hpdGU7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBURVhULUFVVE9TUEFDRTogaWRlb2dyYXBoLW51bWVy aWM7IFRFWFQtQUxJR046IGxlZnQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4iIGFsaWdu PSJsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1G QU1JTFk6IEFyaWFsOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogsby4sjsgbXNvLWZvbnQta2Vy bmluZzogMHB0Ij48Zm9udCBzaXplPSIyIj4mbmJzcDs8L2ZvbnQ+PC9zcGFuPjwvcD4KCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJCQUNLR1JPVU5EOiB3aGl0ZTsgTUFSR0lOOiAwY20gMGNt IDBwdDsgV09SRC1CUkVBSzoga2VlcC1hbGw7IFRFWFQtQVVUT1NQQUNFOiBpZGVvZ3JhcGgtbnVt ZXJpYzsgVEVYVC1BTElHTjogbGVmdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgYWxp Z249ImxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05U LUZBTUlMWTogQXJpYWw7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiCxvLiyOyBtc28tZm9udC1r ZXJuaW5nOiAwcHQiPjxmb250IHNpemU9IjIiPkZpcnN0IG9mIGFsbCwgSSByZWFsbHkgYXBwcmVj aWF0ZSB5b3VyIGNvbW1lbnRzIG9uIHRoZSBtZXRyaWMmbmJzcDtkb2N1bWVudC48L2ZvbnQ+PC9z cGFuPjwvcD4KCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJCQUNLR1JPVU5EOiB3aGl0ZTsg TUFSR0lOOiAwY20gMGNtIDBwdDsgV09SRC1CUkVBSzoga2VlcC1hbGw7IFRFWFQtQVVUT1NQQUNF OiBpZGVvZ3JhcGgtbnVtZXJpYzsgVEVYVC1BTElHTjogbGVmdDsgbXNvLXBhZ2luYXRpb246IHdp ZG93LW9ycGhhbiIgYWxpZ249ImxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1T SVpFOiAxMnB0OyBGT05ULUZBTUlMWTogQXJpYWw7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiCx vLiyOyBtc28tZm9udC1rZXJuaW5nOiAwcHQiPjxmb250IHNpemU9IjIiPkFuZCBzb3JyeSBmb3Ig dGhpcyBsYXRlIHJlcGx5IGR1ZSB0byBteSBsb25nIGJ1c2luZXNzIHRyaXAuPC9mb250Pjwvc3Bh bj48L3A+Cgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iQkFDS0dST1VORDogd2hpdGU7IE1B UkdJTjogMGNtIDBjbSAwcHQ7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBURVhULUFVVE9TUEFDRTog aWRlb2dyYXBoLW51bWVyaWM7IFRFWFQtQUxJR046IGxlZnQ7IG1zby1wYWdpbmF0aW9uOiB3aWRv dy1vcnBoYW4iIGFsaWduPSJsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0la RTogMTJwdDsgRk9OVC1GQU1JTFk6IEFyaWFsOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogsby4 sjsgbXNvLWZvbnQta2VybmluZzogMHB0Ij48Zm9udCBzaXplPSIyIj4mbmJzcDs8L2ZvbnQ+PC9z cGFuPjwvcD4KCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJCQUNLR1JPVU5EOiB3aGl0ZTsg TUFSR0lOOiAwY20gMGNtIDBwdDsgV09SRC1CUkVBSzoga2VlcC1hbGw7IFRFWFQtQVVUT1NQQUNF OiBpZGVvZ3JhcGgtbnVtZXJpYzsgVEVYVC1BTElHTjogbGVmdDsgbXNvLXBhZ2luYXRpb246IHdp ZG93LW9ycGhhbiIgYWxpZ249ImxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1T SVpFOiAxMnB0OyBGT05ULUZBTUlMWTogQXJpYWw7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiCx vLiyOyBtc28tZm9udC1rZXJuaW5nOiAwcHQiPjxmb250IHNpemU9IjIiPkZvciB0aGUgc3ViamVj dCB5b3UgbWVudGlvbmVkLCBJIGFncmVlIHRoYXQgYmktZGlyZWN0aW9uYWxpdHkgaXMgYW4gaW1w b3J0YW50IGZhY3RvciBuZWVkcyB0byBiZSBjb25zaWRlcmVkIHRvIGRlY2lkZSByb3V0aW5nIG1l dHJpY3MuIEhvd2V2ZXIsIEkgYW0gbm90IHN1cmUgd2hldGhlciBiaS1kaXJlY3Rpb25hbGl0eSBz aG91bGQgYmUgb25lIG9mIHJvdXRpbmcgbWV0cmljcyAocHJvYmFibHkgYXMgYSBsaW5rIGF0dHJp YnV0ZSkgb3IgZGlyZWN0aW9uYWwgbGluayBuZWVkcyB0byBiZSBjb25zaWRlcmVkIHdoZW4gcmVs YXRlZCBtZXRyaWNzIGFscmVhZHkgc3BlY2lmaWVkIGlzIHVzZWQgZm9yIHBhdGggY2FsY3VsYXRp b24uIFRoZSBsYXR0ZXIgb25lIG1lYW5zLCBmb3IgaW5zdGFuY2UsIHByb3BhZ2F0aW9uIGRlbGF5 IGFuZCBsaW5rIHJlbGlhYmlsaXR5IHNob3VsZCBiZSBhc3NvY2lhdGVkIHdpdGggZWFjaCBkaXJl Y3Rpb25hbCBsaW5rIChtZWFuaW5nIGFueSBvcHBvc2l0ZSBkaXJlY3Rpb25hbCB0d28gbGlua3Mg Y29ubmVjdGluZyB0d28gbm9kZXMgbWF5IGhhdmUgZGlmZmVyZW50IGxpbmsgYXR0cmlidXRlcyku IEluIGFkZGl0aW9uLCBub2RlIGRlZ3JlZSBzaG91bGQgYmUgZGVmaW5lZCBkaWZmZXJlbnRseSBi eSBjb25zaWRlcmluZyBiaS1kaXJlY3Rpb25hbGl0eS48L2ZvbnQ+PC9zcGFuPjwvcD4KCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJCQUNLR1JPVU5EOiB3aGl0ZTsgTUFSR0lOOiAwY20gMGNt IDBwdDsgV09SRC1CUkVBSzoga2VlcC1hbGw7IFRFWFQtQVVUT1NQQUNFOiBpZGVvZ3JhcGgtbnVt ZXJpYzsgVEVYVC1BTElHTjogbGVmdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgYWxp Z249ImxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05U LUZBTUlMWTogQXJpYWw7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiCxvLiyOyBtc28tZm9udC1r ZXJuaW5nOiAwcHQiPjxmb250IHNpemU9IjIiPiZuYnNwOzwvZm9udD48L3NwYW4+PC9wPgoKPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IkJBQ0tHUk9VTkQ6IHdoaXRlOyBNQVJHSU46IDBjbSAw Y20gMHB0OyBXT1JELUJSRUFLOiBrZWVwLWFsbDsgVEVYVC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1u dW1lcmljOyBURVhULUFMSUdOOiBsZWZ0OyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuIiBh bGlnbj0ibGVmdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZP TlQtRkFNSUxZOiBBcmlhbDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ILG8uLI7IG1zby1mb250 LWtlcm5pbmc6IDBwdCI+PGZvbnQgc2l6ZT0iMiI+SSB3b3VsZCByZWZsZWN0IHlvdXIgY29tbWVu dHMgb24gdGhlIHJldmlzZWQgdmVyc2lvbi4gPC9mb250Pjwvc3Bhbj48L3A+Cgo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iQkFDS0dST1VORDogd2hpdGU7IE1BUkdJTjogMGNtIDBjbSAwcHQ7 IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBURVhULUFVVE9TUEFDRTogaWRlb2dyYXBoLW51bWVyaWM7 IFRFWFQtQUxJR046IGxlZnQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4iIGFsaWduPSJs ZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1J TFk6IEFyaWFsOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogsby4sjsgbXNvLWZvbnQta2Vybmlu ZzogMHB0Ij48Zm9udCBzaXplPSIyIj4mbmJzcDs8L2ZvbnQ+PC9zcGFuPjwvcD4KCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJCQUNLR1JPVU5EOiB3aGl0ZTsgTUFSR0lOOiAwY20gMGNtIDBw dDsgV09SRC1CUkVBSzoga2VlcC1hbGw7IFRFWFQtQVVUT1NQQUNFOiBpZGVvZ3JhcGgtbnVtZXJp YzsgVEVYVC1BTElHTjogbGVmdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgYWxpZ249 ImxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZB TUlMWTogQXJpYWw7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiCxvLiyOyBtc28tZm9udC1rZXJu aW5nOiAwcHQiPjxmb250IHNpemU9IjIiPlRoYW5rIHlvdS48L2ZvbnQ+PC9zcGFuPjwvcD4KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiBBcmlh bDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ILG8uLI7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1V UzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjxm b250IHNpemU9IjIiPk1pamVvbS48L2ZvbnQ+PC9zcGFuPjwvZGl2Pgo8ZGl2Pjxicj48YnI+Jm5i c3A7PC9kaXY+CjxkaXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiA4LzI3LzA4LCA8YiBj bGFzcz0iZ21haWxfc2VuZGVybmFtZSI+QW50aG9ueSBTY2hvb2ZzPC9iPiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmFudGhvbnkuc2Nob29mc0BwaGlsaXBzLmNvbSI+YW50aG9ueS5zY2hvb2ZzQHBoaWxp cHMuY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsg Qk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj4KPGRpdj4KPHA+SGkhPGJyPjxicj5Bbm90aGVy IGxpbmsgbWV0cmljIGNvdWxkIGJlIHRoZSBmYWN0IHRoYXQgdGhlIGxpbmsgaXMgdmFsaWQgb24g ZWFjaCBkaXJlY3Rpb246IEEgdG8gQiBhbmQgQiB0byBBLiBJbmRlZWQsIHN1Y2ggcmVzdWx0IHdv dWxkIGhlbHAgdGhlIHJvdXRpbmcgcHJvdG9jb2wgZm9yIHVwZGF0aW5nIHJvdXRpbmcgdGFibGVz LCBhbmQgdGhlbiBjb3VsZCBoZWxwIGRlY2lkZSBob3cgYSBjZXJ0YWluIHJvdXRlIGNvbXBhcmVz IHRvIGFub3RoZXIuIFN1Y2ggbm9uIGJpZGlyZWN0aW9uYWwgbGlua3MgaGFwcGVuIHdpdGggZGlm ZmVyZW50IFRYIHBvd2VyLCBkaWZmZXJlbnQgcmFkaW8gY292ZXJhZ2UsIG9ic3RhY2xlcy4uLi48 YnI+Cjxicj5QYXBlciBbMV08Zm9udCBzaXplPSIyIj4gPC9mb250PmhhcyBkZXNjcmliZWQgdGhl IG1haW4gYXhpb21zIGFuZCBhc3N1bXB0aW9ucyB0aGF0IGFyZSB0YWtlbiB3aGVuIGRldmVsb3Bp bmcgcHJvdG9jb2xzIGFuZCB0aGF0IGFyZSBvZnRlbiB3cm9uZy4gVGhleSBhcmU6PGJyPjxicj4w OiBUaGUgd29ybGQgaXMgZmxhdC48YnI+MTogQSByYWRpbydzIHRyYW5zbWlzc2lvbiBhcmVhIGlz IGNpcmN1bGFyLjxicj4KMjogQWxsIHJhZGlvcyBoYXZlIGVxdWFsIHJhbmdlLjxicj4zOiBJZiBJ IGNhbiBoZWFyIHlvdSwgeW91IGNhbiBoZWFyIG1lIChzeW1tZXRyeSkuPGJyPjQ6IElmIEkgY2Fu IGhlYXIgeW91IGF0IGFsbCwgSSBjYW4gaGVhciB5b3UgcGVyZmVjdGx5Ljxicj41OiBTaWduYWwg c3RyZW5ndGggaXMgYSBzaW1wbGUgZnVuY3Rpb24gb2YgZGlzdGFuY2UuPGJyPjxicj5BeGlvbXMg MSwgMiBhbmQgZXNwZWNpYWxseSAzIGVtcGhhc2l6ZSBvbiB0aGUgcHJvYmxlbSB0aGF0IEkgbWVu dGlvbm5lZC48YnI+CldpdGggcmVnYXJkcyB0byB0aGUgcm91dGluZyBtZXRyaWNzIHVzZWQgZm9y IFBhdGggQ2FsY3VsYXRpb24sIHRoZSBwcm9wZXJ0eSBvZiB0d28gbm9kZXMgaW4gaGF2aW5nIGJp LWRpcmVjdGlvbmFsIGNvbm5lY3Rpdml0eSBpcyBpbXBvcnRhbnQuIDxicj48YnI+TGV0JiMzOTtz IHNheSB3ZSBkb24mIzM5O3QgY29uc2lkZXIgdGhpcyBwcm9wZXJ0eS4gUHJvYmxlbXMgbWF5IGFy aXNlIGlmIHRoZSBmaW5hbCBST0xMIHJvdXRpbmcgcHJvdG9jb2wgd2lsbCBmb3IgaW5zdGFuY2U6 PGJyPgo8YnI+MS4gdXBkYXRlIHJvdXRpbmcgdGFibGVzIG9uIHJvdXRpbmcgbWVzc2FnZXMgcmVj ZXB0aW9uIChmb3IgaW5zdGFuY2UgJnF1b3Q7SWYgQiByZWNlaXZlcyBmcm9tIEEsIHRoZW4gQSBp cyBhIG5laWdoYm91ciBvZiBCLiZxdW90Oy4gV2hlbiBCIHdhbnRzIHRvIHNlbmQgdG8gQSwgaXQg d2lsbCBmaW5kIGFuIGVudHJ5IGluIHRoZSBuZWlnaGJvdXIgdGFibGUgd2hlcmVhcyB0aGlzIG9u ZSBtYXkgbm90IHBoeXNpY2FsbHkgZXhpc3QuIFRoaXMgZXJyb3Igd2lsbCB0cmlnZ2VyIGEgbmV3 IFJSZXEuIEluIGNhc2UgeW91IHdvdWxkIGhhdmUgY2hvc2VuIGEgcGF0aCB3aXRoIGJpZGlyZWN0 aW9uYWwgbGluaywgeW91IGF2b2lkIHRoZSBwcm9ibGVtLjxicj4KPGJyPjIuIHVzZSB0aGUgcmV2 ZXJzZSBwYXRoIGZvciBSUkVQLiBGb3IgaW5zdGFuY2UgaW4gRFlNTy1sb3csIGEgUlJFUCBpcyBz ZW50IG9uIHRoZSByZXZlcnNlIHBhdGguIFRoaXMgYXNzdW1lcyB0aGF0IHRoZSByZXZlcnNlIHBh dGggaGFzIHZhbGlkIGxpbmtzIHRvIGZvcndhcmQgdGhlIFJSRVAgdG8gdGhlIG9yaWdpbmF0b3Iu IEEgbm9uLWV4aXN0aW5nIGxpbmsgd2lsbCBnZW5lcmF0ZSBlcnJvciBtZXNzYWdlcyBhbmQgcG9z c2libGUgZXh0cmEgb3ZlcmhlYWQgZm9yIG5ldyByb3V0ZSBjYWxjdWxhdGlvbnMuIFJpc2tzIGNh biBiZSBhdm9pZGVkIGlmIHRoZSBpbml0aWFsIFJSRVEgcGF0aCBkZWNpc2lvbiB0YWtlcyBpbnRv IGFjY291bnQgYmlkaXJlY3Rpb25hbCBsaW5rcy48YnI+Cjxicj5UaGVyZWZvcmUsIHdoZW4gYSBy b3V0ZSBwYXRoIGlzIHRvIGJlIGNhbGN1bGF0ZWQsIGJpLWRpcmVjdGlvbmFsaXR5IGJldHdlZW4g bm9kZXMgbWF5IGJlIGNvbnNpZGVyZWQgYXMgb25lIG9mIHRoZSBtZXRyaWMsIG1vc3QgcHJvYmFi bHkgd2l0aCBhIGxvdyB3ZWlnaHQuPGJyPkZvciB1bmlkaXJlY3Rpb25hbCBsaW5rcywgdGhpcyBp cyBjbGVhcmx5IG5vdCBhIG1ldHJpYyBpc3N1ZS48YnI+Cjxicj5JIGhhZCBkaXNjdXNzaW9ucyB3 aXRoIEV1cm9wZWFuIHByb2plY3QgcGFydG5lcnMsIGFuZCBpdCBzZWVtcyBpbXBvcnRhbnQgdG8g Y29uc2lkZXIgdGhpcyBpbiByZWFsIGRlcGxveW1lbnRzLiA8YnI+PGJyPkJlc3QgcmVnYXJkcyw8 YnI+QW50aG9ueTxicj48YnI+PGZvbnQgc2l6ZT0iMiI+WzFdIEQuIEtvdHosIEMuIE5ld3BvcnQs IFIuIFMuIEdyYXksIEouIExpdSwgWS4gWXVhbiwgYW5kIEMuIEVsbGlvdHQsICZxdW90O0V4cGVy aW1lbnRhbCBldmFsdWF0aW9uIG9mIHdpcmVsZXNzIHNpbXVsYXRpb24gYXNzdW1wdGlvbnMmcXVv dDsgLCBQcm9jZWVkaW5ncyBvZiB0aGUgQUNNL0lFRUUgSW50ZXJuYXRpb25hbCBTeW1wb3NpdW0g b24gTW9kZWxpbmcsIEFuYWx5c2lzIGFuZCBTaW11bGF0aW9uIG9mIFdpcmVsZXNzIGFuZCBNb2Jp bGUgU3lzdGVtcyAoTVNXaU0pLCBPY3RvYmVyIDIwMDQ8L2ZvbnQ+PGJyPgo8YnI+LS08YnI+QW50 aG9ueSBTY2hvb2ZzPGJyPlJlc2VhcmNoIFNjaWVudGlzdDxicj5QaGlsaXBzIFJlc2VhcmNoLDxi cj5IaWdoIFRlY2ggQ2FtcHVzIDM0ICwgNTY1NiBBRSBFaW5kaG92ZW4sIFRoZSBOZXRoZXJsYW5k czxicj5FbWFpbDogPGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3cs ZXZlbnQsdGhpcykiIGhyZWY9Im1haWx0bzphbnRob255LnNjaG9vZnNAcGhpbGlwcy5jb20iIHRh cmdldD0iX2JsYW5rIj5hbnRob255LnNjaG9vZnNAcGhpbGlwcy5jb208L2E+PGJyPgo8YnI+PGlt ZyBoZWlnaHQ9IjE2IiBhbHQ9IkluYWN0aXZlIGhpZGUgZGV0YWlscyBmb3IgJnF1b3Q7TWlKZW9t IEtpbSZxdW90OyAmbHQ7bWlqZW9tQGdtYWlsLmNvbSZndDsiIHNyYz0iY2lkOjEwX189NEVCQkZF MjFERkRGQjJBMDhmOWU4YTkzZGY5M0BwaGlsaXBzLmNvbSIgd2lkdGg9IjE2Ij4mcXVvdDtNaUpl b20gS2ltJnF1b3Q7ICZsdDs8YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdp bmRvdyxldmVudCx0aGlzKSIgaHJlZj0ibWFpbHRvOm1pamVvbUBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5taWplb21AZ21haWwuY29tPC9hPiZndDs8YnI+Cjxicj48YnI+Cjx0YWJsZSBjZWxs c3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBib3JkZXI9IjAiPgo8dGJv ZHk+Cjx0ciB2YWxpZ249InRvcCI+Cjx0ZCB3aWR0aD0iMzQlIj4KPHVsPjxiPjxmb250IHNpemU9 IjIiPiZxdW90O01pSmVvbSBLaW0mcXVvdDsgJmx0OzxhIG9uY2xpY2s9InJldHVybiB0b3AuanMu T3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86bWlqZW9tQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1pamVvbUBnbWFpbC5jb208L2E+Jmd0OzwvZm9udD48L2I+ PGZvbnQgc2l6ZT0iMiI+IDwvZm9udD4KPHA+PGZvbnQgc2l6ZT0iMiI+U2VudCBieTo8L2ZvbnQ+ PGJyPjxmb250IHNpemU9IjIiPjxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmso d2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+cm9sbC1ib3VuY2VzQGlldGYub3JnPC9hPjwvZm9udD4gCjxwPjxmb250 IHNpemU9IjIiPjE4LTA3LTIwMDggMDk6MjY8L2ZvbnQ+PC9wPgo8cD48L3A+PC9wPjwvdWw+PC90 ZD4KPHRkIHdpZHRoPSI2NiUiPgo8dGFibGUgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIw IiB3aWR0aD0iMTAwJSIgYm9yZGVyPSIwIj4KPHRib2R5Pgo8dHIgdmFsaWduPSJ0b3AiPgo8dGQg d2lkdGg9IjElIj48aW1nIGhlaWdodD0iMSIgYWx0PSIiIHNyYz0iY2lkOjMwX189NEVCQkZFMjFE RkRGQjJBMDhmOWU4YTkzZGY5M0BwaGlsaXBzLmNvbSIgd2lkdGg9Ijk4IiBib3JkZXI9IjAiPjxi cj4KPGRpdiBhbGlnbj0icmlnaHQiPjxmb250IHNpemU9IjIiPlRvPC9mb250PjwvZGl2PjwvdGQ+ Cjx0ZCB3aWR0aD0iMTAwJSI+PGltZyBoZWlnaHQ9IjEiIGFsdD0iIiBzcmM9ImNpZDozMF9fPTRF QkJGRTIxREZERkIyQTA4ZjllOGE5M2RmOTNAcGhpbGlwcy5jb20iIHdpZHRoPSIxIiBib3JkZXI9 IjAiPjxicj48Zm9udCBzaXplPSIyIj48YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRM aW5rKHdpbmRvdyxldmVudCx0aGlzKSIgaHJlZj0ibWFpbHRvOnJvbGxAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5yb2xsQGlldGYub3JnPC9hPjwvZm9udD48L3RkPgo8L3RyPgo8dHIgdmFsaWdu PSJ0b3AiPgo8dGQgd2lkdGg9IjElIj48aW1nIGhlaWdodD0iMSIgYWx0PSIiIHNyYz0iY2lkOjMw X189NEVCQkZFMjFERkRGQjJBMDhmOWU4YTkzZGY5M0BwaGlsaXBzLmNvbSIgd2lkdGg9Ijk4IiBi b3JkZXI9IjAiPjxicj4KPGRpdiBhbGlnbj0icmlnaHQiPjxmb250IHNpemU9IjIiPmNjPC9mb250 PjwvZGl2PjwvdGQ+Cjx0ZCB3aWR0aD0iMTAwJSI+PGltZyBoZWlnaHQ9IjEiIGFsdD0iIiBzcmM9 ImNpZDozMF9fPTRFQkJGRTIxREZERkIyQTA4ZjllOGE5M2RmOTNAcGhpbGlwcy5jb20iIHdpZHRo PSIxIiBib3JkZXI9IjAiPjxicj48L3RkPjwvdHI+Cjx0ciB2YWxpZ249InRvcCI+Cjx0ZCB3aWR0 aD0iMSUiPjxpbWcgaGVpZ2h0PSIxIiBhbHQ9IiIgc3JjPSJjaWQ6MzBfXz00RUJCRkUyMURGREZC MkEwOGY5ZThhOTNkZjkzQHBoaWxpcHMuY29tIiB3aWR0aD0iOTgiIGJvcmRlcj0iMCI+PGJyPgo8 ZGl2IGFsaWduPSJyaWdodCI+PGZvbnQgc2l6ZT0iMiI+U3ViamVjdDwvZm9udD48L2Rpdj48L3Rk Pgo8dGQgd2lkdGg9IjEwMCUiPjxpbWcgaGVpZ2h0PSIxIiBhbHQ9IiIgc3JjPSJjaWQ6MzBfXz00 RUJCRkUyMURGREZCMkEwOGY5ZThhOTNkZjkzQHBoaWxpcHMuY29tIiB3aWR0aD0iMSIgYm9yZGVy PSIwIj48YnI+PGZvbnQgc2l6ZT0iMiI+W1JvbGxdIFJlcXVlc3RzIGZvciBjb21tZW50cyBvbiB0 aGUgcm91dGluZyBtZXRyaWMgZG9jdW1lbnRzPC9mb250PjwvdGQ+PC90cj4KPHRyIHZhbGlnbj0i dG9wIj4KPHRkIHZhbGlnbj0iY2VudGVyIiB3aWR0aD0iMSUiPjxpbWcgaGVpZ2h0PSIxIiBhbHQ9 IiIgc3JjPSJjaWQ6MzBfXz00RUJCRkUyMURGREZCMkEwOGY5ZThhOTNkZjkzQHBoaWxpcHMuY29t IiB3aWR0aD0iOTgiIGJvcmRlcj0iMCI+PGJyPgo8ZGl2IGFsaWduPSJyaWdodCI+PGZvbnQgc2l6 ZT0iMiI+Q2xhc3NpZmljYXRpb248L2ZvbnQ+PC9kaXY+PC90ZD4KPHRkIHZhbGlnbj0iY2VudGVy IiB3aWR0aD0iMTAwJSI+PGltZyBoZWlnaHQ9IjEiIGFsdD0iIiBzcmM9ImNpZDozMF9fPTRFQkJG RTIxREZERkIyQTA4ZjllOGE5M2RmOTNAcGhpbGlwcy5jb20iIHdpZHRoPSIxIiBib3JkZXI9IjAi Pjxicj48L3RkPjwvdHI+PC90Ym9keT48L3RhYmxlPgo8dGFibGUgY2VsbHNwYWNpbmc9IjAiIGNl bGxwYWRkaW5nPSIwIiBib3JkZXI9IjAiPgo8dGJvZHk+Cjx0ciB2YWxpZ249InRvcCI+Cjx0ZCB3 aWR0aD0iNTgiPjxpbWcgaGVpZ2h0PSIxIiBhbHQ9IiIgc3JjPSJjaWQ6MzBfXz00RUJCRkUyMURG REZCMkEwOGY5ZThhOTNkZjkzQHBoaWxpcHMuY29tIiB3aWR0aD0iMSIgYm9yZGVyPSIwIj48L3Rk Pgo8dGQgd2lkdGg9IjMzNiI+PGltZyBoZWlnaHQ9IjEiIGFsdD0iIiBzcmM9ImNpZDozMF9fPTRF QkJGRTIxREZERkIyQTA4ZjllOGE5M2RmOTNAcGhpbGlwcy5jb20iIHdpZHRoPSIxIiBib3JkZXI9 IjAiPjwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT4K PGRpdj48c3BhbiBjbGFzcz0iZSIgaWQ9InFfMTFjMDQ3MjMyYTQyYTg0Ml8xIj48YnI+PGJyPkhl bGxvIFJPTEwgbWVtYmVycyw8YnI+PGJyPldlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIEkt RCBhcyBmb2xsb3dzLjxicj5JdCB3b3VsZCBiZSB2ZXJ5IGFwcHJlY2lhdGVkIHRvIGhhdmUgc29t ZSBjb21tZW50cyBmcm9tIHlvdS4gPGJyPjxiPjxicj5UaGUgZG9jdW1lbnQgaXMgdGhlcmU6IDwv Yj48YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlz KSIgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LW1qa2ltLXJvbGwtcm91dGlu Zy1tZXRyaWNzLTAwLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPjxiPjx1Pjxmb250IGNvbG9yPSIjMDAw MGZmIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtbWpraW0tcm9sbC1yb3V0aW5nLW1l dHJpY3MtMDAudHh0PC9mb250PjwvdT48L2I+PC9hPjxmb250IHNpemU9IjQiPjxicj4KPC9mb250 Pjxicj5GaWxlbmFtZTogZHJhZnQtbWpraW0tcm9sbC1yb3V0aW5nLW1ldHJpY3M8YnI+UmV2aXNp b246IDAwPGJyPlRpdGxlOiBSb3V0aW5nIE1ldHJpY3MgdXNlZCBmb3IgUGF0aCBDYWxjdWxhdGlv biBpbiBMb3cgUG93ZXIgYW5kIExvc3N5IE5ldHdvcmtzPGJyPjxicj5BdXRob3JzOiBNaWplb20g S2ltLCBKUCBWYXNzZXVyLCBIYWtqaW4gQ2hvbmc8YnI+Q3JlYXRpb25fZGF0ZTogMjAwOC0wNy0w NDxicj4KTnVtYmVyX29mX3BhZ2VzOiAxNDxicj48YnI+QWJzdHJhY3Q6PGJyPlRoaXMgZG9jdW1l bnQgc3BlY2lmaWVzIHJvdXRpbmcgbWV0cmljcyB1c2VkIGluIHBhdGggY2FsY3VsYXRpb24gZm9y PGJyPlJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzIChST0xMKS4gTG93 IHBvd2VyIGFuZDxicj5Mb3NzeSBOZXR3b3JrcyAoTExOcykgaGF2ZSB1bmlxdWUgY2hhcmFjdGVy aXN0aWNzIGNvbXBhcmVkIHdpdGg8YnI+CnRyYWRpdGlvbmFsIHdpcmVkIG5ldHdvcmtzIG9yIGV2 ZW4gd2l0aCBzaW1pbGFyIG9uZXMgc3VjaCBhcyBtb2JpbGU8YnI+YWQtaG9jIG5ldHdvcmtzIGFz IGluZGljYXRlZCBpbiBzZXZlcmFsIGFwcGxpY2F0aW9uLXNwZWNpZmljPGJyPnJlcXVpcmVtZW50 cyBkb2N1bWVudHMuIFNpbmNlIHR5cGljYWwgSUdQIHJvdXRpbmcgbWV0cmljcyBzdWNoIGFzPGJy PmhvcCBjb3VudHMgb3IgbGluayBtZXRyaWNzIGFyZSBub3Qgc3VmZmljaWVudCBmb3IgTExOcywg dGhpcyBkb2N1bWVudDxicj4Kc3BlY2lmaWVzIGEgbmV3IHNldCBvZiByZXF1aXJlZCBsaW5rIGFu ZCBub2RlIG1ldHJpY3Mgc3VpdGFibGUgdG88YnI+TExOcy48YnI+PGJyPjxicj5UaGFuayB5b3Us PGJyPjxicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj48YnI+S2ltLCBNaWplb20sIFBoLiBELCBQ LkUuPGJyPlNlbmlvciBSZXNlYXJjaGVyPGJyPgpVU04gU2VydmljZSBEaXZpc2lvbjxicj5GdXR1 cmUgVGVjaG5vbG9neSBMYWJvcmF0b3J5LCBLVCwgU291dGggS29yZWEgPGJyPlRlbC4gKzgyLTIt NTI2LTYwNjM8YnI+Q2VsbC4gKzgyLTEwLTk4ODMtNDk1MTxicj5FLW1haWw6IDxhIG9uY2xpY2s9 InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJodHRw Oi8vb2FzeXMua3QuY28ua3IvZW9mZmljZS9PV0EvRW1haWwvbWpraW1Aa3QuY29tIiB0YXJnZXQ9 Il9ibGFuayI+PHU+PGZvbnQgY29sb3I9IiMwMDAwZmYiPm1qa2ltQGt0LmNvbTwvZm9udD48L3U+ PC9hPiwgPGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQs dGhpcykiIGhyZWY9Imh0dHA6Ly9vYXN5cy5rdC5jby5rci9lb2ZmaWNlL09XQS9FbWFpbC9taWpl b21AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHU+PGZvbnQgY29sb3I9IiMwMDAwZmYiPm1p amVvbUBnbWFpbC5jb208L2ZvbnQ+PC91PjwvYT48YnI+Cjwvc3Bhbj48L2Rpdj4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTx0dD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj5Sb2xsIG1haWxpbmcgbGlzdDxicj48YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9w ZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSIgaHJlZj0ibWFpbHRvOlJvbGxAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5Sb2xsQGlldGYub3JnPC9hPjxicj4KPC90dD48dHQ+PGEgb25jbGlj az0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbDwvYT48L3R0Pjx0dD48 YnI+PC90dD48YnI+CjxwPjwvcD48L3A+PC9kaXY+PGJyIGNsZWFyPSJhbGwiPjwvYmxvY2txdW90 ZT48L2Rpdj48YnI+Cg== ------=_Part_4183_8347558.1220330648827-- ------=_Part_4182_13539290.1220330648826 Content-Type: image/gif; name=ecblank.gif Content-Transfer-Encoding: base64 Content-ID: <30__=4EBBFE21DFDFB2A08f9e8a93df93@philips.com> X-Attachment-Id: 0.3 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_Part_4182_13539290.1220330648826 Content-Type: image/gif; name=graycol.gif Content-Transfer-Encoding: base64 Content-ID: <10__=4EBBFE21DFDFB2A08f9e8a93df93@philips.com> X-Attachment-Id: 0.1 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------=_Part_4182_13539290.1220330648826-- --===============0444386311== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0444386311==-- From roll-bounces@ietf.org Tue Sep 2 13:47:29 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF5F13A6918; Tue, 2 Sep 2008 13:47:29 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 317233A6918 for ; Tue, 2 Sep 2008 13:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mM03CF9dRBzm for ; Tue, 2 Sep 2008 13:47:27 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 59A0D3A6857 for ; Tue, 2 Sep 2008 13:47:27 -0700 (PDT) Received: from dnab4233e3.stanford.edu ([171.66.51.227]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Kacmj-0005Rc-Lv; Tue, 02 Sep 2008 13:47:33 -0700 Message-Id: From: Philip Levis To: "Drake, John E" In-Reply-To: <51661468CBD1354294533DA79E85955A0109FD7B@XCH-SW-5V2.sw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 2 Sep 2008 13:47:33 -0700 References: <51661468CBD1354294533DA79E85955A01053026@XCH-SW-5V2.sw.nos.boeing.com> <51661468CBD1354294533DA79E85955A0109FD7B@XCH-SW-5V2.sw.nos.boeing.com> X-Mailer: Apple Mail (2.926) X-Scan-Signature: 078eb853d78558c6c655f7b6c94b391a Cc: roll@ietf.org Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Aug 27, 2008, at 7:45 AM, Drake, John E wrote: > JP, > > I thought that was exactly Adrian's point. > > If you evaluate a bunch of routing protocols as they exist today in a > new operational environment and conclude that none of them are > appropriate, then you have no choice but to conclude that you need to > invent at least one, but probably many, new routing protocols. It's > not > like this hasn't been done before. > > I took Adrian's note to say that doing this is not sufficient and that > what needed to be done was to characterize the new operational > environment, propose changes needed in each routing protocol to > address > the new operational environment, and then evaluate these changes. Sorry for taking so long to reply; I spent the past week off the grid and so was not in email contact. This seems to be an argument about the scope of the document. Currently, the draft simply examines *existing* protocols to determine if any of them meet the requirements of ROLL. If the answer to this question is "yes," then ROLL does not need to consider how to come up with a protocol that meets its needs. If the answer to this question is "no," then ROLL needs to discuss how best to proceed. Doing so could be either extending existing protocols or defining new ones; the draft takes no position on this. In other words, proposing changes to existing protocols should be in a subsequent draft, not this one. We first need to agree -- in writing -- whether any proposals of any kind are needed at all. Should I read this discussion as consensus on the conclusion so far? Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Sep 2 21:44:07 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AB753A688E; Tue, 2 Sep 2008 21:44:07 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 489FF3A6812 for ; Tue, 2 Sep 2008 21:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.052 X-Spam-Level: X-Spam-Status: No, score=-6.052 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qi6Jh6rC0xrO for ; Tue, 2 Sep 2008 21:44:05 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E85DF3A688E for ; Tue, 2 Sep 2008 21:44:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,320,1217808000"; d="scan'208";a="19461590" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 03 Sep 2008 04:44:11 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m834iB5V009472; Wed, 3 Sep 2008 00:44:11 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m834iB2n010218; Wed, 3 Sep 2008 04:44:11 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Sep 2008 00:44:10 -0400 Received: from 10.61.97.15 ([10.61.97.15]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 3 Sep 2008 04:43:38 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 03 Sep 2008 06:43:37 +0200 From: JP Vasseur To: Philip Levis Message-ID: Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 Thread-Index: AckNf6EBuCCfK6I5iUmbrMIaT2q5ZQ== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 03 Sep 2008 04:44:10.0973 (UTC) FILETIME=[B54140D0:01C90D7F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2863; t=1220417051; x=1221281051; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20draft-ietf-roll-protocols-surv ey-00 |Sender:=20 |To:=20Philip=20Levis=20; bh=hzHWx1nRBrpk/YFgbnHlcykU6QNk4Xx35cpslSSAizM=; b=goTM9jyEM9rn76V95msgHnP+2EuX8IqKvbgTQUV9gd1hyqoU2LRNwVD25Y AJdZD6On2KfGuMh2RwL01RBilnSi8ZQGfTHzxMIKy8PVI0hJLNYChAf5/dxL /MVlGEjI9o; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: roll@ietf.org, "Drake, John E" Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Phil, On 9/2/08 10:47 PM, "Philip Levis" wrote: > > On Aug 27, 2008, at 7:45 AM, Drake, John E wrote: > >> JP, >> >> I thought that was exactly Adrian's point. >> >> If you evaluate a bunch of routing protocols as they exist today in a >> new operational environment and conclude that none of them are >> appropriate, then you have no choice but to conclude that you need to >> invent at least one, but probably many, new routing protocols. It's >> not >> like this hasn't been done before. >> >> I took Adrian's note to say that doing this is not sufficient and that >> what needed to be done was to characterize the new operational >> environment, propose changes needed in each routing protocol to >> address >> the new operational environment, and then evaluate these changes. > > Sorry for taking so long to reply; I spent the past week off the grid > and so was not in email contact. > > This seems to be an argument about the scope of the document. > Currently, the draft simply examines *existing* protocols to determine > if any of them meet the requirements of ROLL. If the answer to this > question is "yes," then ROLL does not need to consider how to come up > with a protocol that meets its needs. If the answer to this question > is "no," then ROLL needs to discuss how best to proceed. Doing so > could be either extending existing protocols or defining new ones; the > draft takes no position on this. > > In other words, proposing changes to existing protocols should be in a > subsequent draft, not this one. We first need to agree -- in writing > -- whether any proposals of any kind are needed at all. Should I read > this discussion as consensus on the conclusion so far? Not yet ;-) This is why we'll have an interim meeting (for a face to face meeting) + Discussion on the mailing list, at which point we should draw a consensus to move forward. We have to remember that non-IP solution continue to make progress and we do now to move fast considering the demand for IP-based solutions. Routing is of course a key component of the overall architecture. So I would like to be able to converge (should all the requirements document be last called soon) on whether we can find a routing protocol that meet the requirement *and* whether we can extend an existing routing protocol to meet these requirements without having to "twist" its design. If the answer is no, we'll need to re-charter and quickly work on a solution. Could you look at Adrian's comment on the document ? I'll do a WG chair review this week, it would be nice to have a new revision before the interim meeting. Thanks. JP. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Sep 4 02:37:16 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB123A6B8B; Thu, 4 Sep 2008 02:37:16 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC6183A6B89 for ; Thu, 4 Sep 2008 02:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.068 X-Spam-Level: X-Spam-Status: No, score=-0.068 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85cMhKcbfc6B for ; Thu, 4 Sep 2008 02:37:14 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 897983A68DA for ; Thu, 4 Sep 2008 02:37:14 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m849aZY2023691; Thu, 4 Sep 2008 10:36:37 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m849aVUK023592; Thu, 4 Sep 2008 10:36:33 +0100 Message-ID: <01a401c90e71$b6d9cc30$0200a8c0@your029b8cecfe> From: "Adrian Farrel" To: "Philip Levis" , "Drake, John E" References: <51661468CBD1354294533DA79E85955A01053026@XCH-SW-5V2.sw.nos.boeing.com> <51661468CBD1354294533DA79E85955A0109FD7B@XCH-SW-5V2.sw.nos.boeing.com> Date: Thu, 4 Sep 2008 10:36:27 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: roll@ietf.org Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Phil, [SNIP] > Currently, the draft simply examines *existing* protocols to determine if > any of them meet the requirements of ROLL. If the answer to this question > is "yes," then ROLL does not need to consider how to come up with a > protocol that meets its needs. If the answer to this question is "no," > then ROLL needs to discuss how best to proceed. Doing so could be either > extending existing protocols or defining new ones; the draft takes no > position on this. I think that is fine, but I read the infamous table in your I-D as saying that some (many? most?) of the protocols could not be extended (i.e. "fail" rather than "?"). The problem with the whole thing is that it is almost always possible to bodge a protocol to do anything you want :-) Maybe it would be better to analyse into five categories: - base protocol does what we want - base protocol with existing extensions does what we want - base protocol could be extended with minor extensions to do what we want - base protocol would need major extensions to do what we want - protocol cannot be made to do what we want > In other words, proposing changes to existing protocols should be in a > subsequent draft, not this one. We first need to agree -- in writing -- > whether any proposals of any kind are needed at all. Should I read this > discussion as consensus on the conclusion so far? Cheers, Adrian _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Sep 4 04:44:12 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 955113A6D83; Thu, 4 Sep 2008 04:44:11 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 277153A6D92 for ; Thu, 4 Sep 2008 04:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lj6x4qyzTLW3 for ; Thu, 4 Sep 2008 04:44:08 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id 4A2323A67D0 for ; Thu, 4 Sep 2008 04:44:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,320,1217800800"; d="scan'208";a="16808005" Received: from sphinx.lix.polytechnique.fr (HELO BoolfightMaN-Laptop.local) ([129.104.11.1]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Sep 2008 13:44:10 +0200 Message-ID: <48BFCA07.5050609@inria.fr> Date: Thu, 04 Sep 2008 13:44:07 +0200 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: roll@ietf.org References: <48B596DB.5020808@inria.fr> In-Reply-To: <48B596DB.5020808@inria.fr> Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, I'd still like the authors to answer my comments on the "fail/pass" table at the end of section 4, which is not fully justified in the document. As a reminder, here are a couple of "fail/pass" statements present in this table, which were pointed out as being doubtful: - OLSR is said to "fail" the "loss response" criteria. However in the quick justification in section 4, nothing is said about link hysteresis strategy (see OLSR RFC 3626 section 14.3.) which arguably makes OLSR "pass" this criteria. - OLSR is said to "fail" the "control cost" criteria. However, simple fisheye TTL strategy on OLSR control messages makes OLSR "pass" this criteria. See this paper "Fish Eye OLSR Scaling Properties" in Journal of Communication and Networks, 2004. Actually this paper even proves that OLSR can thus reach the Gupta and Kumar bounds in terms of control overhead scalability. I am sure that other people would have additional question marks with this table. But for starters, the items above should be discussed. regards, Emmanuel _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Sep 4 08:55:38 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D58433A6C36; Thu, 4 Sep 2008 08:55:38 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256B23A6BFD for ; Thu, 4 Sep 2008 08:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lc8gStZ-nZ3y for ; Thu, 4 Sep 2008 08:55:36 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 633A63A6C36 for ; Thu, 4 Sep 2008 08:55:36 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Sep 2008 17:55:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Sep 2008 17:55:36 +0200 Message-ID: <8AA97249241F7148BE6D3D8B93D83F5A12F9E8BA@ftrdmel2> In-Reply-To: <48BFCA07.5050609@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 Thread-Index: AckOg5Ohkbjbxd3sRmC4DONn+2ZlxAAIml6Q References: <48B596DB.5020808@inria.fr> <48BFCA07.5050609@inria.fr> From: To: , X-OriginalArrivalTime: 04 Sep 2008 15:55:37.0867 (UTC) FILETIME=[AC872DB0:01C90EA6] Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hello, May I bring my point of view. Theoretically link hysteresis solution solves the issue of bad links. In pr= actice, link hysteresis is not very efficient for at least 2 reasons. The l= ink hysteresis solution is based on the reception of hello packets which ar= e generally sent at lower throughput than data packets because hello packet= s are sent in broadcast. So hello packets have more chance to be received t= han data packets (see "grey zone" issue), all the more so OLSR tends to min= imize the number of hops and so tends to choice the worst links. Furthermor= e, the packet loss is mainly due to the SINR variation which can be very hu= ge depending on the material and the environment and link quality determine= d by link hysteresis can be in phase difference with the SNR variation. = Best regards. Fran=E7ois -----Message d'origine----- De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de Emm= anuel Baccelli Envoy=E9 : jeudi 4 septembre 2008 13:44 =C0 : roll@ietf.org Objet : Re: [Roll] draft-ietf-roll-protocols-survey-00 Hi, I'd still like the authors to answer my comments on the "fail/pass" = table at the end of section 4, which is not fully justified in the document. As a reminder, here are a couple of "fail/pass" statements present in this = table, which were pointed out as being doubtful: - OLSR is said to "fail" the "loss response" criteria. However in the quick justification in section 4, nothing is said about link hysteresis strategy (see OLSR RFC 3626 section 14.3.) which arguably makes OLSR "pass" this criteria. - OLSR is said to "fail" the "control cost" criteria. However, simple fisheye TTL strategy on OLSR control messages makes OLSR "pass" this criteria. See this paper "Fish Eye OLSR Scaling Properties" in Journal of Communication and Networks, 2004. Actually this paper even proves that OLSR can thus reach the Gupta and Kumar bounds in terms of control overhead scalability. I am sure that other people would have additional question marks with = this table. But for starters, the items above should be discussed. regards, Emmanuel _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Sep 4 09:39:55 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205C03A6B75; Thu, 4 Sep 2008 09:39:55 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3116A3A6BAF for ; Thu, 4 Sep 2008 09:39:53 -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=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ywi1rjPOrdw5 for ; Thu, 4 Sep 2008 09:39:51 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id 62F453A6A65 for ; Thu, 4 Sep 2008 09:39:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,320,1217800800"; d="scan'208";a="16825592" Received: from sphinx.lix.polytechnique.fr (HELO BoolfightMaN-Laptop.local) ([129.104.11.1]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Sep 2008 18:39:48 +0200 Message-ID: <48C00F50.5030801@inria.fr> Date: Thu, 04 Sep 2008 18:39:44 +0200 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: roll@ietf.org References: <48B596DB.5020808@inria.fr> <48BFCA07.5050609@inria.fr> <8AA97249241F7148BE6D3D8B93D83F5A12F9E8BA@ftrdmel2> In-Reply-To: <8AA97249241F7148BE6D3D8B93D83F5A12F9E8BA@ftrdmel2> Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Fran=E7ois, thanks for your response. I have a couple of comments about it: - do we have an understanding what kind of data traffic intensity we are = targetting in Roll? This may be interesting to know, since it seems you = have an idea about it. - Link hysteresis is a mechanism to eliminate bad links, and some kind = of metric in this sense. This mechanism is completely ignored in the = document so far. So my comment is: "Take it into account". - As to the efficiency of link hysteresis, it would be useful to gather = the experience of people (there are many) who have implemented and = tested OLSR with real devices. Moreover, we should get a quantitative = appreciation about link hysteresis that could be compared to, say, = TBRPF's corresponding mechanism that is said to "pass" the "loss" test = in the document so far. Again, this should be justified. cheers Emmanuel francois2.jan@orange-ftgroup.com a =E9crit : > Hello, > = > May I bring my point of view. > = > Theoretically link hysteresis solution solves the issue of bad links. In = practice, link hysteresis is not very efficient for at least 2 reasons. The= link hysteresis solution is based on the reception of hello packets which = are generally sent at lower throughput than data packets because hello pack= ets are sent in broadcast. So hello packets have more chance to be received= than data packets (see "grey zone" issue), all the more so OLSR tends to m= inimize the number of hops and so tends to choice the worst links. Furtherm= ore, the packet loss is mainly due to the SINR variation which can be very = huge depending on the material and the environment and link quality determi= ned by link hysteresis can be in phase difference with the SNR variation. = > = > Best regards. > = > Fran=E7ois > = > -----Message d'origine----- > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de E= mmanuel Baccelli > Envoy=E9 : jeudi 4 septembre 2008 13:44 > =C0 : roll@ietf.org > Objet : Re: [Roll] draft-ietf-roll-protocols-survey-00 > = > Hi, > = > I'd still like the authors to answer my comments on the "fail/pass" = > table at the end of section 4, which is not fully justified in the docume= nt. > = > As a reminder, here are a couple of "fail/pass" statements present in thi= s table, which were pointed out as being doubtful: > = > = > - OLSR is said to "fail" the "loss response" criteria. However in the > quick justification in section 4, nothing is said about link hysteresis > strategy (see OLSR RFC 3626 section 14.3.) which arguably makes OLSR > "pass" this criteria. > = > - OLSR is said to "fail" the "control cost" criteria. However, simple > fisheye TTL strategy on OLSR control messages makes OLSR "pass" this > criteria. See this paper "Fish Eye OLSR Scaling Properties" in Journal > of Communication and Networks, 2004. Actually this paper even proves > that OLSR can thus reach the Gupta and Kumar bounds in terms of control > overhead scalability. > = > = > I am sure that other people would have additional question marks with = > this table. But for starters, the items above should be discussed. > = > regards, > = > Emmanuel > = > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > = > = _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Sep 4 11:43:33 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94C243A6AFF; Thu, 4 Sep 2008 11:43:33 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5253A6AB6 for ; Thu, 4 Sep 2008 11:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+1QtG1v4SJx for ; Thu, 4 Sep 2008 11:43:27 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 7C6363A67CC for ; Thu, 4 Sep 2008 11:43:27 -0700 (PDT) Received: from [67.117.81.254] (helo=[10.1.1.132]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1KbJnD-00063P-Il; Thu, 04 Sep 2008 11:42:55 -0700 Message-Id: <4D55B62F-D0F7-4935-AF55-AF2685B31E36@cs.stanford.edu> From: Philip Levis To: Emmanuel Baccelli In-Reply-To: <48BFCA07.5050609@inria.fr> Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 4 Sep 2008 11:42:55 -0700 References: <48B596DB.5020808@inria.fr> <48BFCA07.5050609@inria.fr> X-Mailer: Apple Mail (2.926) X-Scan-Signature: f9929892efd47015c544d6ca2fb551e9 Cc: roll@ietf.org Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Sep 4, 2008, at 4:44 AM, Emmanuel Baccelli wrote: > Hi, > > I'd still like the authors to answer my comments on the "fail/pass" > table at the end of section 4, which is not fully justified in the > document. > > As a reminder, here are a couple of "fail/pass" statements present in > this table, which were pointed out as being doubtful: > > > - OLSR is said to "fail" the "loss response" criteria. However in the > quick justification in section 4, nothing is said about link > hysteresis > strategy (see OLSR RFC 3626 section 14.3.) which arguably makes OLSR > "pass" this criteria. I disagree. All link hysteresis does is smooth a noisy signal. This does not mean that links do not come and go. It can reduce the maximum frequency of advertised link state changes. It is important to note that this technique does have a cost, in terms of routing correctness and efficiency. I.e., a link can go to 0% suddenly yet hysteresis will prevent this change from propagating quickly (a basic property of smoothing). Nevertheless, it will propagate. > > > - OLSR is said to "fail" the "control cost" criteria. However, simple > fisheye TTL strategy on OLSR control messages makes OLSR "pass" this > criteria. See this paper "Fish Eye OLSR Scaling Properties" in Journal > of Communication and Networks, 2004. Actually this paper even proves > that OLSR can thus reach the Gupta and Kumar bounds in terms of > control > overhead scalability. I think it's important to have a clear line defining what sufficiently demonstrates properties of a protocol. I think the paper has some interesting ideas, but it isn't a protocol specification, nor does it demonstrate a working protocol with real wireless behavior (e.g., link dynamics). Do you have running code? Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Sep 8 04:48:54 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87F43A6BE0; Mon, 8 Sep 2008 04:48:54 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 291DC3A6BE0 for ; Mon, 8 Sep 2008 04:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.516 X-Spam-Level: X-Spam-Status: No, score=-0.516 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnzBglubDW5f for ; Mon, 8 Sep 2008 04:48:53 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id DF2143A6BD8 for ; Mon, 8 Sep 2008 04:48:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,358,1217800800"; d="scan'208";a="14692967" Received: from sphinx.lix.polytechnique.fr (HELO BoolfightMaN-Laptop.local) ([129.104.11.1]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Sep 2008 13:48:54 +0200 Message-ID: <48C51122.2080907@inria.fr> Date: Mon, 08 Sep 2008 13:48:50 +0200 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: roll@ietf.org Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Phil, >> >> - OLSR is said to "fail" the "loss response" criteria. However in the >> quick justification in section 4, nothing is said about link hysteresis >> strategy (see OLSR RFC 3626 section 14.3.) which arguably makes OLSR >> "pass" this criteria. > > I disagree. All link hysteresis does is smooth a noisy signal. This does not mean that links do not come and go. It can reduce the maximum frequency of advertised link state changes. It is important to note that this technique does have a cost, in terms of routing correctness and efficiency. I.e., a link can go to 0% suddenly yet hysteresis will prevent this change from propagating quickly (a basic property of smoothing). Nevertheless, it will propagate. > This level of detail should be documented in the document. For each mechanism of each protocol, and for each criteria that is being evaluated. Then people will have the elements to make up their mind. So we agree: the draft is incomplete. >> >> >> - OLSR is said to "fail" the "control cost" criteria. However, simple >> fisheye TTL strategy on OLSR control messages makes OLSR "pass" this >> criteria. See this paper "Fish Eye OLSR Scaling Properties" in Journal >> of Communication and Networks, 2004. Actually this paper even proves >> that OLSR can thus reach the Gupta and Kumar bounds in terms of control >> overhead scalability. > > I think it's important to have a clear line defining what sufficiently demonstrates properties of a protocol. I think the paper has some interesting ideas, but it isn't a protocol specification, nor does it demonstrate a working protocol with real wireless behavior (e.g., link dynamics). Do you have running code? > What is disturbing is that claims to look at "RFCs" and "running code" contrast with the restricted and purely theoretical evaluation of the protocols present in the draft. We've got to be coherent. So if we are relying on theoretical evaluation, the comments I made are valid. If we are instead talking about real experience with real devices and running code, then the draft should be altered quite a bit. regards, Emmanuel _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Sep 8 05:05:23 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A083A6877; Mon, 8 Sep 2008 05:05:23 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1F33A6877 for ; Mon, 8 Sep 2008 05:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.136 X-Spam-Level: X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 291QESTIW4aQ for ; Mon, 8 Sep 2008 05:05:20 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A63FB3A67D0 for ; Mon, 8 Sep 2008 05:05:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,358,1217808000"; d="scan'208";a="20010804" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 08 Sep 2008 12:04:56 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m88C4uej021204; Mon, 8 Sep 2008 08:04:56 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m88C4uaJ012279; Mon, 8 Sep 2008 12:04:56 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Sep 2008 08:04:56 -0400 Received: from 10.61.100.190 ([10.61.100.190]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 8 Sep 2008 12:04:55 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Mon, 08 Sep 2008 14:04:53 +0200 From: JP Vasseur To: Emmanuel Baccelli , Philip Levis Message-ID: Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 Thread-Index: AckRqxn/Og1c4w4EE0SKTLGxgRB3Zw== In-Reply-To: <48C51122.2080907@inria.fr> Mime-version: 1.0 X-OriginalArrivalTime: 08 Sep 2008 12:04:56.0043 (UTC) FILETIME=[1BCF73B0:01C911AB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4385; t=1220875496; x=1221739496; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20draft-ietf-roll-protocols-surv ey-00 |Sender:=20 |To:=20Emmanuel=20Baccelli=20,= 0A=20=20=20=20=20=20=20=20Philip=20Levis=20; bh=Sxrh5m09THpe+X/pnYFIfR65dJoNM04hq01ixAZ5H2I=; b=hGOuRAqv0Lx/xizQXNXqRaUV6c/QBAoTEFOUlbLB+rcf2SGtHnldBbxHnb hYpOrDq3uyACin7zVobg2/gZzDO8Jz+H/z+ISd93YQKstw1TsUkp/KU8EhBk acvph2d68F; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Emmanuel, I'd like to make two comments. 1) Writing such a document is a really difficult exercise. We have to limit the scope in term of number of protocols studied, number of criteria and then evaluation of each criteria. And for sure, there will be disagreement. In the end, we will have to make a compromise and we will hopefully have a rough consensus. We need to bear in mind in that industry needs an IP-based solution and the routing piece is essential. In the mean-time, non-IP and proprietary solutions do make "progress", thus the need for a solution fairly quickly (which does not mean "rushing out", we do have to make sure that we make a careful evaluation) 2) We need to make sure not to require a thorough evaluation of all the characteristics of dozen of protocols and we have to draw the line somewhere. This aim of this document is not to become a text book but rather to look at routing protocol characteristics that are relevant to the context of ROLL (in light with the application-specific routing requirements documents). Of course, if you feel that items are missing, thanks to continue the discussion and suggest improvement. This document is undoubtedly not finalized. You made the following comment: > > What is disturbing is that claims to look at "RFCs" and "running code" > contrast with the restricted and purely theoretical evaluation of the > protocols present in the draft. We've got to be coherent. There are aspects that are indeed theoretical. That said, several of the criteria have been derived from the application-specific documents, which does not appear very clearly, I agree. Phil and I had a discussion about this, and it should be more clearly explained. Phil, are you planning to post a new revision taking into account the various comments received on the ML from Adrian, Emmanuel, ...? Thanks. JP. On 9/8/08 1:48 PM, "Emmanuel Baccelli" wrote: > Hi Phil, > > >>> >>> - OLSR is said to "fail" the "loss response" criteria. However in the >>> quick justification in section 4, nothing is said about link hysteresis >>> strategy (see OLSR RFC 3626 section 14.3.) which arguably makes OLSR >>> "pass" this criteria. >> >> I disagree. All link hysteresis does is smooth a noisy signal. This > does not mean that links do not come and go. It can reduce the maximum > frequency of advertised link state changes. It is important to note that > this technique does have a cost, in terms of routing correctness and > efficiency. I.e., a link can go to 0% suddenly yet hysteresis will > prevent this change from propagating quickly (a basic property of > smoothing). Nevertheless, it will propagate. >> > > > This level of detail should be documented in the document. For each > mechanism of each protocol, and for each criteria that is being > evaluated. Then people will have the elements to make up their mind. So > we agree: the draft is incomplete. > > >>> >>> >>> - OLSR is said to "fail" the "control cost" criteria. However, simple >>> fisheye TTL strategy on OLSR control messages makes OLSR "pass" this >>> criteria. See this paper "Fish Eye OLSR Scaling Properties" in Journal >>> of Communication and Networks, 2004. Actually this paper even proves >>> that OLSR can thus reach the Gupta and Kumar bounds in terms of control >>> overhead scalability. >> >> I think it's important to have a clear line defining what > sufficiently demonstrates properties of a protocol. I think the paper > has some interesting ideas, but it isn't a protocol specification, nor > does it demonstrate a working protocol with real wireless behavior > (e.g., link dynamics). Do you have running code? >> > > > What is disturbing is that claims to look at "RFCs" and "running code" > contrast with the restricted and purely theoretical evaluation of the > protocols present in the draft. We've got to be coherent. > > So if we are relying on theoretical evaluation, the comments I made are > valid. If we are instead talking about real experience with real devices > and running code, then the draft should be altered quite a bit. > > regards, > Emmanuel > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Sep 8 07:09:16 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A99D3A6A71; Mon, 8 Sep 2008 07:09:16 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CDB93A67AE for ; Mon, 8 Sep 2008 07:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mS4jG27zhS40 for ; Mon, 8 Sep 2008 07:09:14 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id A35A93A6B47 for ; Mon, 8 Sep 2008 07:09:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,358,1217800800"; d="scan'208";a="16704765" Received: from sphinx.lix.polytechnique.fr (HELO BoolfightMaN-Laptop.local) ([129.104.11.1]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Sep 2008 16:09:11 +0200 Message-ID: <48C53207.4090807@inria.fr> Date: Mon, 08 Sep 2008 16:09:11 +0200 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi JP, see inline JP Vasseur a =E9crit : > Hi Emmanuel, > = > I'd like to make two comments. > 1) Writing such a document is a really difficult exercise. We have to lim= it > the scope in term of number of protocols studied, number of criteria and > then evaluation of each criteria. And for sure, there will be disagreemen= t. > In the end, we will have to make a compromise and we will hopefully have a > rough consensus. We need to bear in mind in that industry needs an IP-bas= ed > solution and the routing piece is essential. In the mean-time, non-IP and > proprietary solutions do make "progress", thus the need for a solution > fairly quickly (which does not mean "rushing out", we do have to make sure > that we make a careful evaluation) As far as I am concerned, the protocols addressed in the draft are the = ones that ROLL should be looking at. The criteria addressed in the draft = are the ones that ROLL should be concerned with. But it makes no sense = whatsoever to have an incomplete evaluation for these criteria. > 2) We need to make sure not to require a thorough evaluation of all the > characteristics of dozen of protocols and we have to draw the line > somewhere. This aim of this document is not to become a text book but rat= her > to look at routing protocol characteristics that are relevant to the cont= ext > of ROLL (in light with the application-specific routing requirements > documents). > = > Of course, if you feel that items are missing, thanks to continue the > discussion and suggest improvement. This document is undoubtedly not > finalized. Yes. I mentionned some items that are missing for the evaluation of some = criteria. I believe that they would make the evaluation of the criteria = more complete. This level of completeness should be met for each = criteria, for each protocol that is mentionned. We agree that for now the document is incomplete. But another problem is = that the draft is not transparent. And, maybe because of this lack of = transparency, the draft also seems to be incorrect, as pointed out = earlier in the discussion. For now it is not clear how the evaluation is conducted: purely = theoretically? Or more practically? Both? I guess that this survey = serves as some kind of "problem statement" for the ROLL working group. = So in this respect, its aim should be to explain what is currently = missing within the IETF in order to achieve the goal(s) of ROLL. The = document should talk about existing RFCs, existing drafts, and existing = WG activities in detail, in order to evaluate how these could (or could = not) be used to achieve the goal(s) of ROLL. regards Emmanuel > = > You made the following comment: > = >> What is disturbing is that claims to look at "RFCs" and "running code" >> contrast with the restricted and purely theoretical evaluation of the >> protocols present in the draft. We've got to be coherent. > = > There are aspects that are indeed theoretical. That said, several of the > criteria have been derived from the application-specific documents, which > does not appear very clearly, I agree. Phil and I had a discussion about > this, and it should be more clearly explained. > = > Phil, are you planning to post a new revision taking into account the > various comments received on the ML from Adrian, Emmanuel, ...? > = > Thanks. > = > JP. > = > = > On 9/8/08 1:48 PM, "Emmanuel Baccelli" wrote: > = >> Hi Phil, >> >> >>>> - OLSR is said to "fail" the "loss response" criteria. However in the >>>> quick justification in section 4, nothing is said about link hysteresis >>>> strategy (see OLSR RFC 3626 section 14.3.) which arguably makes OLSR >>>> "pass" this criteria. >>> I disagree. All link hysteresis does is smooth a noisy signal. This >> does not mean that links do not come and go. It can reduce the maximum >> frequency of advertised link state changes. It is important to note that >> this technique does have a cost, in terms of routing correctness and >> efficiency. I.e., a link can go to 0% suddenly yet hysteresis will >> prevent this change from propagating quickly (a basic property of >> smoothing). Nevertheless, it will propagate. >> >> This level of detail should be documented in the document. For each >> mechanism of each protocol, and for each criteria that is being >> evaluated. Then people will have the elements to make up their mind. So >> we agree: the draft is incomplete. >> >> >>>> >>>> - OLSR is said to "fail" the "control cost" criteria. However, simple >>>> fisheye TTL strategy on OLSR control messages makes OLSR "pass" this >>>> criteria. See this paper "Fish Eye OLSR Scaling Properties" in Journal >>>> of Communication and Networks, 2004. Actually this paper even proves >>>> that OLSR can thus reach the Gupta and Kumar bounds in terms of control >>>> overhead scalability. >>> I think it's important to have a clear line defining what >> sufficiently demonstrates properties of a protocol. I think the paper >> has some interesting ideas, but it isn't a protocol specification, nor >> does it demonstrate a working protocol with real wireless behavior >> (e.g., link dynamics). Do you have running code? >> >> What is disturbing is that claims to look at "RFCs" and "running code" >> contrast with the restricted and purely theoretical evaluation of the >> protocols present in the draft. We've got to be coherent. >> >> So if we are relying on theoretical evaluation, the comments I made are >> valid. If we are instead talking about real experience with real devices >> and running code, then the draft should be altered quite a bit. >> >> regards, >> Emmanuel >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > = > = _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Sep 8 14:50:49 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69973A6971; Mon, 8 Sep 2008 14:50:48 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DC1E3A6971 for ; Mon, 8 Sep 2008 14:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zymvAr6lsy2F for ; Mon, 8 Sep 2008 14:50:45 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237]) by core3.amsl.com (Postfix) with ESMTP id 0FABD3A68A2 for ; Mon, 8 Sep 2008 14:50:44 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id s16so404308wxc.31 for ; Mon, 08 Sep 2008 14:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=xK0Dnj9+OgG0KG3OG9YXxwa2+Rm8Ohbwgh0Shbqvy/k=; b=cejaZOh27xe+xxclztXT9uSY/aNyug4pmY8zZ8jjgR8R6VPcO+ZqLF7mR+ydzpEuLc XIWkO/g+D5BUFfNmUK6mO1ylu0QtXrsIDpDjI3YE6XUeonOssEReclRO62ka3zj5gvKB JR4gDUFeBz9sQXYEYSwA+lbk3lu4fstWDWXgU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=KNoHa6zMnglJVG6GzuvtmRtLuNoKvL3hTE/LzRE8TnKGOQF78cIOfKlHuBICyVhcpY xtyueDGVQ/clJa5FSePGA9064UzSrl/OEi1v3s8QZsymIfQmUoBWWwFitwpNInDBTpMl IDtTOZPY9etzmUI/oxfaNjEP0IKcJaT9Yu9kI= Received: by 10.70.11.1 with SMTP id 1mr17259616wxk.26.1220910644143; Mon, 08 Sep 2008 14:50:44 -0700 (PDT) Received: by 10.70.118.8 with HTTP; Mon, 8 Sep 2008 14:50:45 -0700 (PDT) Message-ID: <44680fe70809081450m3a5daa40nf53abe936742ff47@mail.gmail.com> Date: Mon, 8 Sep 2008 14:50:45 -0700 From: "Stephen Dawson-Haggerty" To: "Emmanuel Baccelli" In-Reply-To: <48C53207.4090807@inria.fr> MIME-Version: 1.0 References: <48C53207.4090807@inria.fr> X-Google-Sender-Auth: c43e65eeb10e6641 Cc: roll@ietf.org Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0568736099==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0568736099== Content-Type: multipart/alternative; boundary="----=_Part_2935_22513257.1220910645584" ------=_Part_2935_22513257.1220910645584 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Other then the comments about inaccuracies and a lack of detail in Annex A, it seems like we're still debating the scope of the document, as Phil said. We don't want to consider arbitrary protocol modifications and extensions because they aren't generally full protocol specifications and so couldn't usually be adopted without further work. The analysis presented in the draft isn't based particularly on studies of actual protocol performance, although we did look at those where they did exist (I remember at least AODV and TBRPF have them). I suppose this makes it more theoretical then practical; the issue is that it's going to be difficult if not impossible to compare the different studies in the literature due to differing methodology, incomplete implementations, etc. This could be made more clear, and we can provide references to these external studies. One thing I would suggest is to make the guidance and lessons about figure design more explicit and concrete, and to do it by citing mechanism example= s from the protocols we examined. This might help address some of the concerns raised while keeping the document within scope. Thanks for all the good comments! Steve On Mon, Sep 8, 2008 at 7:09 AM, Emmanuel Baccelli < Emmanuel.Baccelli@inria.fr> wrote: > Hi JP, > see inline > > JP Vasseur a =E9crit : > > Hi Emmanuel, > > > > I'd like to make two comments. > > 1) Writing such a document is a really difficult exercise. We have to > limit > > the scope in term of number of protocols studied, number of criteria an= d > > then evaluation of each criteria. And for sure, there will be > disagreement. > > In the end, we will have to make a compromise and we will hopefully hav= e > a > > rough consensus. We need to bear in mind in that industry needs an > IP-based > > solution and the routing piece is essential. In the mean-time, non-IP a= nd > > proprietary solutions do make "progress", thus the need for a solution > > fairly quickly (which does not mean "rushing out", we do have to make > sure > > that we make a careful evaluation) > > As far as I am concerned, the protocols addressed in the draft are the > ones that ROLL should be looking at. The criteria addressed in the draft > are the ones that ROLL should be concerned with. But it makes no sense > whatsoever to have an incomplete evaluation for these criteria. > > > > 2) We need to make sure not to require a thorough evaluation of all the > > characteristics of dozen of protocols and we have to draw the line > > somewhere. This aim of this document is not to become a text book but > rather > > to look at routing protocol characteristics that are relevant to the > context > > of ROLL (in light with the application-specific routing requirements > > documents). > > > > Of course, if you feel that items are missing, thanks to continue the > > discussion and suggest improvement. This document is undoubtedly not > > finalized. > > Yes. I mentionned some items that are missing for the evaluation of some > criteria. I believe that they would make the evaluation of the criteria > more complete. This level of completeness should be met for each > criteria, for each protocol that is mentionned. > > We agree that for now the document is incomplete. But another problem is > that the draft is not transparent. And, maybe because of this lack of > transparency, the draft also seems to be incorrect, as pointed out > earlier in the discussion. > > For now it is not clear how the evaluation is conducted: purely > theoretically? Or more practically? Both? I guess that this survey > serves as some kind of "problem statement" for the ROLL working group. > So in this respect, its aim should be to explain what is currently > missing within the IETF in order to achieve the goal(s) of ROLL. The > document should talk about existing RFCs, existing drafts, and existing > WG activities in detail, in order to evaluate how these could (or could > not) be used to achieve the goal(s) of ROLL. > > regards > Emmanuel > > > > > > > > You made the following comment: > > > >> What is disturbing is that claims to look at "RFCs" and "running code" > >> contrast with the restricted and purely theoretical evaluation of the > >> protocols present in the draft. We've got to be coherent. > > > > There are aspects that are indeed theoretical. That said, several of th= e > > criteria have been derived from the application-specific documents, whi= ch > > does not appear very clearly, I agree. Phil and I had a discussion abou= t > > this, and it should be more clearly explained. > > > > Phil, are you planning to post a new revision taking into account the > > various comments received on the ML from Adrian, Emmanuel, ...? > > > > Thanks. > > > > JP. > > > > > > On 9/8/08 1:48 PM, "Emmanuel Baccelli" > wrote: > > > >> Hi Phil, > >> > >> > >>>> - OLSR is said to "fail" the "loss response" criteria. However in th= e > >>>> quick justification in section 4, nothing is said about link > hysteresis > >>>> strategy (see OLSR RFC 3626 section 14.3.) which arguably makes OLSR > >>>> "pass" this criteria. > >>> I disagree. All link hysteresis does is smooth a noisy signal. This > >> does not mean that links do not come and go. It can reduce the maximum > >> frequency of advertised link state changes. It is important to note th= at > >> this technique does have a cost, in terms of routing correctness and > >> efficiency. I.e., a link can go to 0% suddenly yet hysteresis will > >> prevent this change from propagating quickly (a basic property of > >> smoothing). Nevertheless, it will propagate. > >> > >> This level of detail should be documented in the document. For each > >> mechanism of each protocol, and for each criteria that is being > >> evaluated. Then people will have the elements to make up their mind. S= o > >> we agree: the draft is incomplete. > >> > >> > >>>> > >>>> - OLSR is said to "fail" the "control cost" criteria. However, simpl= e > >>>> fisheye TTL strategy on OLSR control messages makes OLSR "pass" this > >>>> criteria. See this paper "Fish Eye OLSR Scaling Properties" in Journ= al > >>>> of Communication and Networks, 2004. Actually this paper even proves > >>>> that OLSR can thus reach the Gupta and Kumar bounds in terms of > control > >>>> overhead scalability. > >>> I think it's important to have a clear line defining what > >> sufficiently demonstrates properties of a protocol. I think the paper > >> has some interesting ideas, but it isn't a protocol specification, nor > >> does it demonstrate a working protocol with real wireless behavior > >> (e.g., link dynamics). Do you have running code? > >> > >> What is disturbing is that claims to look at "RFCs" and "running code" > >> contrast with the restricted and purely theoretical evaluation of the > >> protocols present in the draft. We've got to be coherent. > >> > >> So if we are relying on theoretical evaluation, the comments I made ar= e > >> valid. If we are instead talking about real experience with real devic= es > >> and running code, then the draft should be altered quite a bit. > >> > >> regards, > >> Emmanuel > >> > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > ------=_Part_2935_22513257.1220910645584 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Other then the comment= s about inaccuracies and a lack of detail in Annex A, it seems like we're still debating the scope of the document, as Phil said.  We don't want t= o consider arbitrary protocol modifications and extensions because they aren't generally full protocol specifications and so couldn't usual= ly be adopted without further work.

The analysis presented in the draft isn't based particularly on studies of actual protocol performance, although we did look at those where they did exist (I remember at least AODV and TBRPF have them).  = I suppose this makes it more theoretical then practical; the issue is that it's going to be difficult if not impossible to compare the different studies in the literature due to differing methodology, incomplete implementations, etc.  This could be made more clear, and w= e can provide references to these external studies.

One thing I would suggest is to make the guidance and lessons about figure design more explicit and concrete, and to do it by citing mechanism examples from the protocols we examined.  This might help ad= dress some of the concerns raised while keeping the document within scope.<= br>
Thanks for all the good comments!
Steve


On Mon, Sep 8, 2008 at 7:09 AM, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr&g= t; wrote:
Hi JP,
see inline

JP Vasseur a =E9crit :
> Hi Emmanuel,
>
> I'd like to make two comments.
> 1) Writing such a document is a really difficult exercise. We have to = limit
> the scope in term of number of protocols studied, number of criteria a= nd
> then evaluation of each criteria. And for sure, there will be disagree= ment.
> In the end, we will have to make a compromise and we will hopefully ha= ve a
> rough consensus. We need to bear in mind in that industry needs an IP-= based
> solution and the routing piece is essential. In the mean-time, non-IP = and
> proprietary solutions do make "progress", thus the need for = a solution
> fairly quickly (which does not mean "rushing out", we do hav= e to make sure
> that we make a careful evaluation)

As far as I am concerned, the protocols addressed in the draft are th= e
ones that ROLL should be looking at. The criteria addressed in the draft are the ones that ROLL should be concerned with. But it makes no sense
whatsoever to have an incomplete evaluation for these criteria.


> 2) We need to make sure not to require a thorough evaluation of all th= e
> characteristics of dozen of protocols and we have to draw the line
> somewhere. This aim of this document is not to become a text book but = rather
> to look at routing protocol characteristics that are relevant to the c= ontext
> of ROLL (in light with the application-specific routing requirements > documents).
>
> Of course, if you feel that items are missing, thanks to continue the<= br> > discussion and suggest improvement. This document is undoubtedly not > finalized.

Yes. I mentionned some items that are missing for the evaluation of s= ome
criteria. I believe that they would make the evaluation of the criteria
more complete. This level of completeness should be met for each
criteria, for each protocol that is mentionned.

We agree that for now the document is incomplete. But another problem is that the draft is not transparent. And, maybe because of this lack of
transparency, the draft also seems to be incorrect, as pointed out
earlier in the discussion.

For now it is not clear how the evaluation is conducted: purely
theoretically? Or more practically? Both? I guess that this survey
serves as some kind of "problem statement" for the ROLL working g= roup.
So in this respect, its aim should be to explain what is currently
missing within the IETF in order to achieve the goal(s) of ROLL. The
document should talk about existing RFCs, existing drafts, and existing
WG activities in detail, in order to evaluate how these could (or could
not) be used to achieve the goal(s) of ROLL.

regards
Emmanuel




>
> You made the following comment:
>
>> What is disturbing is that claims to look at "RFCs" and = "running code"
>> contrast with the restricted and purely theoretical evaluation of = the
>> protocols present in the draft. We've got to be coherent.
>
> There are aspects that are indeed theoretical. That said, several of t= he
> criteria have been derived from the application-specific documents, wh= ich
> does not appear very clearly, I agree. Phil and I had a discussion abo= ut
> this, and it should be more clearly explained.
>
> Phil, are you planning to post a new revision taking into account the<= br> > various comments received on the ML from Adrian, Emmanuel, ...?
>
> Thanks.
>
> JP.
>
>
> On 9/8/08 1:48 PM, "Emmanuel Baccelli" <Emmanuel.Baccelli@inria.fr> wrote:
>
>> Hi Phil,
>>
>>
>>>> - OLSR is said to "fail" the "loss response= " criteria. However in the
>>>> quick justification in section 4, nothing is said about li= nk hysteresis
>>>> strategy (see OLSR RFC 3626 section 14.3.) which arguably = makes OLSR
>>>> "pass" this criteria.
>>> I disagree. All link hysteresis does is smooth a noisy signal.= This
>> does not mean that links do not come and go. It can reduce the max= imum
>> frequency of advertised link state changes. It is important to not= e that
>> this technique does have a cost, in terms of routing correctness a= nd
>> efficiency. I.e., a link can go to 0% suddenly yet hysteresis will=
>> prevent this change from propagating quickly (a basic property of<= br> >> smoothing). Nevertheless, it will propagate.
>>
>> This level of detail should be documented in the document. For eac= h
>> mechanism of each protocol, and for each criteria that is being >> evaluated. Then people will have the elements to make up their min= d. So
>> we agree: the draft is incomplete.
>>
>>
>>>>
>>>> - OLSR is said to "fail" the "control cost&= quot; criteria. However, simple
>>>> fisheye TTL strategy on OLSR control messages makes OLSR &= quot;pass" this
>>>> criteria. See this paper "Fish Eye OLSR Scaling Prope= rties" in Journal
>>>> of Communication and Networks, 2004. Actually this paper e= ven proves
>>>> that OLSR can thus reach the Gupta and Kumar bounds in ter= ms of control
>>>> overhead scalability.
>>> I think it's important to have a clear line defining what<= br> >> sufficiently demonstrates properties of a protocol. I think the pa= per
>> has some interesting ideas, but it isn't a protocol specificat= ion, nor
>> does it demonstrate a working protocol with real wireless behavior=
>> (e.g., link dynamics). Do you have running code?
>>
>> What is disturbing is that claims to look at "RFCs" and = "running code"
>> contrast with the restricted and purely theoretical evaluation of = the
>> protocols present in the draft. We've got to be coherent.
>>
>> So if we are relying on theoretical evaluation, the comments I mad= e are
>> valid. If we are instead talking about real experience with real d= evices
>> and running code, then the draft should be altered quite a bit. >>
>> regards,
>> Emmanuel
>>
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>
>
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

------=_Part_2935_22513257.1220910645584-- --===============0568736099== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0568736099==-- From roll-bounces@ietf.org Tue Sep 9 09:06:51 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95BD13A6B26; Tue, 9 Sep 2008 09:06:51 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0291E3A6B20 for ; Tue, 9 Sep 2008 09:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSz-TkOx4mMm for ; Tue, 9 Sep 2008 09:06:45 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 956383A6CC4 for ; Tue, 9 Sep 2008 09:06:45 -0700 (PDT) Received: from dnab4221f2.stanford.edu ([171.66.33.242]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Kd5jt-0006nj-Vg; Tue, 09 Sep 2008 09:06:50 -0700 Message-Id: <17B94D9A-9010-4D4F-BCB9-322477F20ED3@cs.stanford.edu> From: Philip Levis To: Stephen Dawson-Haggerty In-Reply-To: <44680fe70809081450m3a5daa40nf53abe936742ff47@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 9 Sep 2008 08:46:26 -0700 References: <48C53207.4090807@inria.fr> <44680fe70809081450m3a5daa40nf53abe936742ff47@mail.gmail.com> X-Mailer: Apple Mail (2.926) X-Scan-Signature: f9929892efd47015c544d6ca2fb551e9 Cc: roll@ietf.org Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Sep 8, 2008, at 2:50 PM, Stephen Dawson-Haggerty wrote: > > Other then the comments about inaccuracies and a lack of detail in > Annex A, it seems like we're still debating the scope of the > document, as Phil said. We don't want to consider arbitrary > protocol modifications and extensions because they aren't generally > full protocol specifications and so couldn't usually be adopted > without further work. > > The analysis presented in the draft isn't based particularly on > studies of actual protocol performance, although we did look at > those where they did exist (I remember at least AODV and TBRPF have > them). I suppose this makes it more theoretical then practical; the > issue is that it's going to be difficult if not impossible to > compare the different studies in the literature due to differing > methodology, incomplete implementations, etc. This could be made > more clear, and we can provide references to these external studies. Thanks for articulating this much better than I did, Stephen. It's not that running code is necessary for an understanding of a protocol; rather, a precise specification is. RFCs and other standardization documents can meet this requirement, as can running code. But I'm uncomfortable with simulations based on simplified wireless models being sufficient; practice has shown us time and time again that the real complexities (and costs) come from all of the tricky edge cases which rarely emerge in simplified environments. I can read RFC 3561 and think through what will happen when a link is bursty; I'm not sure I can with most academic papers, as they (due to space concerns) are often forced to elide the details which would let a reader do the same. > One thing I would suggest is to make the guidance and lessons about > figure design more explicit and concrete, and to do it by citing > mechanism examples from the protocols we examined. This might help > address some of the concerns raised while keeping the document > within scope. This is a great idea. It's clear from this discussion that the document needs to be clearer on its methodology and why that methodology is used. Our initial intention had been to make it very concise and factual rather than explanatory. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Sep 9 09:42:24 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0793528C1E6; Tue, 9 Sep 2008 09:42:24 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA3328C1EF for ; Tue, 9 Sep 2008 09:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffqzq8DKeDKj for ; Tue, 9 Sep 2008 09:42:20 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by core3.amsl.com (Postfix) with ESMTP id C1C3B28C1EA for ; Tue, 9 Sep 2008 09:42:19 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id q7so218555uge.15 for ; Tue, 09 Sep 2008 09:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=2iggO/2H3dZ7X8UOyWklotK6xknGqnq4zh9lt1Vu2FA=; b=VTFa9J+HVD5A4JYcvgZV/X4e2t0ZL7h2vQx0v35XzM9SpqxYCo5yPusaF2AWXtpWlD fCBGW/Jni12cpVHm+qNU7K27hR00ZtO5Ngnnbhm+RXighXkMQTQWsvlRAGr1/ninfTHD GhiWFi1GMtNQPAEE4oUOtKeL6OwTgw/k+H3/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=M22cTmTFR0bdDpicZ8Pw1wRODaSm/cTfq3psM9R8RTS5XHuw0pF8wX1aplttGuzQW1 q3ERt3zfvXm+Elwcb8JRsyfgdURUFbywqR9goGU1rguuV5DvKqVA5TC/C89KxBbWTpY2 EeOFFSzv4kJ6Po4OTByMWOx/v0fN2s1pEP5Ik= Received: by 10.210.47.1 with SMTP id u1mr20843111ebu.133.1220978542171; Tue, 09 Sep 2008 09:42:22 -0700 (PDT) Received: by 10.210.37.8 with HTTP; Tue, 9 Sep 2008 09:42:22 -0700 (PDT) Message-ID: <69306dde0809090942l424f1b30ja4cdf45c9c907e94@mail.gmail.com> Date: Tue, 9 Sep 2008 09:42:22 -0700 From: "Arsalan Tavakoli" To: roll@ietf.org In-Reply-To: <17B94D9A-9010-4D4F-BCB9-322477F20ED3@cs.stanford.edu> MIME-Version: 1.0 Content-Disposition: inline References: <48C53207.4090807@inria.fr> <44680fe70809081450m3a5daa40nf53abe936742ff47@mail.gmail.com> <17B94D9A-9010-4D4F-BCB9-322477F20ED3@cs.stanford.edu> X-Google-Sender-Auth: 3e901222f613d531 Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I would just like to follow-up on what some others have been saying. In terms of scope, I think the purpose of this document was to provide a baseline benchmark of the suitability of the discussed protocols for L2N applications. The criteria and quantitative benchmarks were culled from the application requirement documents, but admittedly can be more clearly stated in the draft rather than just simple references. As far as the set of extensions/twists/etc., I would argue the following two points: first, the set of all these is immense, at least to the point that it is not practical to include them all in a single survey. Second, it's not quite clear what's an extension, and what's a reworking. If I take one of the protocols, and completely change its concept of link estimation and path calculation, that is in essence twisting it into a new protocol. As Phil has pointed out, the RFCs are a much more precise specification than an academic paper or code, which allows us to go through the process of theoretically verifying bounds and performances. The unique requirements of L2N networks (which prompted such a document in the first place), make it very difficult to hypothesize how existing performance studies would be affected by L2N specific conditions. Granted that the justifications can be lengthier and any inaccuracies should be cleaned up, but the purpose of the table is to provide a strict evaluation of the protocol RFCs, which serve to provide a starting point for discussions such as the one on this list, and allow subsequent drafts to detail specific extensions or modifications that can address shortcomings of the RFC (according to the criteria in this survey) in a much more focused manner. This draft absolutely does not take a position on whether a new protocol is needed or whether extensions can address all the requirements. However, if all extensions and code and tweaks were included in the evaluation, due to the sheer quantity and imprecision/uncertainty of those specifications, we would end up with a table filled with all "?'s" or passes, which I argue would make it essentially useless. Thanks for all the comments; they have been quite helpful in highlighting things in the draft that need to be clarified. Arsalan On Tue, Sep 9, 2008 at 8:46 AM, Philip Levis wrote: > > On Sep 8, 2008, at 2:50 PM, Stephen Dawson-Haggerty wrote: > >> >> Other then the comments about inaccuracies and a lack of detail in >> Annex A, it seems like we're still debating the scope of the >> document, as Phil said. We don't want to consider arbitrary >> protocol modifications and extensions because they aren't generally >> full protocol specifications and so couldn't usually be adopted >> without further work. >> >> The analysis presented in the draft isn't based particularly on >> studies of actual protocol performance, although we did look at >> those where they did exist (I remember at least AODV and TBRPF have >> them). I suppose this makes it more theoretical then practical; the >> issue is that it's going to be difficult if not impossible to >> compare the different studies in the literature due to differing >> methodology, incomplete implementations, etc. This could be made >> more clear, and we can provide references to these external studies. > > Thanks for articulating this much better than I did, Stephen. It's not > that running code is necessary for an understanding of a protocol; > rather, a precise specification is. RFCs and other standardization > documents can meet this requirement, as can running code. But I'm > uncomfortable with simulations based on simplified wireless models > being sufficient; practice has shown us time and time again that the > real complexities (and costs) come from all of the tricky edge cases > which rarely emerge in simplified environments. I can read RFC 3561 > and think through what will happen when a link is bursty; I'm not sure > I can with most academic papers, as they (due to space concerns) are > often forced to elide the details which would let a reader do the same. > >> One thing I would suggest is to make the guidance and lessons about >> figure design more explicit and concrete, and to do it by citing >> mechanism examples from the protocols we examined. This might help >> address some of the concerns raised while keeping the document >> within scope. > > This is a great idea. It's clear from this discussion that the > document needs to be clearer on its methodology and why that > methodology is used. Our initial intention had been to make it very > concise and factual rather than explanatory. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Sep 10 01:05:12 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14B4F28C131; Wed, 10 Sep 2008 01:05:12 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768063A688B for ; Wed, 10 Sep 2008 01:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1xY3tMrK9EX for ; Wed, 10 Sep 2008 01:05:09 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D06B23A6809 for ; Wed, 10 Sep 2008 01:05:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,371,1217808000"; d="scan'208";a="20278844" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Sep 2008 08:05:13 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8A85DEM003488; Wed, 10 Sep 2008 04:05:13 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8A85DHN008493; Wed, 10 Sep 2008 08:05:13 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Sep 2008 04:05:13 -0400 Received: from 10.61.97.215 ([10.61.97.215]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 10 Sep 2008 08:05:12 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 10 Sep 2008 10:05:08 +0200 From: JP Vasseur To: Emmanuel Baccelli , Message-ID: Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 Thread-Index: AckTG/CxZzgsbFHslEeJdKiBRhgang== In-Reply-To: <48C53207.4090807@inria.fr> Mime-version: 1.0 X-OriginalArrivalTime: 10 Sep 2008 08:05:13.0383 (UTC) FILETIME=[F3E73370:01C9131B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7214; t=1221033913; x=1221897913; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20draft-ietf-roll-protocols-surv ey-00 |Sender:=20 |To:=20Emmanuel=20Baccelli=20,= 20; bh=9utBiYx6oWTYqhoDKAP1l0TwmFiBJGLu6cmHYnKgBxI=; b=jFElsB/U8RDCUme1+evL2OF6T6BxqRYHrbbGl3fRUtmFWEdKOPfxEnrPwq 6+0LtpgXamriSzcPm+95OZymXTfJyUwf2WF/keUpCVR5M45AnAPyV1O7Y7G7 Xe3YfuG5GF; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Emanuel, On 9/8/08 4:09 PM, "Emmanuel Baccelli" wrote: > Hi JP, > see inline > = > JP Vasseur a =E9crit : >> Hi Emmanuel, >> = >> I'd like to make two comments. >> 1) Writing such a document is a really difficult exercise. We have to li= mit >> the scope in term of number of protocols studied, number of criteria and >> then evaluation of each criteria. And for sure, there will be disagreeme= nt. >> In the end, we will have to make a compromise and we will hopefully have= a >> rough consensus. We need to bear in mind in that industry needs an IP-ba= sed >> solution and the routing piece is essential. In the mean-time, non-IP and >> proprietary solutions do make "progress", thus the need for a solution >> fairly quickly (which does not mean "rushing out", we do have to make su= re >> that we make a careful evaluation) > = > As far as I am concerned, the protocols addressed in the draft are the > ones that ROLL should be looking at. The criteria addressed in the draft > are the ones that ROLL should be concerned with. But it makes no sense > whatsoever to have an incomplete evaluation for these criteria. We're in full sync. Could you then propose additional text/sections/... ? > = > = >> 2) We need to make sure not to require a thorough evaluation of all the >> characteristics of dozen of protocols and we have to draw the line >> somewhere. This aim of this document is not to become a text book but ra= ther >> to look at routing protocol characteristics that are relevant to the con= text >> of ROLL (in light with the application-specific routing requirements >> documents). >> = >> Of course, if you feel that items are missing, thanks to continue the >> discussion and suggest improvement. This document is undoubtedly not >> finalized. > = > Yes. I mentionned some items that are missing for the evaluation of some > criteria. I believe that they would make the evaluation of the criteria > more complete. This level of completeness should be met for each > criteria, for each protocol that is mentionned. Yes, and this is a -00 version. That said, we need to find the right compromise between conciseness and accuracy, not so easy in this case. > = > We agree that for now the document is incomplete. But another problem is > that the draft is not transparent. And, maybe because of this lack of > transparency, the draft also seems to be incorrect, as pointed out > earlier in the discussion. Not sure what you mean by transparent. It is probably just because of missing explanations, which I am sure, the authors will be happy to add. DO not hesitate to propose text. > = > For now it is not clear how the evaluation is conducted: purely > theoretically? Or more practically? Both? It should certainly be both. I guess that this survey > serves as some kind of "problem statement" for the ROLL working group. We fortunately pass that stage. The aim of this document is to determine the next steps for the WG. > So in this respect, its aim should be to explain what is currently > missing within the IETF in order to achieve the goal(s) of ROLL. This is the aim of the table. The = > document should talk about existing RFCs, existing drafts, and existing > WG activities in detail, in order to evaluate how these could (or could > not) be used to achieve the goal(s) of ROLL. Not quite. Remember, we cannot afford to write a text book or to document the activity of other WGs. Still, the document has to be clear, detailed enough and concise. Thanks for your help. Thanks. JP. > = > regards > Emmanuel > = > = > = > = >> = >> You made the following comment: >> = >>> What is disturbing is that claims to look at "RFCs" and "running code" >>> contrast with the restricted and purely theoretical evaluation of the >>> protocols present in the draft. We've got to be coherent. >> = >> There are aspects that are indeed theoretical. That said, several of the >> criteria have been derived from the application-specific documents, which >> does not appear very clearly, I agree. Phil and I had a discussion about >> this, and it should be more clearly explained. >> = >> Phil, are you planning to post a new revision taking into account the >> various comments received on the ML from Adrian, Emmanuel, ...? >> = >> Thanks. >> = >> JP. >> = >> = >> On 9/8/08 1:48 PM, "Emmanuel Baccelli" wrot= e: >> = >>> Hi Phil, >>> = >>> = >>>>> - OLSR is said to "fail" the "loss response" criteria. However in the >>>>> quick justification in section 4, nothing is said about link hysteres= is >>>>> strategy (see OLSR RFC 3626 section 14.3.) which arguably makes OLSR >>>>> "pass" this criteria. >>>> I disagree. All link hysteresis does is smooth a noisy signal. This >>> does not mean that links do not come and go. It can reduce the maximum >>> frequency of advertised link state changes. It is important to note that >>> this technique does have a cost, in terms of routing correctness and >>> efficiency. I.e., a link can go to 0% suddenly yet hysteresis will >>> prevent this change from propagating quickly (a basic property of >>> smoothing). Nevertheless, it will propagate. >>> = >>> This level of detail should be documented in the document. For each >>> mechanism of each protocol, and for each criteria that is being >>> evaluated. Then people will have the elements to make up their mind. So >>> we agree: the draft is incomplete. >>> = >>> = >>>>> = >>>>> - OLSR is said to "fail" the "control cost" criteria. However, simple >>>>> fisheye TTL strategy on OLSR control messages makes OLSR "pass" this >>>>> criteria. See this paper "Fish Eye OLSR Scaling Properties" in Journal >>>>> of Communication and Networks, 2004. Actually this paper even proves >>>>> that OLSR can thus reach the Gupta and Kumar bounds in terms of contr= ol >>>>> overhead scalability. >>>> I think it's important to have a clear line defining what >>> sufficiently demonstrates properties of a protocol. I think the paper >>> has some interesting ideas, but it isn't a protocol specification, nor >>> does it demonstrate a working protocol with real wireless behavior >>> (e.g., link dynamics). Do you have running code? >>> = >>> What is disturbing is that claims to look at "RFCs" and "running code" >>> contrast with the restricted and purely theoretical evaluation of the >>> protocols present in the draft. We've got to be coherent. >>> = >>> So if we are relying on theoretical evaluation, the comments I made are >>> valid. If we are instead talking about real experience with real devices >>> and running code, then the draft should be altered quite a bit. >>> = >>> regards, >>> Emmanuel >>> = >>> = >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> = >> = > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Sep 10 01:27:16 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D363628C174; Wed, 10 Sep 2008 01:27:16 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33523A693D for ; Wed, 10 Sep 2008 01:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TSlLLCBeuHq for ; Wed, 10 Sep 2008 01:27:14 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id 60ED43A6D4D for ; Wed, 10 Sep 2008 01:27:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,371,1217800800"; d="scan'208";a="17053413" Received: from sphinx.lix.polytechnique.fr (HELO BoolfightMaN-Laptop.local) ([129.104.11.1]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Sep 2008 10:27:17 +0200 Message-ID: <48C784E5.7060002@inria.fr> Date: Wed, 10 Sep 2008 10:27:17 +0200 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: roll@ietf.org References: <48C53207.4090807@inria.fr> <44680fe70809081450m3a5daa40nf53abe936742ff47@mail.gmail.com> <17B94D9A-9010-4D4F-BCB9-322477F20ED3@cs.stanford.edu> <69306dde0809090942l424f1b30ja4cdf45c9c907e94@mail.gmail.com> In-Reply-To: <69306dde0809090942l424f1b30ja4cdf45c9c907e94@mail.gmail.com> Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Arsalan, OK. I think we basically agree on these three points: 1 - the methodology of the draft should be more transparent. 2 - overall, it should be clearer that the draft does not take a = position on whether a new protocol is needed or whether an existing = protocol can be extended. 3 - the evaluation of mentionned RFCs, drafts and related on-going = activities in other IETF WGs should be more precise. Cheers, Emmanuel Arsalan Tavakoli a =E9crit : > I would just like to follow-up on what some others have been saying. > In terms of scope, I think the purpose of this document was to provide > a baseline benchmark of the suitability of the discussed protocols for > L2N applications. The criteria and quantitative benchmarks were > culled from the application requirement documents, but admittedly can > be more clearly stated in the draft rather than just simple > references. As far as the set of extensions/twists/etc., I would > argue the following two points: first, the set of all these is > immense, at least to the point that it is not practical to include > them all in a single survey. Second, it's not quite clear what's an > extension, and what's a reworking. If I take one of the protocols, > and completely change its concept of link estimation and path > calculation, that is in essence twisting it into a new protocol. As > Phil has pointed out, the RFCs are a much more precise specification > than an academic paper or code, which allows us to go through the > process of theoretically verifying bounds and performances. The > unique requirements of L2N networks (which prompted such a document in > the first place), make it very difficult to hypothesize how existing > performance studies would be affected by L2N specific conditions. > Granted that the justifications can be lengthier and any inaccuracies > should be cleaned up, but the purpose of the table is to provide a > strict evaluation of the protocol RFCs, which serve to provide a > starting point for discussions such as the one on this list, and allow > subsequent drafts to detail specific extensions or modifications that > can address shortcomings of the RFC (according to the criteria in this > survey) in a much more focused manner. This draft absolutely does not > take a position on whether a new protocol is needed or whether > extensions can address all the requirements. However, if all > extensions and code and tweaks were included in the evaluation, due to > the sheer quantity and imprecision/uncertainty of those > specifications, we would end up with a table filled with all "?'s" or > passes, which I argue would make it essentially useless. > = > Thanks for all the comments; they have been quite helpful in > highlighting things in the draft that need to be clarified. > = > Arsalan > = > On Tue, Sep 9, 2008 at 8:46 AM, Philip Levis wrote: >> On Sep 8, 2008, at 2:50 PM, Stephen Dawson-Haggerty wrote: >> >>> Other then the comments about inaccuracies and a lack of detail in >>> Annex A, it seems like we're still debating the scope of the >>> document, as Phil said. We don't want to consider arbitrary >>> protocol modifications and extensions because they aren't generally >>> full protocol specifications and so couldn't usually be adopted >>> without further work. >>> >>> The analysis presented in the draft isn't based particularly on >>> studies of actual protocol performance, although we did look at >>> those where they did exist (I remember at least AODV and TBRPF have >>> them). I suppose this makes it more theoretical then practical; the >>> issue is that it's going to be difficult if not impossible to >>> compare the different studies in the literature due to differing >>> methodology, incomplete implementations, etc. This could be made >>> more clear, and we can provide references to these external studies. >> Thanks for articulating this much better than I did, Stephen. It's not >> that running code is necessary for an understanding of a protocol; >> rather, a precise specification is. RFCs and other standardization >> documents can meet this requirement, as can running code. But I'm >> uncomfortable with simulations based on simplified wireless models >> being sufficient; practice has shown us time and time again that the >> real complexities (and costs) come from all of the tricky edge cases >> which rarely emerge in simplified environments. I can read RFC 3561 >> and think through what will happen when a link is bursty; I'm not sure >> I can with most academic papers, as they (due to space concerns) are >> often forced to elide the details which would let a reader do the same. >> >>> One thing I would suggest is to make the guidance and lessons about >>> figure design more explicit and concrete, and to do it by citing >>> mechanism examples from the protocols we examined. This might help >>> address some of the concerns raised while keeping the document >>> within scope. >> This is a great idea. It's clear from this discussion that the >> document needs to be clearer on its methodology and why that >> methodology is used. Our initial intention had been to make it very >> concise and factual rather than explanatory. >> >> Phil >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > = > = _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Sep 10 01:37:26 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B275E3A6927; Wed, 10 Sep 2008 01:37:26 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29DAA3A6927 for ; Wed, 10 Sep 2008 01:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.609 X-Spam-Level: X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_40=-0.185, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOBcs1s+0t3B for ; Wed, 10 Sep 2008 01:37:24 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id EEE523A6919 for ; Wed, 10 Sep 2008 01:37:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,371,1217800800"; d="scan'208";a="17053916" Received: from sphinx.lix.polytechnique.fr (HELO BoolfightMaN-Laptop.local) ([129.104.11.1]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Sep 2008 10:37:28 +0200 Message-ID: <48C78748.4090605@inria.fr> Date: Wed, 10 Sep 2008 10:37:28 +0200 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi JP, Do you also agree with the points mentionned in my previous email? Moreover, what do you mean exactly by your comment below? >> I guess that this survey >> serves as some kind of "problem statement" for the ROLL working group. > > We fortunately pass that stage. The aim of this document is to determine the > next steps for the WG. > Problem statements are there to do exaclty this: indentify next steps for a WG. So what do you mean by "we pass(ed) this stage"? cheers Emmanuel _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Sep 10 02:30:00 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B0B03A6D48; Wed, 10 Sep 2008 02:30:00 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D72073A6D48 for ; Wed, 10 Sep 2008 02:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.068 X-Spam-Level: X-Spam-Status: No, score=-6.068 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQW3PE60TKL8 for ; Wed, 10 Sep 2008 02:29:58 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 9DA2D3A68CD for ; Wed, 10 Sep 2008 02:29:57 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id m8A9TFrQ015254 for ; Wed, 10 Sep 2008 10:29:15 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id m8A9TFd2022600 for ; Wed, 10 Sep 2008 10:29:15 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 10 Sep 2008 10:29:15 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 10 Sep 2008 10:29:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 10 Sep 2008 10:29:17 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Roll] draft-ietf-roll-protocols-survey-00 thread-index: AckTJ7InwxTsZVnaQsugZElgy8I1Ew== From: "Dearlove, Christopher (UK)" To: X-OriginalArrivalTime: 10 Sep 2008 09:29:15.0278 (UTC) FILETIME=[B11B52E0:01C91327] Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org (Apologies if this doesn't thread properly, it's from a posting before I subscribed.) Philip Levis wrote: > Emmanuel Baccelli wrote: >> - OLSR is said to "fail" the "control cost" criteria. However, simple >> fisheye TTL strategy on OLSR control messages makes OLSR "pass" this >> criteria. See this paper "Fish Eye OLSR Scaling Properties" in Journal >> of Communication and Networks, 2004. Actually this paper even proves >> that OLSR can thus reach the Gupta and Kumar bounds in terms of >> control >> overhead scalability. > I think it's important to have a clear line defining what sufficiently > demonstrates properties of a protocol. I think the paper has some > interesting ideas, but it isn't a protocol specification, nor does it > demonstrate a working protocol with real wireless behavior (e.g., link > dynamics). The OLSRv2 protocol specification allows the use of the Fisheye property (also see Fuzzy/Hazy Sighted Link State routing) as part of its specification. It does however leave it entirely up to the implementor/user how to use it (i.e. how to use a suitable - and what is suitable is defined - pattern of hop limits). In OLSRv1 it isn't specified in RFC 3626, just hooks are there (mostly, there is a detail in which using fisheye in unmodified OLSRv1 has a problem - not a showstopper, but a "should be better" and OLSRv2 has it better). > Do you have running code? Yes. Code that runs in simulation and on real hardware. However I've currently only run the fisheye in small simulated networks. -- Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** 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. ******************************************************************** _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Sep 10 02:31:00 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39F5E28C1F2; Wed, 10 Sep 2008 02:31:00 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840FB28C1F2 for ; Wed, 10 Sep 2008 02:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0-b7eOn39Bs for ; Wed, 10 Sep 2008 02:30:57 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 0FF1A28C1E8 for ; Wed, 10 Sep 2008 02:30:56 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id m8A95ZI5004527 for ; Wed, 10 Sep 2008 10:05:35 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id m8A95Z8r007345 for ; Wed, 10 Sep 2008 10:05:35 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 10 Sep 2008 10:05:35 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 10 Sep 2008 10:05:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 10 Sep 2008 10:05:30 +0100 Message-ID: In-Reply-To: <48C78748.4090605@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 thread-index: AckTIIiZzdrLzo+fQjW8BABPCwhLeQAABumQ References: <48C78748.4090605@inria.fr> From: "Dearlove, Christopher (UK)" To: X-OriginalArrivalTime: 10 Sep 2008 09:05:35.0059 (UTC) FILETIME=[62971A30:01C91324] Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org (Apologies if this doesn't thread properly, it's from a posting before I subscribed.) francois2.jan at orange-ftgroup.com wrote: > Theoretically link hysteresis solution solves the issue of bad links. In practice, link hysteresis is not very efficient > for at least 2 reasons. The link hysteresis solution is based on the reception of hello packets It doesn't have to be. OLSR (RFC 3626) only discusses use of HELLO packets as an option. OLSRv2 is similar, but leaves some options more open. > which are generally sent at lower throughput than data packets because hello packets are sent in broadcast. So hello > packets have more chance to be received than data packets (see "grey zone" issue), First note that the grey zone issue isn't universal - it arises for 802.11 because broadcast packets are sent at a lower data rate than unicast packets. It will however be an issue for any lower layers standard that does the same. And that points to where you really want information to base your hysteresis solutions on - from lower layers. In a radio-based system not having/using such information is never going to do as well as you should be able to. Use of signal to noise ratio to base the link quality in OLSRv1/v2 works well in 802.11 systems, provided your driver software gives you access to it. > all the more so OLSR tends to minimize the number of hops and so tends to choice the worst links. That's a reason why, in 802.11 (and similar) systems at least you need something more. The link quality mechanism in RFC 3626, and as in current OLSRv2, is one approach that does make things work. An alternative solution is full-blown link metrics. This is actually where what others have called the "infamous table" is actually generous to OLSRv2 - while I don't agree with all of the Fails (putting aside whether I agree with the metholodology), the Passes for metrics are generous, I would have said ? with an agreement at the last IETF to move to Pass, because we should be adding link metrics to OLSRv2. > Furthermore, the packet loss is mainly due to the SINR variation which can be very huge depending on the material and > the environment and link quality determined by link hysteresis can be in phase difference with the SNR variation. I think this is misusing the term hysteresis, but I think that derives from RFC 3626. I hope the OLSRv2 draft is clearer. There are two things to be separated out - Link quality. That can be assessed by HELLO messages (with the limitations you note), or signal to noise ratio, or other possibilities. - Hysteresis. That you can't just flap the link on/off according to the latest link quality, you need to constrain that. The two threshold approach in OLSRv1/v2 is its implementation of hysteresis. "Link quality determined by link hysteresis" is thus confusing. But wordingh aside, yes, hysteresis can put a delay (I think that's a more useful view than phase, as cyclic behaviour is not the general case) on whether use or nor of a link matches actual SNR. That indicates engineering is needed. -- Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** 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. ******************************************************************** _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Sep 10 03:11:45 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37653A6AC1; Wed, 10 Sep 2008 03:11:45 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D6E13A6AC1 for ; Wed, 10 Sep 2008 03:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.172 X-Spam-Level: X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1tf-gsP-KTA for ; Wed, 10 Sep 2008 03:11:40 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 409143A677E for ; Wed, 10 Sep 2008 03:11:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,371,1217808000"; d="scan'208";a="20312019" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Sep 2008 10:11:43 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8AABhio012684; Wed, 10 Sep 2008 06:11:43 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8AABgf4009170; Wed, 10 Sep 2008 10:11:42 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Sep 2008 06:11:42 -0400 Received: from 10.61.101.222 ([10.61.101.222]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 10 Sep 2008 10:11:42 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 10 Sep 2008 12:11:39 +0200 From: JP Vasseur To: Emmanuel Baccelli , Message-ID: Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 Thread-Index: AckTLZ1Ixtr2d5LNK0W8Idd0P9NvmA== In-Reply-To: <48C78748.4090605@inria.fr> Mime-version: 1.0 X-OriginalArrivalTime: 10 Sep 2008 10:11:42.0935 (UTC) FILETIME=[9FA0EE70:01C9132D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=963; t=1221041503; x=1221905503; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20draft-ietf-roll-protocols-surv ey-00 |Sender:=20 |To:=20Emmanuel=20Baccelli=20,= 20; bh=gCkm7U8gxRywHc08K+E7LDKYI/ZtEZoFzpnL/uMG2eI=; b=rjpuKcEBhOjmrwFWRLeTX1j4wro/HsMNsBRGn5U4XREFZ4S5rX8I2vJpZi HX/QBOL0IeirL35IAzYyhKX2Ec/kpKFgRqnc0xwdXGOc8+mxzaiAWI+XPYiI +bIuI6o2+7; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, On 9/10/08 10:37 AM, "Emmanuel Baccelli" wrote: > Hi JP, > > Do you also agree with the points mentionned in my previous email? > As stated in my previous email, yes I agree with some of them. > Moreover, what do you mean exactly by your comment below? > > >>> I guess that this survey >>> serves as some kind of "problem statement" for the ROLL working group. >> >> We fortunately pass that stage. The aim of this document is to determine the >> next steps for the WG. >> > > Problem statements are there to do exaclty this: indentify next steps > for a WG. JP> Problem statements are usually used to scope the WG. So what do you mean by "we pass(ed) this stage"? JP> ROLL is very much well-scoped ;-) Thanks. JP. > > cheers > Emmanuel > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Sep 10 03:13:18 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE36F3A68B9; Wed, 10 Sep 2008 03:13:18 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 515033A68B9 for ; Wed, 10 Sep 2008 03:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tbo1wQNj1iUE for ; Wed, 10 Sep 2008 03:13:17 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E801D3A677E for ; Wed, 10 Sep 2008 03:13:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,371,1217808000"; d="scan'208";a="20286918" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Sep 2008 10:13:10 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8AADAi1016457; Wed, 10 Sep 2008 06:13:10 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8AADAXv028197; Wed, 10 Sep 2008 10:13:10 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Sep 2008 06:13:10 -0400 Received: from 10.61.101.222 ([10.61.101.222]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 10 Sep 2008 10:13:10 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 10 Sep 2008 12:13:07 +0200 From: JP Vasseur To: Emmanuel Baccelli , Message-ID: Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 Thread-Index: AckTLdG8RoSUXwzTxk28HLv/JmAw9g== In-Reply-To: <48C784E5.7060002@inria.fr> Mime-version: 1.0 X-OriginalArrivalTime: 10 Sep 2008 10:13:10.0690 (UTC) FILETIME=[D3EF4820:01C9132D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6233; t=1221041590; x=1221905590; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20draft-ietf-roll-protocols-surv ey-00 |Sender:=20 |To:=20Emmanuel=20Baccelli=20,= 20; bh=Lehh4+rP9rHQASDDo7f9MQwreJcg0x7CHIgGrgFUivM=; b=n3rvSUmKbkPKcBOy+m7Il6MEr6Ve85tWQ+eRLbUof33vNAq5Iodiw0YdSO A21weSDFPUHCF7VyTP6nfaVrNuYOAE4ZQNODAVZfo95InpE2YvqeQh3LIn6Q x0/6VPPEox; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, On 9/10/08 10:27 AM, "Emmanuel Baccelli" wrote: > Hi Arsalan, > = > OK. I think we basically agree on these three points: > = > = > 1 - the methodology of the draft should be more transparent. > = > 2 - overall, it should be clearer that the draft does not take a > position on whether a new protocol is needed or whether an existing > protocol can be extended. The aim of the document IS to help determine whether a new protocol is needed. The outcome of the WG decision will be documented in a separate ID. > = > 3 - the evaluation of mentionned RFCs, drafts and related on-going > activities in other IETF WGs should be more precise. Do not hesitate to propose text. Thanks. JP. > = > = > Cheers, > Emmanuel > = > = > = > Arsalan Tavakoli a =E9crit : >> I would just like to follow-up on what some others have been saying. >> In terms of scope, I think the purpose of this document was to provide >> a baseline benchmark of the suitability of the discussed protocols for >> L2N applications. The criteria and quantitative benchmarks were >> culled from the application requirement documents, but admittedly can >> be more clearly stated in the draft rather than just simple >> references. As far as the set of extensions/twists/etc., I would >> argue the following two points: first, the set of all these is >> immense, at least to the point that it is not practical to include >> them all in a single survey. Second, it's not quite clear what's an >> extension, and what's a reworking. If I take one of the protocols, >> and completely change its concept of link estimation and path >> calculation, that is in essence twisting it into a new protocol. As >> Phil has pointed out, the RFCs are a much more precise specification >> than an academic paper or code, which allows us to go through the >> process of theoretically verifying bounds and performances. The >> unique requirements of L2N networks (which prompted such a document in >> the first place), make it very difficult to hypothesize how existing >> performance studies would be affected by L2N specific conditions. >> Granted that the justifications can be lengthier and any inaccuracies >> should be cleaned up, but the purpose of the table is to provide a >> strict evaluation of the protocol RFCs, which serve to provide a >> starting point for discussions such as the one on this list, and allow >> subsequent drafts to detail specific extensions or modifications that >> can address shortcomings of the RFC (according to the criteria in this >> survey) in a much more focused manner. This draft absolutely does not >> take a position on whether a new protocol is needed or whether >> extensions can address all the requirements. However, if all >> extensions and code and tweaks were included in the evaluation, due to >> the sheer quantity and imprecision/uncertainty of those >> specifications, we would end up with a table filled with all "?'s" or >> passes, which I argue would make it essentially useless. >> = >> Thanks for all the comments; they have been quite helpful in >> highlighting things in the draft that need to be clarified. >> = >> Arsalan >> = >> On Tue, Sep 9, 2008 at 8:46 AM, Philip Levis wrote: >>> On Sep 8, 2008, at 2:50 PM, Stephen Dawson-Haggerty wrote: >>> = >>>> Other then the comments about inaccuracies and a lack of detail in >>>> Annex A, it seems like we're still debating the scope of the >>>> document, as Phil said. We don't want to consider arbitrary >>>> protocol modifications and extensions because they aren't generally >>>> full protocol specifications and so couldn't usually be adopted >>>> without further work. >>>> = >>>> The analysis presented in the draft isn't based particularly on >>>> studies of actual protocol performance, although we did look at >>>> those where they did exist (I remember at least AODV and TBRPF have >>>> them). I suppose this makes it more theoretical then practical; the >>>> issue is that it's going to be difficult if not impossible to >>>> compare the different studies in the literature due to differing >>>> methodology, incomplete implementations, etc. This could be made >>>> more clear, and we can provide references to these external studies. >>> Thanks for articulating this much better than I did, Stephen. It's not >>> that running code is necessary for an understanding of a protocol; >>> rather, a precise specification is. RFCs and other standardization >>> documents can meet this requirement, as can running code. But I'm >>> uncomfortable with simulations based on simplified wireless models >>> being sufficient; practice has shown us time and time again that the >>> real complexities (and costs) come from all of the tricky edge cases >>> which rarely emerge in simplified environments. I can read RFC 3561 >>> and think through what will happen when a link is bursty; I'm not sure >>> I can with most academic papers, as they (due to space concerns) are >>> often forced to elide the details which would let a reader do the same. >>> = >>>> One thing I would suggest is to make the guidance and lessons about >>>> figure design more explicit and concrete, and to do it by citing >>>> mechanism examples from the protocols we examined. This might help >>>> address some of the concerns raised while keeping the document >>>> within scope. >>> This is a great idea. It's clear from this discussion that the >>> document needs to be clearer on its methodology and why that >>> methodology is used. Our initial intention had been to make it very >>> concise and factual rather than explanatory. >>> = >>> Phil >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> = >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> = >> = > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Sep 10 03:33:05 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9BF28C0FB; Wed, 10 Sep 2008 03:33:05 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DEC83A6B0C for ; Wed, 10 Sep 2008 03:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.705 X-Spam-Level: X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhgKH+yhJ66F for ; Wed, 10 Sep 2008 03:32:59 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id 9799B3A6879 for ; Wed, 10 Sep 2008 03:32:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,371,1217800800"; d="scan'208";a="29012581" Received: from sphinx.lix.polytechnique.fr (HELO BoolfightMaN-Laptop.local) ([129.104.11.1]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Sep 2008 12:33:01 +0200 Message-ID: <48C7A25D.1040408@inria.fr> Date: Wed, 10 Sep 2008 12:33:01 +0200 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi JP, please see inline. JP Vasseur a =E9crit : >> >> Do you also agree with the points mentionned in my previous email? >> > = > As stated in my previous email, yes I agree with some of them. > = Well, since we now boiled down to 3 simple items, it would be better if = you stated again which item(s) you disagree with, and why. I had the = impression we basically agreed on all of them. >> Moreover, what do you mean exactly by your comment below? >> >>>> I guess that this survey >>>> serves as some kind of "problem statement" for the ROLL working group. >>> We fortunately pass that stage. The aim of this document is to determin= e the >>> next steps for the WG. >>> >> Problem statements are there to do exaclty this: indentify next steps >> for a WG. = > = > JP> Problem statements are usually used to scope the WG. > = > So what do you mean by "we pass(ed) this stage"? > = > JP> ROLL is very much well-scoped ;-) > = Problem statements usually say something like: "we have a target scenario, and the tools curently available or in = development are not enough because... So what do we do?". Isn't it exactly what draft-ietf-roll-protocols-survey is about? The target scenario may already be clear to some, but people in general = do not see why the protocols curently available or in development are = not up to the task. And this is why a document such as = draft-ietf-roll-protocols-survey is needed. Isn't it so? Or am I missing = something here? Regards, Emmanuel _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Sep 10 03:41:44 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966E228C0EC; Wed, 10 Sep 2008 03:41:44 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0723A6B0C for ; Wed, 10 Sep 2008 03:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaGjc8SlHkGT for ; Wed, 10 Sep 2008 03:41:41 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 802E43A6852 for ; Wed, 10 Sep 2008 03:41:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,371,1217808000"; d="scan'208";a="20288356" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Sep 2008 10:41:46 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8AAfkpM021330; Wed, 10 Sep 2008 06:41:46 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8AAfkgm004399; Wed, 10 Sep 2008 10:41:46 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Sep 2008 06:41:46 -0400 Received: from 10.61.101.222 ([10.61.101.222]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 10 Sep 2008 10:41:45 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 10 Sep 2008 12:41:44 +0200 From: JP Vasseur To: Emmanuel Baccelli , Message-ID: Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 Thread-Index: AckTMdElViFvZvtLAUyixRv563z96Q== In-Reply-To: <48C7A25D.1040408@inria.fr> Mime-version: 1.0 X-OriginalArrivalTime: 10 Sep 2008 10:41:46.0100 (UTC) FILETIME=[D2661340:01C91331] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3336; t=1221043306; x=1221907306; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20draft-ietf-roll-protocols-surv ey-00 |Sender:=20 |To:=20Emmanuel=20Baccelli=20,= 20; bh=mGcC/wirTJl0+iwARZP+yRWFQtEnrM8ArNnSnfpZv0M=; b=UXzwbZKHpZd5YCUt6s9oTGHeXgGjf2evzbHP+VQoXLJpeuLuoC7DShBVSo JlyhSH1bvb+Om2/HcpSUZvCOJeeMi48otysCbZdFgdQS9nzisRHOXuJrJg4W hc9nRoDiTh; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Emmanuel, First of all, there are no strong disagreements here, just (important) clarifications. On 9/10/08 12:33 PM, "Emmanuel Baccelli" wrote: > Hi JP, > please see inline. > = > = > JP Vasseur a =E9crit : >>> = >>> Do you also agree with the points mentionned in my previous email? >>> = >> = >> As stated in my previous email, yes I agree with some of them. >> = > = > Well, since we now boiled down to 3 simple items, it would be better if > you stated again which item(s) you disagree with, and why. I had the > impression we basically agreed on all of them. 1 - the methodology of the draft should be more transparent. JP> I would not say "transparent" but sure it is worth detailing the methodology. Please do not hesitate to propose text. 2 - overall, it should be clearer that the draft does not take a position on whether a new protocol is needed or whether an existing protocol can be extended. JP> As I said before, the aim of this draft is to draw a conclusion and hopefully have a consensus. Please note that the evaluation is made in light of the requirements spelled out in the application specific requirements IDs. This is particularly important ... We're not "evaluating" protocols in general but in light of specific requirements. 3 - the evaluation of mentionned RFCs, drafts and related on-going activities in other IETF WGs should be more precise. JP> Not quite correct. Evaluation of RFCs/drafts, yes but we are not chartered to give an overview of other WG activities. > = > = > = >>> Moreover, what do you mean exactly by your comment below? >>> = >>>>> I guess that this survey >>>>> serves as some kind of "problem statement" for the ROLL working group. >>>> We fortunately pass that stage. The aim of this document is to determi= ne >>>> the >>>> next steps for the WG. >>>> = >>> Problem statements are there to do exaclty this: indentify next steps >>> for a WG. = >> = >> JP> Problem statements are usually used to scope the WG. >> = >> So what do you mean by "we pass(ed) this stage"? >> = >> JP> ROLL is very much well-scoped ;-) >> = > = > Problem statements usually say something like: > = > "we have a target scenario, and the tools curently available or in > development are not enough because... So what do we do?". > = > Isn't it exactly what draft-ietf-roll-protocols-survey is about? > = > The target scenario For the target scenario, see the requirements IDs. may already be clear to some, but people in general > do not see why the protocols curently available or in development are > not up to the task. And this is why a document such as > draft-ietf-roll-protocols-survey is needed. Isn't it so? Or am I missing > something here? I do not think that we need to argue on what a problem statement is. The point I was trying to make is that we passed the stage to understand why we have a WG. The aim of this document is to provide an evaluation of the existing routing protocol *in light* of the requirements ID and draw a consensus. Thanks. JP. > = > Regards, > Emmanuel > = > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Sep 10 04:37:23 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D783A6B0C; Wed, 10 Sep 2008 04:37:23 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE9E3A6AA7 for ; Wed, 10 Sep 2008 04:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Apbt1vVSmRnQ for ; Wed, 10 Sep 2008 04:37:22 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id C096E3A69C4 for ; Wed, 10 Sep 2008 04:37:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,372,1217800800"; d="scan'208";a="29014866" Received: from sphinx.lix.polytechnique.fr (HELO BoolfightMaN-Laptop.local) ([129.104.11.1]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Sep 2008 13:37:13 +0200 Message-ID: <48C7B169.9090509@inria.fr> Date: Wed, 10 Sep 2008 13:37:13 +0200 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi JP, JP Vasseur a =E9crit : > Hi Emmanuel, > = > 1 - the methodology of the draft should be more transparent. > = > JP> I would not say "transparent" but sure it is worth detailing the > methodology. Please do not hesitate to propose text. > = OK I guess we agree about this point then. > 2 - overall, it should be clearer that the draft does not take a > position on whether a new protocol is needed or whether an existing > protocol can be extended. > = > JP> As I said before, the aim of this draft is to draw a conclusion and > hopefully have a consensus. Please note that the evaluation is made in li= ght > of the requirements spelled out in the application specific requirements > IDs. This is particularly important ... We're not "evaluating" protocols = in > general but in light of specific requirements. > = This point is too fuzzy. In a previous post, you said that the = conclusion drawing was supposed to happen in a different draft. Now you = say it is supposed to happen in this draft. So it's either of the two, = but not both: (i) conclusion drawing is supposed to happen in a different draft. It = should thus be clear that draft-ietf-roll-protocols-survey does not take = a position on whether a new protocol is needed, or whether an existing = protocol can be extended. (ii) conclusion drawing is supposed to happen in = draft-ietf-roll-protocols-survey, and then it should be clear in the = draft that the different alternatives are being discussed, and in = particular the discussion whether a new protocol is needed, or whether = an existing protocol can be extended. What is it then? It should be cristal clear whether we place ourselves = in (i) XOR (ii) in order to avoid wasting time. > 3 - the evaluation of mentionned RFCs, drafts and related on-going > activities in other IETF WGs should be more precise. > = > JP> Not quite correct. Evaluation of RFCs/drafts, yes but we are not > chartered to give an overview of other WG activities. > = I guess WG activities are supposed to be documented in drafts ;) So we = agree here too. Cheers Emmanuel _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Sep 10 05:12:49 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09B6128C203; Wed, 10 Sep 2008 05:12:49 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9052428C203 for ; Wed, 10 Sep 2008 05:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.231 X-Spam-Level: X-Spam-Status: No, score=-6.231 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MjpvxL4k1cb for ; Wed, 10 Sep 2008 05:12:42 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id DDA3228C1F3 for ; Wed, 10 Sep 2008 05:12:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,372,1217808000"; d="scan'208";a="20320151" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Sep 2008 12:12:46 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8ACCk3O021891; Wed, 10 Sep 2008 08:12:46 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8ACCkO5028608; Wed, 10 Sep 2008 12:12:46 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Sep 2008 08:12:46 -0400 Received: from 10.61.101.222 ([10.61.101.222]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 10 Sep 2008 12:12:46 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 10 Sep 2008 14:12:39 +0200 From: JP Vasseur To: Emmanuel Baccelli , Message-ID: Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 Thread-Index: AckTPoSUU6lnc3dSkEOZ6rR1PfAgxw== In-Reply-To: <48C7B169.9090509@inria.fr> Mime-version: 1.0 X-OriginalArrivalTime: 10 Sep 2008 12:12:46.0800 (UTC) FILETIME=[893AC500:01C9133E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2761; t=1221048766; x=1221912766; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20draft-ietf-roll-protocols-surv ey-00 |Sender:=20 |To:=20Emmanuel=20Baccelli=20,= 20; bh=LKiq6yEIsq2Ty8mzSb653Bo88FUOv1M5JDr8cJZfQjM=; b=JxH1Llrl3xhjEyDdWuaKhgjAFxPOLV2V4NxPt/ZyDbWQhGtZemHip5/2/y 8uc3/wUiDJD5eMy42hymgXFw1ZzpJ1dzdJRaSP2s7u/Xku3YNsYC7d3uwM4A h1d+3b3dGy; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, On 9/10/08 1:37 PM, "Emmanuel Baccelli" wrote: > Hi JP, > = > JP Vasseur a =E9crit : >> Hi Emmanuel, >> = >> 1 - the methodology of the draft should be more transparent. >> = >> JP> I would not say "transparent" but sure it is worth detailing the >> methodology. Please do not hesitate to propose text. >> = > = > OK I guess we agree about this point then. > = >> 2 - overall, it should be clearer that the draft does not take a >> position on whether a new protocol is needed or whether an existing >> protocol can be extended. >> = >> JP> As I said before, the aim of this draft is to draw a conclusion and >> hopefully have a consensus. Please note that the evaluation is made in l= ight >> of the requirements spelled out in the application specific requirements >> IDs. This is particularly important ... We're not "evaluating" protocols= in >> general but in light of specific requirements. >> = > = > This point is too fuzzy. In a previous post, you said that the > conclusion drawing was supposed to happen in a different draft. Now you > say it is supposed to happen in this draft. Looks like we're quibbling on words ;-) The objective is this ID is to determine whether or not we can find a routing protocol that meets the specific requirements of ROLL. The final WG decision will be documented in a separate ID. So it's either of the two, > but not both: > = > (i) conclusion drawing is supposed to happen in a different draft. It > should thus be clear that draft-ietf-roll-protocols-survey does not take > a position on whether a new protocol is needed, or whether an existing > protocol can be extended. > = > (ii) conclusion drawing is supposed to happen in > draft-ietf-roll-protocols-survey, and then it should be clear in the > draft that the different alternatives are being discussed, and in > particular the discussion whether a new protocol is needed, or whether > an existing protocol can be extended. > = > What is it then? It should be cristal clear whether we place ourselves > in (i) XOR (ii) in order to avoid wasting time. I hopefully clarified. Cheers, JP. > = > = >> 3 - the evaluation of mentionned RFCs, drafts and related on-going >> activities in other IETF WGs should be more precise. >> = >> JP> Not quite correct. Evaluation of RFCs/drafts, yes but we are not >> chartered to give an overview of other WG activities. >> = > = > I guess WG activities are supposed to be documented in drafts ;) So we > agree here too. > = > = > Cheers > Emmanuel > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Sep 10 07:34:10 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC5028C264; Wed, 10 Sep 2008 07:34:10 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CEA528C258 for ; Wed, 10 Sep 2008 07:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.135 X-Spam-Level: X-Spam-Status: No, score=-4.135 tagged_above=-999 required=5 tests=[AWL=-1.760, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjUvOoV8o280 for ; Wed, 10 Sep 2008 07:33:51 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BBCFF28C26F for ; Wed, 10 Sep 2008 07:33:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,372,1217808000"; d="scan'208,217";a="20314688" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Sep 2008 14:33:55 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8AEXt2V010768; Wed, 10 Sep 2008 10:33:55 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8AEXtNu003483; Wed, 10 Sep 2008 14:33:55 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Sep 2008 10:33:55 -0400 Received: from 10.61.82.35 ([10.61.82.35]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 10 Sep 2008 14:33:55 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 10 Sep 2008 16:01:28 +0200 From: JP Vasseur To: , Kris Pister , "Pascal Thubert (pthubert)" , , Message-ID: Thread-Topic: Detailed Review of draft-ietf-roll-indus-routing-reqs Thread-Index: AckTTbgqoQKRXfGitUeUUNsgwdH72Q== Mime-version: 1.0 X-OriginalArrivalTime: 10 Sep 2008 14:33:55.0741 (UTC) FILETIME=[411C9CD0:01C91352] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=35784; t=1221057235; x=1221921235; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Detailed=20Review=20of=20draft-ietf-roll-indus- routing-reqs |Sender:=20 |To:=20,=20Kris=20Pister=20,=0A=20=20=20=20=20=20=20=20=22Pascal=20Thubert=20( pthubert)=22=20,=0A=20=20=20=20=20=20=20 =20,=20; bh=tD6dToa0QrjJ99PnwjWSm2dCH1hOflORbD2oG58qhY0=; b=lXKYJleQNJBPDUAHUWoTUQn3Cjixa3mvwlfKVwmo2vXLpUH+nSLeeRkwmR ofq2ZLmFbOycuAxF4uWqeBjdjJ/UGLxs2hinEPcdsLDoeWhPKMnzROGA/vuC OpJ9bVw28o; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [Roll] Detailed Review of draft-ietf-roll-indus-routing-reqs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0002907567==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0002907567== Content-type: multipart/alternative; boundary="B_3303909233_29860354" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3303909233_29860354 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, After the review of draft-ietf-roll-urban-routing-reqs and draft-ietf-roll-home-routing-reqs (new revision coming soon according to their authors), here is my review of draft-ietf-roll-indus-routing-reqs (lots of excellent content). 1) Abstract and Section 2 For wireless devices to have a significant advantage over wired devices in an industrial environment the wireless network needs to have three qualities: low power, high reliability, and easy installation and maintenance. JP> I would propose not to =B3oppose=B2 wireless and wired devices. Indeed, sensor networks will more than likely be interconnected by a variety of links. Still those networks will be LLN and will require these three qualities. I would then suggest to keep the list of qualities but generaliz= e it to devices in LLN. 2) s/L2N/LLN in the entire document (to match the ROLL charter). I still owe the WG a terminology ID (will be done early next week). 3) I skip the terminology section since it will addressed in the terminolog= y ID.=20 4) Introduction Referring to: =B3Wireless field devices enable expansion of networked points by appreciably reducing cost of installing a device. The cost reductions come from eliminating cabling costs and simplified planning. Cabling also carries an overhead cost associated with planning the installation, determining where the cable has to run, and interfacing with the various organizations required to coordinate its deployment. Doing away with the network and power cables reduces the planning and administrative overhead of installing a device.=B2 JP> This is a bit arguable ... (look at PLC) and not really a technical consideration. I would suggest to simply remove this paragraph. 5) Section 2 * =B3wired HART=B2 please add a informative reference. 6) s/=B2In the near future, most low power and lossy network systems will be for low frequency data collection.=B2/=B2In the near future, most low power and lossy network systems in industrial automation environments will be for low frequency data collection.=B2 7) In several places, you make the assumption that the collected data is sent to a Sink/... Residing outside of the LLN. Don=B9t you see cases where there will be intra-LLN flows in Industrial automation ? And I just read: =B3 In the future, it is envisioned that some open loop processes will be automated (closed loop) and packets will flow over local loops and not involve the L2N access point. =B3 - Thanks. 8) you wrote: =B3More likely though is that loops will be closed in the field entirely, which in most cases eliminates the need for having wireless links within the control loop.=B2 Why does this eliminate the need for wireless links ? 9) =B3L2N-ish=B2 ... You may want to slighlty reword here ;-) 10) s/=B2maximum number of hops from two to twenty.=B2/=B2maximum number of hops of twenty=B2 11) Section 2.2 You wrote: =B3 The backbone is a high-speed infrastructure network that may interconnect multiple WSNs through backbone routers. Infrastructure devices can be connected to the backbone. A gateway / manager that interconnects the backbone to the plant network of the corporate network can be viewed as collapsing the backbone and the infrastructure devices into a single device that operates all the required logical roles. The backbone is likely to become an important function of the industrial network.=B2 Although I do agree that this is a common architecture, you may want to indicate that this is only one possible architecture. 12) Could you please use a coherent terminology throughout the document ? L2N sensor, field devices, ... I=B9ll try to write the terminology ID this week, then thanks to align the terminology. 13) I found this section is bit out of the scope: =B3This multiple domain multiple applications connectivity creates a significant challenge. Many different applications will all share the same medium, the ether, within the fence, preferably sharing the same frequency bands, and preferably sharing the same protocols, preferably synchronized to optimize co-existence challenges, yet logically segregated to avoid creation of intolerable short cuts between existing wired domains. Given this challenge, L2N networks are best to be treated as all sitting on yet another segregated domain, segregated from all other wired domains where conventional security is organized by perimeter. Moving away from the traditional perimeter security mindset means moving towards stronger end-device identity authentication, so that L2N access points can split the various wireless data streams and interconnect back to the appropriate domain pending identity and trust established by the gateways in the authenticity of message originators.=B2 14) Question about Figure 1: it looks like we still do have to compute routes within the LLN ? Furthermore, thanks to mention that this is one of many potential architectures. For example, in section 2.2.2 you wrote =B32.2.2. Logical Topologies Most of the traffic over the LLN is publish/subscribe of sensor data from the field device towards the backbone router or gateway that acts as the sink for the WSN.=B2 You may want to replace the backbone router/gateway by a sink to make the statement more general and applicable to other topologies (without a gateway, ...). The use of gateway is a bit dangerous here unless carefully defined but we=B9ll discuss terminology in a separate email. 15) Section 2.2.2: =B3Since publishing the data is the raison d'etre for most of the sensors, it makes sense to build proactively a set of default routes between the sensors and one or more backbone router and maintain those routes at all times. Also, because of the lossy nature of the network, the routing in place should attempt to propose multiple forwarding solutions, building forwarding topologies in the form of Directed Acyclic Graphs oriented towards the sinks.=B2 Is it a requirement to be able to configure =B3default routes?=B2 By =B3multiple forwarding solutions=B2 do you actually means =B3multiple paths=B2 ? 16) Comment on =B3For these reasons, the ROLL routing infrastructure MUST be able to compute and update constrained routes on demand (that is reactively), and it can be expected that this model will become more prevalent for field device to field device connectivity as well as for some field device to Infrastructure devices over time.=B2 * you may want to move the MUST in the routing requirement sections, to hav= e them all in one place. * Are you requiring a reactive mechanism 17) Section 3. * =B3Service Requirement=B2 - You may want to change the title for =B3Traffic Characteristics=B2 just to avoid confusion with upper layer requirements. excellent paragraph * I=B9m not sure to see the rationale of the various bullets =B3data bandwidth=B2= , =B3Latency=B2, ... In this context of routing requirements. * You wrote =B3The routing protocol MUST be able to set up unidirectional or asymmetrical cost routes that are composed of one or more non congruent paths.=B2 You may want to reword this sentence, which may be misleading (in particular, there is no =B3or=B2 routes can be unidirectional and asymmetrical=B2). Did you mean =B3The routing protocol MUST be able to compute = a set of unidirectional routes with potentially different costs=B2. 18) Section 3.1 * S/ Time-varying user requirements for latency and bandwidth will require changes in the provisioning of the underlying L2 protocols/ Time-varying user requirements for latency and bandwidth may require changes in the provisioning of the underlying L2 protocols. * =B3The routing protocol MUST route on paths that are changed to appropriately provision the application requirements.=B2 JP> This should translate into =B3The routing protocol MUST dynamically recompute path if the underlying topology changes. =B3The routing protocol MUST support the ability to recompute paths based on underlying link characteristics that may change dynamically.=B2 JP> Could you be more accurate ? =B3What if the BER crosses some threshold?=B2. Should it trigger a path computation ? If so, you would need to list all parameters that can trigger a path computation. Alternatively, (IMO the prefered option) each of the link characteristic should be reflected in a metric or attribute change that will trigger a path computation (use filter= s of course).=20 19) Section 3.2. S/=B2The routing algorithm MUST be able to generate different routes for different flows.=B2/=B2The routing algorithm MUST be able to generate different routes with different characteritics (e.g. Optimized according to different cost, ...).=B2 20) Replace globally =B3low power lossy network=B2 by =B3LLN=B2. 21) Replace globally =B3#=B2 by =B3number=B2. 22) s/=B2 3) Probability of failure on demand,=B2/=B2 3) Probability of failure to compute an on demand route=B2 23) In the list of =B3Reliability Requirements=B2 you may want to add a =B3...=B2 since there are many other ones (ability to reroute upon a network failure, ...). 24) =B3Hop-by-hop path diversity is used to improve latency-bounded reliability.=B2 JP> Path diversity does not help with latency-bounded reliability ... It does help to increase packet delivery if you use a 1+1 technique, or to fin= d an alternate path or limit the proportion of flows impacted by a single failure but not for latency. What did you mean ? 25) =B3The routing protocol MUST support multiple L2N access points and load distribution among L2N access points. JP> In order to make this requirement not =B3topology dependent=B2 could you reword it =B3The routing protocol MUST be able to compute paths towards different destination so as to perform load balancing across a variety of paths.=B2 26) =B3The routing protocol MUST support multiple L2N access points when L2N access point redundancy is required.=B2 This is not a routing protocol requirement. 27) =B3Because L2Ns are lossy in nature, multiple paths in a L2N route MUST be supported. =B3 --> already stated. 28) Section 6: =B32) Delivery of common packets to multiple routers over a backbone, where the packets results in each receiving router initiating multicast (sometimes as a full broadcast) within the LLN. This is byproduct of having potentially physically separated backbone routers that can inject messages into different portions of the same larger LLN.=B2 JP> IMO a too solution-specific statement. 29) Section 7 * =B3The routing algorithm SHOULD always be in the process of optimizing the system in response to changing link statistics.=B2 JP> The term =B3optimizing=B2 is worth a few words of explanation. Optimizing with regards to which objective ? * =B3The routing algorithm MUST re-optimize the paths when field devices change due to insertion, removal or failure, and this re-optimization MUST not cause latencies greater than the specified constraints (typically seconds to minutes).=B2 Few comments here: (1) The first =B3MUST=B2 is not different than the basic requirement of being able to compute new path upon topology changes. (2) I would propose to carefully use the term =B3re-optimization=B2. Indeed, I guess that you refer to the event where a =B3shorter=B2 path is found according to some metrics. Then you are requiring the ability to switch to a shorter pat= h while bounding the latency, which requires to only switch if the delta between the old and new cost is also bounded and also implies other constraints. Indeed, in distributed systems, you cannot guarantee that systems are fully synchronized. Thus a router may start using a route that is not yet ready if some of the next hops have not converged yet, which may lead to micro-loops. Could you elaborate on this requirement ? 30)=20 * =B3The routing protocol SHOULD support the wireless worker with fast network connection times of a few of seconds, and low command and response latencies to the plant behind the L2N access points, to applications, and to field devices. =B3 Is it a different requirement than the one expressed in Section 7: =B3The routing algorithm MUST find the appropriate route(s) and report success or failure within several minutes, and SHOULD report success or failure within tens of seconds.=B2 * =B3The routing protocol SHOULD also support the bandwidth allocation for bulk transfers between the field device and the handheld device of the wireless worker. =B3 JP> of course, I see what you mean but this should either be removed or reworded. This may simply refer to topology changes, for which you already have a routing requirement or some cross-layer function (hope not). =B3The routing protocol SHOULD support walking speeds for maintaining network connectivity as the handheld device changes position in the wireless network. Some field devices will be mobile. These devices may be located on moving parts such as rotating components or they may be located on vehicles such as cranes or fork lifts. The routing protocol SHOULD support vehicular speeds of up to 35 kmph. =B3 JP> You may just want to say that such requirement has also consequences on non-routing functions. 31) Section 9 * =B3Therefore, the routing protocol MUST support auto-provisioning of field devices.=B2 JP> To which extent ? Does that mean a true 0-configuration routing protoco= l ? *=B2The protocol also MUST support the distribution of configuration from a centralized management controller if operator-initiated configuration change is allowed.=B2 JP> Not a routing requirement. Or do you refer to the dynamic set up of a =B3default DAG/Tree=B2 used to retrieve a more sophisticated =B3routing feature=B2 from a centralized tool ? 32) Section 10 * s/=B21) attacks on the actual application served be the wireless devices and =B3/=B21) attacks on the actual application served by the wireless devices and =B3 * =B32) attacks that exploit the presence of a wireless access point that MAY provide connectivity onto legacy wired plant networks, so attacks that have little to do with the wireless devices in the L2Ns. =B3/=B22) attacks that exploit the presence of a wireless access point that may provide connectivity onto legacy wired plant networks, so attacks that have little to do with the wireless devices in the LLNs. =B3 * =B3The routing protocol SHOULD place limited trust in the field devices deployed in the plant network. =B3 JP> Could you elaborate a little bit ? It sounds a bit too vague for a protocol designer to figure out what action to take according to this requirement.=20 =B3Standards exist that address those vulnerabilities.=B2 JP> ?? 33) replace =B3isn=B9t by is not=B2, =B3doesn=B9t by does not=B2 , ... Thanks. Cheers, JP. --B_3303909233_29860354 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Detailed Review of draft-ietf-roll-indus-routing-reqs Hi,

After the review of draft-ietf-roll-urban-routing-reqs and draft-ietf-roll-= home-routing-reqs (new revision coming soon according to their authors), her= e is my review of draft-ietf-roll-indus-routing-reqs (lots of excellent cont= ent).

1) Abstract and Section 2
      For wireless devices to have a signific= ant
   advantage over wired devices in an industrial environment= the
   wireless network needs to have three qualities: low power= , high
   reliability, and easy installation and maintenance.

JP> I would propose not to “oppose” wireless and wired devic= es. Indeed, sensor networks will more than likely be interconnected by a var= iety of links. Still those networks will be LLN and will require these three= qualities. I would then suggest to keep the list of qualities but generaliz= e it to devices in LLN.


2) s/L2N/LLN in the entire document (to match the ROLL charter).
I still owe the WG a terminology ID (will be done early next week).

3) I skip the terminology section since it will addressed in the terminolog= y ID.

4) Introduction

Referring to:
“Wireless field devices enable expansion of networked points by
   appreciably reducing cost of installing a device.  T= he cost
   reductions come from eliminating cabling costs and simpli= fied
   planning.  Cabling also carries an overhead cost ass= ociated with
   planning the installation, determining where the cable ha= s to run,
   and interfacing with the various organizations required t= o coordinate
   its deployment.  Doing away with the network and pow= er cables reduces
   the planning and administrative overhead of installing a = device.”

JP> This is a bit arguable ... (look at PLC) and not really a technical = consideration. I would suggest to simply remove this paragraph.

5) Section 2

* “wired HART” please add a informative reference.

6) s/”In t= he near future, most low power and lossy network systems will be
   for low frequency data collection.”/”In the n= ear future, most low power and lossy network systems in industrial automatio= n environments will be
   for low frequency data collection.”

7) In several places, you make the assumption that the collected data is se= nt to a Sink/... Residing outside of the LLN. Don’t you see cases wher= e there will be intra-LLN flows in Industrial automation ?
And I just read: “  In the future, it is envisioned that some op= en loop processes will be
   automated (closed loop) and packets will flow over local = loops and
   not involve the L2N access point. “ - Thanks.

8) you wrote: “More likely though is that loops will be closed in the= field
   entirely, which in most cases eliminates the need for hav= ing wireless
   links within the control loop.”
Why does this eliminate the need for wireless links ?

9) “L2N-ish” ... You may want to slighlty reword here ;-)

10) s/”maximum number of hops from two to twenty.”/”maxim= um number of hops of twenty”

11) Section 2.2

You wrote: “ The backbone is a high-speed infrastructure network that= may
   interconnect multiple WSNs through backbone routers. &nbs= p;Infrastructure
   devices can be connected to the backbone.  A gateway= / manager that
   interconnects the backbone to the plant network of the co= rporate
   network can be viewed as collapsing the backbone and the<= BR>    infrastructure devices into a single device that operates= all the
   required logical roles.  The backbone is likely to b= ecome an
   important function of the industrial network.”

Although I do agree that this is a common architecture, you may want to ind= icate that this is only one possible architecture.

12) Could you please use a coherent terminology throughout the document ? L= 2N sensor, field devices, ... I’ll try to write the terminology ID thi= s week, then thanks to align the terminology.

13) I found this section is bit out of the scope:

“This multiple domain multiple applications connectivity creates a    significant challenge.  Many different applications = will all share
   the same medium, the ether, within the fence, preferably = sharing the
   same frequency bands, and preferably sharing the same pro= tocols,
   preferably synchronized to optimize co-existence challeng= es, yet
   logically segregated to avoid creation of intolerable sho= rt cuts
   between existing wired domains.

   Given this challenge, L2N networks are best to be treated= as all
   sitting on yet another segregated domain, segregated from= all other
   wired domains where conventional security is organized by= perimeter.
   Moving away from the traditional perimeter security minds= et means
   moving towards stronger end-device identity authenticatio= n, so that
   L2N access points can split the various wireless data str= eams and
   interconnect back to the appropriate domain pending ident= ity and
   trust established by the gateways in the authenticity of = message
   originators.”

14) Question about Figure 1: it looks like we still do have to compute rout= es within the LLN ?
Furthermore, thanks to mention that this is one of many potential architect= ures. For example, in section 2.2.2 you wrote “2.2.2.  Logical To= pologies

   Most of the traffic over the LLN is publish/subscribe of = sensor data
   from the field device towards the backbone router or gate= way that
   acts as the sink for the WSN.”

You may want to replace the backbone router/gateway by a sink to make the s= tatement more general and applicable to other topologies (without a gateway,= ...). The use of gateway is a bit dangerous here unless carefully defined b= ut we’ll discuss terminology in a separate email.

15) Section 2.2.2: “Since publishing the data is the raison d'etre fo= r most of the
   sensors, it makes sense to build proactively a set of def= ault routes
   between the sensors and one or more backbone router and m= aintain
   those routes at all times.  Also, because of the los= sy nature of the
   network, the routing in place should attempt to propose m= ultiple
   forwarding solutions, building forwarding topologies in t= he form of
   Directed Acyclic Graphs oriented towards the sinks.”= ;

Is it a requirement to be able to configure “default routes?” By “multiple forwarding solutions” do you actually means “= ;multiple paths” ?

16) Comment on “For these reasons, the ROLL routing infrastructure MU= ST be able to
   compute and update constrained routes on demand (that is = reactively),
   and it can be expected that this model will become more p= revalent for
   field device to field device connectivity as well as for = some field
   device to Infrastructure devices over time.”

  • you may want to move the MUST in the routing= requirement sections, to have them all in one place.=20
  • <= SPAN STYLE=3D'font-size:10pt'>Are you requiring a reactive mechanism
=
17) Section 3.
* “Service Requirement” - You may want to change the title for = “Traffic Characteristics” just to avoid confusion with upper lay= er requirements. excellent paragraph
* I’m not sure to see the rationale of the various bullets “= ;data bandwidth”, “Latency”, ... In this context of routin= g requirements.
* You wrote “The routing protocol
   MUST be able to set up unidirectional or asymmetrical cos= t routes
   that are composed of one or more non congruent paths.R= 21;
You may want to reword this sentence, which may be misleading (in particula= r, there is no “or” routes can be unidirectional and asymmetrica= l”). Did you mean “The routing protocol MUST be able to compute = a set of unidirectional routes with potentially different costs”.

18) Section 3.1

* S/ Time-varying user requirements for latency and bandwidth will require<= BR>    changes in the provisioning of the underlying L2 protocol= s/ Time-varying user requirements for latency and bandwidth may require
   changes in the provisioning of the underlying L2 protocol= s.

*  “The routing protocol MUST route on paths that are changed to=
   appropriately provision the application requirements.R= 21;  

JP> This should translate into “The routing protocol MUST dynamica= lly recompute path if the underlying topology changes.

   “The routing
   protocol MUST support the ability to recompute paths base= d on
   underlying link characteristics that may change dynamical= ly.”

JP> Could you be more accurate ? “What if the BER crosses some thr= eshold?”. Should it trigger a path computation ? If so, you would need= to list all parameters that can trigger a path computation. Alternatively, = (IMO the prefered option) each of the link characteristic should be reflecte= d in a metric or attribute change that will trigger a path computation (use = filters of course).

19) Section 3.2.
S/”The routing algorithm MUST be able to
   generate different routes for different flows.”/= 221;The routing algorithm MUST be able to
   generate different routes with different characteritics (= e.g. Optimized according to different cost, ...).”

20) Replace globally “low power lossy network” by “LLN= 221;.

21) Replace globally “#” by “number”.

22) s/” 3)  Probability of failure on demand,”/” 3) =  Probability of failure to compute an on demand route”

23) In the list of “Reliability Requirements” you may want to a= dd a “...” since there are many other ones (ability to reroute u= pon a network failure, ...).

24) “Hop-by-hop path diversity is used to improve latency-bounded
   reliability.”

JP> Path diversity does not help with latency-bounded reliability ... It= does help to increase packet delivery if you use a 1+1 technique, or to fin= d an alternate path or limit the proportion of flows impacted by a single fa= ilure but not for latency. What did you mean ?

25) “The routing protocol MUST support multiple L2N access
   points and load distribution among L2N access points. &nb= sp;
JP> In order to make this requirement not “topology dependent̶= 1; could you reword it “The routing protocol MUST be able to compute p= aths towards different destination so as to perform load balancing across a = variety of paths.”

26) “The routing
   protocol MUST support multiple L2N access points when L2N= access
   point redundancy is required.”

This is not a routing protocol requirement.

27) “Because L2Ns are lossy in nature,
   multiple paths in a L2N route MUST be supported. “ = --> already stated.

28) Section 6:

“2)  Delivery of common packets to multiple routers over a backb= one,
       where the packets results in each= receiving router initiating
       multicast (sometimes as a full br= oadcast) within the LLN.  This
       is byproduct of having potentiall= y physically separated backbone
       routers that can inject messages = into different portions of the
       same larger LLN.”

JP> IMO a too solution-specific statement.

29) Section 7
* “The routing algorithm SHOULD always be in the process of
   optimizing the system in response to changing link statis= tics.”
JP> The term “optimizing” is worth a few words of explanatio= n. Optimizing with regards to which objective ?

* “The
   routing algorithm MUST re-optimize the paths when field d= evices
   change due to insertion, removal or failure, and this re-= optimization
   MUST not cause latencies greater than the specified const= raints
   (typically seconds to minutes).”
Few comments here: (1) The first “MUST” is not different than t= he basic requirement of being able to compute new path upon topology changes= . (2) I would propose to carefully use the term “re-optimization”= ;. Indeed, I guess that you refer to the event where a “shorter”= path is found according to some metrics. Then you are requiring the ability= to switch to a shorter path while bounding the latency, which requires to o= nly switch if the delta between the old and new cost is also bounded and als= o implies other constraints. Indeed, in distributed systems, you cannot guar= antee that systems are fully synchronized. Thus a router may start using a r= oute that is not yet ready if some of the next hops have not converged yet, = which may lead to micro-loops. Could you elaborate on this requirement ?

30)
* “The routing protocol SHOULD support the wireless worker with fast<= BR>    network connection times of a few of seconds, and low com= mand and
   response latencies to the plant behind the L2N access poi= nts, to
   applications, and to field devices.  “

Is it a different requirement than the one expressed in Section 7:

“The routing algorithm MUST find the appropriate
   route(s) and report success or failure within several min= utes, and
   SHOULD report success or failure within tens of seconds.&= #8221;


* “The routing protocol SHOULD also
   support the bandwidth allocation for bulk transfers betwe= en the field
   device and the handheld device of the wireless worker. &n= bsp; “

JP> of course, I see what you mean but this should either be removed or = reworded. This may simply refer to topology changes, for which you already h= ave a routing requirement or some cross-layer function (hope not).

“The routing
   protocol SHOULD support walking speeds for maintaining ne= twork
   connectivity as the handheld device changes position in t= he wireless
   network.

   Some field devices will be mobile.  These devices ma= y be located on
   moving parts such as rotating components or they may be l= ocated on
   vehicles such as cranes or fork lifts.  The routing = protocol SHOULD
   support vehicular speeds of up to 35 kmph.
“

JP> You may just want to say that such requirement has also consequences= on non-routing functions.

31) Section 9

* “Therefore,
   the routing protocol MUST support auto-provisioning of fi= eld devices.”

JP> To which extent ? Does that mean a true 0-configuration routing prot= ocol ?

*”The protocol also MUST support the distribution of configuration fr= om
   a centralized management controller if operator-initiated=
   configuration change is allowed.”

JP> Not a routing requirement. Or do you refer to the dynamic set up of = a “default DAG/Tree” used to retrieve a more sophisticated ̶= 0;routing feature” from a centralized tool ?

32) Section 10

* s/”1) attacks on the actual application served be the wireless
   devices and “/”1) attacks on the actual appli= cation served by the wireless
   devices and “

* “2) attacks that exploit the presence of a wireless access
   point that MAY provide connectivity onto legacy wired pla= nt networks,
   so attacks that have little to do with the wireless devic= es in the
   L2Ns. “/”2) attacks that exploit the presence= of a wireless access
   point that may provide connectivity onto legacy wired pla= nt networks,
   so attacks that have little to do with the wireless devic= es in the
   LLNs. “

* “The routing protocol SHOULD place limited trust in the field devic= es
   deployed in the plant network.
“

JP> Could you elaborate a little bit ? It sounds a bit too vague for a p= rotocol designer to figure out what action to take according to this require= ment.

“Standards exist that address those
   vulnerabilities.”

JP> ??

33) replace “isn’t by is not”, “doesn’t by do= es not” , ...

Thanks.

Cheers,

JP. --B_3303909233_29860354-- --===============0002907567== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0002907567==-- From roll-bounces@ietf.org Wed Sep 10 08:23:54 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8FAC3A6A94; Wed, 10 Sep 2008 08:23:54 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854353A6997 for ; Wed, 10 Sep 2008 08:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.432 X-Spam-Level: X-Spam-Status: No, score=-4.432 tagged_above=-999 required=5 tests=[AWL=-1.316, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxGc5PsGRuER for ; Wed, 10 Sep 2008 08:23:32 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id DCF8D3A6870 for ; Wed, 10 Sep 2008 08:23:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,373,1217808000"; d="scan'208,217";a="20347768" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Sep 2008 15:23:36 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8AFNar0011261; Wed, 10 Sep 2008 11:23:36 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8AFNaEU012976; Wed, 10 Sep 2008 15:23:36 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Sep 2008 11:23:36 -0400 Received: from 10.61.82.35 ([10.61.82.35]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 10 Sep 2008 15:23:36 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 10 Sep 2008 17:23:31 +0200 From: JP Vasseur To: JP Vasseur , , Kris Pister , "Pascal Thubert (pthubert)" , , Message-ID: Thread-Topic: [Roll] Detailed Review of draft-ietf-roll-indus-routing-reqs Thread-Index: AckTTbgqoQKRXfGitUeUUNsgwdH72QAC3ZWG In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 10 Sep 2008 15:23:36.0785 (UTC) FILETIME=[31F3D410:01C91359] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=42547; t=1221060217; x=1221924217; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Detailed=20Review=20of=20draft -ietf-roll-indus-routing-reqs |Sender:=20 |To:=20JP=20Vasseur=20,=20,=0A=20=20=20=20=20=20=20=20Kris=20Pister=20,=0A=20=20=20=20=20=20=20=20=22Pascal=20Thubert= 20(pthubert)=22=20,=0A=20=20=20=20=20=20 =20=20,=20; bh=XfoJSMkLzR0ljad1ZGc3tm56QsgWLLq7NphUmNvZbhM=; b=T4E65KLdIS/K14eo0t87S8FMYbfz1hIi2tjJwsS9DQcakkeGHPbwDzSChB BbvJV8eeeqbaQF78jd6LrUT10b+sRwmpmZZCMByBcjjuzkxREv8/qiJXnsYr xo+pUfZP8y; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Roll] Detailed Review of draft-ietf-roll-indus-routing-reqs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1135721488==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1135721488== Content-type: multipart/alternative; boundary="B_3303912212_30053634" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3303912212_30053634 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, Two more things:=20 1) Can you remove the following reference: draft-culler-rl2n-routing-reqs ? 2) idnits: Miscellaneous warnings: =20 ---------------------------------------------------------------------------= - =3D=3D Using lowercase 'not' together with uppercase 'MUST' is not an accepte= d usage according to RFC 2119. Please use 'MUST NOT' (if that is what you mean). =20 Found 'MUST not' in this paragraph: =20 Network connectivity in real deployments is always time varying, with time constants from seconds to months. So long as the underlying connectivity has not been compromised, this link churn should not substantially affect network operation. The routing algorithm MUST respond to normal link failure rates with routes that meet the Service requirements (especially latency) throughout the routing response. Th= e routing algorithm SHOULD always be in the process of optimizing the system in response to changing link statistics. The routing algorithm MUST re-optimize the paths when field devices change due to insertion, removal or failure, and this re-optimization MUST not cause latencies greater than the specified constraints (typically seconds to minutes). Checking references for intended status: Informational =20 ---------------------------------------------------------------------------= - =3D=3D Missing Reference: 'HART' is mentioned on line 1003, but not defined '[HART] www.hartcomm.org, "Highway Addressable Remote Transduc...' =3D=3D Unused Reference: 'I-D.culler-rl2n-routing-reqs' is defined on line 995, but no explicit reference was found in the text '[I-D.culler-rl2n-routing-reqs] Vasseur, J. and D. Cullerot, "Routing...' Thanks. JP. On 9/10/08 4:01 PM, "JP Vasseur" wrote: > Hi, >=20 > After the review of draft-ietf-roll-urban-routing-reqs and > draft-ietf-roll-home-routing-reqs (new revision coming soon according to = their > authors), here is my review of draft-ietf-roll-indus-routing-reqs (lots o= f > excellent content). >=20 > 1) Abstract and Section 2 > For wireless devices to have a significant > advantage over wired devices in an industrial environment the > wireless network needs to have three qualities: low power, high > reliability, and easy installation and maintenance. >=20 > JP> I would propose not to =B3oppose=B2 wireless and wired devices. Indeed, s= ensor > networks will more than likely be interconnected by a variety of links. S= till > those networks will be LLN and will require these three qualities. I woul= d > then suggest to keep the list of qualities but generalize it to devices i= n > LLN. >=20 >=20 > 2) s/L2N/LLN in the entire document (to match the ROLL charter). > I still owe the WG a terminology ID (will be done early next week). >=20 > 3) I skip the terminology section since it will addressed in the terminol= ogy > ID.=20 >=20 > 4) Introduction >=20 > Referring to: > =B3Wireless field devices enable expansion of networked points by > appreciably reducing cost of installing a device. The cost > reductions come from eliminating cabling costs and simplified > planning. Cabling also carries an overhead cost associated with > planning the installation, determining where the cable has to run, > and interfacing with the various organizations required to coordinate > its deployment. Doing away with the network and power cables reduces > the planning and administrative overhead of installing a device.=B2 >=20 > JP> This is a bit arguable ... (look at PLC) and not really a technical > consideration. I would suggest to simply remove this paragraph. >=20 > 5) Section 2 >=20 > * =B3wired HART=B2 please add a informative reference. >=20 > 6) s/=B2In the near future, most low power and lossy network systems will b= e > for low frequency data collection.=B2/=B2In the near future, most low powe= r and > lossy network systems in industrial automation environments will be > for low frequency data collection.=B2 >=20 > 7) In several places, you make the assumption that the collected data is = sent > to a Sink/... Residing outside of the LLN. Don=B9t you see cases where ther= e > will be intra-LLN flows in Industrial automation ? > And I just read: =B3 In the future, it is envisioned that some open loop > processes will be > automated (closed loop) and packets will flow over local loops and > not involve the L2N access point. =B3 - Thanks. >=20 > 8) you wrote: =B3More likely though is that loops will be closed in the fie= ld > entirely, which in most cases eliminates the need for having wireless > links within the control loop.=B2 > Why does this eliminate the need for wireless links ? >=20 > 9) =B3L2N-ish=B2 ... You may want to slighlty reword here ;-) >=20 > 10) s/=B2maximum number of hops from two to twenty.=B2/=B2maximum number of hop= s of > twenty=B2 >=20 > 11) Section 2.2 >=20 > You wrote: =B3 The backbone is a high-speed infrastructure network that may > interconnect multiple WSNs through backbone routers. Infrastructure > devices can be connected to the backbone. A gateway / manager that > interconnects the backbone to the plant network of the corporate > network can be viewed as collapsing the backbone and the > infrastructure devices into a single device that operates all the > required logical roles. The backbone is likely to become an > important function of the industrial network.=B2 >=20 > Although I do agree that this is a common architecture, you may want to > indicate that this is only one possible architecture. >=20 > 12) Could you please use a coherent terminology throughout the document ?= L2N > sensor, field devices, ... I=B9ll try to write the terminology ID this week= , > then thanks to align the terminology. >=20 > 13) I found this section is bit out of the scope: >=20 > =B3This multiple domain multiple applications connectivity creates a > significant challenge. Many different applications will all share > the same medium, the ether, within the fence, preferably sharing the > same frequency bands, and preferably sharing the same protocols, > preferably synchronized to optimize co-existence challenges, yet > logically segregated to avoid creation of intolerable short cuts > between existing wired domains. >=20 > Given this challenge, L2N networks are best to be treated as all > sitting on yet another segregated domain, segregated from all other > wired domains where conventional security is organized by perimeter. > Moving away from the traditional perimeter security mindset means > moving towards stronger end-device identity authentication, so that > L2N access points can split the various wireless data streams and > interconnect back to the appropriate domain pending identity and > trust established by the gateways in the authenticity of message > originators.=B2 >=20 > 14) Question about Figure 1: it looks like we still do have to compute ro= utes > within the LLN ? > Furthermore, thanks to mention that this is one of many potential > architectures. For example, in section 2.2.2 you wrote =B32.2.2. Logical > Topologies >=20 > Most of the traffic over the LLN is publish/subscribe of sensor data > from the field device towards the backbone router or gateway that > acts as the sink for the WSN.=B2 >=20 > You may want to replace the backbone router/gateway by a sink to make the > statement more general and applicable to other topologies (without a gate= way, > ...). The use of gateway is a bit dangerous here unless carefully defined= but > we=B9ll discuss terminology in a separate email. >=20 > 15) Section 2.2.2: =B3Since publishing the data is the raison d'etre for mo= st of > the > sensors, it makes sense to build proactively a set of default routes > between the sensors and one or more backbone router and maintain > those routes at all times. Also, because of the lossy nature of the > network, the routing in place should attempt to propose multiple > forwarding solutions, building forwarding topologies in the form of > Directed Acyclic Graphs oriented towards the sinks.=B2 >=20 > Is it a requirement to be able to configure =B3default routes?=B2 > By =B3multiple forwarding solutions=B2 do you actually means =B3multiple paths=B2= ? >=20 > 16) Comment on =B3For these reasons, the ROLL routing infrastructure MUST b= e > able to > compute and update constrained routes on demand (that is reactively), > and it can be expected that this model will become more prevalent for > field device to field device connectivity as well as for some field > device to Infrastructure devices over time.=B2 >=20 > * you may want to move the MUST in the routing requirement sections, to h= ave > them all in one place. > * Are you requiring a reactive mechanism >=20 > 17) Section 3. > * =B3Service Requirement=B2 - You may want to change the title for =B3Traffic > Characteristics=B2 just to avoid confusion with upper layer requirements. > excellent paragraph > * I=B9m not sure to see the rationale of the various bullets =B3data bandwidt= h=B2, > =B3Latency=B2, ... In this context of routing requirements. > * You wrote =B3The routing protocol > MUST be able to set up unidirectional or asymmetrical cost routes > that are composed of one or more non congruent paths.=B2 > You may want to reword this sentence, which may be misleading (in particu= lar, > there is no =B3or=B2 routes can be unidirectional and asymmetrical=B2). Did you= mean > =B3The routing protocol MUST be able to compute a set of unidirectional rou= tes > with potentially different costs=B2. >=20 > 18) Section 3.1 >=20 > * S/ Time-varying user requirements for latency and bandwidth will requir= e > changes in the provisioning of the underlying L2 protocols/ Time-varyi= ng > user requirements for latency and bandwidth may require > changes in the provisioning of the underlying L2 protocols. >=20 > * =B3The routing protocol MUST route on paths that are changed to > appropriately provision the application requirements.=B2 >=20 > JP> This should translate into =B3The routing protocol MUST dynamically > recompute path if the underlying topology changes. >=20 > =B3The routing > protocol MUST support the ability to recompute paths based on > underlying link characteristics that may change dynamically.=B2 >=20 > JP> Could you be more accurate ? =B3What if the BER crosses some threshold?= =B2. > Should it trigger a path computation ? If so, you would need to list all > parameters that can trigger a path computation. Alternatively, (IMO the > prefered option) each of the link characteristic should be reflected in a > metric or attribute change that will trigger a path computation (use filt= ers > of course).=20 >=20 > 19) Section 3.2. > S/=B2The routing algorithm MUST be able to > generate different routes for different flows.=B2/=B2The routing algorithm= MUST > be able to > generate different routes with different characteritics (e.g. Optimize= d > according to different cost, ...).=B2 >=20 > 20) Replace globally =B3low power lossy network=B2 by =B3LLN=B2. >=20 > 21) Replace globally =B3#=B2 by =B3number=B2. >=20 > 22) s/=B2 3) Probability of failure on demand,=B2/=B2 3) Probability of failu= re to > compute an on demand route=B2 >=20 > 23) In the list of =B3Reliability Requirements=B2 you may want to add a =B3...=B2 > since there are many other ones (ability to reroute upon a network failur= e, > ...). >=20 > 24) =B3Hop-by-hop path diversity is used to improve latency-bounded > reliability.=B2 >=20 > JP> Path diversity does not help with latency-bounded reliability ... It = does > help to increase packet delivery if you use a 1+1 technique, or to find a= n > alternate path or limit the proportion of flows impacted by a single fail= ure > but not for latency. What did you mean ? >=20 > 25) =B3The routing protocol MUST support multiple L2N access > points and load distribution among L2N access points. > JP> In order to make this requirement not =B3topology dependent=B2 could you > reword it =B3The routing protocol MUST be able to compute paths towards > different destination so as to perform load balancing across a variety of > paths.=B2 >=20 > 26) =B3The routing > protocol MUST support multiple L2N access points when L2N access > point redundancy is required.=B2 >=20 > This is not a routing protocol requirement. >=20 > 27) =B3Because L2Ns are lossy in nature, > multiple paths in a L2N route MUST be supported. =B3 --> already stated. >=20 > 28) Section 6: >=20 > =B32) Delivery of common packets to multiple routers over a backbone, > where the packets results in each receiving router initiating > multicast (sometimes as a full broadcast) within the LLN. This > is byproduct of having potentially physically separated backbone > routers that can inject messages into different portions of the > same larger LLN.=B2 >=20 > JP> IMO a too solution-specific statement. >=20 > 29) Section 7 > * =B3The routing algorithm SHOULD always be in the process of > optimizing the system in response to changing link statistics.=B2 > JP> The term =B3optimizing=B2 is worth a few words of explanation. Optimizing= with > regards to which objective ? >=20 > * =B3The > routing algorithm MUST re-optimize the paths when field devices > change due to insertion, removal or failure, and this re-optimization > MUST not cause latencies greater than the specified constraints > (typically seconds to minutes).=B2 > Few comments here: (1) The first =B3MUST=B2 is not different than the basic > requirement of being able to compute new path upon topology changes. (2) = I > would propose to carefully use the term =B3re-optimization=B2. Indeed, I gues= s > that you refer to the event where a =B3shorter=B2 path is found according to = some > metrics. Then you are requiring the ability to switch to a shorter path w= hile > bounding the latency, which requires to only switch if the delta between = the > old and new cost is also bounded and also implies other constraints. Inde= ed, > in distributed systems, you cannot guarantee that systems are fully > synchronized. Thus a router may start using a route that is not yet ready= if > some of the next hops have not converged yet, which may lead to micro-loo= ps. > Could you elaborate on this requirement ? >=20 > 30)=20 > * =B3The routing protocol SHOULD support the wireless worker with fast > network connection times of a few of seconds, and low command and > response latencies to the plant behind the L2N access points, to > applications, and to field devices. =B3 >=20 > Is it a different requirement than the one expressed in Section 7: >=20 > =B3The routing algorithm MUST find the appropriate > route(s) and report success or failure within several minutes, and > SHOULD report success or failure within tens of seconds.=B2 >=20 >=20 > * =B3The routing protocol SHOULD also > support the bandwidth allocation for bulk transfers between the field > device and the handheld device of the wireless worker. =B3 >=20 > JP> of course, I see what you mean but this should either be removed or > reworded. This may simply refer to topology changes, for which you alread= y > have a routing requirement or some cross-layer function (hope not). >=20 > =B3The routing > protocol SHOULD support walking speeds for maintaining network > connectivity as the handheld device changes position in the wireless > network. >=20 > Some field devices will be mobile. These devices may be located on > moving parts such as rotating components or they may be located on > vehicles such as cranes or fork lifts. The routing protocol SHOULD > support vehicular speeds of up to 35 kmph. > =B3 >=20 > JP> You may just want to say that such requirement has also consequences = on > non-routing functions. >=20 > 31) Section 9 >=20 > * =B3Therefore, > the routing protocol MUST support auto-provisioning of field devices.=B2 >=20 > JP> To which extent ? Does that mean a true 0-configuration routing proto= col ? >=20 > *=B2The protocol also MUST support the distribution of configuration from > a centralized management controller if operator-initiated > configuration change is allowed.=B2 >=20 > JP> Not a routing requirement. Or do you refer to the dynamic set up of a > =B3default DAG/Tree=B2 used to retrieve a more sophisticated =B3routing feature= =B2 > from a centralized tool ? >=20 > 32) Section 10 >=20 > * s/=B21) attacks on the actual application served be the wireless > devices and =B3/=B21) attacks on the actual application served by the wire= less > devices and =B3 >=20 > * =B32) attacks that exploit the presence of a wireless access > point that MAY provide connectivity onto legacy wired plant networks, > so attacks that have little to do with the wireless devices in the > L2Ns. =B3/=B22) attacks that exploit the presence of a wireless access > point that may provide connectivity onto legacy wired plant networks, > so attacks that have little to do with the wireless devices in the > LLNs. =B3 >=20 > * =B3The routing protocol SHOULD place limited trust in the field devices > deployed in the plant network. > =B3 >=20 > JP> Could you elaborate a little bit ? It sounds a bit too vague for a > protocol designer to figure out what action to take according to this > requirement.=20 >=20 > =B3Standards exist that address those > vulnerabilities.=B2 >=20 > JP> ?? >=20 > 33) replace =B3isn=B9t by is not=B2, =B3doesn=B9t by does not=B2 , ... >=20 > Thanks. >=20 > Cheers, >=20 > JP. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --B_3303912212_30053634 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Roll] Detailed Review of draft-ietf-roll-indus-routing-reqs</TI= TLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:13pt= '>Hi,<BR> <BR> Two more things: <BR> <BR> 1) Can you remove the following reference: draft-culler-rl2n-routing-reqs ?= <BR> <BR> 2) idnits:<BR> </SPAN></FONT><FONT SIZE=3D"1"><FONT FACE=3D"Courier, Courier New"><SPAN STYLE=3D= 'font-size:10pt'>  Miscellaneous warnings:<BR>   ---------------------------------------------------------------= -------------<BR> <BR>   =3D=3D Using lowercase 'not' together with uppercase 'MUST' is not = an accepted<BR>      usage according to RFC 2119.  Please use= 'MUST NOT' (if that is what you<BR>      mean).<BR>      <BR>      Found 'MUST not' in this paragraph:<BR>      <BR>      Network connectivity in real deployments is a= lways time varying,<BR>      with time constants from seconds to months. &= nbsp;So long as the underlying<BR>      connectivity has not been compromised, this l= ink churn should not<BR>      substantially affect network operation.  = ;The routing algorithm MUST<BR>      respond to normal link failure rates with rou= tes that meet the Service<BR>      requirements (especially latency) throughout = the routing response.  The<BR>      routing algorithm SHOULD always be in the pro= cess of optimizing the<BR>      system in response to changing link statistic= s.  The routing algorithm<BR>      MUST re-optimize the paths when field devices= change due to insertion,<BR>      removal or failure, and this re-optimization = MUST not cause latencies<BR>      greater than the specified constraints (typic= ally seconds to minutes).<BR> <BR> <BR>   Checking references for intended status: Informational<BR>   ---------------------------------------------------------------= -------------<BR> <BR>   =3D=3D Missing Reference: 'HART' is mentioned on line 1003, but not= <BR>      defined<BR>      '[HART]     www.hartcomm.= org, "Highway Addressable Remote Transduc...'<BR> <BR>   =3D=3D Unused Reference: 'I-D.culler-rl2n-routing-reqs' is defined = on line 995,<BR>      but no explicit reference was found in the<BR= >      text<BR>      '[I-D.culler-rl2n-routing-reqs] Vasseur, J. a= nd D. Cullerot, "Routing...'<BR> <BR> </SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN = STYLE=3D'font-size:13pt'><BR> <BR> Thanks.<BR> <BR> JP.<BR> <BR> <BR> On 9/10/08 4:01 PM, "JP Vasseur" <<a href=3D"jvasseur@cisco.com"= >jvasseur@cisco.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT SIZE=3D"1"><FONT FACE=3D"Courier, Courier New">= <SPAN STYLE=3D'font-size:10pt'>Hi,<BR> <BR> After the review of draft-ietf-roll-urban-routing-reqs and draft-ietf-roll-= home-routing-reqs (new revision coming soon according to their authors), her= e is my review of draft-ietf-roll-indus-routing-reqs (lots of excellent cont= ent).<BR> <BR> 1) Abstract and Section 2<BR>       For wireless devices to have a signific= ant<BR>    advantage over wired devices in an industrial environment= the<BR>    wireless network needs to have three qualities: low power= , high<BR>    reliability, and easy installation and maintenance. <BR> <BR> JP> I would propose not to “oppose” wireless and wired devic= es. Indeed, sensor networks will more than likely be interconnected by a var= iety of links. Still those networks will be LLN and will require these three= qualities. I would then suggest to keep the list of qualities but generaliz= e it to devices in LLN.<BR> <BR> <BR> 2) s/L2N/LLN in the entire document (to match the ROLL charter).<BR> I still owe the WG a terminology ID (will be done early next week).<BR> <BR> 3) I skip the terminology section since it will addressed in the terminolog= y ID. <BR> <BR> 4) Introduction<BR> <BR> Referring to:<BR> “Wireless field devices enable expansion of networked points by<BR>    appreciably reducing cost of installing a device.  T= he cost<BR>    reductions come from eliminating cabling costs and simpli= fied<BR>    planning.  Cabling also carries an overhead cost ass= ociated with<BR>    planning the installation, determining where the cable ha= s to run,<BR>    and interfacing with the various organizations required t= o coordinate<BR>    its deployment.  Doing away with the network and pow= er cables reduces<BR>    the planning and administrative overhead of installing a = device.”<BR> <BR> JP> This is a bit arguable ... (look at PLC) and not really a technical = consideration. I would suggest to simply remove this paragraph.<BR> <BR> 5) Section 2<BR> <BR> * “wired HART” please add a informative reference.<BR> <BR> </SPAN></FONT></FONT><FONT FACE=3D"Courier, Courier New"><SPAN STYLE=3D'font-si= ze:13pt'>6) s/”</SPAN><FONT SIZE=3D"1"><SPAN STYLE=3D'font-size:10pt'>In t= he near future, most low power and lossy network systems will be<BR>    for low frequency data collection.”/”In the n= ear future, most low power and lossy network systems in industrial automatio= n environments will be<BR>    for low frequency data collection.”<BR> <BR> 7) In several places, you make the assumption that the collected data is se= nt to a Sink/... Residing outside of the LLN. Don’t you see cases wher= e there will be intra-LLN flows in Industrial automation ?<BR> And I just read: “  In the future, it is envisioned that some op= en loop processes will be<BR>    automated (closed loop) and packets will flow over local = loops and<BR>    not involve the L2N access point. “ - Thanks.<BR> <BR> 8) you wrote: “More likely though is that loops will be closed in the= field<BR>    entirely, which in most cases eliminates the need for hav= ing wireless<BR>    links within the control loop.”<BR> Why does this eliminate the need for wireless links ?<BR> <BR> 9) “L2N-ish” ... You may want to slighlty reword here ;-)<BR> <BR> 10) s/”maximum number of hops from two to twenty.”/”maxim= um number of hops of twenty”<BR> <BR> 11) Section 2.2<BR> <BR> You wrote: “ The backbone is a high-speed infrastructure network that= may<BR>    interconnect multiple WSNs through backbone routers. &nbs= p;Infrastructure<BR>    devices can be connected to the backbone.  A gateway= / manager that<BR>    interconnects the backbone to the plant network of the co= rporate<BR>    network can be viewed as collapsing the backbone and the<= BR>    infrastructure devices into a single device that operates= all the<BR>    required logical roles.  The backbone is likely to b= ecome an<BR>    important function of the industrial network.”<BR> <BR> Although I do agree that this is a common architecture, you may want to ind= icate that this is only <B>one</B> possible architecture. <BR> <BR> 12) Could you please use a coherent terminology throughout the document ? L= 2N sensor, field devices, ... I’ll try to write the terminology ID thi= s week, then thanks to align the terminology.<BR> <BR> 13) I found this section is bit out of the scope:<BR> <BR> “This multiple domain multiple applications connectivity creates a<BR= >    significant challenge.  Many different applications = will all share<BR>    the same medium, the ether, within the fence, preferably = sharing the<BR>    same frequency bands, and preferably sharing the same pro= tocols,<BR>    preferably synchronized to optimize co-existence challeng= es, yet<BR>    logically segregated to avoid creation of intolerable sho= rt cuts<BR>    between existing wired domains.<BR> <BR>    Given this challenge, L2N networks are best to be treated= as all<BR>    sitting on yet another segregated domain, segregated from= all other<BR>    wired domains where conventional security is organized by= perimeter.<BR>    Moving away from the traditional perimeter security minds= et means<BR>    moving towards stronger end-device identity authenticatio= n, so that<BR>    L2N access points can split the various wireless data str= eams and<BR>    interconnect back to the appropriate domain pending ident= ity and<BR>    trust established by the gateways in the authenticity of = message<BR>    originators.”<BR> <BR> 14) Question about Figure 1: it looks like we still do have to compute rout= es within the LLN ?<BR> Furthermore, thanks to mention that this is one of many potential architect= ures. For example, in section 2.2.2 you wrote “2.2.2.  Logical To= pologies<BR> <BR>    Most of the traffic over the LLN is publish/subscribe of = sensor data<BR>    from the field device towards the backbone router or gate= way that<BR>    acts as the sink for the WSN.”<BR> <BR> You may want to replace the backbone router/gateway by a sink to make the s= tatement more general and applicable to other topologies (without a gateway,= ...). The use of gateway is a bit dangerous here unless carefully defined b= ut we’ll discuss terminology in a separate email.<BR> <BR> 15) Section 2.2.2: “Since publishing the data is the raison d'etre fo= r most of the<BR>    sensors, it makes sense to build proactively a set of def= ault routes<BR>    between the sensors and one or more backbone router and m= aintain<BR>    those routes at all times.  Also, because of the los= sy nature of the<BR>    network, the routing in place should attempt to propose m= ultiple<BR>    forwarding solutions, building forwarding topologies in t= he form of<BR>    Directed Acyclic Graphs oriented towards the sinks.”= ;<BR> <BR> Is it a requirement to be able to configure “default routes?”<B= R> By “multiple forwarding solutions” do you actually means “= ;multiple paths” ?<BR> <BR> 16) Comment on “For these reasons, the ROLL routing infrastructure MU= ST be able to<BR>    compute and update constrained routes on demand (that is = reactively),<BR>    and it can be expected that this model will become more p= revalent for<BR>    field device to field device connectivity as well as for = some field<BR>    device to Infrastructure devices over time.”<BR> <BR> </SPAN></FONT></FONT><UL><LI><FONT FACE=3D"Courier, Courier New"><FONT SIZE=3D"= 1"><SPAN STYLE=3D'font-size:10pt'>you may want to move the MUST in the routing= requirement sections, to have them all in one place.=20 </SPAN></FONT></FONT><LI><FONT FACE=3D"Courier, Courier New"><FONT SIZE=3D"1"><= SPAN STYLE=3D'font-size:10pt'>Are you requiring a reactive mechanism <BR> </SPAN></FONT></FONT></UL><FONT FACE=3D"Courier, Courier New"><FONT SIZE=3D"1">= <SPAN STYLE=3D'font-size:10pt'><BR> 17) Section 3.<BR> * “Service Requirement” - You may want to change the title for = “Traffic Characteristics” just to avoid confusion with upper lay= er requirements. <B>excellent paragraph<BR> </B>* I’m not sure to see the rationale of the various bullets “= ;data bandwidth”, “Latency”, ... In this context of routin= g requirements.<BR> * You wrote “The routing protocol<BR>    MUST be able to set up unidirectional or asymmetrical cos= t routes<BR>    that are composed of one or more non congruent paths.R= 21;<BR> You may want to reword this sentence, which may be misleading (in particula= r, there is no “or” routes can be unidirectional and asymmetrica= l”). Did you mean “The routing protocol MUST be able to compute = a set of unidirectional routes with potentially different costs”.<BR> <BR> 18) Section 3.1<BR> <BR> * S/ Time-varying user requirements for latency and bandwidth will require<= BR>    changes in the provisioning of the underlying L2 protocol= s/ Time-varying user requirements for latency and bandwidth may require<BR>    changes in the provisioning of the underlying L2 protocol= s.<BR> <BR> *  “The routing protocol MUST route on paths that are changed to= <BR>    appropriately provision the application requirements.R= 21;  <BR> <BR> JP> This should translate into “The routing protocol MUST dynamica= lly recompute path if the underlying topology changes.<BR> <BR>    “The routing<BR>    protocol MUST support the ability to recompute paths base= d on<BR>    underlying link characteristics that may change dynamical= ly.”<BR> <BR> JP> Could you be more accurate ? “What if the BER crosses some thr= eshold?”. Should it trigger a path computation ? If so, you would need= to list all parameters that can trigger a path computation. Alternatively, = (IMO the prefered option) each of the link characteristic should be reflecte= d in a metric or attribute change that will trigger a path computation (use = filters of course). <BR> <BR> 19) Section 3.2.<BR> S/”The routing algorithm MUST be able to<BR>    generate different routes for different flows.”/= 221;The routing algorithm MUST be able to<BR>    generate different routes with different characteritics (= e.g. Optimized according to different cost, ...).”<BR> <BR> 20) Replace globally “low power lossy network” by “LLN= 221;.<BR> <BR> 21) Replace globally “#” by “number”.<BR> <BR> 22) s/” 3)  Probability of failure on demand,”/” 3) =  Probability of failure to compute an on demand route”<BR> <BR> 23) In the list of “Reliability Requirements” you may want to a= dd a “...” since there are many other ones (ability to reroute u= pon a network failure, ...).<BR> <BR> 24) “Hop-by-hop path diversity is used to improve latency-bounded<BR>    reliability.”<BR> <BR> JP> Path diversity does not help with latency-bounded reliability ... It= does help to increase packet delivery if you use a 1+1 technique, or to fin= d an alternate path or limit the proportion of flows impacted by a single fa= ilure but not for latency. What did you mean ?<BR> <BR> 25) “The routing protocol MUST support multiple L2N access<BR>    points and load distribution among L2N access points. &nb= sp;<BR> JP> In order to make this requirement not “topology dependent̶= 1; could you reword it “The routing protocol MUST be able to compute p= aths towards different destination so as to perform load balancing across a = variety of paths.”<BR> <BR> 26) “The routing<BR>    protocol MUST support multiple L2N access points when L2N= access<BR>    point redundancy is required.”<BR> <BR> This is not a routing protocol requirement.<BR> <BR> 27) “Because L2Ns are lossy in nature,<BR>    multiple paths in a L2N route MUST be supported. “ = --> already stated.<BR> <BR> 28) Section 6:<BR> <BR> “2)  Delivery of common packets to multiple routers over a backb= one,<BR>        where the packets results in each= receiving router initiating<BR>        multicast (sometimes as a full br= oadcast) within the LLN.  This<BR>        is byproduct of having potentiall= y physically separated backbone<BR>        routers that can inject messages = into different portions of the<BR>        same larger LLN.”<BR> <BR> JP> IMO a too solution-specific statement.<BR> <BR> 29) Section 7<BR> * “The routing algorithm SHOULD always be in the process of<BR>    optimizing the system in response to changing link statis= tics.”<BR> JP> The term “optimizing” is worth a few words of explanatio= n. Optimizing with regards to which objective ?<BR> <BR> * “The<BR>    routing algorithm MUST re-optimize the paths when field d= evices<BR>    change due to insertion, removal or failure, and this re-= optimization<BR>    MUST not cause latencies greater than the specified const= raints<BR>    (typically seconds to minutes).”<BR> Few comments here: (1) The first “MUST” is not different than t= he basic requirement of being able to compute new path upon topology changes= . (2) I would propose to carefully use the term “re-optimization”= ;. Indeed, I guess that you refer to the event where a “shorter”= path is found according to some metrics. Then you are requiring the ability= to switch to a shorter path while bounding the latency, which requires to o= nly switch if the delta between the old and new cost is also bounded and als= o implies other constraints. Indeed, in distributed systems, you cannot guar= antee that systems are fully synchronized. Thus a router may start using a r= oute that is not yet ready if some of the next hops have not converged yet, = which may lead to micro-loops. Could you elaborate on this requirement ?<BR> <BR> 30) <BR> * “The routing protocol SHOULD support the wireless worker with fast<= BR>    network connection times of a few of seconds, and low com= mand and<BR>    response latencies to the plant behind the L2N access poi= nts, to<BR>    applications, and to field devices.  “<BR> <BR> Is it a different requirement than the one expressed in Section 7: <BR> <BR> “The routing algorithm MUST find the appropriate<BR>    route(s) and report success or failure within several min= utes, and<BR>    SHOULD report success or failure within tens of seconds.&= #8221; <BR> <BR> <BR> * “The routing protocol SHOULD also<BR>    support the bandwidth allocation for bulk transfers betwe= en the field<BR>    device and the handheld device of the wireless worker. &n= bsp; “<BR> <BR> JP> of course, I see what you mean but this should either be removed or = reworded. This may simply refer to topology changes, for which you already h= ave a routing requirement or some cross-layer function (hope not).<BR> <BR> “The routing<BR>    protocol SHOULD support walking speeds for maintaining ne= twork<BR>    connectivity as the handheld device changes position in t= he wireless<BR>    network.<BR> <BR>    Some field devices will be mobile.  These devices ma= y be located on<BR>    moving parts such as rotating components or they may be l= ocated on<BR>    vehicles such as cranes or fork lifts.  The routing = protocol SHOULD<BR>    support vehicular speeds of up to 35 kmph.<BR> “<BR> <BR> JP> You may just want to say that such requirement has also consequences= on non-routing functions.<BR> <BR> 31) Section 9<BR> <BR> * “Therefore,<BR>    the routing protocol MUST support auto-provisioning of fi= eld devices.”<BR> <BR> JP> To which extent ? Does that mean a true 0-configuration routing prot= ocol ?<BR> <BR> *”The protocol also MUST support the distribution of configuration fr= om<BR>    a centralized management controller if operator-initiated= <BR>    configuration change is allowed.”<BR> <BR> JP> Not a routing requirement. Or do you refer to the dynamic set up of = a “default DAG/Tree” used to retrieve a more sophisticated ̶= 0;routing feature” from a centralized tool ?<BR> <BR> 32) Section 10<BR> <BR> * s/”1) attacks on the actual application served be the wireless<BR>    devices and “/”1) attacks on the actual appli= cation served by the wireless<BR>    devices and “<BR> <BR> * “2) attacks that exploit the presence of a wireless access<BR>    point that MAY provide connectivity onto legacy wired pla= nt networks,<BR>    so attacks that have little to do with the wireless devic= es in the<BR>    L2Ns. “/”2) attacks that exploit the presence= of a wireless access<BR>    point that may provide connectivity onto legacy wired pla= nt networks,<BR>    so attacks that have little to do with the wireless devic= es in the<BR>    LLNs. “<BR> <BR> * “The routing protocol SHOULD place limited trust in the field devic= es<BR>    deployed in the plant network.<BR> “<BR> <BR> JP> Could you elaborate a little bit ? It sounds a bit too vague for a p= rotocol designer to figure out what action to take according to this require= ment. <BR> <BR> “Standards exist that address those<BR>    vulnerabilities.”<BR> <BR> JP> ??<BR> <BR> 33) replace “isn’t by is not”, “doesn’t by do= es not” , ... <BR> <BR> Thanks.<BR> <BR> Cheers,<BR> <BR> JP.<BR> </SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN = STYLE=3D'font-size:13pt'><HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><= FONT SIZE=3D"1"><FONT FACE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-= size:10pt'>_______________________________________________<BR> Roll mailing list<BR> <a href=3D"Roll@ietf.org">Roll@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/roll">https://www.ietf.org/m= ailman/listinfo/roll</a><BR> </SPAN></FONT></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3303912212_30053634-- --===============1135721488== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1135721488==-- From roll-bounces@ietf.org Wed Sep 10 11:34:51 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E63D3A6828; Wed, 10 Sep 2008 11:34:51 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C5A03A6828 for <roll@core3.amsl.com>; Wed, 10 Sep 2008 11:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wBsUulNrtgm for <roll@core3.amsl.com>; Wed, 10 Sep 2008 11:34:45 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id DE7433A680F for <roll@ietf.org>; Wed, 10 Sep 2008 11:34:45 -0700 (PDT) Received: from dnab4223a6.stanford.edu ([171.66.35.166]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from <pal@cs.stanford.edu>) id 1KdUWh-0001Vu-D6; Wed, 10 Sep 2008 11:34:51 -0700 Message-Id: <7D8A808B-B9EC-449B-ABC1-02FAF8A93554@cs.stanford.edu> From: Philip Levis <pal@cs.stanford.edu> To: JP Vasseur <jvasseur@cisco.com> In-Reply-To: <C4ED8657.50345%jvasseur@cisco.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 10 Sep 2008 11:34:48 -0700 References: <C4ED8657.50345%jvasseur@cisco.com> X-Mailer: Apple Mail (2.926) X-Scan-Signature: ae7d61d5ad21aa0d569d6b6c8168eb46 Cc: roll@ietf.org Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/roll> List-Post: <mailto:roll@ietf.org> List-Help: <mailto:roll-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0899379427==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0899379427== Content-Type: multipart/alternative; boundary=Apple-Mail-37-98836728 --Apple-Mail-37-98836728 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Sep 10, 2008, at 5:12 AM, JP Vasseur wrote: > > Looks like we're quibbling on words ;-) The objective is this ID is to > determine whether or not we can find a routing protocol that meets the > specific requirements of ROLL. The final WG decision will be > documented in a > separate ID. I agree. I'd like to repeat a paragraph from my September 2 mail: "This seems to be an argument about the scope of the document. Currently, the draft simply examines *existing* protocols to determine if any of them meet the requirements of ROLL. If the answer to this question is "yes," then ROLL does not need to consider how to come up with a protocol that meets its needs. If the answer to this question is "no," then ROLL needs to discuss how best to proceed. Doing so could be either extending existing protocols or defining new ones; the draft takes no position on this." In particular, work item 2 of the ROLL charter is: "Survey the applicability of existing protocols to LLNs. The aim of this document will be to analyze the scaling and characteristics of existing protocols and identify whether or not they meet the routing requirements of the applications identified above. " Making a conclusion based on the factual findings of the draft is something that will guide the decision of whether to recharter or close the WG. Phil --Apple-Mail-37-98836728 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable <html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; "><br><div><div>On Sep 10, 2008, = at 5:12 AM, JP Vasseur wrote:</div><blockquote = type=3D"cite"><div><br>Looks like we're quibbling on words ;-) The = objective is this ID is to<br>determine whether or not we can find a = routing protocol that meets the<br>specific requirements of ROLL. The = final WG decision will be documented in a<br>separate = ID.</div></blockquote><br></div><div>I agree. I'd like to repeat a = paragraph from my September 2 mail:</div><div><br></div><div>"This seems = to be an argument about the scope of the document. =  </div>Currently, the draft simply examines *existing* protocols to = determine  <br>if any of them meet the requirements of ROLL. If the = answer to this  <br>question is "yes," then ROLL does not need to = consider how to come up  <br>with a protocol that meets its needs. = If the answer to this question  <br>is "no," then ROLL needs to = discuss how best to proceed. Doing so  <br>could be either = extending existing protocols or defining new ones; the  <br>draft = takes no position on this."<div><br></div><div>In particular, work item = 2 of the ROLL charter is:</div><div><br></div><div><div = style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; font: normal normal normal 12px/normal Helvetica; = ">"Survey the applicability of existing protocols to LLNs. The aim = of</div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: = 0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; = ">this document will be to analyze the scaling and characteristics = of</div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: = 0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; = ">existing protocols and identify whether or not they meet the = routing</div><div style=3D"margin-top: 0px; margin-right: 0px; = margin-bottom: 0px; margin-left: 0px; font: normal normal normal = 12px/normal Helvetica; ">requirements of the applications identified = above. "</div></div><div><br></div><div>Making a conclusion based = on the factual findings of the draft is something that will guide the = decision of whether to recharter or close the = WG.<br></div><div><br></div><div>Phil</div></body></html>= --Apple-Mail-37-98836728-- --===============0899379427== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0899379427==-- From roll-bounces@ietf.org Wed Sep 10 11:48:03 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CC8B3A680F; Wed, 10 Sep 2008 11:48:03 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C5073A680F for <roll@core3.amsl.com>; Wed, 10 Sep 2008 11:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.422 X-Spam-Level: X-Spam-Status: No, score=-5.422 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUvsoO3Jl9tr for <roll@core3.amsl.com>; Wed, 10 Sep 2008 11:47:57 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 014D93A6783 for <roll@ietf.org>; Wed, 10 Sep 2008 11:47:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,373,1217808000"; d="scan'208,217";a="20372449" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Sep 2008 18:48:02 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8AIm2k7026071; Wed, 10 Sep 2008 14:48:02 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8AIm2wQ005515; Wed, 10 Sep 2008 18:48:02 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Sep 2008 14:48:02 -0400 Received: from 10.61.82.35 ([10.61.82.35]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 10 Sep 2008 18:48:01 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 10 Sep 2008 20:47:57 +0200 From: JP Vasseur <jvasseur@cisco.com> To: Philip Levis <pal@cs.stanford.edu> Message-ID: <C4EDE2FD.504A2%jvasseur@cisco.com> Thread-Topic: [Roll] draft-ietf-roll-protocols-survey-00 Thread-Index: AckTdb0Dfl3q9Xxyr0CvgYH43nVsxg== In-Reply-To: <7D8A808B-B9EC-449B-ABC1-02FAF8A93554@cs.stanford.edu> Mime-version: 1.0 X-OriginalArrivalTime: 10 Sep 2008 18:48:02.0209 (UTC) FILETIME=[C0B70110:01C91375] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5374; t=1221072482; x=1221936482; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20<jvasseur@cisco.com> |Subject:=20Re=3A=20[Roll]=20draft-ietf-roll-protocols-surv ey-00 |Sender:=20 |To:=20Philip=20Levis=20<pal@cs.stanford.edu>; bh=uAQewtw6TAECfyVWW7VvCwCx2CarfdNnPsBFTVpHr+Q=; b=pwqoZSKxVXMd/0mCRYp2qfPPPVCkTanR/3G/NtouOEUaktm5J7NIV+wABn /c2EuiGaOAKgLcElZHZB+5d5pPKNB+oeOYWukQs2I54EfR30wU4GWd5GeU1G 7OCkdgzreT; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/roll> List-Post: <mailto:roll@ietf.org> List-Help: <mailto:roll-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0613997697==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0613997697== Content-type: multipart/alternative; boundary="B_3303924479_30740599" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3303924479_30740599 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Phil,=20 Could you please post a new revision of the draft taking into account the various comments received so far fairly quickly ? I=B9ll so make a detailed pass. It would be nice to have a more mature version of the ID for the ROLL interim WG meeting in a month. Thanks. Cheers, JP. On 9/10/08 8:34 PM, "Philip Levis" <pal@cs.stanford.edu> wrote: >=20 > On Sep 10, 2008, at 5:12 AM, JP Vasseur wrote: >>=20 >> Looks like we're quibbling on words ;-) The objective is this ID is to >> determine whether or not we can find a routing protocol that meets the >> specific requirements of ROLL. The final WG decision will be documented = in a >> separate ID. >=20 > I agree. I'd like to repeat a paragraph from my September 2 mail: >=20 > "This seems to be an argument about the scope of the document. > Currently, the draft simply examines *existing* protocols to determine > if any of them meet the requirements of ROLL. If the answer to this > question is "yes," then ROLL does not need to consider how to come up > with a protocol that meets its needs. If the answer to this question > is "no," then ROLL needs to discuss how best to proceed. Doing so > could be either extending existing protocols or defining new ones; the > draft takes no position on this." >=20 > In particular, work item 2 of the ROLL charter is: >=20 > "Survey the applicability of existing protocols to LLNs. The aim of > this document will be to analyze the scaling and characteristics of > existing protocols and identify whether or not they meet the routing > requirements of the applications identified above. " >=20 > Making a conclusion based on the factual findings of the draft is somethi= ng > that will guide the decision of whether to recharter or close the WG. >=20 > Phil >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --B_3303924479_30740599 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [Roll] draft-ietf-roll-protocols-survey-00 Phil,

Could you please post a new revision of the draft taking into account the v= arious comments received so far fairly quickly ? I’ll so make a detail= ed pass. It would be nice to have a more mature version of the ID for the RO= LL interim WG meeting in a month.

Thanks.

Cheers,

JP.


On 9/10/08 8:34 PM, "Philip Levis" <pal@cs.stanford.edu> wrote:

<= SPAN STYLE=3D'font-size:13pt'>
On Sep 10, 2008, at 5:12 AM, JP Vasseur wrote:
<= SPAN STYLE=3D'font-size:13pt'>
Looks like we're quibbling on words ;-) The objective is this ID is to
determine whether or not we can find a routing protocol that meets the
specific requirements of ROLL. The final WG decision will be documented in = a
separate ID.
=
I agree. I'd like to repeat a paragraph from my September 2 mail:

"This seems to be an argument about the scope of the document.  <= BR> Currently, the draft simply examines *existing* protocols to determine &nbs= p;
if any of them meet the requirements of ROLL. If the answer to this  <= BR> question is "yes," then ROLL does not need to consider how to com= e up  
with a protocol that meets its needs. If the answer to this question  =
is "no," then ROLL needs to discuss how best to proceed. Doing so=  
could be either extending existing protocols or defining new ones; the &nbs= p;
draft takes no position on this."

In particular, work item 2 of the ROLL charter is:

"Survey the applicability of existing protocols to LLNs. The aim of this document will be to analyze the scaling and characteristics of
existing protocols and identify whether or not they meet the routing
requirements of the applications identified above. "

Making a conclusion based on the factual findings of the draft is something= that will guide the decision of whether to recharter or close the WG.

Phil

___________= ____________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
--B_3303924479_30740599-- --===============0613997697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0613997697==-- From roll-bounces@ietf.org Wed Sep 10 12:06:10 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C9D73A689E; Wed, 10 Sep 2008 12:06:10 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1D43A689E for ; Wed, 10 Sep 2008 12:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evsNJwFvsDtH for ; Wed, 10 Sep 2008 12:06:08 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id AAEBD3A67AA for ; Wed, 10 Sep 2008 12:06:08 -0700 (PDT) Received: from dnab4223a6.stanford.edu ([171.66.35.166]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1KdV0b-0003AH-Kq; Wed, 10 Sep 2008 12:05:45 -0700 Message-Id: <696BE40E-93E1-48DA-8B9B-7A15A95ACA58@cs.stanford.edu> From: Philip Levis To: JP Vasseur In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 10 Sep 2008 12:05:45 -0700 References: X-Mailer: Apple Mail (2.926) X-Scan-Signature: 4c7a780eb20f40a19c8376fd8d8b00d5 Cc: roll@ietf.org Subject: Re: [Roll] draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Sep 10, 2008, at 11:47 AM, JP Vasseur wrote: > Phil, > > Could you please post a new revision of the draft taking into = > account the various comments received so far fairly quickly ? I=92ll = > so make a detailed pass. It would be nice to have a more mature = > version of the ID for the ROLL interim WG meeting in a month. Absolutely. Stephen, Arsalan and I are working on it now. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Sep 10 13:31:11 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47E7828C20F; Wed, 10 Sep 2008 13:31:11 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFDE33A6DA6 for ; Wed, 10 Sep 2008 13:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfp-MdePJ5u4 for ; Wed, 10 Sep 2008 13:31:10 -0700 (PDT) Received: from exprod8og109.obsmtp.com (exprod8og109.obsmtp.com [64.18.3.98]) by core3.amsl.com (Postfix) with ESMTP id E23953A6DA8 for ; Wed, 10 Sep 2008 13:31:09 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob109.postini.com ([64.18.7.12]) with SMTP; Wed, 10 Sep 2008 13:28:46 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2008091015345957-5159871 ; Wed, 10 Sep 2008 15:34:59 -0500 MIME-Version: 1.0 To: roll@ietf.org X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Wed, 10 Sep 2008 15:30:59 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 09/10/2008 03:31:06 PM, Serialize complete at 09/10/2008 03:31:06 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 09/10/2008 03:34:59 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 09/10/2008 03:35:07 PM, Serialize complete at 09/10/2008 03:35:07 PM Subject: [Roll] New version of ROLL Building requirements posted X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0019111842==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multipart message in MIME format. --===============0019111842== Content-Type: multipart/alternative; boundary="=_alternative 0070B392862574C0_=" This is a multipart message in MIME format. --=_alternative 0070B392862574C0_= Content-Type: text/plain; charset="US-ASCII" All, Today (Sept 10, 2008), I posted a new version of the ROLL Building requirements that originally was presented in Dublin. This version incorporates all comments know to date including: Merging Pieter's document (use cases and requirements) into this document Moving non-routing requirements into an informative appendix - JP Following the 'Home Requirements' template - Zach Grouping the requirements - Zach Remove all references to 802.15.4, 6LoWPAN. Become media and protocol agnostic - JP Deleted use case 3.9 (Changing Office Layout) - Pieter Reduce Introductory Section - JP The previous version was called 'draft-martocci-roll-commercial -routing-reqs-00.txt'. JP wanted me to change the file name from 'commercial' to 'building'. However the repository wouldn't allow me to submit a version 01 of a file without previously submitting a version 00. While this is actually the second version of the document, it is posted as "draft-martocci-roll-building-routing-reqs-00.txt". All comments welcomed and appreciated. Regards, Jerry Martocci --=_alternative 0070B392862574C0_= Content-Type: text/html; charset="US-ASCII"
All,

Today (Sept 10, 2008), I posted a new version of the ROLL Building requirements that originally was presented in Dublin.  This version incorporates all comments know to date including:
  • Merging Pieter's document (use cases and requirements) into this document
  • Moving non-routing requirements into an informative appendix - JP
  • Following the 'Home Requirements' template - Zach
  • Grouping the requirements - Zach
  • Remove all references to 802.15.4, 6LoWPAN.  Become media and protocol agnostic - JP
  • Deleted use case 3.9 (Changing Office Layout) - Pieter
  • Reduce Introductory Section - JP


The previous version was called 'draft-martocci-roll-commercial-routing-reqs-00.txt'.  JP wanted me to change the file name from 'commercial' to 'building'.  However the repository wouldn't allow me to submit a version 01 of a file without previously submitting a version 00.  While this is actually the second version of the document, it is posted as "draft-martocci-roll-building-routing-reqs-00.txt".

All comments welcomed and appreciated.


Regards,

Jerry Martocci

--=_alternative 0070B392862574C0_=-- --===============0019111842== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0019111842==-- From roll-bounces@ietf.org Wed Sep 10 22:18:09 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3BED3A6B9E; Wed, 10 Sep 2008 22:18:09 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29A6A3A6B85 for ; Wed, 10 Sep 2008 22:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.414 X-Spam-Level: X-Spam-Status: No, score=-5.414 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JC0OWqZ8kS+X for ; Wed, 10 Sep 2008 22:18:03 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E56F73A6922 for ; Wed, 10 Sep 2008 22:18:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,377,1217808000"; d="scan'208,217";a="20444147" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 11 Sep 2008 05:17:48 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8B5Hlqa006907; Thu, 11 Sep 2008 01:17:47 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8B5HlXK003317; Thu, 11 Sep 2008 05:17:47 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Sep 2008 01:17:47 -0400 Received: from 10.61.82.35 ([10.61.82.35]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 11 Sep 2008 05:17:47 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Thu, 11 Sep 2008 07:17:46 +0200 From: JP Vasseur To: , Message-ID: Thread-Topic: [Roll] New version of ROLL Building requirements posted Thread-Index: AckTzbmbF2bmTfMgrk6SMcCTk8+6QQ== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 11 Sep 2008 05:17:47.0792 (UTC) FILETIME=[BAAD6900:01C913CD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5233; t=1221110267; x=1221974267; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20New=20version=20of=20ROLL=20Bu ilding=20requirements=20posted |Sender:=20 |To:=20,=20; bh=Cqn7qSleND5d18MonoIuX4eCqSk0V2OUGKdmFtISJ9k=; b=qg4LwsIqrX0g2h4l/cNsy4W0sMwdpyJIvYYRR7Wu0XAl4/VgXqPCHob78b vyaK3oIzPmQy3rxuv/YbZQv7ytQEbywyD+PT+nvtcIX5f3MZ2yjfyOIMPW36 ToY9zrRZZk; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Roll] New version of ROLL Building requirements posted X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0326141098==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0326141098== Content-type: multipart/alternative; boundary="B_3303962266_33059524" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3303962266_33059524 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Many Thanks Jerry, I=B9ll do my pass this week. All, please review and comment, we should be able to poll the WG for WG adoption after one more revision. Thanks. JP. On 9/10/08 10:30 PM, "Jerald.P.Martocci@jci.com" wrote: >=20 > All,=20 >=20 > Today (Sept 10, 2008), I posted a new version of the ROLL Building > requirements that originally was presented in Dublin. This version > incorporates all comments know to date including: > * Merging Pieter's document (use cases and requirements) into this docume= nt > * Moving non-routing requirements into an informative appendix - JP > * Following the 'Home Requirements' template - Zach > * Grouping the requirements - Zach > * Remove all references to 802.15.4, 6LoWPAN. Become media and protocol > agnostic - JP=20 > * Deleted use case 3.9 (Changing Office Layout) - Pieter > * Reduce Introductory Section - JP >=20 >=20 > The previous version was called > 'draft-martocci-roll-commercial-routing-reqs-00.txt'. JP wanted me to ch= ange > the file name from 'commercial' to 'building'. However the repository > wouldn't allow me to submit a version 01 of a file without previously > submitting a version 00. While this is actually the second version of th= e > document, it is posted as "draft-martocci-roll-building-routing-reqs-00.t= xt". >=20 > All comments welcomed and appreciated. >=20 >=20 > Regards,=20 >=20 > Jerry Martocci=20 >=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --B_3303962266_33059524 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Roll] New version of ROLL Building requirements posted Many Thanks Jerry, I’ll do my pass this week. All, please review and= comment, we should be able to poll the WG for WG adoption after one more re= vision.

Thanks.

JP.


On 9/10/08 10:30 PM, "Jerald.P.Mar= tocci@jci.com" <Jerald.P.Mar= tocci@jci.com> wrote:

<= SPAN STYLE=3D'font-size:13pt'>
All,

Today (Sept 10, 2008), I posted a new version of the ROLL Building requirem= ents that originally was presented in Dublin.  This version incorporate= s all comments know to date including:
  • Merging Pieter's document (use cases and requirement= s) into this document=20
  • Moving non-routing requirements into an informative appe= ndix - JP=20
  • Following the 'Home Requirements' template - Zach=20
  • Grouping the requirements - Zach=20
  • Remove all references to 802.15.4, 6LoWPAN.  Become= media and protocol agnostic - JP=20
  • Deleted use case 3.9 (Changing Office Layout) - Pieter=20
  • Reduce Introductory Section - JP


The previous version was called 'draft-martocci-roll-commercial-rout= ing-reqs-00.txt'.  JP wanted me to change the file name from 'commercia= l' to 'building'.  However the repository wouldn't allow me to submit a= version 01 of a file without previously submitting a version 00.  Whil= e this is actually the second version of the document, it is posted as "= ;draft-martocci-roll-building-routing-reqs-00.txt".

All comments welcomed and appreciated.


Regards,

Jerry Martocci


___________= ____________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
--B_3303962266_33059524-- --===============0326141098== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0326141098==-- From roll-bounces@ietf.org Thu Sep 11 03:22:41 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E302C3A6A6A; Thu, 11 Sep 2008 03:22:41 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26C4E3A68B7 for ; Thu, 11 Sep 2008 03:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.992 X-Spam-Level: X-Spam-Status: No, score=-3.992 tagged_above=-999 required=5 tests=[AWL=-1.617, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rJJTDUTbMtW for ; Thu, 11 Sep 2008 03:22:21 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B40F03A6A6A for ; Thu, 11 Sep 2008 03:22:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,378,1217808000"; d="scan'208,217";a="20475474" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 Sep 2008 10:21:55 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8BALtBj015606; Thu, 11 Sep 2008 06:21:55 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8BALsnh016867; Thu, 11 Sep 2008 10:21:55 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Sep 2008 06:20:35 -0400 Received: from 10.61.97.226 ([10.61.97.226]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 11 Sep 2008 10:20:35 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Thu, 11 Sep 2008 12:19:51 +0200 From: JP Vasseur To: "Jerald.P.Martocci@jci.com" , , , Message-ID: Thread-Topic: Detailed Review of draft-martocci-roll-building-routing-reqs Thread-Index: AckT9+zzW5ChN6taNk2uIgkdfBdjRg== Mime-version: 1.0 X-OriginalArrivalTime: 11 Sep 2008 10:20:35.0801 (UTC) FILETIME=[07A79490:01C913F8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=34685; t=1221128515; x=1221992515; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Detailed=20Review=20of=20draft-martocci-roll-bu ilding-routing-reqs |Sender:=20 |To:=20=22Jerald.P.Martocci@jci.com=22=20,=0A=20=20=20=20=20=20=20=20,=0A=20=20=20=20=20=20=20=20,=20; bh=EeVGZzY7H5EPHBtwSS49rf7MUxq9UokLjdXdxq78hyM=; b=KBbFZdJZfhobvHAje+X8UafB07uvs4CMPFtsWtjNMcXrCh5vbKslzmtOUV Oc3g+zSOFywIucrA1YbcH91vZxfqCCi/V/WOgfFptcVyI6bWUuVHBulNycdj erzjhcfUvC; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: roll@ietf.org Subject: [Roll] Detailed Review of draft-martocci-roll-building-routing-reqs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2049105802==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============2049105802== Content-type: multipart/alternative; boundary="B_3303980433_34110396" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3303980433_34110396 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Jerry, Again thanks for the great work and time you spend spelling out the buildin= g automation requirements for ROLL. The document provide an outstanding level of details, very helpful to understand the context. The main comment is that requirements have to be exclusively related to the routing aspects and there are still quite a few non routing related requirements (see below, comments on section 4). Some of them also needs to be more accurately specified for the protocol designer. Detailed comments below (comments are not by border of importance but in chronological order) 1) Abstract * S/=B2The ROLL Working Group was recently chartered by the IETF to define routing characteristics for low power embedded devices. ROLL would like to serve the Industrial, Commercial (Building), Home and Urban markets.=B2/=B2The Routing Over Low power and Lossy network (ROLL) Working Group has been chartered to work on routing solution for Low Power and Loss= y networks (LLN) in various markets: Industrial, Commercial (Building), Home and Urban=B2. * S/=B2Pursuant to this effort, this document defines the functional requirements for installing integrated facility management systems in commercial facilities. =B3/=B2Pursuant to this effort, this document defines the routing requirement for building automation. =B3 2) Terminology: I=B9ll post a terminology ID soon, you may want to refer to i= t in this document. 3) Introduction * Although listed in the terminology section, thanks to expand acronyms whe= n first used (e.g. HVAC, K-12, * (NOTE:... =3D> paranthesis missing at the end of the sentence. 4) Section 2.2 * EIA 485: could you please expand and add a informative reference ? * s/=B2mbps=B2/Mbits/s=B2 * s/=B2kbps=B2/Kbits/s=B2 * I would suggest to remove =B3To date, camera systems have been deployed on = a proprietary wired high speed network or on enterprise VLAN. =B3 or try to soften this statement. We see more and more IP video cameras installed in buildings. 5) Section 3 * This use case is certainly interesting and useful but as written the introduction looks like a commercial brochure ;-) Could you make it a bit more anonymous ?=20 * Section 3.3. Are you referring to the need for assets tracking (e.g. RFID= ) * Section 3.4, 3.5, 3.6 and 3.7: The text is pretty straightforward. Thus I would suggest to (at least) shorten the paragraph and spell out a bit more clearly the network implication in section 3.4 6) Section 4 * s/=8Crouting=B9 /routing * Section 4.1: this has been explained in the previous section * =B3It MUST be possible to fully commission devices without requiring any additional commissioning device (e.g. laptop). The device MAY be completely configured for network operation by setting a bank of switches. The number of switches MUST not exceed 16 switches. =B3 JP> The first requirement is a 0-configuration routing requirement (you may want to say it this way) and has been spelled out in other routing requirements IDs. The two last comments are implementation specific (hardware requirements in this case), thus outside of the scope of IETF requirement IDs. * =B3The device network address MUST be settable and henceforth fixed for the device without the need for other system devices such as DHCP servers. =B3 JP> This is a requirement on the address configuration ... * =B3 Network setup MUST support device commissioning times of no more than 15 minutes per sensor/controller pair.=B2 JP> Could you slightly reword this sentence referring to the time to discover a new path ? * Thanks to move section 4.1.4 to the introduction. No routing requirement. * I would suggest to remove section 4.1.5 * Section 4.2.1 =B3A network MUST operationally support at least 1000 routing and 1000 non-routing devices. =B3 JP> Can you rephrase ? For example: =B3The routing protocol MUST be able to support networks with at least 1000 routers and 1000 hosts=B2 * =B3Subnetworks (e.g. rooms, primary equipment) within the network must support upwards to 255 sensors and/or actuators. Subnetworks MUST seamlessly merge into networks. Networks MUST seamlessly merge into internetworks. =B3 JP> Not a routing requirement * =B3A source device may be upwards to 1000 feet from its destination. Communication MUST be established between these devices without needing to install other intermediate 'communication only' devices such as repeaters. =B3 JP> You are referring to the PHY/MAC protocols, not a routing function. * =B3For wireless implementations, the routing algorithms SHOULD incorporate automatic transmit power regulation to maximize packet transfer and minimize network interference regardless of network size or density.=B2 JP> Please do not use =B3algorithm=B2 since we do not specify algorithm at the IETF ;-) More importantly, this (important) requirement is for the PHY layer, not the routing protocol unless you intend to derive from this characteristic a routing requirement (dynamic metric such as the bandwidth ?). * =B3Network devices MUST be able to communicate in a peer-to-peer manner with all other devices on the network without being subject to intermediate bridge or gating devices. =B3 JP> An important requirement. If I may, I would suggest the following wording: =B3Network devices must be able to communicate in a peer-to-peer manner with all other devices on the network. Thus the routing protocol MUS= T provide routes to any other devices without being subject to a constrained path via a gating device.=B3 * =B3Mobile devices SHOULD be capable of unjoining from an old network joining onto a new network within 15 seconds. =B3 JP> Could you refer to route discovery time instead (just a question of terminology) * =B3The total installed infrastructure cost including but not limited to the media, required infrastructure devices (amortized across the number of devices); labor to install and commission the network MUST not exceed $1.00/foot for wired implementations. =B3 JP> Definitely not a protocol issue (pricing). Thanks to delete. * =B3The software stack requirements for sensors and actuators MUST be implementable in 8-bit devices with no more than 128kb of flash memory (including at least 32Kb for the application code) and no more than 8Kb of RAM (including at least 1Kb RAM available for application). =B3 JP> What if we have a very efficient protocol optimized for small footprint and I am a really bad coder ? This is a typically difficult requirement to express. What I would suggest is to use a non normative language here and replace the MUST and a =8Cmust=B9. The same comment applies to section 4.4.3 * =B3The routing algorithms must support in-bound packet caches for sensor and actuator devices when these devices are not accessible on the network. The cached packets need to be delivered to its destination when the device is accessible on the network. =B3 JP> Interesting requirement but needs to be fleshed out. Could you elaborat= e a bit more ? Are you referring to store-and-forward techniques since this has other implications than just routing * =B3ROLL routing MUST support adjustable router table entry sizes on a per node basis to maximize limited RAM in the devices. =B3 This one falls into the category of =B3implementation specific issues=B2 outsid= e of the scope * =B3Routers MUST support quality of service prioritization to assure timely response for critical FMS packets (e.g. Fire and Security events). =B3 Qos is undoubtedly an important function but as such refers to the forwarding plane and ability to prioritize packet treatment using various scheduling techniques (WFQ, MDR, .... W/ or without dynamic priority, feed-back, etc) and congestion avoidane ((W)RED, ...). Now we also call QoS routing the ability to compute different paths for different flows. For example compute the shortest (constrained) path with respect to metric X, Y and Z where X can be the bandwidth metric, Y the delay metrics and so on. Are you referring to QoS routing here ? * =B3Sensor/Actuator/Controller addressability MUST be unique site-wide. All addressable nodes MUST be accessible to all other nodes in the internetwork.=20 =B3 JP> This is given :-) You can remove this paragraph. * s/ plug-n-play/=B2plug-and-play=B2 * =B3No bound information from other nodes MUST need be reconfigured. =B3 JP> This comes back to the 0-configuration requirement. Thanks to aggregate all requirements related to 0-config in one place. * =B3 To support high speed code downloads, a mechanism MUST be defined to download firmware to devices in parallel yet support guaranteed delivery. Devices receiving a high speed download MAY cease normal operation, but upon completion of the download MUST automatically resume normal operation. =B3 JP> If by mechanism you refer to a default routes to reach a management device then you may want to say it (be routing specific). The last sentence is implementation specific, this out of the scope of this document. * Section 4.7.3 =B34.7.3. Diagnostics To improve diagnostics, the network layer SHOULD be able to be placed in and out of 'verbose' mode. Verbose mode is a temporary debugging mode that provides additional communication information including at least total number of packets sent, packets received, number of failed communication attempts, neighbor table and routing table entries.=B2 JP> Very interesting, I=B9ll send a separate email to the list about this topic. * =B34.7.4. Trace Route Network diagnostics such as PING and Trace Route SHOULD be supported with extensions in Trace Route describing wireless parameter information when applicable. =B3 JP> Traceroute uses ICMP, not routing ... * =B34.8. Compatibility The building automation industry adheres to application layer protocol standards to achieve vendor interoperability. These standards are BACnet and LON. It is estimated that fully 80% of the customer bid requests received world-wide will require compliance to one or both of these standards. The ROLL routing algorithms will therefore need to dovetail to these application protocols to assure acceptance in the building automation industry. These protocols have been in place for over 10 years. Many sites will require backwards compatibility with the existing legacy devices. =B3 JP> Well ... I do agree that both Bacnet and Lonwork are important legacy protocols. That being said, we cannot design a solution that will be compatible with these protocols, the IETF is responsible for IP specification. As you know, we can expect Bacnet to take advantage of the protocols defined here thanks to its Bacnet over IP version although IP is used by Bacnet as a layer 2 with Bacnet routing on top of it but this is another debate.=20 * =B34.8.1. IPv4 Compatibility The routing protocol MUST define a communication scheme to assure compatibility of IPv4 and IPv6 devices. =B3 JP> Do you see other requirements than 6to4 ? * =B34.8.2. Maximum Packet Size Routing algorithms must support packet sizes to 1526 octets. =B3 JP> Two questions here: Q1: Why ? Q2: is it a =B3must=B2 or =B3MUST=B2? * =B3Route adaptation also reduces latency if the new route costs consider ho= p count as a=20 cost attribute. =B3 JP> Not sure that I completely agree with that statement, could you elaborate ? * =B34.9.1. Path Cost Path selection MUST be based on path quality, rather than signal strength only. Path quality includes signal strength, available bandwidth, hop count and communication error rates. =B3 JP> This is an important requirement. I would suggest to phrase it a bit differently by saying that the routing protocol MUST support a range of metrics and optimize (constrained) path according to these metrics. If I may, could you have a look at the following document http://www.ietf.org/internet-drafts/draft-mjkim-roll-routing-metrics-00.txt and provide comments/suggestions ? Thanks. * =B34.9.2. Path Adaptation Communication paths MUST adapt toward signal quality optimality in time. =B3 This actually translate to the ability to support dynamic metrics. Look at the ID referred above. * =B34.9.3. Route Redundancy To reduce real-time latency, the network layer SHOULD be configurable to allow secondary and tertiary paths to be established and used upon failure of the primary path =B3 JP> Let me make sure that I get this requirement right: are you referring t= o the ability for the routing protocol to dynamically recompute path upon failure or the support of that is usually refers to as path protection whereby diverse paths are pre-calculated. It is an important aspect to clarify since diverse path computation is certainly not a trivial issue. * =B34.9.4. Route Preference The route discovery mechanism SHOULD allow a source node (sensor) to dictate a configured destination node (controller) as a preferred routing path.=20 =B3 JP> Not sure to understand what you mean by =B3dictate a configured destination node as a preferred path ?=B2 * =B3The default MUST be asymmetric routes. =B3 JP> Do you mean that the routing engine must compute asymmetrical paths (paths to the destination with different cost) and these routes must systematically be used ? * =B34.9.6. Path Persistence Devices SHOULD optionally persist communication paths across boots =B3 JP> This is an local node issue. * =B34.10.1. Device Integrity Commercial Building devices MUST all be periodically scanned to assure that the device is viable and can communicate data and alarm information as needed. =B3 JP> Isn=B9t it a system architecture issue as opposed to a routing issue ? 7) Traffic Pattern * Interesting. Does that mean that by contrast with many other sensoring systems, the traffic is very much localized and aggregated whereby traffic between controller tends to generate heavy loads ? * Would you have any information about typical packet size distribution ? 8) Security=20 JP> You may want to say a few words on the security routing issues ? 9) References IETF: just add=20 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. and draft-vasseur-roll-terminology External: please add reference to Bacnet, Lonwork, ... Thanks. JP. --B_3303980433_34110396 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Detailed Review of draft-martocci-roll-building-routing-reqs Hi Jerry,

Again thanks for the great work and time you spend spelling out the buildin= g automation requirements for ROLL.

The document provide an outstanding level of details, very helpful to under= stand the context.

The main comment is that requirements have to be exclusively related to the= routing aspects and there are still quite a few non routing related require= ments (see below, comments on section 4). Some of them also needs to be more= accurately specified for the protocol designer.

Detailed comments below (comments are not by border of importance but in ch= ronological order)

1) Abstract

* S/”The ROLL Working Group was recently chartered by the IETF to def= ine
   routing characteristics for low power embedded devices. &= nbsp;ROLL would
   like to serve the Industrial, Commercial (Building), Home= and Urban
   markets.”/”The Routing Over Low power and Los= sy network (ROLL) Working Group has been chartered to work on routing soluti= on for Low Power and Lossy networks (LLN) in various markets: Industrial, Co= mmercial (Building), Home and Urban”.

* S/”Pursuant to this effort, this document defines the
   functional requirements for installing integrated facilit= y management
   systems in commercial facilities.  “/”Pu= rsuant to this effort, this document defines the
   routing requirement for building automation.  “= ;

2) Terminology: I’ll post a terminology ID soon, you may want to refe= r to it in this document.

3) Introduction
  • Although listed in the terminology section, = thanks to expand acronyms when first used (e.g. HVAC, K-12,=20
  • <= SPAN STYLE=3D'font-size:10pt'>(NOTE:... =3D> paranthesis missing at the end o= f the sentence.
=
4) Section 2.2

  • EIA 485: could you please expand and add a i= nformative reference ?=20
  • <= SPAN STYLE=3D'font-size:10pt'>s/”mbps”/Mbits/s”=20
  • <= SPAN STYLE=3D'font-size:10pt'>s/”kbps”/Kbits/s”=20
  • <= SPAN STYLE=3D'font-size:10pt'>I would suggest to remove “To date, camera= systems have been deployed on a proprietary wired high speed network or on = enterprise VLAN. “ or try to soften this statement. We see more and mo= re IP video cameras installed in buildings.
=
5) Section 3
  • This use case is certainly interesting and u= seful but as written the introduction looks like a commercial brochure ;-) C= ould  you make it a bit more anonymous ?=20
  • <= SPAN STYLE=3D'font-size:10pt'>Section 3.3. Are you referring to the need for a= ssets tracking (e.g. RFID)=20
  • <= SPAN STYLE=3D'font-size:10pt'>Section 3.4, 3.5, 3.6 and 3.7: The text is prett= y straightforward. Thus I would suggest to (at least) shorten the paragraph = and spell out a bit more clearly the network implication in section 3.4
=
6) Section 4
* s/‘routing’ /routing
* Section 4.1: this has been explained in the previous section
* “It MUST be possible to fully commission devices without requiring = any
additional commissioning device (e.g. laptop). The device MAY be
completely configured for network operation by setting a bank of
switches. The number of switches MUST not exceed 16 switches.
“
JP> The first requirement is a 0-configuration routing requirement (you = may want to say it this way) and has been spelled out in other routing requi= rements IDs. The two last comments are implementation specific (hardware req= uirements in this case), thus outside of the scope of IETF requirement IDs.<= BR> * “The device network address MUST be settable and henceforth fixed f= or
   the device without the need for other system devices such= as DHCP
   servers. “
JP> This is a requirement on the address configuration ...
* “ Network setup MUST support device commissioning times of no more = than
   15 minutes per sensor/controller pair.”
JP> Could you slightly reword this sentence referring to the time to dis= cover a new path ?
* Thanks to move section 4.1.4 to the introduction. No routing requirement.=
* I would suggest to remove section 4.1.5
* Section 4.2.1
“A network MUST operationally support at least 1000 routing and 1000 =
   non-routing devices.
“
JP> Can you rephrase ? For example: “The routing protocol MUST be = able to support networks with at least 1000 routers and 1000 hosts” * “Subnetworks (e.g. rooms, primary equipment) within the network mus= t
   support upwards to 255 sensors and/or actuators.

   Subnetworks MUST seamlessly merge into networks.  Ne= tworks MUST
   seamlessly merge into internetworks. “
JP> Not a routing requirement
* “A source device may be upwards to 1000 feet from its destination. =  
   Communication MUST be established between these devices w= ithout
   needing to install other intermediate 'communication only= ' devices
   such as repeaters. “
JP> You are referring to the PHY/MAC protocols, not a routing function.<= BR> * “For wireless implementations, the routing algorithms SHOULD
   incorporate automatic transmit power regulation to maximi= ze packet
   transfer and minimize network interference regardless of = network size
   or density.”
JP> Please do not use “algorithm” since we do not specify al= gorithm at the IETF ;-) More importantly, this (important) requirement is fo= r the PHY layer, not the routing protocol unless you intend to derive from t= his characteristic a routing requirement (dynamic metric such as the bandwid= th ?).
* “Network devices MUST be able to communicate in a peer-to-peer mann= er
   with all other devices on the network without being subje= ct to
   intermediate bridge or gating devices. “
JP> An important requirement. If I may, I would suggest the following wo= rding: “Network devices must be able to communicate in a peer-to-peer = manner with all other devices on the network. Thus the routing protocol MUST= provide routes to any other devices without being subject to a constrained = path via a gating device.“
* “Mobile devices SHOULD be capable of unjoining from an old network =
   joining onto a new network within 15 seconds. “
JP> Could you refer to route discovery time instead (just a question of = terminology)
* “The total installed infrastructure cost including but not limited = to
   the media, required infrastructure devices (amortized acr= oss the
   number of devices); labor to install and commission the n= etwork MUST
   not exceed $1.00/foot for wired implementations.  &#= 8220;
JP> Definitely not a protocol issue (pricing). Thanks to delete.
* “The software stack requirements for sensors and actuators MUST be =
   implementable in 8-bit devices with no more than 128kb of= flash
   memory (including at least 32Kb for the application code)= and no more
   than 8Kb of RAM (including at least 1Kb RAM available for=
   application). “
JP> What if we have a very efficient protocol optimized for small footpr= int and I am a really bad coder ? This is a typically difficult requirement = to express. What I would suggest is to use a non normative language here and= replace the MUST and a ‘must’. The same comment applies to sect= ion 4.4.3
* “The routing algorithms must support in-bound packet caches for sen= sor
   and actuator devices when these devices are not accessibl= e on the
   network.  The cached packets need to be delivered to= its destination
   when the device is accessible on the network.
“
JP> Interesting requirement but needs to be fleshed out. Could you elabo= rate a bit more ? Are you referring to store-and-forward techniques since th= is has other implications than just routing
* “ROLL routing MUST support adjustable router table entry sizes on a=
   per node basis to maximize limited RAM in the devices. &#= 8220;
This one falls into the category of “implementation specific issues&#= 8221; outside of the scope
* “Routers MUST support quality of service prioritization to assure <= BR>    timely response for critical FMS packets (e.g. Fire and S= ecurity
   events). “
Qos is undoubtedly an important function but as such refers to the forwardi= ng plane and ability to prioritize packet treatment using various scheduling= techniques (WFQ, MDR, .... W/ or without dynamic priority, feed-back, etc) = and congestion avoidane ((W)RED, ...). Now we also call QoS routing the abil= ity to compute different paths for different flows. For example compute the = shortest (constrained) path with respect to metric X, Y and Z where X can be= the bandwidth metric, Y the delay metrics and so on. Are you referring to Q= oS routing here ?
* “Sensor/Actuator/Controller addressability MUST be unique site-wide= .  
   All addressable nodes MUST be accessible to all other nod= es in the
   internetwork.
“
JP> This is given :-) You can remove this paragraph.
* s/ plug-n-play/”plug-and-play”
* “No bound information
   from other nodes MUST need be reconfigured.  “=
JP> This comes back to the 0-configuration requirement. Thanks to aggreg= ate all requirements related to 0-config in one place.
* “ To support high speed code downloads, a mechanism MUST be defined= to
   download firmware to devices in parallel yet support guar= anteed
   delivery. Devices receiving a high speed download MAY cea= se normal
   operation, but upon completion of the download MUST autom= atically
   resume normal operation. “
JP> If by mechanism you refer to a default routes to reach a management = device then you may want to say it (be routing specific). The last sentence = is implementation specific, this out of the scope of this document.
* Section 4.7.3
“4.7.3. Diagnostics

   To improve diagnostics, the network layer SHOULD be able = to be placed
   in and out of 'verbose' mode.  Verbose mode is a tem= porary debugging
   mode that provides additional communication information i= ncluding at
   least total number of packets sent, packets received, num= ber of
   failed communication attempts, neighbor table and routing= table
   entries.”
JP> Very interesting, I’ll send a separate email to the list about= this topic.
* “4.7.4. Trace Route

   Network diagnostics such as PING and Trace Route SHOULD b= e supported
   with extensions in Trace Route describing wireless parame= ter
   information when applicable. “
JP> Traceroute uses ICMP, not routing ...
* “4.8. Compatibility

   The building automation industry adheres to application l= ayer
   protocol standards to achieve vendor interoperability. &n= bsp;These
   standards are BACnet and LON.  It is estimated that = fully 80% of the
   customer bid requests received world-wide will require co= mpliance to  
   one or both of these standards.  The ROLL routing al= gorithms will
   therefore need to dovetail to these application protocols= to assure
   acceptance in the building automation industry.  The= se protocols have
   been in place for over 10 years.  Many sites will re= quire backwards
   compatibility with the existing legacy devices. “ JP> Well ... I do agree that both Bacnet and Lonwork are important legac= y protocols. That being said, we cannot design a solution that will be compa= tible with these protocols, the IETF is responsible for IP specification. As= you know, we can expect Bacnet to take advantage of the protocols defined h= ere thanks to its Bacnet over IP version although IP is used by Bacnet as a = layer 2 with Bacnet routing on top of it but this is another debate.
* “4.8.1. IPv4 Compatibility

   The routing protocol MUST define a communication scheme t= o assure
   compatibility of IPv4 and IPv6 devices. “
JP> Do you see other requirements than 6to4 ?
* “4.8.2. Maximum Packet Size

   Routing algorithms must support packet sizes to 1526 octe= ts. “
JP> Two questions here:
Q1: Why ?
Q2: is it a “must” or “MUST”?
* “Route adaptation also reduces latency if the new route costs consi= der hop count as a
   cost attribute. “
JP> Not sure that I completely agree with that statement, could you elab= orate ?
* “4.9.1. Path Cost

   Path selection MUST be based on path quality, rather than= signal
   strength only.  Path quality includes signal strengt= h, available
   bandwidth, hop count and communication error rates. ̶= 0;
JP> This is an important requirement. I would suggest to phrase it a bit= differently by saying that the routing protocol MUST support a range of met= rics and optimize (constrained) path according to these metrics. If I may, c= ould you have a look at the following document http://www.ietf.org= /internet-drafts/draft-mjkim-roll-routing-metrics-00.txt and provide com= ments/suggestions ? Thanks.
* “4.9.2. Path Adaptation

   Communication paths MUST adapt toward signal quality opti= mality in
   time. “
This actually translate to the ability to support dynamic metrics. Look at = the ID referred above.
* “4.9.3. Route Redundancy

   To reduce real-time latency, the network layer SHOULD be = configurable
   to allow secondary and tertiary paths to be established a= nd used upon
   failure of the primary path “
JP> Let me make sure that I get this requirement right: are you referrin= g to the ability for the routing protocol to dynamically recompute path upon= failure or the support of that is usually refers to as path protection wher= eby diverse paths are pre-calculated. It is an important aspect to clarify s= ince diverse path computation is certainly not a trivial issue.
* “4.9.4. Route Preference

   The route discovery mechanism SHOULD allow a source node = (sensor) to
   dictate a configured destination node (controller) as a p= referred
   routing path.
“
JP> Not sure to understand what you mean by “dictate a configured = destination node as a preferred path ?”
* “The default MUST be asymmetric routes. “
JP> Do you mean that the routing engine must compute asymmetrical paths = (paths to the destination with different cost) and these routes must systema= tically be used ?
* “4.9.6. Path Persistence

   Devices SHOULD optionally persist communication paths acr= oss boots
“
JP> This is an local node issue.
* “4.10.1. Device Integrity

   Commercial Building devices MUST all be periodically scan= ned to
   assure that the device is viable and can communicate data= and alarm
   information as needed. “
JP> Isn’t it a system architecture issue as opposed to a routing i= ssue ?

7) Traffic Pattern
* Interesting. Does that mean that by contrast with many other sensoring sy= stems, the traffic is very much localized and aggregated whereby traffic bet= ween controller tends to generate heavy loads ?
* Would you have any information about typical packet size distribution ?
8) Security
JP> You may want to say a few words on the security routing issues ?

9) References
IETF: just add
[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate             &nb= sp; Requirement Levels", BCP 14, RFC 2119, March 1997.

and draft-vasseur-roll-terminology
External: please add reference to Bacnet, Lonwork, ...

Thanks.

JP. --B_3303980433_34110396-- --===============2049105802== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============2049105802==-- From roll-bounces@ietf.org Thu Sep 11 03:30:09 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EDBE3A6A24; Thu, 11 Sep 2008 03:30:09 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 692053A6A24 for ; Thu, 11 Sep 2008 03:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.348 X-Spam-Level: X-Spam-Status: No, score=-5.348 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HS0hSKvWeqFj for ; Thu, 11 Sep 2008 03:30:07 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1EDE93A67F2 for ; Thu, 11 Sep 2008 03:30:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,378,1217808000"; d="scan'208,217";a="153353470" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 Sep 2008 10:29:18 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8BATIDR015757 for ; Thu, 11 Sep 2008 03:29:18 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m8BATHR2015225 for ; Thu, 11 Sep 2008 10:29:17 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Sep 2008 06:29:17 -0400 Received: from 10.61.97.226 ([10.61.97.226]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 11 Sep 2008 10:29:17 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Thu, 11 Sep 2008 12:29:16 +0200 From: JP Vasseur To: Message-ID: Thread-Topic: PCE WG Meeting in Dublin Thread-Index: AckT+T23sXEQLjz9Vkq+xb+JwvlbfA== Mime-version: 1.0 X-OriginalArrivalTime: 11 Sep 2008 10:29:17.0608 (UTC) FILETIME=[3EAD0280:01C913F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=885; t=1221128958; x=1221992958; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20PCE=20WG=20Meeting=20in=20Dublin |Sender:=20; bh=J/Zn5GzxB0D850MeKBzwfAlFA5KjAC/+Qnvri8MTDiQ=; b=igSrQY1CiRXUDEUCLxqR/KlCWT4AP8+VEjs42ExYL8TtwrxWKQIZFrF3k5 fp/r1nhART3YICPnqu3/L1ncfiVwBkQGMEcQczCurO++h8+cRTjkITnMVCem rqljWdAXVc7MQ0BNUd5AL6Lvi0i9hupkshX5HgW2j6t97UCHEpSsM=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Roll] PCE WG Meeting in Dublin X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1393733883==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1393733883== Content-type: multipart/alternative; boundary="B_3303980956_34183692" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3303980956_34183692 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi, Minutes takers during the last WG meeting in Dublin, could you send me again your notes (sorry I has an email DB crash ...) ? Many Thanks. JP. --B_3303980956_34183692 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable PCE WG Meeting in Dublin Hi,

Minutes takers during the last WG meeting in Dublin, could you send me agai= n your notes (sorry I has an email DB crash ...) ?

Many Thanks.

JP. --B_3303980956_34183692-- --===============1393733883== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1393733883==-- From roll-bounces@ietf.org Thu Sep 11 04:06:07 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A1C93A69C8; Thu, 11 Sep 2008 04:06:07 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 551C23A69C8 for ; Thu, 11 Sep 2008 04:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.928 X-Spam-Level: X-Spam-Status: No, score=-5.928 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BG34jeoR1Bsd for ; Thu, 11 Sep 2008 04:06:05 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D063A3A684A for ; Thu, 11 Sep 2008 04:06:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,379,1217808000"; d="scan'208";a="20453520" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 11 Sep 2008 11:05:19 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8BB5JdW022091; Thu, 11 Sep 2008 07:05:19 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8BB5JXA029698; Thu, 11 Sep 2008 11:05:19 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Sep 2008 07:05:18 -0400 Received: from 10.61.97.226 ([10.61.97.226]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 11 Sep 2008 11:05:18 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Thu, 11 Sep 2008 13:05:13 +0200 From: JP Vasseur To: "Dearlove, Christopher (UK)" , , Kris Pister , "Pascal Thubert (pthubert)" , , Message-ID: Thread-Topic: [Roll] Detailed Review of draft-ietf-roll-indus-routing-reqs Thread-Index: AckTTbgqoQKRXfGitUeUUNsgwdH72QAB6GvAACo6Y/I= In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 11 Sep 2008 11:05:18.0873 (UTC) FILETIME=[46E3E090:01C913FE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4248; t=1221131119; x=1221995119; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Detailed=20Review=20of=20draft -ietf-roll-indus-routing-reqs |Sender:=20 |To:=20=22Dearlove,=20Christopher=20(UK)=22=20,=0A=20=20=20=20=20=20=20=20,=20Kris=20Pister=20,=0A=20=20=20 =20=20=20=20=20=22Pascal=20Thubert=20(pthubert)=22=20,=0A=20=20=20=20=20=20=20=20,=20; bh=zRSHtmv8bFHm8Cv3Dw34o30Ucc0Rr4WRYmUVl+h6l88=; b=fGliRLD0W/weY7rCwxaFOW7P2vc9eIqNMirn8w+Z1ROvi+wMri9cC/IYr2 Cd8cqQ3Kda+YjVxDauEHL/IS0uZHDjQ4WcsZI5lPHsYu1HjJL9iBLq3f2O5+ 0HxMMAr8fS; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Roll] Detailed Review of draft-ietf-roll-indus-routing-reqs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Christopher, On 9/10/08 5:35 PM, "Dearlove, Christopher (UK)" wrote: > >> 15) Section 2.2.2: "Since publishing the data is the raison d'etre > for most of the >> sensors, it makes sense to build proactively a set of default routes >> between the sensors and one or more backbone router and maintain >> those routes at all times. Also, because of the lossy nature of the >> network, the routing in place should attempt to propose multiple >> forwarding solutions, building forwarding topologies in the form of >> Directed Acyclic Graphs oriented towards the sinks." > > That contradicts the routing protocols comparison draft which demands no > signalling traffic with no data traffic. This requirement has been discussed during the WG meeting and should indeed be reworked, I agree with you. Any proactive route maintenance > needs some signalling. (Note however that it doesn't however necessarily > require a fixed period beacon, various forms of backoff - supported by > OLSRv2 incidentally - can be used, depending on mobility/dynamism and > also how it can be recognised. In some cases the overhead can be made > very small - possibly even comparing favourably with traffic-dependent > signalling for actual traffic levels, although not meeting the absolute > specification of zero for zero.) > > I think this is actually a issue for both documents, in particular > for the routing comparison document which is rather absolutist in its > limited set of requirements for existing routing protocols to pass. > I think there is the distinct possibility that you will exclude all > existing protocols on these strict grounds, then later determine that > what you actually design ends up violating your strict conditions in > order to support requirements such as that quoted above. That would > raise the question as to whether the process had been right. > > I think this argues in favour of looking more closely at the existing > protocols not just what they do with default settings, but what they > can do if pushed hard (for example the previously mentioned fisheye > support in OLSRv2 and the possibilities for backed-off beacon messages > noted above) and what is fundamental, and what is not, i.e. can we > extend rather than replace? > > Note that I'm not quoting OLSRv2 because I think it's the protocol > ROLL definitely wants, but because I'm familiar with it (I'm an author) > and thus have examples at my fingertips. In particular I know we've > put stuff in whose usage may not be obvious, and we haven't put stuff > in because it would be a step too far (for current requirements in the > MANET WG). I'm sure other protocols have similar possibilities. The > choice between use as-is and develop new is easy (develop new, no one > in the IETF has already done exactly what you want, because their > requirements were different). The choice between develop new and develop > modification/extension/new mode/whatever of an existing protocol is > harder. I *fully* agree with your comment. The answer to the first choice is pretty straightforward. And we will of course look at the second choice: if we can find an existing protocol that can meet ROLL's requirements with reasonable adaptations this would be a very good outcome. We should avoid developing protocols if existing protocol can be reused. Now we all known that protocols can always be adapted and will satisfy requirements to a *certain* extent. That will be the hard part. Now we also need to bear in mind that the protocol needs to satisfy the requirements *without* to imposing drastic overloaded of unneeded functions for constrained devices. Thanks. JP. > > ******************************************************************** > 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. > ******************************************************************** > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Sep 11 05:45:02 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9019F3A67C0; Thu, 11 Sep 2008 05:45:02 -0700 (PDT) X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4AA473A67C0; Thu, 11 Sep 2008 05:45:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080911124501.4AA473A67C0@core3.amsl.com> Date: Thu, 11 Sep 2008 05:45:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Home Automation Routing Requirement in Low Power and Lossy Networks Author(s) : A. Brandt, et al. Filename : draft-ietf-roll-home-routing-reqs-03.txt Pages : 18 Date : 2008-09-11 This document presents home control and automation application specific requirements for Routing Over Low power and Lossy networks (ROLL). In a modern home, a high number of wireless devices are used for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure) and advanced controllers. Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home control and automation environment. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-home-routing-reqs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-09-11054129.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --NextPart-- From roll-bounces@ietf.org Fri Sep 12 02:56:34 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDE8228C0FB; Fri, 12 Sep 2008 02:56:33 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504183A67EE for ; Fri, 12 Sep 2008 02:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKvc7mr9wK3v for ; Fri, 12 Sep 2008 02:38:14 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 9B34C3A6C03 for ; Fri, 12 Sep 2008 02:38:12 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C914BB.415C7F08" Date: Fri, 12 Sep 2008 11:38:04 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3EB68DF5@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-03.txt Thread-Index: AckUMiDrdXqJlL/LC0yvf3BrmcP73AAhY8gA References: <20080911124501.4AA473A67C0@core3.amsl.com> From: "Anders Brandt" To: "JP Vasseur" , X-Mailman-Approved-At: Fri, 12 Sep 2008 02:56:32 -0700 Cc: Porcu Giorgio Subject: Re: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C914BB.415C7F08 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi JP >Thanks ! Could send an email summarizing the changes, and tell us if you addressed the comments that I sent you ? Sure. Delta spec is attached showing all changes from v.02 to v.03 We have tried to incorporate most of your comments and suggestions as well. The same goes for the comments posted to the list by Zach Shelby and some few others we received directly. To all of you: Thanks for taking the time to review this doc. It is beginning to look right. V.03 has no additional input from TelecomItalia. All blame should be put on Jakob and me. Cheers, Anders -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: 11. september 2008 19:16 To: Anders Brandt; Porcu Giorgio Subject: FW: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-03.txt Thanks ! Could send an email summarizing the changes, and tell us if you addressed the comments that I sent you ? Thanks. JP. ------ Forwarded Message From: Date: Thu, 11 Sep 2008 05:45:01 -0700 (PDT) To: Cc: Subject: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Home Automation Routing Requirement in Low Power and Lossy Networks Author(s) : A. Brandt, et al. Filename : draft-ietf-roll-home-routing-reqs-03.txt Pages : 18 Date : 2008-09-11 This document presents home control and automation application specific requirements for Routing Over Low power and Lossy networks (ROLL). In a modern home, a high number of wireless devices are used for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure) and advanced controllers. Because such devices only cover a limited radio range, routing is =20 =20 often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home control and automation environment. =20 Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-03 .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------ End of Forwarded Message ------_=_NextPart_001_01C914BB.415C7F08 Content-Type: application/octet-stream; name="draft-ietf-roll-home-routing-reqs_delta_02_to_03.pdf" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-roll-home-routing-reqs_delta_02_to_03.pdf Content-Disposition: attachment; filename="draft-ietf-roll-home-routing-reqs_delta_02_to_03.pdf" JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nN1d6XMcx3Uvh6ZEQy5biekoh5NM+UsWLmHU5xz+pjtUybJMocpVIfUBXJzW LgAuAIH879M908frmd/M7AKgqUAUq7qn7/d+7+jX3cuXGcu5yJj94xPz5RbLvjR/j7ZeblW5tP81 BTQ9X2af7G599LTMuGmost3DLZbXdS3roinnmZR5kZWlzHaXW7Nse/dvW6Ymq7Ldr232v21O2Mzu H57Nvtku81oUJZ8dbO/IvOaq1LPLmLyOybO2qtSzVftRcz77ISZPQvlp/HgUk1lTXrJq9tf48Swm k15tVV1I02k7vqx9rzZ5FLrK4scvY3LVlFda+P7tx6uYPG+Tpn/TXte1zkub4gXjhnazj2PNHI30 SXckW74HZ7ofk5ctfQpLie93v4pMsXx4EvhwCvlAuLNCdD6IyctQnsWPn1E6d6ZsPx7S9m1SN2vm 3GArbwjFlTDkKWf/G9d0EPoia76IydehnHz8MCYjJp5A8s27nEjIJ25AvdNAnX1IvX1EvYsudTvU u4zJK9rKo/iPdMUh+aRHvKrwjLDlZ6F8FT8uY5IgLs7qhLYnJAUwXcRRzayENGJQ1Y66sipzXSuj T3b3t54Z2fLtc7iUb0M5GXQF+XjV4eOOH2rHCYQd7/PA0FeRdecxeRKTURwOIMP+iBj6VUzudbnQ 4SJh8yow9DWkgghdsfiRJGuy9J2yYmWuVCNYkjFD+9kuFawemxJxm0M2L5G2eoJgAmBgkgQ8ex02 NZbDyj9jtUeFnTorzLd69l3omcz8HI18QKcbki/QIleQyjyUiwmdIiAXSLLqYtEvMGKxNaCqrFpt kxhQnxmwrZ8EEPuFGLjuxSTRVVHreK3VCiVngnOjfT8Pa3oFyXuCaEYofdEDhun/T1CVrBDGjums fDmnyCecICAH5QknfFd1Z9WMs9mzUPotnOgRghRZHpne92T5iel1qK5zg+JMsyrXRWT657tbfzGF RaZLVeVFmems0tnqYOvwVu5ZWeRFlRUVzyvroT2b/Q91hzwOltA6ZaH8Y6isopglWuF2JoPw8Smy Tle0064uEbUmXR1BiX6KOPmyazIUTxQUBvoSdXWKVp31pjq46q97BOLWMwY1v0X0uYYzXaH2iRPZ 2GGDIs1Kr3H3J6cH/C3oj2XbBWONzuPa4LcsGp0n2mG+gTO+RCvC9v6H3jwayW7Gq3TOJU/t/T7S X4QYh6Gc6McdpP+S+ZL2pBUYiqxiEcoXcKjjCRE7WH+oq96qhsB4BKeSiICv+rLP+KaVpX2j0bjZ cDKmjI4tBE0+/XKwaHXLDalmucqMSci1aFUeMQLSA7FVt7VgmVZVbfWtsX6ZbBXuneyLC5EXdB5d NS9F0ap5oeXt9XyzDS8kz5lqF/1d8AfI1oT4A+TrVdDzxJMl/mu0E4ewPIrqcfx4EpNJr96p/VMf xIlGPYtwcmbUOEWaZzvCKA4nyJ/ENbye2EnFNb6IH5d0uh2fqLPT6gmKXQM2MD1ydASt7x6lfvNp tGXQkV11p4I1kZlfVAmfweajOm/Izz2A7edo0djWQEVEWsGdaEYXMO79r5AtO+jZiBR4p2hSF2j9 eNLQ18ng/LMNyr3Z9KuhZixx7j16X0MJ3Qvl5/EjSS5CORHbOW0fZvcioH8BCRlnfz5BnSGfKaA/ 6ymDFL6wPGHPuPT0oiPW6SNO1VM0FNmnLOgCgX9L7PRF8OTgpA/RSNd0JcD5ADsmGSIqKfohJcjy p0TuoivdJYlzpVVPkKDdEP3kIxIE0ZOD64DjJJASkgfIShCjFeXkR9qoK1KpHBA6QIWS0BloMVJ+ TekY5KDvJKYkezHB3X0ETsKdBNJeDs5g1ahGSawZmonRCHUiB7jm6wn6HU7Q7xjJwbTwACsGlduQ RhoWmcGubmolxmyDj3A1YuoxTRQ6OQlZToQ0MyRT19A2rJBMJOwBQFzQJFjzix75UttAgAidLKyw 4d6VzDqBt5eJDXbx0DXCcdRVkIn9CZmYTwg6pG9iEIFMREp+BykRB8X7xkjJUzipYkJ8oO27S5kQ vc3CpwHS3/Z0u02WobyOH/1ZRNiQuI2IPxQKvUdnjOwfiGyteaRWcL/77h2pdeyVJcghZDjcasDw 6xCgxl2EH5DdT45OAe/2aadBoHuHNlbgQKRDbuKrD8GM0GpdLY2PDMc2aFzjsNoBmj6Z0+cTlISU xk7ICimEgaPtMXPiz4qaEAIIFpCD+WguvoDmJqKfmCPsYj2fBXvyhJInJHfD9L8grba7qns4AEs2 GzcSFVIe2zt3qD3vBzVPkSRAD3oK3htERje42nCEFj10tQHg+yLoL3B8a7TnNxPbtgM0qaFdNxSl ESvghyx9cMUikewAoJ4mpuEIlRN4k+OR8y44dAqJJVoHPuuN5QsICaJH13eMLimfAfpeQJb3GNVx jO7UZHg9uo8g07MYtvymFgPgOBId72T7NyqGcJxE7ND8WijKUrjQOVTCPoaXXEMYulUDlHTPgbm/ fss+qppEO4EFx+0jiBO8BXlbdhlu5QEDAq7qxwkpP4GzyhABp6ILe6h9/7zWyNur8c3zskeJVp/d YMd+AVf6asIvccrczyO5L0jASXB8jCQCRkhJ+/1e1bhOq8wJQV8j2va3rml5/5IgYbMFF7RvyS61 43R05GAqVN6LYFrwzm801FQIMZ5lx3BV34K1kwKThnoV+08vEHinwklTG4HVBCLj2TKAJPF0iX8A Ay8Jeqcg25m9XsPlxP4FvJ6Bj5n7d1TNR3jrC7vc0TsciqYAfUgge454cjZRfgKpsoHPeYbKr7qr GjZITxAmoVcCMTfmNRCDaz8OnfStb3DXC7VfIO8YhtoP6UfgTWD0z7vMWcd7nqIjxsEiKtz1j5wS cIByMn8cjIPe89Tp1RINNXT65RXu1B1HqPug9sDa5WI8rPj7WHODzUGGmJZEGMfUMLm9C7dpcBuH 498R6Hn86NeU+NIkSnKMOiWCAg9cexe/O9JF5t8Lmlrp6DuoKfrxJTaohfo3E9KrdbdRWJqXd6uw wsc5ao+j0vAK8Abxe3jddegoYVQ8gEGK19eADvYymkQwiKdLjvXjbfSP4keSjMel1/RjSJL4zUlA 2dCdN78e0ghuSMgG/6OejrQog/HRQ9rKl/Ne++ipdlC2B1k/FQzZQ6yHKMxh+Sv6Nfo9PxWFsXlM O1UYAArpncHPkO6ZunVEpDBe9MeWCe7Tr2FXcSpD13rHWQ2xfELbb6ibLBSGdNPoqcGb0lLA9K6t m7zdvZ/K6SIqp2NEmykYklGPEeKJV+d80cbXHVUTY/crbfmT+BHuKRNXvFs1CoQl6puR7esu/zqB r+SuC9A4yduUKdkGXSWvDzrlVjZv+mAlfB19OpS8bdngwUpypNLeqO/fi3Xn2yWnxx3EJX4dkysE KOIdHyMpJiamd5iD7822O7qulI7d7f00zjEGUoj6IBcdb7uG57NI1E/DJOk5IuFqPHPc4MQ4ObMM uuQLpNLJs7yItSTSAAx1emjqNUgCK181eZAW2GAW21WRUdED7nwcEEZuGl3EJLldDs8qSESs91K5 P9qNFCAJ3p7RgX15EokLyd7GiCrAFAlR60w9g5u86Qo9BnglGp9vwbADVnCXIeww9SLlZqfX8RAB 3vOG70dxTO6kq1p6qnr00A7HDOPyiKmA+8ah206AEqMxMyIV58j6ElGIjxAO6UcA3qGYW5jcywDe K7gOeDLQO8saPtwkLtEmZ1H09c3f/2mQ4CwTVdHoFftGZvMHhinf8fuPP4fyHyk9p+lRajM9WUj7 LKjQ9V2+RhJVbX10uvj+O8PWKwPif47odNOHhiG53vNCaxjWfl4YXlcZMt7hI1rN80ploixy96KM PKaOcW7iXJBtytQPmcA4ujfiNv20iywr1F9DijkrPnz1Bl5Z2OCE+AxxbypKMGTSgCEgXU1dKk96 BTr9CI6aIQLAM2x8dgvhnZxxj8b6+vf7B3Vx74cY6rocEIRR80MOJCNUyesGaF42uAmOzU+MMWHX deoMN24eRy/ap2fkU5vLfcjSyB0cGLnsVu28joD3l4nGhKH4RKN2CZQc2bhv9sFN3h3JCjrZWpAd 8R6S3sQNWveNHLyYiH80J/pWZM1DRH+7noDT6FqbCbcqnRxtRjnAP7Wzh8rhFVd8cB/2m0YjT8k+ vBkIdSO+M5SowfGADHwmtKRJqPEpI5UU1slq31Nrwe/UhZEql0XCM0gHvC2f8usHnLq37K/W2qhx uuKp22KJx+lVhHELonOkChZYJJm60yfvktsfG5nk0NALXKIHx7X/xVvmizRudKo9QADGSnf0pvFP IC2GsCaFoGzSkU1HrX9rjITzb1Vb8mYVpdJ56ZZK9rMxRE+8CKIToyIlN6w/7DkUBXpP1umK3mHo aRwm9BvYM3HJLH/p2jPKOqANCZd/eMsY5QW3Wz06e3Bxz2D0BVoTkTvo8+PNITRm2Ge9IvxE2sDo rIR+UqnA56q401/qEIWyJBrg8+ahr5RSP050NXXb8m3bIKnqrhQMxRiBhU1ijF17ZcAHf25uFcsJ YvLOT7dYLegFn92p4CshyXpn6e+2CGbUwl1HFqS2vxXTEJc8U4Qvd4l6hL/bAn+/K/khFKKeO75h 54rdPmIOwXMSQR2XfLJfg+9FCQ7gTd05wtFQeA3s13DgAAaDl3SBANL9M/PkNTs+DIW+Nbw3iNvD h4TwN+l6Hpd9VXLTX4Qi2wjAlIHftOnG4nititRXeWbEC///vVnbvlFl1+bvV+bv38Y0nkmpTFdl 0/tyS1a8CtnF1nfpB1vO0vIRjenqFr5pWZWkqSut0mzhsod/MAtsF3Kbbo6bGR5tGTVYmM912fbR ZmvWhDdVpW2Gu4zSITM31BExuzBZ+6ODvmpDOd9JS8Z2gLmjqvbTcFmt2qq2E61cxg7gMqZdM7zL mnbN1HzVZtK+kzbTDjC35JLNT8Jd3/ulWpaub6CqrMjLWtofiXR2Q2nhTVSlcuMRlYzbPbG1Uj/7 hwc/f/jOO+8++oU1Vx895Yw2l1WuzHbcKY6fbe8YgyMKzWdNq+0dkfNSFYUp4SJnqqRVbJc7ZmdX KqPoQoXnp+898j+p2/S9U4Xz2l8+X/3q1023xgcVVU17Cx28/+gf/8kqkEIzKWmNpucdZXpjImn6 m8cPHz5+z3QrRa5kVQ50+9tmWhV5nD/Y4z8/X33w8Nd2oiIvrfWDPb7b6LmCrzXJf3kQFi9zxaQl mb/I8/6/Pvq3ba5yJuR6nf3748cPH/zODG+4XSla8sHz1X88/M//en76wAxU5Kwqk8n//HeP33Nk UJ4KDz741QMzLbNx1JXm6VJD8v1H775PuRK5HWMI66nvCbWtak3VtstGtR3LmQEXLR9T20yaupqX sKlkPJYu0sqp2r5FN6na1rygukyLMuoyLcuoy1zG6zKX9brMV20VlKAZXlBdprSiukwpEXWZkjLq MpfxusxlvS7zVZtJ+07ajFYDavv+LtWydB3MNxMRJafAFrKoE2D7D8stocy2hZaPANs6saZuzWBT U1CF0kVaOQH2bbpJgC1KSY20cL9Z3JBUlDoaaZ9x3PZZx+1QtaWcohlJjbQoSk24LYpCBm4bvRWN tM84bvus43ao2kzad9Jm2gH6wL7HS90M2AVTFNguAhmBzT3wea1FUj4CbF4Xtq4ncaep2TrE0kVa OQH2bbpJgV0ITbldyKjGRNFuZBy5VUG57bKe275qSzmi0/wAntu6EJTbRstFbmvFI7ddxnPbZT23 fdVm0r6TNtMOAIB9f5e6GbBVzdcDtigLtS6wRVkqgshOU6MNJIFgUjnV2LfoJgW25pJyWwsVua2l itx2Gc9tl/Xc9lVbFgqa4ZJyW2lOua1kHbmt2hhaO4DLeG67rOe2r9pM2nfSZjQfAPb9XepmwJYV o8BmkqfAdh+MvmQ1S8rHNDZn3NTVAjblrGKhdJFWTjX2LbpJgW3oTLmtuIzcVkJEbruM57bLem77 qi0LXSdthnHKbSlrym3pfVTbieRl5LbLeG5Lv0Vop+arNpP2nbSZdgAA7Pu71M2ALdrbfdPAFoIV 6wJbtOF9j8hOU2G8BgLBpHKqsW/RTQpsUdWU25KxyG0bCg7cdhnPbZf13PZVWxYyknEDeG7zQlJu c2qfud9e2QFcxnPbZT23OdlEhU7aTCEHgH1/l7oZsFkt1gO21LaD9YAtjSEjiOw0lZorAsGkchoV uUU3KbB5ap956yY6klL7zFP7zFP7zKl99p20mdQ+s9Q+G9JEbjNqn1lqn1lqnxm1z76TNjPoitzf pW4EbF4nrog/EgrA9h+W7c0XWj4GbCPjpm4wBmlTaa/7+9JFWjkF9i26SYHNUvvMqH1mQkZuu4zn tst6bvuqLQupfWaJfeZ1Yp95TewzD+cfZgAej0rs8Dweldiphap20qGTNjPoitzfpVqWvjTDyNIG IB1slahVyC5cVungVtnKKmq7v2and3vSU2idl0V7ReD5qT2wKaQ92X93254Ji4rP3tvmueS8NJ92 ypwrLeXsne06Z0ZRc1LvkU1VxlrNfmG60bk2mnv2y21hLE9dlCHI/5eNrlIMz1+bvarxcej82TY3 9ctiJpozhc76d4zqKWVRZTuy+UdtmhOlN73kzhr8FNx52VM/4T9v75iO6lJVzUWKkL4k6ROSPvUN j8jHbLAyreNO0QeJY0RFip8CcRZ+jXQtdL3Hg4RyDU8HGlJCzUn6DDWkPa+SyjG9SO4mOBkX4Zyn EWoRTnLarFI1kfGYbWX8TmTbXvNVf1fRvhORJtOee46cDeB5mDuu4WIdwBtavXXAzz4M18E8gEQt KYBc1gNICE0BFLJ3CSDjjfh/7Oz/FYLIvDOPhH0Cj4MBCB0kmsE1vARSX7XvnMP3C5L+0Dck76c8 2Ep7kd39oomrRcfcS5QKnmNoOB9ouBpYUKAEnezrgUWkVHENl0llLFhOnPwFibdpQVaIxMsBHQ4X PGwphtSRazhsKfrktljKxz2Wn4iOsr+M6xZ4tQZST8gCd3zD4wHKnCMvxSmF/wMpcgLAZW5kc3Ry ZWFtCmVuZG9iago2IDAgb2JqCjUyODQKZW5kb2JqCjE0IDAgb2JqCjw8L0xlbmd0aCAxNSAwIFIv RmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nN1bW3MVNxIO2QU7J1SSrdrXTc2y+3C8xRl0 Gd0eAzjBKcLFOLWVMjwQ33DwBYy9kF+Rf7NP/If8IVex0kgttY7bxwdsAmuMXd26trq/bkkzPc8b 1nLRsPADxMr2gDXf+d+NwfOBbWX411dgemW7ub40uLZoGu47ds3S+oC1zjnpdF/PGylb3Rgjm6Xt wfJwYc60TmjDhztzI9k63hk13C/kWiH3YlOpoKniHOoDuR/rNR+OSuHNQpb+j0vhOu4fp7J62MyN BHOutWq42vcyzPr+sV46GCCQ63nW/VI4KuRmIdfyUPu4f551RE21W8gtTI6tNRQ+wb1gqG08/9RT HRRyPzdFS9kp5AYlyh616uel8AXWNdQHrSsm2k4PH8w9Wvp+IJVunVEeNkurHitrpf8zSj5Uj1b9 M1W/V9kaSkVuykohIm1eatPLN780uD8QXDe6E12rTaMaq5q9tcH6qTxE8dZ2jdHCTxa8xM+29Euc jHt3ZKxjjGuBycXvjq3aOwN3FUK21o7JEgJBWDy3nU2L7+Li36so3P89VhSjZW2H9yoKC3/7MHY9 hzFAlslhJpAouK3mMFQHHM4E560czmcQviLxvkm57hp2reJPmrGCU+sF16bXj9eAaGTU0FnEdCFs KzqskB/IYLmXZVvBYQuL+ccjXCjbGlGER7gSXOmsNMXOVGW6q2ZdHnIciDJ59UNrx/owpGntSGWL dviZase6llmsHUFGZJYB5T6wnqSPS13lAt6nfQPrJR0uZzHvkX6xQW2XY+6r/TEs+y933Vmqu/Mb beUC4gPuOJ3f+CzS5PBRFkZaZQh/PN1stp6N2FW0cfUGF3R++h2eOw+ZIxHHz6d8v34+rl2ccLkJ 4ZX6/8gPuOpN8XKSpTzV+UOKNmHYba9GbjO7NXhQF4R6VtdPsHRqq6CrsQZ1TbWmZlVi1//lFxYX cJphnvQSbgz8RhqOYtbGMSKrWK/LzqqecZHpVGZWvHZEYbc8y2Vp2msOBolqjBOsJK3KeOTYAlaJ 2DQMIrvEhAkS4/v10yfW9+tFg6a90DBIZOIEK0FdspVG97b+3v/+cu6XHEw7fYDzoGiN87eG7HKd EuDntgvx2RiRfO7Cp3/688VLl2ZmPwvOd22RM9zbx+1OcLh5XJgbqVYLrfzJ/+u//+2SP635GKUs xzUX5nwh68xw5srsVyGgex1KiVs83Pl8tr84jNLwI39ssnGKyw/3vvjyor8BcV/EdBntH34yf1To bCn6518vhvNiKzvt8Phf+2LtaaNULVgme9H8cExIPiZZudFME2xYq5oUV4RkGsUViJY5rkDB9oA7 Jqr6MMqGL+biSCvDeGzFreOoU9W4CiGnGaYKIUIK7E9CSpf9Sciu+BMwyZ+ATf6Um0YlScwI7E/C b/fIn0Q4kII/CQGDhAlEnq+fXuT5etGgaS80DBKZOEEVQs77Us88dAh/7GA2nu0uPNyb8b7ctdxL ooeX50am7TzY7fCLT2dnvHO6tnOdrCq+vPjVX2Zm387NTtrThdHuHX1vwp4enSO5zpGu0ZOKY+HG hEO+2zC1QxrHMUotEwWllouC0sQAShMLKIWmveZgkKjGOAGgVIMYkVWOFZQqywpKEwMoTSygFJr2 QsMgPZMmIBzy/C41mHQazCdBJJsO2EIwPS2wRXxIBIgc6yq40wiCVeMK2KcZpga2UpW1VTz3JJUa WaydGLB2YsHa0DRqTmNGVdbuXBV+O4PCb6dR+E0MWDuxYG1o2gsNg0TGHbfTnN+lvh2wO26nBHbH 3NTA7rjDiKy7CuksRiRuXAP7FMPUwO6kw9buom1ApaxYOzFg7cSCtaFp1FwaJDLSYWtLuBsmVuti 7fAaIVs7MWDtxIK1oWk8DGnMxAkIYJ/fpU4LbHwZ4G7KA8kReMfLQETVWKuCuR6CBZG4MYHkdxum RrKP7ti8/kBbzOs7FvMmBsybWDAvNI3HXok25DQBmJdXl2vBAQlhEI4u18CAeXl1uc5Ne6FhkMgQ zxPO+1LP/jLgvVV0H9llgDkxne9Jy9S0W4vvig87Y12lcQo5VtV47AHfuw9TOyTnEqOUC1VQymVX UJoYQGliAaXQNEIvDRIZLjFKmapOyF41BaVMohNyYgCliQWUQtNeaBgkMnBwOeKQ53epb3Vm4s5W lwHlVA3sVOD1JHlVPQHXXReeB3FNdQzP5qBuq2pZYfpdh6jxzMAnEsvRwZgJdDBODBg5sWBkaBot xzHDODIyd9IhI3MnTDayv4TbbGRgkpGBTUbOTYPQeZDIwHnlCJ7P71LfboM5Mfcj7Ghpd9ktqQPr 46kDYxlQO7m+wWlPqCnUPy+FB4XcHH9T7+9XOLVgtSQstDhrBwqX8Et9IuumIV9+blK5SqhpyWVa J+tLAtATPOiRXKO+FzRdxeNnciXXowSoberl7A6en5KqrOrFCVLvkvUljeMZnh+J2mdIeRwpZuA9 xSalql+p9e9jU/UkV9W7ZyqVq0oQI0aqEsSgfgNPn95oj0Du8BZDRNlR4szJOIX6CtyZ3M71lXMc yfTLag44R0tex0smsm0aap1rJCJeRlI4RQ/1lE7cQWaenNP3jDRUVJC/1WDwnWwdQpQDUpQCmYKo SlJiphekfmKckUbUEQH1J2C+RrkxEn+VMsp/KN9EQlcpVITH0NmPpf4xLqRwztKbPohSBiARgLpN Arn5wEktVnjvNEK0MuW0rBTZdql9B+1Le2TTLQrkjym80KZ9TCFzn4TeNmWafQoFu8VJdyqNa6sa 5Vx/bOPc30nOMsXJnwZ5rd2Gwu3OCRCm4/MOFSzWqHqkkbZs5Q3WfpXrqhzvD0AoO+UDZaUaJtIL OSJpRxnISs1injZrp59UW39Ci+ZazEmfKEv9eSEPCnn6HWssjMbokMnbhXycd7QqSZvYuScloJUk Z3/2FYo3I8FyrsJSWdgTSnAk2FOq/lfcFOpfkvECoXs1L4w+UV3JC0PJpz8W8kGuX8KdMnm1RIHi iKi+GhXqH5TCJSwV1N8phXfJplfyVn31hFUtlsL5Qt7P9WipC4VczFt1SSy+ecz6idB8hdLfrVL4 TSFvU1v1bUqTVylNVTNl8laur2aiyImnS7CDh+zdDLmlgrMrhbxK3aJQ/YNcf6sU3i3kj1g6gOwZ qhzh6McC2duUddGod3L9JByG+uNwiCAFkEU4vIEFJBwRkfOUd9zE9QDZm/l0SKCn+naE9tNvcv1P x+ifgCx5pEOxdPUEo5Xl3yM1vUA1vYOFHsPP2Pomny7hmNp/dEAAGZ3QSuzeLIXV/gL1q2RsRofn gwz0tzhukMc6+qOGpgD9pIsz+b0PeTGn7/DVV0IAdPqadfSDLo/J6nnJ5MPuSU8myK86VkhRyqp+ JvuvTkb6SZcbtPd8i30ejgro0y+UqM8xWRL1kfseF66XC4oXMwq/LdC7UUiR63kpRKTL9Y/KzC1G eX28ZUbEcyN8QnQmudceuugJtndgUT3BhoJtf9xirKqflKdlQ9Iqi9+eHenKjSu1W3XjOk/rFMPU uddc4ReI2ouZn+9qbsoLRGAgETmxkIgMTaPmtECMwi8QNbP4+a5mpjzf1UyX57vAQCJyYiERGZr2 QsMgkbHHPMo+x0s9+5xr2T/U7u9MD3148YuUwR9n5oLjC8uHn8/xVnJufNHI+MuXknJ4ac61TCrB UbvZQFnhTwafhW9FWyUVH16eEy58o2SCH4f7G07jZq2R2kLA25nzl25j+iDtB3L+jtjviJl+iehd RO9Bx6ew+Y6tfAQzjTom82b8vlebbrzhJ1yo/c21p3XTSe5Cwmo06fbg+sLg2sIPzf7ewdrg2r8b LgbXbjVucO36vRsNHyzcbN4cvnn95vXvr397/cmz3w5/P3xzOJhfaO5XYzItG3/dVacdc9onJycC q//mCj7ATAbaQ1Z7jOgdRK9W1scPfEhdivB6SnP+Fuv2P/7fq0/Y4avDM1y38gt2Gq97Hi3lFaKf IXqTAjL2gBeIbo4DuN/AlPT7zih+6PaH4HuSN8dnPse64f+HlN5BufjwsYI1gumPAd+C9ck1nQF8 LwNe7x3j1xuIXpsGx1K3jDvz0SBk2Z9L0xr/W46i9wf/A/mDinllbmRzdHJlYW0KZW5kb2JqCjE1 IDAgb2JqCjMwODcKZW5kb2JqCjE4IDAgb2JqCjw8L0xlbmd0aCAxOSAwIFIvRmlsdGVyIC9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nO29W5MlyXEeaKREANOi7Y5ghofdpzKZcdlNU5fiHpF6A0kYSRlB SJhZ8QHkA9BzlapngJ4ZQND7/u/NuLjH53ni1DknK09VdQIkgD5e6elxyfAvPDw8PH5zo261uVH5 /+nHm7cv1M3fzf/9/MVvXqRbm/+vPMDfb97e/PXHL/7Tz+ONnl90Nx9/9kLdTtNkp1Ce6xtrb8NN jPbm47cvfvHyH17F28mEqF9+9eq1vZ20i/7lt/3np/3nu8pqPbF6rel5/vltfR70y9f9j3/bf/b3 f9n/+Bm+X4tK4eXNq9dGTdNt8i8/KW9Fleb363M7kYD88zMu9dv+x9f955f956cs6lt8n0t9PSrq 6/7zDn8u2pr/+AW+RaLeYvlnF/Vd//kts0JTvuo/Px9V5d2o1b/pf/wG+5qe5173yty68PKjV//6 8X95YX24naKfh83Hn8xj5dP+/q9H9YPn0OpfjZ6/E9+a/mqYVfU/ws/ETb0p9fvJxy/+2wujw01w xt2GeONvkr959+mLzx6kIV7fJncTg5kLy1oyl/bx/6iF6VkdlXJK6WDw58//7uijdxuoqzH2NqVF XTIQ5Mbr5FJrvKuNv2pV9Py/R6sSg5Xf4apVUfl/C4z9NcMYjazIMJN/Arh9wjAkAUcro/WtffkT HoT/azjevxyp7qeoWl2fglJ9nKa54iGW/pl7wNzY2kNbYLox6dY47JCfDsHyHdftDcIWVvPxR7jx 6TaaXnkYV0b7wJ3m1aZdFpwo9RcvNQIR//yPT907aYahMO4d61PvHb1p76TpViXsHTNEZMUDanri frIzLjmhArNOzwxprunLX3A1/+tQLz4fTZcL9Q2zGcb6qye3ZXe7eaIVKmCfcMZx88SXoCdf/itX xiYfB/r4sNKSLG0wq4Q4yQku9/nDZ3g9zUPmAHHm8vz8XilPh6kW+IubDK+j//zrLPCT+VP87r4v Nf9yN2Gai53Fvp27UafZZgkxk3cvPpJ/yM+VfH7Pl268nl6NKcKr7WmUpG/kZ381N6w24CFivig1 /PzFPJHOpthUR8dbIlOxzFzymZga4TwTb+beMZ28m0ltO2vtuYRELeAN9ar29F4hla2sWUgiIbmA xOWV4hOXV6pGrLXSTUglagFvcnfZWxtD+db/Zf7v/9h9k/OnPR/g5kFxG6d51cAq57whPZ/bM+Nz surWVfPxT/703/zbP/ve977/A1a+31RFIH1/m9vX1f+ukrNqzn+YFfOucgP9xYt/vvnqLF1Vt/6m qeXrabZZrTWkl724j+YqnS9sUXXj1CRkZa4Zz5yeDrii0pXL2AkrIJiFuj5ETP6mj9XT9yPia6+n h3T9UemLxulJGSH8HjzVU57nW1cevKrTpKGjBbP4QA8Rgx/ITx4/UCO3+kD1K2gV8mfgr8CFnPMV ltW0WghwbqaDDqOnzvRnd4JTdOVaEY83zms3BqvXD+YlehhRzY/mP5TlNY2nxXOjp4D6j8wSNx4g Zrv+PKO/TqFpxbTeEPm8AmBvCDKX/njI6489rqJ7wPy0qOZsuXkhYX6OA2Lx3MbJQ8sF88J8XC/m 8foTZ/3k/fpeHc74B7NMnfEruC+4OvSXmaBPDMg8mFDWibnMiju1deDMbXB1if0xu93A1/ar/vOu //yU3W433eX/NW4EDJ7/DbLSuhx2H74dbkR8VVh9sOjnFx7vvKrX6dZ4ffPaqFuTsoO7rgLntpub j//xxcd/lZs3qP67XtDb/vPL0eYINO+On8MfP+8/f//qtUnpdv512+t8y20Wfxz/PMX60Ofvb1F5 w2DTosreiJ5ROU20N/LMulLrvBB7aUtV/9PPjeo6PS/63BRrvReODz/psqQ/7b6/nvepbb4ok/2P wi87a+GtcMm5Gb59MqXKWm3q/5yXhPNvrAWg0j8soQY2E+pG5wK18vNP+h+/6z/fLLdPF/t8sCX4 1TqEeGa6+DyLug8hTok6BQZPofd+oPfJ3NpwTPGTpX27E1uI11b8MOm209m3HIriD6yDvx/pGczJ YBLc8PMfD/UQDIWv2XqATWzYKzitp7CfTn/88cFWopn8/JNYIbQApL7h56J8YKXnEifA5qmQYd4X RXwv598D9DiYpPISblYva13Ydtto7oMAOvMyZLWWeh9utbFH1D5y5MCTzfdR5Sk2pLkJpQWGa+hn OPDB1xpuOrvHMNv4XOQvAF10h4RbRI+n3dvUSmXfOdT4H3vlvuw/YT3xxSjWSQQQ0XPY+xSARc8h 9AF+CsAaBBU8BDAzNP7DENAqjDstAPXNJUVdxYZ6RnhJ0OgVQOOqQnHIpxlASBXN5DZVRgIxRoAL MSwEJ02XDdAo6kXYQwWEp0WB2YAzR6s2sHR+0v84Dth8N8KA3y+1LT//mxOK+03/4yDIb/7520st mYwBB4q/eB+efzLCiJ8NkWuIEW9HVfnfR5CTf34+MvV+Muqg1ivaY6f010Wn80/R6wvvVzPv6Od3 EG9aIUDNEBAJAk41fwSR9kKMCLMN4WeLohg6arLXwAga/JdihOcAkqe2c4K+9eYEtBTDx6XpCn6N iiFQCft88G0qAQJYuY5lP8WlHv/8LVpBAwX5/ASAgK79/EQU89cjDfr0iNrevyqr7ydvToeZD+2d dyNY+G5Y1Cf7tHceuv47iWU5+ok00EzTVewdHucv42Vg5urm91P6ahqYeX1rzWjV5pS/1qqNy8Rl m3t2KAbVHPqePhn+PB/Ffox/5J//NIKm3w1ZfzpCKTCjukUBePTpsioZxT7uf/x6WNTHjGJf3CMq F/XR0A7tEfXfDt9/+37unT0SilVVvBaKdQi4FMUoxvbJTTKn89mJAYpZo66FYlwmoph/digG1ewo JjblR0vMbiAdM3Dud3uf8k39df/5yxE0CJQYVOVgiZtRbLxYFKtZQrHxErYX9cmw1v88WniNl7Dd rBtj90f8/AvsChCVn09TlOeSxgu79wPGmi5eC8Y6BqTLYMya8EyMMatv1RDGjA3XgjEuE2EsPDsY g2p2GPt5ryb4xGD78OsTZkc3W/77EMb6yeVPUbXvV2hYxw3dZ58Oi7pjGLsbAgLAzBuGsU/HZtMz spB2Z4w1VbwWinUIuBDF5vHwTIyxGeanMEIxXQ9PXQPFuExEsYgoxj87fEDwAcAHZDa4G8HHF0tF XHik5JHiPfpunkVRF8f7XAUeTj9v4TxpEM4Tc14QY8f6rH18aqtkHrrzwjDMj+NSn+OMVV7Vs4Xb 6nOb77nQ0wotNvyfeJffuNskKj8OIDrIs7IAlntzj0i74+9HdgXA0SkM6ybQz4dF/XpUq3fYFLBm xq6vEybKfjHqvuen4EgM5Hl4srqZaNM1LI+u5tNlloeK5qktj4ZUSlFeE4lUbkrmakjFhZ5GqmcU idCQCir/HiHVT7H80Qrpy5EoYO1hE8eiAv5ouK1HKlK3ayFVV/PLkGqu15lZlq69RvITHaFfxBAQ fqQTSxfYhrobLl3ejfRy6K4QuzQLvT++mf7N+7lh814UVZc2FxxKuEr7luEsLk1Fe+zmiXOKVneV uFir1SJh2cOPMPikbp2Irjk8uvT42FFPNEHd4CDF/9t/9gNNEFf8m/7zO34uTlfwT/CqDoNTzrD4 z11cQDrD75ZTcg4fHOZAHBsafcdpcGJUYt/X7D/9bPi8GypgMrwdVWVsMw0zPzZR2sszKYNKf7ms 6aJ/j51JIdZfj8IHNw32PpwFrEARAR3z8HZJ26tAh4t5zwc0AhLAKaqGRBJt5leiG0NJ0tPWgcg+ ltPIzyxQrwQRQtWOHZogpPgI4YN//hp/DnTm3WhQ3QwH1Wej5383FDUEJXJTpDD2ygrT5o/G/cXG /8WHEc7zzy6jj100U40+dptm1ySkOBjxuUJ6BVJE657a6dHwJZTs0ocAQ6p76ozByViQYeyWyOR8 /2J66EL4Fb4PWjpYdRwcDFjYEyLn8v3z6ZEl/jPSt6sU9SRLiYP1Q3D1YMHMeQ3VBj0QaWAv1+3g 1TNxE7jpdrpPt49aFKXDc5dkN4zatL+r2xOr9kRmwhM7UEO8ld0w9kr+aoSOQ2scIOtIKpnnjjPv SVGzjbgWyLSdfFesnHzqCkgGY+qBSOaDfyZWip2yX+X+ZVABLRf9tQ5NYSWe3XEDrNwQUMHP+yn+ 7Mv+scVDz8eBuP80AmSwuEbRp++jzj/3ogomPdSOW4dpOayN1M5MbtMU/QRpMLgB0uwKSHNJb+6i yWvOU+D0VD4aqJs4XDBYyT1CPNvAOlu7EgNcMtM843nzfmvwExZ1lpNmiTDrwKI4aeykr+mkgSH/ QLCYZT8T+0dPtz7cs5ITEfcD3QZDABLODXUbdBe8LH2dMT6x01dev99SIfepcBtO9M/NS2NVuKaX BvTgobqtzTPx0qgpb2Af1+1TcegnPbDDsyPDLCRiQ3Qwr48js+D4b4cJuc16ZXfEPnR7veUO2HBF 3TbGXFO3QQ9At90K3TbmyZPYVt1280Ro0j26fSpQC7KewGT9Ff51sEAXAZL0XEzm/LPP+2Iy559/ zEp9vaKeMFDrQLe1jVfUbdSDB+q2dk+ep7bpdr0g77huT+fb5JA6GtT8j77/Z1fUhVPs89Bt5e01 dRv04IG6rfyTJ6OtAZwuTsLPP848P7+VrpZ5nqsAoZUf95+nrtLul2lAFCcs/UHqfx0t/UUyjfuX D1/9MSDqakXdFwb19Gnn2+HU01p/X+Z5O0X31DN60/p8EanwlR/R+1RvZryO3vdKgI7+rP/8NWu2 uPAGNPtZpKqGdsBtGd8Mf343QpgjR0Ser66+V0Vt7CtY16oHpqpe5qcmvTRpusYuJIxoQDx/uZ0z 1/PJk9E2xKsXr5c2hXshL07XSEbbIA9qAZgH66N+9xaYMBAi1q0hsHZgUfV7hEcaQBektD6V00eE sw4MJziTcqyoumdin4FWPs+itrF21u9ijqydI7p/r7WT1JPnbm267xKnWY73676+RkxV032oxfiC rR+zbv8T/nGh0BeGoguF5p/DXIEPPNq0W4V8Hrp/VuDTw59vo/vRPHnG06b7NmUbvWhdulf3g1XX 032oBeg+6PYb1u3/OVTofunX7/ofx5GOfd6GjZLhqUzQYnkW9I9ejisV9b55OcIK3Q/2ydOENt03 iVP6TvfqvnfheroPtRgfHu82/2f4R/7Zbf6xH+TNUhQZ2n/MeHmtoh5iXe9Z971/Jsk1nZ7HPmTp 4j0i68K1kmv2Ms+5Zm9g64MtL27evn/Xom+O/hYnef55KrfEZ/jXwbLgIHdEzr37Zvh87SWcz0Op H6WoLY4mnJvS82ydvi/B5qwwT55gs+m0ipQwd6HTNl4hwWbVaS4TdfrUUXFxazb/hNn9MEPkPKNc kO9kGOg4PmvQdVooOv98NxIFK4NhTOTDtyz+qNJn2xn3q3RcodI2LTJRPtzYtlPky6z/thvbX7JO wC4YGKx3/Bx298G1/XZk+8LkeJCtKF9mPc5W9N9H8+gwyOgT/ONyys2u7d/jPPfUw+89KupSTXky n1caK1U+gXrM9DVT2u68XdOpFCmB47IwbZ/azrZzDW7KxLuoYJ53SyWVa+EOOkx9Wn54mT7yfWP1 uq0Qeb2cMedd//m2/+xIBFMyWNwdieCPcMv079n0unnF3oPcTpOiX7Rzg09vI9/j8fPeiJ9xJeFW bPj5n/n5TVch8DrMP9NkbpUpDDkhYAoRG/QEURRO5ZaOGmyP5LC6KLEe//zZiXVSN4QWgSW6pGhN 5SMHP21pYxo95WQs2Ph/HDX+d/1rQm6gYcrx351sHFiZI4PvkxHrsFawbww/fz96/6thrb4d1XqY fvh/YlFPG/YzT155I69/swH2mTjp8xZNG2mPCXxuXFyXOFj6/wy/Kj3/x6HKfDX66uOkB72ot8MB NhwVvzohCrwM4rKf+wdgx4TP8I+jooZjfZhn62ZY1HAv5ZsTY/k/HvS19tAoaDQAXY8cG3uBhiUN gUyVkWlcghSTNGrVmceANxq1OvD9D0fqz398MxqKXw27YpgC8W44lIYOr9tBrwVdeibqTeOtjPF5 b6D3w8LOM97GzU0LMwXOqU1YET3sQIr9BP75zWgldxBcvbCfYCUnvhWt1P6zsFJqZJDGY5ZfnHB0 DNXmmHNyABsgaphya5iJ4dvh+1+Oijo22w6eD4v6bDishwg11oDvzsYV4fIdBCxCVYehYb9lLBsm zh0C/Di9xjAQRWJZ0Q7n7XZLroZJJgU+wHUKc4RRc383iyH3xGHL8yo2BtHQU/fEC5MBfoqGBGNv jA22ZbzYFCdtubMSq3wd2xJWTQcZqRe9I4bu/SD1DycmrOEsdKxVT2z8zgv++RMc+RKnJvFvRgp1 7D4UbKjVzvHgciocWC42nHmgahvLxZTNgdJ8kaB1AAIwun41GlLj73wzGjIPGt3Fl7awauZVbe61 FDg9zYO01NlsWHDfjNZFepoWBs1VQ0CM97eUInBo60DoNERZ/3L0XOzO0nNhwFg1/56tGuFaaT8D bfRKhQcU+N1IOd4NB5IAv8GYGkZ63gyL6tgF9scbfD4Yk/fdGr2wWoZjUt6PMmjVN6NWnbpZ4Nej Vo1vbRFtLbbObIkHy7cAHO4QaA/t/+Wwqy4Imj2MQTJa1YTes4psoYw55FAbUIChNuozQ7Q3Qk3n +fjD3+LHGIyL4cd+d2rc/HIEm8O82OMAh2FyqPEQGo6GUzngoKj/NXr/7XA091p9eqIqIgPw/VW9 3M2g/RiYvjk2rusko0zNmGiS3mRgz6uSGGAsjQa2sov441/cZPtx9J9/naV+MhfiZzt1Hu3uJoRa 4bcvbNL5CipdJsm7Fx/JP8zPY5TPs5TP5z+nAZedKpeNuWL8kmC+e/HZX81VrVV6iJgv5srouSrz vBTmBtXwxrdE1sPnLvlM1OgOl5xn4s3cEaaTdzOpbWetndSEVKIW8KZ1oE8TvVfI2N7LQnxo7+UC GjG/V4pv5PxeqRqxlkqTkErUAt7k7rK3c1fc/G73Tc2f9Py1VLoJeU8zpxBrGuS8IQ1KJZFudlFT GqI/+Zd33/93P3jl5inDTeHln796HWdTTqf08v/40x98/9VrPd26yVnx4P/8sw///fd/0E3KUyqm 5490z4KldKA2dRZsuucm5YTu0R/ycyOf3zN12WQHr1Ytv1uWJJilQj5AjFBIbSo8vSXSGR6l2tQQ yjJMiGijlMg2Spm19lwTUolaQBulWkcLo3SGZcOjdEZ1w6OUiDZKiWyjlFlLpUlIJWoBhwq546Zu rpDa6bax/fJP/vTf/Ns/+973ZvWiqe03dYDZeVy1/lQqMHlXybknQpzmlVUbjkB/8eKfb77aREdf uxmfckb3t7JKWQkfjAKLRgbrhPx7lDy4HNxLyilfDKY/uxOcQsHXisgj4RIDIzmGkPsNDGf1wL5w Th/wkFngDL6BnKKla0VIuyIFj5Ntonkrz2gphT7ZNoIm20bSZEustW8izLytAJpskxKTbZxgso0p 9sm2ETTZNpImW2ItlSYhtQXqmF2x36ZuDmNJR05LvIVd8YeJfMW6OBP6iq2xfNV1S0RUVTAf2jcr xZwDgW0o1y3Ny8GvIpGdRk8rZjGCOaQOYO9yERL2oqcaVjKqjgUxTh0LGkFY0EjCAmKtvdKEVMLT WqEuOSbGkELWSKS2UIm+Y0EjCAsaSVhArHVhlJCYwhHY229TzxmwWWNx3tZTwKGbLCun+EMbWfAY 5u0Fj6d6G3wDOQ8H8AoRcgAbHfGrGjP1r2ps6l+1EfRVG0lflVhL35CQSuiIX1XXa4Doq2o39a+q 7dS/aiPoq2rWxlI1Yi2VJiGVCOrIAN5vU7f3B+S7R9Lj+gNAu7TVqF33Lf2zJwyfg9vtgIuX59lf BstzZD50u60UI1f51uLY09b1saet72OPCFr6NpKWvhbcTyykEhbHnjYJx5425H6q6+c+9oigpW8j aelLrHW9Do4pKmCwyt9vU7df5XvHW+fPxe0WPHuZT7m8s1GIz0+ZpQevsgNbliSYD83SlWLkvOfZ 8qskuZ+qB1b1ycAHBaOUSJoMiLX2HDimqACaDFwyMEqDI8MnC3EkJBfguLxSvOPyStWItVSahFQi mSPz3n6buv28Fykx08DtduEk5qcoVjfRTVKR2h+a7QaPwURc8ETqIYNvIOehibhChFAVP03C8Fca DH+lwfBvBI2fRtL4IdYyKEhI7agJDX8/ORw/s3r38eMno3n8ENHGD5Ft/DBrbYNVQLgjqrLjpm6v KvnY2ZNZiMFpjcp1fP1V90oPFmB1k3TJ5dG06y8J5sHG7DoxckJy1uDQczXjf4NCb/vQawQNvUbS 0CPW2kkOCWtg6AXLy+RKUjxdFmK96yjdCELpRhJKE2upNAmpBC3LDyak/TZ1ey0Lnu9+ei4Wok9R nTexVXWA5/dZiEU5IouWr1ZN4slLMA8Ucp0YOe2lScMo9Tl0j0bpbFQaHqVEtFFKZBulzFoBXvVR SgXQXJAMuvl90n0d45Pq4QNE0FzQSJoLiLW2QSNhjuxo7Lip57r2GjIo9nefmFTKwgOen1z6LF/1 GCoAUwQyD5Y+68TImcYah/Brbejwax3sX1kn9q8aSfBLrLXnLBLGwdcOhuNbKulDh1/jYP+qEQS/ jST4JdbqvGtCKkHxNAczzX6buv1M4w0F0T186cN7BRfPEGidLbk6bBcU76Ce0nj98xAxcjJouxaE kO1IL8FQD10hghCykYSQxFo7aUKib5oU0oiFQdSwMIgKFgZRiYVBVGJhQKy10hoWBq2AwWSw36Zu rjMh9fQTT7AIsvNnQzUztJr8SP7h7Yt5KhCPq5bNq8MDntCmDB/xDeQUGrZWhNAuayd0GVunusvY OprX529ORBtyRLYhx6ylb0hI7agJXcZ25oQhZy1t4mQh1nQPFRFtyBHZhhyz1jbQdlIhnB5r146b url2zZXkw8nPZu0TvPA73DOzFQPtzLVPMdeWr/I8JUsSzAMTcZ0YOd2FiCt0H5Lrc0CY+gqdCJoD GklzALHWnmtCKhFxhe6DxhW6D6qv0L0nIbkAz+WV4j2XV6pGrLXSCgl9xBmx46ZuP91F1xRypYl4 SrusCRjyfc+ElgMy8fGJYFCalJYv5kjOPmEh50Ew6BoR+Qtc2LBqo+LzYpZy4Yvn1YblAgVzacJD XpeTtJkwetta1aO3rdXdLiSCZq5G0sxFrHU6Ut1jQAXQzGUMrqVsC66oQozqaykiaOZqJM1cxFrb oJEwR5aNO27qRf4Q72VwcggyDIP+0FQCHp9Sx5DC6MWiS4HCZJHzUB1XiGB1PL9hVV/weVERLnzx vOoTFyiYQR3XvS6naC+ikL2P3bXhPUQhE0HzlhdRyMxauyUiIaKQvVd4mMI7WtFlIW1DthbAu7O1 +L4bXKpGrKXSJKS2QB05N7Ljpl6kjlZ7saF8zyRSLL/zpsdqBy5f5RlBliSYB7bnOjFyntER92Ct nvoe7IxwPVyBCALfRhL4EmvtuQmJiHuwVhuxQtIKVkhawQpJK7FC0kqskIi1VlrBCkmbY4vB/TZ1 c9szb7Ft5Z3k/cdT6F/8GfAY3CYLHkKa4vPgN5Dz0G2yQoScAtoGKOGiC77joouu42IjCBcbSbhI rLVvmpBK9P3XTFoRke0trXKyEAsR2d6KiGxvRUQ2s5ZKk5BKHAs+33FTt1+luXT7hD5J5cXm8AUr HXT9L7n6CiVEsX5Jx+ajB4iR85GKuDlqVeqbo1ZNfXOUCALpRhJIE2vtpGSBiLg5apV2MPSsonXD LMRM4CAgog09ItvQY9ZaaWWA0O7IfLTfpm4/HwXz6CfmcQ6zMjHFBSsYVLMlV195ZP2AdUlK44ns IWLkZGZFtgZvIVuDt5CtgQhCeCuyNTBr7SSIIfdWZGvwOWk/ILyBbA0zTvQ1NxGE8CbgmptZS6VN RCIdcS/suKnbT2bW841pT6BmZnIiIqStwLqa8ZKs2HDwGEzFBQ8dhyt2Hr+BnIem4goRQrvMRBra yNjtJzPRobgCrcnDkCOyDTlmrX0TkQgYCGEm9kwVMk09EMLwwedcQD8jXYrvZ6RL1fg4da40Cakt IE/YUrt23NTtJzE3q8wz22DjU3onJ7biYjjP6VgdDstXeZqSJQnmgZNjnRg52xlxJsMb31f+M872 lT8RNAUYcSaDWWvPeSTEmQyvE678ZwSBIAsNZzK8FmcyvBZnMpi1VFpHJNIRJ8eOm7r9bGdM1ccr 7a+ZZIXVeHw6K051eHzKoa8paEi+WLzxPF0h56FDf4UIOcclqnwjQzerTIo9tIIIAv5GEvATa+2w gITH0AoTJ9zJNZEWOllIJEdDLiCyT6IUH9knUapGrKXSJKQS05FN6x03dcVZfK+1cDl4OhD6kfxD s57gMRhpkidQbFmxsPgN5Dw00laIkJOCtiIMW8O5CM9JqApUeVx++56vqoKc78tvFlIJK8KwlTgX 4RWci/AKzkUQQUipxLkIZi2VVnAuggoYTAr7ber2k4KaNj0CQjl0kqJdtZJDp5F3lXyaHDpch81y 6HAj/dzxKP+eCc27zGri6MXZ2OBnd4JT4sFKEWenzvFKHlU4H/PqhoLSo6d164GBCzgHuxeXi+j7 72fXvjqU8Hn1IVHhi+fN4UQFCmbcf1/1ugRrJY4WeAVHC7xyfZlJBCFYIwnBiLV2CxwtoAIags3q jmHSbvJ9U3pW+R4mTURDMCIbgjFrrjQLqUQ4FhG+36bmT/p4eLgR6C2qW3NznQdtNVPX8lVCn0V9 BPMgO9g6MWdDnONTaSdBoqzDxXN7+LyrtRQnmAfL/XViBFi4djLuLZGmB5m6yfbtSyKaBhHZNIhZ q1oYJPrBvNJ1Hs2dWXQ3d1yy3dwhgjQoWTR3mLVUmoRUwh+x7Hbc1M0tu3nmbOlf7knyGg1ZygWW IoRwPJWZxnXYzEzjRhZTCeSfMtMiHz0RLxYbK/LRE4fU0kxbIeLCJK8uJhFueIG5g5t1Cy4wU7LV AkZMOoZnDxAj8azPlZWkWNOiSaZH5BFBSt5IUnJirZpLUa+FUBiR56LDHSwXbfexu2j6DhYRpOSR 5qRaNWItlSYhlXBHNut23NTt8Syq/M/mK9U/LAis1tR5GFhtq+WrPcxSVFUwD+y5dWLOt+eCzIfk JrZYxR8ImPB5xSLeGZLPG3BpMj+ReYR/q8RI/AsiT5CLcIrPRcgTRASBQhR5gpi1ajqc4qMCCBSC xXA0F8geykLaeZ9aAB/+qcX3w0alasRa22DA4mkFDPBvv02FxZ/zgUIyMqYQuSXEgD2wRJNe3Llo UoUtqj7rZBSyyHiw8ZAr8TDX+JJgXijPejHnOfXvh2DHpwBOwkdZp8HzkxvDi1c7BsiSBPNgpbhO jEQWT0dDGjn1nR0X6HxPGe98FKhqQ49CKJqiwMIgIZXoZyQKKVKxOA9Hj5yHVCxEkLp5kYqFWWul 4egRFTBAlv02dXvLys2GVLh/pehcQjOJyMfCMC5uDYZx1bMzGUX1HboFD5/RyQ7n/gZyHvis14g4 37xxMufJcXwqDnN4XJzk8ilDR3GnMy9yHnrkV4iQ2ONE5g/nIPPH3Fk9UoMIUkgvjqMwa+0VyPxB BZBCOnEcxTnI/OEcHEchghTSieMozForrZE4dvJmx03dHnus3jTJyZ7gqlpBB3hVzZ8FF8NNtZX4 JcE8MLnWiTkft6w8sHHxsmzxHBZQ8z+4vErHjKcHiJEAZkUuB2fh/IKzkMuBCNJqK3I5MGvtnoSE yOXgrDi/4CzkcnAGzi8QQVptxPkFZq2VVkgcO6qx46ZuD2A6bXpUgwCsp/IpANbIxwIwLm4NgHHV iyEEosDekjycf6gYS/wGch7aWytEbLJUNDJq32nGZ/GHFmoIj0+FOfLJUfliiVFsz+4E52GY4woR HDdxfsMaVsPzipt88lU+byBLBQpmiJtY97rEaCPC852Bw/zOQHg+EQRcRoTnM2vtFjjMTwUQcBlx mN9pOMzvWiRvLYDDemvxPYy4VI1YS6U1HOanAgYYvd+moutsDzBYTasDHKw21YKLYawaYPySYB7Y cevEnG/HaXmq/XJsWDzv2lyUu+t6wrcP7bhVYiRGaHHa2+kAMQQaTnsTQYqjxWlvZq3dE5AQp72d EuHNTsFpb6cgvJkIUhwlwpuZtVRaJSSORXLvuKnb5wOczK3aMB8gAxhHrFQA60mtHwXAqLhVAEZV r3ZcF4V2nOShsJdqhNEbyDmw4y4XsYkdx4GHJyGtuvzPMuSa+33xqsXNToApZB65/FeJkWjX4iIJ ApSHCAMFx4GJIAhQ4jgws9ae80j0sMyZtJM4DjzPND3CwE5wHJgIygIziePAzFoO2pOQShw7+bzj pm6PdnFqJ5/vcfnvAbqa7bXErmYHLbgIeprRpNm4sHGMXw8Rc7btZSd5aPU4UFXff39c3fHyKWFI ddwTL3IOfP+Xi5BZTiYrUlFNcEpzJvo2PxGU+mPyuM3PrLVX4JQmFUCamcQpTZsCpKJKcEqTCNLM JE5pMmupNAmpxLEDqTtu6vYgFMKWB8QJtlo6SoItTH/5CLDFxa2BLa56MYVAFFhcCx5KsVzMJX4D OQ8trhUizkerJM9LWsMRI+IPDUzgcQGQxVMHTr3Oi5yHaLVChESrJI4P2uQgQWuC44NEkAoncXyQ WWuvOCTE8UHbz7FWEo4P2ui795sIUuHo0fvNrKXSMSBBq60DtNpvU7dHq7nMK8Sf7gKuquFzgFfV 4lly9StRNL4kmAdW1joxW6wUbVTC+XUc0orXHR6f8vg3cFq+WNz1DFzIeejxXyGiJw4/u2HV3YbP i4eNC188r+44LlAwg8d/3esSrKM4Pjh//Z6Qx0Y4PkgEIVgUxweZtXaLRUIcH7RBHB+0gUyzLCTA 8UEiCMGCOD7IrKXSJKQSx05K7rip6PHXtAtV8bCRj4WHXNwaPOSqF7sKRIH5tuAJFDkV8Q3kPDTf VojYBAa9PDJ5D1oUd9V5OFidV8tXWfVlSYJ54DBbJ0YCShBHDG2AI4Y22B77QARpWbA8UIuCWMhM GeCIIRVAWubFEUPr4Yih9RZMIm+FSeStMImItVTaOySOnabccVO3t/5MPHmachfQVa2rA+yqZtWS i6Cn2mD8kmAemHLrxJy/BHXyROTlZs3ieTdEil3SzZR0DI0eIEaikRcHBK3XfZffejggSASpqBcH BJm16p1GQhwQtM71DfZMwgFB60hIuTKMy6sXinF59bIxqlqutLNI0N2UB2i036Zuj0baXSVqVnkK XC4AprpP8jEAjItbA2Bc9WIUgSiwvRY8mFWmv4Gch7bXChFb2F7zGJh7O3FXJc3tE39olg8+P2V7 HbzqeFtRlCSYD22vlWIE2mmlEQK0Mn0HT3NimFkHiWgQQGSDAI3pX1hIJTRCQHGyz73aIGDK+hpS hYDiZi/EXAARDQKIbBDArLnSLKQQrYBDtNtxUzdHO51bcmqzcg/QVc2hA+yqdtCSq6dS0PiSYB7Y XuvEbIFhKSWJYYE3ZcUf8nMln9+LYYXX8xZsivBqexolSc5rgWHrxQgMm9TUWlnJfLVp0ZGiPUQU zVKkaFXvFCto0cnGWrTVIKEmfi/3ak491RU7OdUVO7GQuYDUy8vFp15erhqz5kqzkEK0Ag4xbMdN 3R7DlLk9lYxnig4gjMhHgrBe3AoIg6pbLURVBHNOH/DwHTgG30BOoaBrRZy9aoxJnWli5cLxcS5w +ZRdoAZ5kfOgdWtECOgpl6J3fUzadn1MxnZ9JKLpI5FNH5m1KJlGQmnUx+gc6mPMcSGkj5GFzAXE Xl4uPvbyctWYNVeahRSiFXAIPTtu6ubQk6bbKajtV4u7wKtiBR0CVjF/DrgIb4qt1F8SzIcm10ox W5hcIdpzl43FGjxz2Vhsw4ZPB69WQ7Iv/5B5YI+uEyNwL/DiuKqSCh0MYl47EBgQ0cCAyAYGzFo0 nISUbpwcgkFoitvAIBjdwSBo3cGAiAYGRDYwYNbSBoNEK+AQ93bcVJEtla9IrtlSJ/WYyMLFrUGW XvVsooAosIQkz6Rhooe2OqSWltAKEeenfw40uVaQaHvEHTUiXfRQnGDwuDi+Fk89RVxF5EXOQy/b ChEyf3IyqCblOntSk3KdPakJEU1NiGxqwqylVyYkkkE18cajmnjtupp45bqaEMEZ4B2qCbOWSmsk DKnzQf7k/Tb1Cvd93fqrWEJ7wKtqnBwAVrVKFlxTP2in8SXBPLCE1onZJsGXdKAfx7Rqh8Dzk5ZQ w6eDV6sJw+glmAeW0Dox8rRP9AgGLsUOBm4KHQyI4PzIAcGAWUvPkZBCRI9g4LRFMHAKzAM7mQ4G RPARGINgwKz13A6YB1TA4LTPfpt60b3tJspjbMdvXaoxMeddu1QjZJav0s1Ii5IE8yAqZ50Yef1S FGe7TISzXSaGvl1CRPvaRLavzay15+Bsl4nibJcJ4myXCXC2ywQSkgsIXF4pPnB5pWrEWiodIhLH jrHtuKnbXzFo7PFjbFuk5rWOrKuT00bZ9Txz2ih7oMtXGeBlSYJ5sO+6Tswi5s0iltroO5aWe8UJ S4ngYwAOsZRZazApLDGpAAq9UAGx1Ey+Y2nJR0FYSgQNueQRS5m1jLIJCCpgFPO226Zur12z3auq ubxSvfCy2yBPMd4zT5VoqYPbbmuY1JKL55ISU9XnEmQehGatEyOnpCBO+pngeu5iE+CkHxGE00Gc 9GPW2kkOCXHSz3C2/EbCST/jSUguwHN5pXjP5ZWqEWuptA9IJHVkStpvU7dXGq1aoOjT3CltV69z MNhgydUXH1ouTWw8Mjc9QIxUMx8QsMs14QTY5ZpwAmwi2ByKCNjM2mwcIHxAwNaTCJTRvCTI0TYR AmWIaGOPyDb2mLVE9/DiJBPTsZigHTd1czUz+X+3dOVcqmdecbhbnr1UtELP6A9vX0QbxOOqZtGF A56p7fzE4j2jN5BTqNhaEQv1suS6qiScAJ3xU3dobwSNuUbSmCPW2jdwApQKIGh34gSoccF0aHdw ApQIgnYnToAya6k0CanEscOuO27q9uo1xU0Pu26xFtMmiqktTFLl6A8UPwbPT8aPhcQnEnLgF79a n0YlyMY8iB9bJ0bGwLqEk0C5KJwmAR2mPgkQQYGhYcJJgFlLz5GQQriEk8AkNvgShFRF2N6LYncv is29CE4ser/Ggx2Z53bYxCvEvN6Gh629Tl7X7uTh33tmsCRnsHu0KU59Flq+GKOYoSakcFpbKYJP NZ/fsLr4w+dlvceFL57XxSEXKJjhVPO61+Ws7AydJKskHPU1zvXEfUTQVNVImqqItXYLHPWlAmiq sgGzyBgLR33nFUXPIkMETVWNpKmKWEulrUciHEmYs+Omrrht3sid93ZaGqY4SqdeNsbhMZxyWfBQ 0HLZPOc3kPNw/32FiBq+kZHgJvRlTGTqrlKw+Vl4DzZDIZcvThIet7VxV1tuass9bdzFht9ObGi/ 1r7sprYB8dqEQhYJry0Rs3Ai2oAgsg0IZs21ZSGFaAWMcvjurolflE3oPBDykp4Hgo6OqLtKiYEw 8x4MhE2n09f61tgpta2CatDSZFqqq8vQ5upOCqs7U1jdzHul6uYrP2KQ1f3zRU173XL0j7VQ01IU 1lTWfNua5oB2UdGyHBB1hdrlunrs1UxhXRd137SuOofA3turULe5prPpBTXNlKipv16vGrPo07aS 6pV9aCSEMRyEcco8Ktu15xl+dfN2+SrbOrIkwTzYMF4nRlpQVuQ2MNbYblZYyG1ABJkVVuQ2YNZq KxgkRG4DY7xY7BsHi30DuQ2IILPCiNwGzFoqTUIq4Y/5Nfbb1O39GvNK7tRVZ7bd4UjRXHhn5FPd CMt12OxGWG5kuZga5J+6FDvQTWTyxXKjdXt2JzgPL8VeIeLCS7GNZk/MpWtA3G1ccvW1W1nK9ZVd OoZnDxAj8cwoTP5kDGRHMMb05E9EkJI3kpScWKvmQnYEKoCUXIvsCEbTiioL0ZAdgQhSci2yIzBr qTQJqcSxRBA7bur2eDbrxxUSQfyBQWC9kvo8DKwXVC9fJZhaVFUwDy7FXifmUixUkUvJPgROW/6R /EPdQ8LHfatK8nil26o/lohKegM5D7aq1oiQEKj4LpiqVXBZtNE6dVxoBOGCpstQmkrrfosrC6kd NXFe+EKyx6eSBqIQlIYoBKVFFILSIgqBWGsbDBLkYTqAwP029Qo7wf4aF7BZT7kAKgT6nvH2ySCQ 67AZBHIjiyUG8k9ZgZ5MGvliMeE8WTDIeWgFrhBx9hEmPQW8L/c+zEsS8+qmAuWwlk/r9gMD14TU wQ7G5SJ4B+P82heDUjyvNiTn4JbPm8FJBQpm3MFY9brcxpz4SEzVf6U7gikNm+2NIARTWmy2E2uF JdUJKoBjWSBvcibJ3ssbhRNd4p03ESe+77tsMU5833fZfiTW2gYdgDBHArZ33FQ8k3l9PNwI9BbV rabVedBWDa3lq93fJOojmAfG3Tox50Nc6scqToBECQwXz+3Bc1BrKU4wD+LP14mRYJEixpfqdvKr DtM09fhSIiggoJEUEECstXuakBbahvGlOokLs3VS3dzRcermDhEc+DahucOstdIKiWN3g++4qdtb drO5diwCglDJBbwfksjHOnnJxa05eclVr4chQRaevFxyJcyP0F8SzIOTl+vEnA9GUdzzfbHFsniO NkYeaGCBpGNg9AAxEoxixDsxdEw9THBWg34nBhGkoY0kDSXW2j0JiYh3Yuio2Q1fSNXd6TqQkBr+ ROW14CgqrwVOdQ86C6mEtkfAaL9N3R6MVGhHzbZdZu4BwHKUyCF+5fiQJQ/BTo4k6W8g50EwyhoR W5wY18FhGNn8Qdk9KP5A4abw/GS46cR+vxInyq+2p16SQ/fhejES7ULA8CsdYg+/0gGukSaCYzHF NdLMWnsuIhEw/EoH1Qf4TPqpO9u1T93ZTgRBQCMJAoi1VJqEtGjSI/sKO27q9uGnk709lXHVJZo8 SsZVBxfRPZGDrNdhKwdZb2S7V7sXcDIthFd2+Go9/OQ5GByZB2eo1om5cI9A+36KuGCb4oRo4g8t IhAeQ+Dhgod240rUIL+BnIeBhytESDjzlESjkSF1Hfex3wFLBOl4I0nHibX2TUhAeD50XyLN+7Ks Bp6nruMupq7jjpdlpfhGko4TawuPR4KWZQdwtt+mbg9naR6m2+8R/KFBYPEjnQmBxd2zeLWDlayq YB64mNaJOX/x6vhquRPg1xav8LwuJI0fPm+rTkIxwTxavK4Sszg95CiHbCUDuJdcVB0UGkGg0EgC BWKt3ROQcOyWyqRNwsaxEWwcC8lDiCBQsCJ5CLOWSpOQSqRj5tx+m4pudzORv7CsDxt5fbc7F3SZ 252rW53eIOWk233xqjXoSO6SBPPA7b5OjOhynlhrl9M6apsuP9LdPpzf3YtqlvUdSmh/cLg67M/b 0yBJWjsuF5krxWB/Kk5oVPpT9esIr9efXMj5/cnVrE0BCe0PPZlB7gh+3p56SQ7z9awXA/1p4oRW B5FX7c9eyNn92aupkwlCgk42p7TRdvhcJ+356Z1kFv35EDHYn+2ANfVnP359xf7kQs7vz15Nq4WA nObVuOhHT3NCWHp2JzgPcsquEYHdaAPewELkud047iYWkrtpUYye5vUwcujJ5j/QbvziuZ50f3on mUtfPOT1p+wHM09lgmOuloWGLJ4bGy3UXDCXfnjI65e6HbTCK0UvyU+O2WqWXE64SCCluEXyMBX5 KjHS/tbiNKvWtl+pqTWcZiWCjFItTrMya+0ki4Q4zapVT/pXSO+6Uaroot9ybxQn/au3SvEkXG+c cmCHkpBKkDF7YH/vt6nb+x/mBabbMCkU+R/6yZ/if2jkk/ofuA6b+R+4kXX1DwWc9D8sX7V4kKxL EswD/8M6MY+X0H5sAl+UFnqZDLqsnUBCXS4tnvf8zbJAwTxYoq0Tg5eEG4OrYiKv2p+9kLP7s1ez ziggoU4ixk3D53XGaU/vJPNg4lonBvvzukCyAVIsoaA0FCTUtjXNPHheO6LrLTIP+nOdmLP9jUHJ E7jJsikv/lAjo/Fxjob2yfvR0xw3Tc/uBOdB6PUaEfLGFa0xcCRo0wNHgrY9cIQISl7QSMpeQKyl V0hIJTQGjgTluoJnEu7qDXzrZbnVwGDIK5Ft7mfWUmm+ZbMQ7kh0746bihOUTbgGJvKxwlC4uDVh KDbhBinKwji6BZfrznWNLwnmQRzdOjEItde+JP5Ce+3CW+NP2GrHr5E/uV3eboE/eLVdCt/viLdI Ht4tv0rM43nc71ODi3zuqAK9yvk2IBADlw5JHnaLlxuDehudHvvW14rYrmPP6LLlFkRRUeCoWrl4 3jcIigr3DQJkbodj1r/+B4gAZa10JgKUldPyVdZVWU3BPFitrRPzXq8uSkNxdVHatnzO6wBZoGAe 9Oc6Mdif172be9yfF93IvajmwT3c7TbspIbP29XZ/SZti+ThDdyrxCCQRoMbQEQ+xgzFRV06Q/Uq 56kDxMAMteBxZD8bfAM5D2eoFSIeb6BejMwX3ip/Apn78C56DMJPIvPyVR6jspqCeYAk68TsZeRX e+Fg6FdDYcnl0OXQXxLMg+XJOjHYw9e+1PfCI+8X3vJ74rg7N64cOQfZp467tzt7ly+Ws+p8ny9y Hh53XyECv8t1M7LcN/IvSryCI79XOYMxiAHMX/BQApQC2L2NTo+zqKwV8Yc34Jun/awRX/3uy1f5 1mpZTcE88PWvE7OXkV9h+GDoV/xdcnH2nwLWPfsPMg8wf52Yx7xu+UIVuPA+0xMqwI0ruAuyT2I+ OX7lixWwacsKOQeYf7mI7b7LGZ273PVbXgHbrqTXevi83V+vhVGBffGQ19Es9wERgMirIIA2wgLn oi5EgF7lcpAFxMB5mQUPhReXwy78BnIenpdZIUJs+3GaqbrtN218+PTS2AEqf5P1Djeu7dp34afj BuSrTrOPQ1RTMI/iBlaJwQ/EidjrB+Js61t6TlIQHwGSyp/rOOFaVo8GZq0vToyWQP7gefV4cHp5 wTxwnKwT83i7XJvtcA13t8rp54PNrXLuWfLwnlQ5Ic1vIOfhIesVIh57nOopXX2gLp5HsfEPA84i eThQV4l5vGRL4yF6UaKlRTXr1A4S6my+fB5xMw5SICHzwMJdJ+bxxufJic4qv37onpzo+nAr0wwI PznRLV/lkSqrKZgHE906McLUVeKMSCMfA5m5qEuRuVc5+x1ADLg3FjwcomHwDeQ8dG+sEPE+I0lp JQgoLVs8Jf0vfdBb5PQYRNaKeLzxucHIXFSzrbW6hAqOy+c0miqSMrtgHgDyOjGPt6S7eOVx0Trv JCBz40ruT5B94uY0WsAtX8xJQ/viDjkP8o6uEbHddzmjcxfFVAsJOFoeC2rF4nlLepEiDDDRFw95 HfX9ummZxvp+UTKmRTWrdxUkVIfq8nnCvXtI+4bMAyfuOjGPp+8bKPVyXNZMAzAui+2yfM4jSRYo mAf20jox7/P4DNYJASFfld7G0fJpMA7GGHKKrlwr4vEcYBt4uRbVLG4+EFBce82vtHxanIDsc0LO Qz/iChHbdeMZ3bT06NW4/M5RkZxbsXheYb+735AZZo11r9PFh/MfQ+QMY2buKyLvGhkmNhozM5NX uO8uKXc7tXtB/uWrV69ni9YG619+/5WeVycm6Zf/7pW+tVrH+U+v46123tqX33s13SrrjQa+H+Rf yWj/8oNZjL/11uuXf/7KTOZ2CpFPpP23C+of772qzecLmrD++pWe+WN4efvq9VyVKbq5WjevglJc uplfmfuzrCv9zTxo33364jP+Klp7/CqNpK+i+u0vmZnJ+lU2+RrzcGq3Tj3a19jkK2C9Tf8KBz2v apjJQc/7RDEPpauJvCOyx1UW5h46uF3Pq7m70nvY81BvOx7//fffw++v4fdbevHTexVn7ng7/nye T7KX7+X5JHsllcbPx+SGny/kq3Td+/f5sN78+f4/+Aofw+/v4Pc7+P0Vvfil+GP//fmR8fA1vfgZ /PGz+8eAq5PdPAaMHAPtFhcaA41sY8BNAcdAJzccA34GjfQejgGs94EKJz2J8YCf7yejMfDpkUGC Y+D3935iygd7oOYu0n3p9Zs2kj5xsA4/cejHHbf7xPkmg/fwC/dqn8Tonx7B6N+uVfJf0ouDLx2s WirzFl9JzR36SDblov/n9kQb5qXDzcefHINU7Jwfw+9PxO+H9/b4RdTP392vh3o60MMNvo5zcx+9 H1/nb47oAoPdt0fAjpgzet7B3+8u+6zLL2JDPeQ8fxEnkNGaCVcORN4RaXDl0MkNkdGmlO8Df++g Eet9cjz8/Igesf2Kg+TbI8wocAiqnxx58ev7x4YxB2ubLb5rDsN8pHXJfdo6fxxK651ba2LNx3ug CYZTpJahT2TTBGODAk3o5IaaYOZ/HgvfttQErPdF89a3AHav6cUvji71jmnFckAby2C35YA2Ob3B I1npGxoHV+pkPdWjNQd6NDfbgR4R2fRIW878X5iZ3FCPdIjv5XIK6z20tiP8xr9b8fejRvPc2Vrq BWc78Zo3/yupKdPZNBOGbvtTTLx54YLzTM6fM+Qrb4k15HvSSEglFGUsK6TiDMWVDO29cm9uy1hW CmhETgGSi1c8mkrVMLkZC6kEZUT+7K9238SazO0cv7RW9w1DP+WbtvOVG9WwefkXf/EXf/L/fP8v /+UlT6F9xHjKINRIZ3p3+hr/VNvTCOpOz4FppSeItfQRCamEddidjnMpVLLudVUhrl3IVApoBHVn I6k7ibVUmoRUYkqLEbPfJm48YuZ/tIER8+FoxLgo7gV0MUXuThcnx91JROtOIlt3MmvuIxZSCb6V oZKcdaKSLfFiFdJyB9UCepqhUjykGZo6a620dUA4K0fMjpu47YjJl3B4HDH/1xBjghOQHTxAdggA 2Y0gBQxBQDaxFq0iIZVwArKDFpAdFEC2n2xXwEaQAjaSFJBYa6UVQHYrADBmv03cGGOiafebtBHz /eGIMZzlr5JG9e5siTtqe4xJ2J09AUrpCWItfURCKqENdqeOAbtTh9i7U7ebFqoVERR2p+blZLU/ 6GaHYpmECEQMixGz3yZuPGLmNtWMtG3E/Gg4YqIX3RlZ56ZMQHc2grqzkdSdxFr6KKI2tgKoO6OO 2J1Rpd6dkbSxFKA0dmfkvchaNdQ5ElIJHRcjZr9N3HjEJN+uhKsD5t8PzRht8FIqp63n3nSaTUTF BM3xmlO1lOlZgyHIQiphAvSmUxMitlOpI7ZTsa8jiKA5XkVcRzBrqTQJqcS0mJR23MRtB4ybxWqY lD4cQoybJkwj7pWCdYSii6bL0k9N0J1Ekv4Ra11OKujbiefqSnrUPze5rn8z0fWPCOrOyaH+MWtt g0tA+AXE7LiJGxu+s2WPdu//PRwwKaFROC/hulE4D7luFBJB+jcpNAqZtXRRwjVFSmgUZlnYm8mB /iUL+pes0L9khf4lXDkk7NrklxCz3yZuPGBmGLNo9/6HoRXjBGJ7B4jtHSA2EaR/TiA2s1b/AyA2 FUBTvOUbeSpJ3okshG78KgU0gqZ4y5eslKrh5WAspBKTXlgx+23ixlaMC7cG7d4fDjHGWERsZ8C5 RQkQqwYYh4jdkyNW3SHWUBMnAmK3AkgBtXBuOQ3OrZkAxG4EKaBOArE1TusanFtUAGDMfpu4McYo K/x3H34wxBhLl8c0kteaeZSzNiomSAEt3fDVdAd1zuIqtBVACmgSOre8IZ0rq9fQnVtEkAKagM4t Zq2rZdTGVgBgzH6buDHGzAPfoh0zHDE2TLjwtLygm+tseUE3t4eI1p1Etu5k1txHLKQQrYDWnTYI q9AGsApnoisgEa07iWzdyay1DWAVUgF9xOy4iRsvlWxCw/fDocPXBT7zVckIC8+QbEfskCz0JpGE 2MQa6lF9WHgG1qNKWpzj5//pc7wLus/xRBBiB41zPLPWShsDhF2YMTtu4saTkve3CsyYD4feGOvF OsJ6WEfYAOsIIkj/glhHMGtRKg/rCCqA9M9326CSfR1hve3+cyJI/7xF/zmz1kqjMnqyRRhi9tvE jSHG+FsD/rsfjv133uMc7/ql8vMo97HP8USQAvqIczyzFq3y4BqlAkgBvXHQnc7rPsc7T7BfCuAZ ohbPM0StGjhAWUgljFtgzH6buDHGzMY8jpgPh5tK1oldXetS6AroYFeXCFJAJ3Z1mbVoFQmphNjV tbBiLSTpXBFiQlfAvmKtxZsA3cmstdKojbxCZozZbxM3xhhtcIvgh8MB45zYcHEONlxmohuFRJD+ ObHhwqxFqRxsuFABpH9O4xadc7DhMhN9i44I0r9Gkv4Ra600KmMrACBmv03cGGLMJLwxHw5jY6yN GvXPpr6pOxORu5MI0j+bInQnsxalIiGViBq601qL3Wmt6Zu6dN9LK8Bgd8KNOLVqpncnC6mEXYyY HTdx2xFjp6kFzjeMGUdTWRE44qy33J3OQuAIEaSAVgSOMGvRKhJSCRE44qxCq3AmVVdAA4EjRJAC GhE4wqy10qiNVi0M3x03cWOMmaHLoRkz9PhaI6xCa8AqtAasQiJIAY2wCpm1aJUB/KYCSAGNQeeW NRQrW4So7twighSwkaSAxForrR0QdHsyY8x+m7gxxsymGXp8fzgeMXau1gxFbBWGQtLyjgjFBHVn I6k7ibWaegGIVgB1Z16htvdmMofZV1abD5n4RswFENG6k8jWncyaK81CSgtaAWJW2msTNx4x/tYl BUPmR0MPntVezPIc9ZX7k6O+cn/qIGZ5HcQsz1Fmuc84yqwQXszyWtiFViuY5TXYhUSQBmphFzJr rTSqo16avjtu4sZDJlph+v5wuElgcrqFroHGpq6BxvmugUS07iSydSezFrUiIYVoBbTu1HmJ2jVQ s9LNQnRMXQOJaN1JZOtOZs2V1qiOVEAfMTtu4rYjJruVHYLMX46dvsrhwQyrwDC0itVRMUEaqDgk tSiPQqVTYBhSAQzawjCcyW4YmgkMQzMJw5BIAu0JDEMW0oil03e/TdwYZOYGou37w3EIntLo33J8 dXQJG7Tdv0UELSWURf8Ws5b1AQmphBb+rUls7NKtP/WbTLCxSwRh9iQ2dpm19OAE4Y1UAKyW9tvE jV14OQsfbkUOz7fNizjsTjO57hE1k+/dSQRh9uSxO5m1WnsuAGGxO82k0CNqEulcMQxT94gSwYZh Qo8os5ZKJ9BGKgCmpf02cWOMcS0LToOY4YDplwA1Es5lzASYhZMRZuFkhFk4gcqxkEpoYRYmcS5j XtGBWZjgXAYRpH9JnMtg1lLphMqYlkdPdtzEjSEmOHH05MNhmC9kXK+khjk+wYlkIqg7kziRzKy1 jzTM8UmcSLYxiDk+hj7H2+j7HE8EdWcjqTuJtQa8YN+2AmDE7LeJG4+YvORDF94wzNcEoYAzOXF3 mgAKSAQhdhAKyKwFhklII1ABDWwIFzKEjthtD7gW0DeES/GerxUuVSPWUmkSUgnyw/GktN8mbjwp qSQCw384DgyfIu7T+YliS3PY4JTg7FcjcrfEwGTulvkfZg1BdSGViLxPV0jLn6GQFPxYhJAWlwJY 4WvxrPC1aoQNpdImAWGXx9v228StRkywt8rdxHngw6Q0RhivcN1pPAC28aavO4kg9fMG153MWnUK AJsKIPVzArBnEtadDgCbCFI/JwCbWUulHQA2FQAIs98mbuyNybngcGk9PqTfrKu3TELMdLOv6vhn Y6tqBxh3WXOItegUCWkEf4ZC9mCjQlKwURFCYQGlABFsRCSpX8IDpQmCjagAQJj9NnFbhAlTEvFU wwFjrAiZNg5Cpo2DkGki2BsqQqaZtSoVBDdSAaR/1uMqwljXVxEz0VcRRJD+NZL0j1hrG1wEwi8W Sjtu4sYQk4wI8v1g6O/1PqD/3AfX/ec+mu4/J6J1J5GtO5k19xELKUQroHVnQfbuP/dad/95wXby nxNB+qcc+s+ZtVSahBSiFYC5hnbbxI1PnujbeT2G+5DDtbXJSQlBAzkmowxzCJomgjTQiqBpZm27 LDDJtwJIA40Imp5JmOQNBE0bI4KmiSQNNBDDyEIasbRj9tvEjUFmNo9wVvrgSNCmRQ0s4Yekgc5P XQOJ4KDpCTWQWYvL3IM6UgEUbaQSamCJ+iINtBwWUL1nqIFEsv8cN/9JSN0BSAuQ2XETN/bGzC8a ATLjxZKOeJbHaIiaNprVUTFBGqh506woj0al0xA1TQWQBmoRNW00RE0bDVHTRouoaSJJAzVETbOQ SiwDw3fcxI1BZp5fEWOGQZuh7Y68JRKyfYUp9DPsRLSFBJFtIcGseXXAQirheAFSyJ7tq5AE9VkI Z0vIBSQO6y/FJw7rL1Xj7Ayl0pCWhwroA2bHTdx2rZTvAhIJzYYIo0TQtFEQND0T4A1VImiaSFI/ BUHTLKQSImjaKCu8oYo0rgjR4A1VWnhDG0nqR6y10qiLyi4dvvtt4sYIM0+uOGA+GMZshmQxBDYk 130VIfkeAksE6V8jSf+ItSgVCamE5RDYQir0VYQ4dV9F4NSVuYDIn68UH/nzlapxqsxcaRJSW6AW 7pgdN3FjiNG+JZRum0qjAaMnj1EAmuMxcgQYx2Pk6LCJk2+V2LGJk2+VuDKO/ygBaBDbSAVwcJqI mdYTxEzrCWKmiaDgtEnETDNrrTTETFMBfcDsuIkbQ4xVIiz8g2HEpjYGlxHa6r6M0D22UTFB3WkT LiM0RjCykEIYg8uIFHEVwfGLs4io+xoialxCRI0riAiOCQxqTHGxQtph07YdIdNtyvd5Q4Tm0G7R ScRI6wQx0jpBjDQR1I9JxEgzaw1jhVhGKoA0Lmmc1HWCGGkdpz6pE8ERrxNO6sxaK43ql/TCbtlx EzcGFR1FGPgHGKH5m+Ya0F3tmLqrVPYjtst0Cy/Q9dKIPuq8CLMGF2rXY0W/KdJEo+KiqtL7pbc9 au1ro27zPb53RE6FLBJe29CIWTgR7VMQ2T4Fs+baspBKqPYej7b9Ne2Lcu1xHgBB31jF7SthyzwA bJADYOY9GADbjNPX9lb7Ce2lv0SDCdEtiuBs3dLfNv2C4GwiSPWjCM5m1vIZSEglRHC2hmRBmQyk 7VlIyw9UC+jJgkrxjSTVJ9ZS6YA4wMmJeLztt4kbo9tsumM08QfjaOIogrNNhOBsEyE4mwha5EYR nM2sRYkjhjhFEZxtQhJutADB2SYEcKM1gha5jaRFbsBApgDB2VQArOP328SNA7eMFiPmh8MNLB0s Ol51gOBsHXx3vBJBChg8Ol6ZtWoVBGdTAaSAQQRnaw/B2dpDcDYRpIBeBGcza520IDibCgCM2W8T tx0xOicKBYgZDxg1oeNVt9uIapW17o5XIqg3G0m9Sayli0hIIVoB1Juqn7IvJIF7FqJcTyxGBPVm I6k3ibW2wQN8KzrVzwNmv03ceMCYIFJI/Gjs+fEWw5pmsofaas/KqJig7mwkdadHlSMhjVDYnZAs qJCpe151yw9UC+jJgkrxjaTuJNZSaYfKyMmJutm82yZuPGJygbh/NdzwnJI4yDpNcJBVK9U9r0RQ dzaSulOBzrGQQiRxkLXs+3T/yMQHYGchE/tY5gKm7o7JxU/dHZOrxqyl0nzgNhN+eVZ3x03ceMRo K5zLPxpuR2gnrELNCbvKKAerkAjqTiesQmatWmVAG52wCrUVVqHOZ9BZAS1YhUSQAlphFTJr9QJG mOPt0vDdcRM3HjHBYwrYD4bRoSGIFMwhQArmECAFMxG0uRP6tt78D7OWHZvAIfqKC6DNHZ/E5g7n PMxCOOdhLsAHRGwiaXOHcyzmSntIwUwFwP7Vfpu48YGFGSrF2e4hwlgtpngLB4a0NTDFWyOmeGvE FG9R4ywcGKICSP2MODA0m1owxRs4MKSNODBEJKmfgQNDLKQSyzNRO27ixggz29Z4JupHw3Di4MUN asHzOcQ8yOEGNSJI/3y/Qa2oDqocCalEX35k0sExgExy5H/MhOr658QxViJJ//DMBwupxPKk7o6b uDHEZLEwJ433O8WBIW3gwJA2cGCICFI/Iw4Mabxkj4VUQhwY0rrnyCykB1+o9uAL1V74QhtJ6qdx palRFzXhfN/33G0TN0aYee2HF5f+aLj9GZwSQXAO7poOznRHBRGkfo0k9SPWqlMURVAIJYLgbL9r upCU8TALsRQ8lwuw4q5pIkn9LNw1zUIqsbxOe8dN3Bhh5n/wOu1hfppgJlxDBKu68zxY3dcQRFBv NpJ602IHkpBCmClhb5pgsTcNB1jOQgydHsoFNIJ6s5HUmwbOCLGQSoRFEM6Om7jxgPHz3zEH1nDA 6AmjD4KhVEulyqpHH4SeebI2lkOMakeIDqSkT5nQk8be1BA7l0nqwCxEk0MsF6AtmoREUm8Sa20D dq32C6t3x03ceMDYeDsBwgy3B1ISkU1pgsim1J1ciok2wxPZZviEriwWUogkI5taEsw2w6eWBrMK afv7tQCr0K+VYO8/V41YS6VJSCFcWLjudtzEjY2YWQkSbg8Mzd4YHXZnTLZ3Z5wg6oSI1p1Etu6M 2IMspBDRYXdGO2F3Ru7BLMTY3p1EUDycsdidzFoqjX1LBfQRs+MmbjtiUpqBRhyIGpsxQRwwC/3g ag5/hgNmRLT+JLL1J7PmTgp4pJUKaP1Zkrz0/ixuL+rPwEdacwFahFASyZANQZQspE46ywjRHTdx 2yGTR74SQ+YvRTTV/w8pzJXVZW5kc3RyZWFtCmVuZG9iagoxOSAwIG9iagoyMDA2NQplbmRvYmoK MjMgMCBvYmoKPDwvTGVuZ3RoIDI0IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic 7V1bjxy3lY6TtaV0jFyAfd2gsrsPM4GnVLwWS2+yZWQVyIIsa2FgJT+MZkYj2T0XzUWyfkX+TZ78 H/KHDGTJ4u2w+6uunpmetiLYsuxi83Z4+J0LyVOsV1VTM1417k982DmYNNVf7N/9yauJqYX7p8+g zzsH1aePJ7cetRWzFWX1+PmkqbuuE53u81klRK2rthXV44PJk417m23dcd2yjcPNLVF3TLZq4yw/ 7uXHE19UqFhUMRbz3eOZz9dsYyv/eDc/5vrb+cfntL7vyuiNanOLN11XG7Wx29dqG2Pr+3zRxQbc 4/PU61n+cSs/vsyPe6mpM1o/9bqFujrKj1P6ODNW9+MLWis2dUD7X7qr8/x4loqSoRzmx31Eygka 9av84ynldcx3XFcNr6Xe+Grzm8d/nQil665VFjaPdy1W9nL9Y0QfySejfobyT4q5jr/yVLTJP5JH k4Za9fR9/njy5YQzXWnJZa3bSlVGVSd7k+dXkhDFaiOrVnPbmZMS29vjb31nzIpj08imYZrTx0d/ Gcw6WYG4ci5qY2ZocYrADZ4ZacLgpR/8tZLC7H8HSWm1KOfhWklp3H97NfZpUmMRWW1SM+6RKLfd pIZKhcMazlgtNj5PIPwe4v0lEt09KlpZnnTTZJwaS7hue/5YDvBKeA6tQqdzbmouKUO+gMryJNG2 Q9UWJXP9COfK1C3PxBNccaZ0YppqVsoyLYten2wwqojS4yc/NXeMVUMac0cok7nDVsod09WNodzh UCM3CVDdT8wnYfWSLETAyrQtYCylG08SmQ+hXOwjczkjvtq6YUl+WSdXyW5pDW0hAvIntDjSGj5D OLnxTSJGGNUCebxab6bsDVgV3XalgXM8v7qFZ52FzJzGsf0pW6/vj+nOd/ikcuoV/fuNbXDXTsWb RTNln6R1UnTrmj2wbGQmJaeTr8ofXH5T5i+Y6VBWxaqtaUnVkNuWSRWSz/9sB+YHcJVmXvQU7k+s IXWumDG+DZ9UTc9LaVSf6HxCqpTYsdzhOTm1SSZy0Z5zsRHPRt/BTuCq8C7HNCYV90VdI0KGhOsg JGy9vvuQtPV60mLRnujYiE/4DnYcu0QtWt3P9V/t32/f+yG7qV1ewVlQ1G1nVw1J5KTiUc6NdPq5 bXmQuQ9++at/+/Cjj27c/LUTvluPWENrW70tOYsrjw82t1StuVbW8//jn/7jI+utWR2lDKM5H2za HxvZbtz4z5u/dwrd8lAIWuLp4W9u9guHrdD8lnWbjO/i46cnv/3dh3YFxOxPjc6t/ZftzLoK0uSf /vvfP3T+Yi2k7mj7f7Q/a/vcKlUSlh570mxzDRdshrK8olmFsuGSGaJsogpNyib+cDDhsumK/AXK xrZqy7YNg1W56EzKnZaFC2VzlWYKZcOtxSaSx6ViSfK41E2SvJgIkheTQfJSUc+50IhPiI5IHhdR BYak1knyuFstR8mLiSB5MRkkLxXtiY6N+ITvoFA27/tQ3ZQug/mmVlWEt2j0cvBmXcOLfNfKvv2Z 8blSCWTMdIxUKgoXSL5KMyWSBac2hAvR5ekVMtuQmIjTG5JxemNRzyRBE5zaEG5dXDq9bhGWppfH RlwHPPXXd89Tfz1psWhPdGzEJ9pmAMnv71BXbi65dbUb49czHzw9uWHtl6yZpURvfLy51dbSgt1s /PaXN29Yg9TVspOiyPjdh7//w42bKzYtre4uKXsLTIsXjmQTZqp6ScqCRQsDgbxcM6VAth2jKDUN zyg1jGeUhkREaUhGlMaiPediI56NvoOIUh3J8EnVNRmlyjQZpSERURqSEaWxaE90bKRPhA6AQL6/ Q13WtARCRLMcsDlv9NI+k98YTc5OWZWzTlNnhxYufaYrNFMCW6litpX39QNLW5FnOyTibIdknO1Y 1HNO04QqZlt2hfqVLVG/UhP1GxJxtkMyznYs6r2flqjf0AEA9vs71AsBm3WmALbqVAns8IPlk2BF 9gJcS+l8G6ZRRbe2innTomSB6cs2UeK5aYpJbhiZZLvOypMcEnGSQzJOcizaz1xsxCcaOsmsEx2Z ZNbxNk2yNSgmTXJMhEmOyTDJqagjOjXiE9ERn8Pz+zvUy6wBWLekHzK3xPVrAL+ynCmVdWi/DM0a lhYGq9nLNVMi2Sp1Or3Wj83Tayvm6Q2JOL0hGac3FvXeriB2OHQQ1RUr9pE4i6tB1wgj+0gxEdUV K/aRUtGe6NiIT4Cts/d9qKtfA9gVO5fv2Bqg6fhysidMo5Z1lWxV6uPMVBVtp4hgFYVn9rIv30wp kMzrxohSxlVGKRMyozQkIkpDMqI0FvXQC434BBMUpY0qHGPLmozSRhDHOCQiSkMyojQW9UZC0kT0 V+YE8v0d6ovFoLvKORKzHVrqW6cVZAyomglNCpE1s5E3fZBPzH9OK6HQpR0UBESCDg5RaBOJV3qL SCFBDST06M2ieJ3igHSXnpKnxxxPtE3pJ/FCgAHbMP9oLtSijBfKoyb0784zyNY6nWOA/fGAHgbH /Ld0KMWZttUhlfVBe0xzZkg4gj+n1KztIXftgTgRdtbeyQC7YzSUE8jVlygI5CWExTaC1R6aaxyb ViFSjvIEXCjMbX4uGtPzmzGmVhr8YJd7pmRvBWnaQ+S/gVKVI2++G8TX+mMm3D6pKQZ6gKT/lD4C kd2HLMlF6zKSohVdmjtplfgKogiEcUf5eSAgisCSwL10plP9a2JriB9kvGYhFOWzHH72AkXBHtLH mE9Ca6f58XbKJ4qs2hSNfdaiD3qxj0a3+VFvPEIivQul/whZiucUyIsjS89RPpEZonOgUXoGA3QO EdUV7TXmn0Is7qKuzqCkVinIdAeScoJ02tvZ+jOj3oO9vvFRts5LEm086z6CvP4O2S+oqXdopcWq ivCqFFEpeKU6v50rBGcrCfRRTS00EQsgo8oIsU4Z1R0LcbWFjB6hSPez/Jgj2Y+gjE6RDBMX5nb+ NaONiOsDJEMFbha4SOW8X8hbWiwjL0a8NVJrB3V1iCA4FGkPIFpRtIOuCsdysQsDDXMhDaTXXkbt wlr34Opl9LMF42PqAsOr5sWulb0ICIvyWQfT5sVI7+sNrw4OprY2OkgHxAn2H7PdfwlHf4iKkskd 98qJsQDeypAxuYSFKKhevJiDi7HTEchV9EfA4G1KH+J17mp/jioLxE9GiQa2apzoOU9caX8czu0a fQ60Wst1roq0W4R50JI5eY2QAjUSGf4nEFSnCP8vEFPjnJUrnSkiBbs10KrDpdwF5As7GGNLOajS DxApxaJtaetwQB8B/g8prxZbh8JbhV15ld7UqkluF0K11bc9qpWZV8UqxSSvRxVrVivuYQ1tMlaA 99Cs4LX8CSoK3cYhLC3OH6MaYhGvBjKAiKfzDPZ6OMIgmF+4WgBA2NUaWu96LEnT44U33KxuwZtR gZxp6c9S16Z4rU8t+M+7oDMQ3hnAJRCsMW9xCkcNBe8QNrWLRpXdhUx04YNB/gGEN35nlBs2py1l fKNiTdpSsnRk9i+4Myou8QLw8PyPLyEBlPAScg27gx5Lwp/erlhbJlQgbRmOkte29WBH2AU/Nbwk X249hBma2R48TfnFfkR63EPbiwf58fYsBJXp6NbD3RGIbyMI47UJ1JaX82MrRAq+DwA6+lPU1ZCf CswRltEDJHiQQfdh/R0kLVNaH2w93EGKYy+p8G1E04X2k8aUwdyGRQiDELbonN5n/h2x1b25FxW8 zW+D9DzdyOTdTzTfgcN/uvkTH7mwtqlL8pfckJ6BCan1cMRVOR0RrgJ8AD13ECT25usXd0k8mAPn hR1rQAqd6ofjU71YVcHdgcLbBFIzY6wkbyrV+NckedN2K9kotwJvDMEIsFayM2ad1spFV0szZ60e pd3rYkt7ixlnTrh7NB2vG64GDqbuIh5j53P+CKi/RyXlP0JNEd+k8PMXb3vtzSk5u3rr+c3smmoV c8xF74pktsI5btZzmUbQqS6cPvjMjzMvxnYYoEuIN8a2EdvhxvEB7OoImWZyHHaOmlqkE8OxCwAb URPfpqbOIVgu5Z6fQQbtoabgvsjlFq1g1SaND8viFpGz1tvmdevcQFDWNob9gx0061hYzxFqjiGr l3czL7Bowyuh46V3ZrFYnaH6Vz0Bm8KmjtGosB1c5DwX+weE6OeIf0P4BaJAiKo3Z8Db8m52g3YF R9QJh0gpazV7N8T1Gl7Z1R2fM7xfpWVevOhn9lh5i7nw+O6aTXCpgL9CSMEeVz73xjcVHSL84p0E aIGK/bU5a678S9DMrOYOkxAwlucKAUdptVZrLjpHUw8ccukNPBCBnm6xrYNVENArUyrYMf8NxQVA Ez4mgg7bGwgBuAU6toU2hVTBogPXeyEbA+OnMDAzA5/NUcUUjscYl8Z5E28VRq8lheBzJl6atYas Kqew5VxIwUuEOjLUZwhq2HBOEcALzw50VSFSDufzrY67qmcyh9oZJ/SY5i/WzNB1Bu6IpbpGWPp6 xAnFTk424sRyPEL5uD7ciyuoXu501pZlQ6ezNk+vVdlaR1mF/ZyxmJHXCEBTihpsxMAmUBGAuFhZ QCdxKD4HNDV+pg5MO14wQb1NsApP0QjWiJfxBSJ1/OyK6BUA+8vGDwGqC64uC2t/swmGNeNr1dZN 5/zh2ViaQyThYweWWAXCE9tltXExKxircDsbAwTufR6j+qTRfZoPqDoAE8x5P4lM8ZVe2Shss1YH 0TmbC2NMV9xJJmcDba++VpH+0si+63jiYdcqd9JaJezOknOouRBY3bS1EeOrluJEBRwuXWhTGygB vNX+ABmsy0WL1GTUbmp4019Fdn/y+M/ZYb8u7j1EQy62xxY7OUPnVWBHfqXcBVQB7s74O467xtRc WTi7W9saE0/SAOV4iXmE8vH5Y95NIT4VjGHBTMxoxSGv0H3CTiG8mRvaKbxAg1OHHfDsf2KvejzM aqmpLfaYcGwY9IRxdCWEtscL63eAvDCSdmqEgxpx1OQfyXW5HDVF7h1WKF+OEH8C8/8vC0O+bP5r yDJ4ZF6EJgPIjr09VOf+ie1Z/4FrME3+guxiN8Qq17tJud6h5C5/fnVhReoU9QUU6V3I5XykUEg7 8D/wju8dSiAQXLiwxEEg0IGrB3oFdpj0CsN+oWbEcdljJ027tChA/DR984CJ9M0D+lrA7DaiUFIP vaohws1A61qBuus+49uGcIsCH46co+nDh0cgTEtIvcqXOFkn3Yl3HgrYRhXCrPUtTtG16Q0xojju J8URXxu7vOK41ObmfSitY9HO8L0lGHmPdyHG/Jjxs7Y5GeL+IhHWKb6SrXijnYOXpw1hiLO1vmXY X3TqIfQoQyg79l9cDkLwpV6s76AawAYhz+sOROOYp/cFguABJQUA++08Lpi/o4q1ciVBNdxqqpbn qUCwaKRcKyxUm+Llv8q4yBGcRdhneswRoiTsc2hByN0ZoOIDCHpX3jO1wL/ce6bw6A8uBs4p7AAp GMy7tNXFjhCM0oMvLd0aEAbQ1K53SQRzdnH+K0xwgbeD8kdfo6WbvrOyyDslfYQn62b9HN7pZp1b kkK27ntol3+9D7gx3Pj7e0UjV+LGtNq9lJMpBbrGdrnW02AhWve/iwZ3wcX00Kuii9ej0LuH1ybg LRj4QgPegoFiMbZpPBRYHosej4zqyi9EwBj3oCCKfQ/8ag88t34+wupCf80IRWv8qbESak7ow32+ axN6rlMsw9j5azGPwBDhWAUIqQvstuwi7uPzT3gSt/AlNWseF57k2XzSKzlfXP4lJWyzrvUqL7yk 5OEmPhqPeKWQrqZ1tjMjCCnjtlnrabFgOkX///yiJPJRhqzN4tOVMRW56O1HKs/9zXBj1moeueF6 YvoaQEKY5ms9uHVnyDEe4ef3H0eXNsBi/LTvP1qjy1f//mNGBVKCUs1uiqzmK2tuR4aHHbT/DeO3 y9zjtIwla1t4xxK5Q6l4pzHml2GvUYLto7tLvPv59cbrf72RbGYW72ItdrOLwHZwEdr8ITFToy/4 zXy0kfUfHZq5NGkFCpbbNR5fcDPSawiZHTR579ZBGVdWZgZXreG2XaIj+g9NdFKX1m3pLxMIxemX CexclfdIxx/81wFo9siXCbjoGlTRfVYg5k2LknNfJrhME8X10UJJel2/UCpf1y+Uzt9ViYlwp3JM hjuVU1HPMCVIIl+O3n9zRRZ3KhtB7lQ2nNypbHhxp3JIxjuVY1H/MRh6wbKRA9dHv8dDvdCXNjRn kuBZN2bmG5/hB/cBF8OL/IWfkLEiqVljYFXO25w7LQvPfELm8s2U3/jkQpHZ1lzqNNuaxw++uS9O 8vRtuP57lDx9G67/VmUs6jknacJ3ED942UhNZls38ZJx10jDZZrtmIgfvAzJ+MHLWLQnOjbiE1Jj YL/HQ3VT+sp2Yy2uJSKqWd7JlJyGZLjXehoKp+SLydfV4Yq/Dyp52qh8al0Yqw6Ec/JubLrIWW7Y xm82WS0Ya+1PW601ZUqIjY82u7qxtoSRcjfdk+HWZ/i1bUbVSii28fGmO2/sdJsM7ZeOB7xzU8TT BxYtVTE5DUkWv4XrC6fkRXnQLuCBYsqdfFMefLLpNgva3p+1w+laaYd2TJ6PyPNp8RwqviQ/PiPP U/L8ljxXseJr8iNtZLsoTH9PpFIf7MsVMScCxGJZpECH0OP5ABPOBhh1ECvukR9PBsZ1XJQBFQ8G GEUp2YsVTwd6mQ6Qmsa4PVA4cbt1d3mHmLU0FycFDXSyQq0ZqRRN2/t/vpnrlsCZGbf2t7XeepVu WQ2DeDGAvsOB58RsyqfbiGfBvXV/nPtcMdY/K6tjpV15S+515cHk03uTW/e+qM5Ozvcmt76uGJ/c +p+qm9z69OFnFZvcu1v980f3x/7z/S+aH7//0T5PPr9XfenabFKbhq+8TeZOrlfQ5goEtOu3FyxF cWn0aGDedpFuOgKCYVi/w7lY/F6R5/MBuB/GijuDWg9rySRIhwX9AEruk9SMWwtrZSJEGJ8jod8b bIjqrVARMWVWsZ2MkUt7H9JVZ8jObKNxtv0ektcPB4jO3YH5mCI6zy7IGWjW9gf0QKkyZ60T1ZdQ y54MPL8teAgYvj9A/DHiAEXkdwPcOEMcqImQ/L3fOXAjuYum5M0Ag04RAoZNBobRbWz3qVb1z+51 U+WOP8LnclehAftXWM1K2lyB/+YumKuEKe7KWYx5KGJbyvVhbdGWx6gPRAXAH5qqHTSvQ8r2cACt EBCU3tcDvU9Rj8PyAfTKc9T10QD+BnzQLBz3B10rUHE60PKdQbYDzQF1zANkvCgW3gzQmazedwO0 uWux4GjvxJoPSAF3MdaoUTm6gD0gry2NuNWnAyM8RExcbiZAj0MLlAdo2pabAKqi5+1IBq6diZD9 cIDiBTMRau4WZGJxo5K1g3gwbxxmHH0m+k/lrMfPHzYIgnXu+ozuAsr7h3/+8I8f/vbDL47/9uM/ oEFotKi49gFWV2lzZWtW4ZjtDcKnY0p1yM88Gzeu3O1oasbeAUNoB9xpOu7PyVC+H3CJXo4Jdrl2 xgvYLd5ZAGpebQWE765hJ2nROtafo8xSGYv8i1BpBdTFMq6DykW6oql4o98FfPOm/zKrbCO+nyC9 T+V6f0CrD+JY6LphXfvOIOTJxjdxjH/fJLt7/w9YvkUfZW5kc3RyZWFtCmVuZG9iagoyNCAwIG9i ago1NzM1CmVuZG9iagoyNyAwIG9iago8PC9MZW5ndGggMjggMCBSL0ZpbHRlciAvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJzdXVtzHMd1tpPYkhFXLlV5TWpzqQrgElbT15lJnixH5Sgl27LEVB4kPUBL gqC1ACGAIKX8Cf+bPPk/5A+5Kume6dN9zs43M7vAkqAgSuKc7Z6+nWufc7rnm0W1VHpRxT/0sDo/ qBa/DP89PfjmoFma+E9XwJ9X54sPHh28/2m9UOFFu3h0elAt27Y1re/K1cKYpV/UtVk8Oj/4/PCj o3rZal+rw4ujY7Nsla3d4Yvy+KQ8XvVVjaOqTikqj48v+nKvDo/Lj/9WHsv7J+XHU/5+31XjDxdH x7pq22XjDh93b9VVE97vy01LDcTH09zri/LjcXl8Vh6f5KZe8Pdzr8eoq+flcc0fN+Yafzzjb1FT 57z/rbu6KY8vclU2lYvy+BQN5QrN+pvy4zVfayqPq+4qvbT+8LOjLx/9x4FxftnWLpDNo8eBVp6U 9y/R+Fg5m/VXqPxK4Jp+1blqVX5kj02e6qIb34ePDn57oJVfeKvt0tcLt2jc4urJwemdOMSpZWMX tdehs8globdHv+s7U4Edq8pWlfKaP376y9Giqz2wq9Zm2TQbY4mCIE5eNbZJk7f95F/rUFT4/+hQ am8kHl7rUKr4/06MfZDFGFFWncVMfGTC7XEWQ1LgqEortTSHH2Yi/BbS+zPEuk84axV+8lVV6LQJ A/d1tz5hBfTC9Cu0D5mudbPUli/Ir6CwvMpjW3GxxYf55ilcu2ZZ6zJ4RldaOZ8XzVV7XTJvRa+f HyouiPLje/e9Ok0QQx6vjnFNWR2119Vp2mXV8NXRUCJXmaDae14nE+SSFSwQeDpUaMJIDz/Pw/wE 8sVTpC432NcHMyzzr2rtPpfbBkUrWMDdo8axQfE1bCUPv8yDMY2rAT/erbdG9ga0iq9bqeDimt9d w6s2kMxA4oT+XHiv60/5tu/w80UUr+jfL0ODjwMqXk1hKjzZYKT4OjZ7HpZRNRlcH3wmf4jllSyf wHSq6+jVuqnZq6m0lqBL4OnPwsT6CdylmbNuhE8PgiKNpljT9G30oKu6tbSN64C2B6zLwCqsji7g OoDKlKrdylEj/TL2HazSqpre5FgT6HRfNTZibAJiBwkI73XdJzC81w2NqnaDpkZ6oO9gFZfLLE3t O1z/R/jvdw9+yhG12wu4QBTLug27hsxy1mni88ZG+VzXOvHcD//kT//sRz/+8Tvv/iQy3/ufqoq/ HeS21Yp2Hj88OnZLr70Llv/f/f3f/jhYa0FGuUbxkh8ehR8rWx++8w/v/lUU6GENjeE1vrj483e7 jcNxav44mE1N38VPv7j6i7/8UdgBqfBT5Utr/xg6C6aCbcpP//Q3P4r24tJY3/L2/y787MNz7Zwc WH7shhaaq7RRGyMrO5pthE21dIskV7RqWyZXSFpmuUI/nB9oW7WiPLYSZKxV7aBWXam+ljYtb1RU FiLkLs0IEaK1rhg/hc2Pzvykw4uZnwhI/ERg4qdctVskaqQH+g5WtICCn4LRqTI/acX4iYDETwQm fspVu0FTIz0ARMhDn+reRYf2VdzkdLbdD7+4eifwsl0qbVt/+NOj43ppA7E3h3/xJ+++E5izXdrW GlHwlz/6q79+593d2GxOp+uq1dvxXtCZTpRP6vRuL92zzuBVU7eOMZaovKHTb9+MZEilDKdSpV2h UmVsodIEEJUmkKiUqvaklxrpAWU4lVZOcSoNS1OotDJVodIEEJUmkKiUqnaDpkZ6wKkRhny4U40o 3Ybmu4Gotqk4YbvWScJOP4R1MkoUT9C1taGqVx69GNUxla1FTUHTt21C0nNFPJHAHiVpJbUpSE4A ITmBhGSq2mNOcaBSDMlho9EyJKuwv8xIVq1qMpIJSEgmMCE5V42Dzo30gGlH6PnhTnUnetbOCHqe MJJ05bcV1FoLCbvxajDMuEgVlaXldIdmJGE7J7DtPMO2qxm2E0DYTiBhm6r2K+c54Di2g/KtGLa1 rZsivYJxXKRXAkh6JZCkF1XtBk2N9EBbjRD2w53qboRtVbMlYW9a/1OE3ZnnhSLlq70tXyiSVwZb gts1IwnbmpZj25LJ2S9pVbCdAMJ2AgnbVLVfOTJ+O4DESg8a8nUk0PuC7RgWy9hOAGE7gYRtqtoN mhrpgb4DQNgPd6rbEjbf3JrKb0feqq002NwGTaIHtTKRqaZV7CVRWVDyXZqRlGw0dxZpY9qCXmOL s4gAQm8CCb1UtV8kwwHNnUVa10JuxWhLRq+2TG5pK+SWtkJuUdV+m+qY3EodAEp+uFPd/+Y2qKGq ecs2t7Xf0rE04L0J1dIzR9YJG6/2nFQYi1cGDHm7ZiRD1q0wJJqKuWAapQuVJoCoNIFEpVS1Wzlq pF/GVhgSnoaRzIyW7fhcw3Z8CSAqTSBRKVXtrZ+WAZ4s8gFDPtyp7saQc9lR0btlKSpMmQXLkkOw KJkDH/Ekg43Mgj7rKT8+z+WPy4835XGF3n/G32f5P7Gqa9pBJkzVdPqSxa72kAqj9dKkqOqjMt+z PF42yOvyuEDzfY7myxbhfJBbxubrDU/dYplDl1snZYhGWRJT96hbJ/I3uh9Dp9tmdnWDAikWz0c6 ncs32xjJRtT6Ipc/hovCqt6g1DfW1XkuPxksikx6wVPpqdAEMnJVTVGbk/zSJccUmB/LbFvx8YPU vmcjqzoSte9YopdQJXy8B44IElAljqBcusARl5miWV7kijMzlZ/yHwFHLKAEYXT2TeaIG7g4V4ji BclS+ZANWIZg5IhC0qdw8a8QnX6KWOZmhLg28Bg2gjwlY3HfKTh9ghLH+W/ylF5CKXA1So9Bn7m2 15/amdeQs8OH+THE1yuEr0uEr1ezk8NyKT8+RlU/Rl1dD0gvPn43wddhGevE1zPJhq+PNJI0CAKG jHeWafgE6fNXyB5gLP41V6V8ytbohWvIner2STmqqrrYPJsGkz9fHBZr59Pyc2GBj4eoDVW/OMoV lpyXmeUEJBCmqCKBziFFP0bC7opTJCDDM9jUOWrqPTSUEzjqM6TUnsJeF2gBbtBQvtqeD9lUTlFX jKXntMWa9xrL27YORAk0/TXvacCnjTH71r8+7DOaRKpk/AiOezmjX5l+hhYrO6KA9e8C6d/rzRUb N85OkUV1Naga9e8JwrPAI+gKmqTXsPzFZtWof+foiOmLG0RHQp9sLpBybH3Sb3XA33Kzp2j8fVh+ ZBnZJ0gkCOMS0Omg0w2kPEMcueKNAktmbNHv12hJfNKEv3o2YdnwcKPJ9mAnqJxt3MpJHsE7UGPM SZaCx+9m5O2a4wmLVrDJWXBEAdF8zh+hFhkoYd+7BJXT+825NjbushnK4DKcDcktLPMJmvvAsI7l b5Nh3bql5hN+ieiC4V0Y2yQfgqGBCUcoIuurjLk9m0/GmjABNg0sZplIuZ4R/tf3nUzf+KUQHoyL OHOXncQJZO71GDqM1gUdhqOjT/l23ltpM7xeMVmr5XA3/wr5t5hELGL0rPz4HpeIA9Hhavv67Hc2 C7bLOIFjL5pwaHNITfeE82R+/PqeKVT5mKfLp/zecB6BQr9CU2JMBzcReFsMNRnett6g1WVvBZEl ls8E7BFtNH6/R8P6c05soe7sTCwL9XKmqRWcPV/oe5Zzto1nPNnijDltgXYVTttNZRVIb7B94vQQ yhm9LJkTv43iL9GCr9q9HjPSpsx149BL6LKV3pQ9iNXApE7TCc0sV0+Q+TjnBWUitvhNhsECZon2 tjvt0vbogh/6IOIurVD1DX8f0ADee1yj98UxTbBLO4HkBHf7J2hW65Gh5Mei4Z/xVdtY4BG71LTD aMpAVoBt2pwkhtuwp2UpjtGghZMpiZ1j6jie5tB954TdQKhzAbv11u4ERqhMH3+3ibJIqNjXs0AS CG68L+D7jwuhLmZWp/DEc0gdJ6irKU0RCfXumgIxQhqgcnjvBgeNYxAwrCdiYYBO56NigOWhdJkN jDzHi47ouEonmmjJa8fiToz6mHB9gSxZIVGpnFH/9aCqJOQ5DxKOGJTyj8qPdGq3420gUS8gzsrN E0IMT1MXe19ELae9ECs0q53ip4CTsZl5OdMU9HKI+0IAJUPx8hxhhQ1qsBufjSbOCl8S4sKXi6+b gdfJDHY4G8Kb0TyTs99lmsUOVuiLWKPVuYbvPyvCtwhXrNqhlQD9QDgSMqC5DV/unHQa5FyMS6+r LHyLkgebMDMS6N/BcQdjDpDkxEiBaScWFXA/vmMIuoWnhS9zI0BCZsIThgFZ+XvIHGY0P+D9DUKG a4IjRgXl5Inv7ka5fzd2PAydXFG/Rit7uwDrAmGG+bmFZ59WFlvvMIFmYN9Fd+WYfcfwBWTtTs7D OZN7aw24Qox5w6tOq40dRvUClbNWz9CqzMkIGCSas6qfIaw+ycIOBLPD488nRUR2ANq26VI/jLhA pPd5hrI3c49Tz1Mxj9ImnmK3vH2L1CrbvpQUpzVUy4WnxpICN6jnrVC7t0pxwr69y6x2RZQL8NTt ErMWmRJH1BJo6dvBokiWHIsZAZZ6ilaCybTi+nwGkTZvnoLxCZ4b8FTTNuM8Vb2ZC8kSTzXV0k7k yQ6dVJKl8O6qvD80X5lHokjRjTxZqOBvq8YySz1FdHyBqA8bVfDeQEG9+fFlZqmx7N3pWW2Za6FG Ui2ET3iaOa9QT0J6TVqywzHVOa98o9GBbcIHHay2sZluL+eGfNYf+zUB+wM+a1T7JnVX3e0Yt0lr YFro5cyOsXhJmDn4FKqu54jP4DYOh9cKna0gHd0UPpu3sbqhqJq3f4FIFiSqbIYhAPX/fJ82GliA PVlm8Uex+5w0B2+nuwY33A4U5pSaqnXbR7tbM2Cf2tg3qaZ8d6lwxz/svsyynWKmnXBXAz0kPNtU /h3UcwMjaPw8x8mMRC9HAyb5Z7s9CiAKIR3nWBkQ7b7CiKYd8V3O5X7OlRdWxnGbq2kvITZ9C1Ni j9TY3Yode3jbsYBubTVgD++qN6ld+qjwZjrIXf04y+GcHZ3Rdvu4SjGlgZThHw7vUrRBU2+cD9vP ZYouSjc7iPWWRWPHYJhMucnlw3DCMIfmHvJM0pqy2Ykc+Pz4MX8k4XQLjZz3PRvXXDcm0Inpj1c6 1+w1fcjXSzlF7DAubtzhjkDubNn7MEiwgyTF8ZZzpKmhpMHZLGJLAqrCyNvc+3gXK+wTYKhD+T8W D5zuCmYyT+bmh1/9vrM+XNgKOC8JqXZ0Ub+0zhmnl9OzY2ffqPwbLj7y4+A0Q7QuhhHwuORDOzf8 +KhUhXYsDpIsZnj5JSJUEeyeM3SASsfW9Q1qChpC2LoYeKs3rAMRuwHloqm5bTSwLqBvAu6tTwaD UnyXDJA+xhzbJoWIL2IANc+s4OIAZZGEU1Q+PFjCLIYiDzbOmFzxFZ2mU+ggHWYXxV3mGcLYCW91 eusErWwhkDfwGL05WI1AgfoYzQpvHc8zSUDTHZL5DuERptsut/bmDPxeptYjbHyLYCOhVNxBwOwp JnDLHo05EIUnH0hhIaU3RFukTiF6gTa7GCBHir7pnIExgf0JagrHeuFQ5jyg2IiZ18GApsY+8rIt oY/5GEBXIlEKkCe0MeC5NRzLL+9f8pfQ+KaWSrlpgcsMhytEkmw3UbLwmMAVmaVbu/VgROoxmvyc e3X2UB8MvkBtv9OBHtRUSRc9h02tEPfA8+Ks0eG5d+Xw/OfShKDoZw6YU/4+oGgYpGbu8zlXx7Rs hf4xRn1MNpY4ztj9LYAQF7yczRkQ4iu0kOJMBiBErIRYOihMTYPpCDh55wINZc3f7x7DVKAU/xRN 6hS2VMqx028+XRIQ2pzoFfmEbFKTopUtOvxS1vwlJkhhipDcwJOGpCitk0i6H0vhBFJWZItOm61i n07EixcPni0SO2Kw+DtszgdD2cDz16Wr+bxHgD1sjEPs3aBy7DyFo77FAppt4p3bBkeEjgfjh6jA m66BdBunXpK9bNf1LPvExs58EHkOM+P6VC5A3kxMi7znadkBP2i3g2aG3+ZjAT8YJfsKEsow8ivF xNPNpqIRgI1JmA4JY3vYboSccpYtg7nQHgxtnMPm/wFRLzzcJw7nUfl3vKX8uMy7ssWRpEdd5W+E /Gehx7LPYpsnpuu/zuU456PYAmNEuLEeG7bA4Jqs8fV8OiMNWJrUnDeq8PjpoDyM75NczILGvx7i Iwje7ckNizjoa76Aj3Nmw5yv+Ax1Jfaxk6EyvA2EBty8/zY/zrnVhZdju9NOJRTDzFtGkgtUzrZc 0PUwvNmvDDmSNDsPyWLq0JKCX3LFroPBIY+oOEaTyO4hqtTW8foa23+2MeWLze1SgPE4dvUJqDon MEaMZ7FO3rYL42wXMaj9fj/H2F9exldkLkUdB9fgR35fzZCW2DmBrubyrgCPBoKe42Eo7vD5oWHk xqTr6fcZuYlXydPVcfd9q9LcvXo7hCCH4QR5DHKH4y8i2gi4DI/6vWx74d08vDNsVQgJOudxXgiM ZsKQwNxBr7GLVLf1KU7GKTpxv8WuFbpMhGcb7EoZlUHfH6PSwZZ/I2g4cHdvIGknd3cmPZgHBJF0 xjE7PZQpd3QkPdb+Go36FX8pP/4ilzN3+38ORi18fzsEU675Uk37kWDq7HwsaNr2nfOj0E6UzF1B ksz2YUb8JSJJJi3hLdEi1rEpOIPtIpIwp5kZZqGOJWGChcL2NpR2MJiDwwY7p79sjFowApVjaQtH DXw63e0w056oS8SI3/GhTp4KX8GlhrcvwKjkNVzq+YscJux94vKx67uF6Q9cJpfl8WaCkLeJq0CH F45QzCUes2s4bsUTl7wqsDCwBbDKshVLLIhI9v5/z/Bcud3gdGb+c7vlQufYvIS3G8ztK/91xvk0 d6PQDs4l7i3Y0mE4d+jmK2SUvuCP4H0m0eHdHZjhL9HqrzhJAJKl9otGKF1taARoOWC3wtzlAuLq GjAqeBIdp+DBcrwRglY7vJgROHuEF3/sVMuk6bCGL73KS33MUQnU2Ngt2dtJ5LtkGDO3SV8VSGSW iz/I8xjfRt9KSc9tKRj2mUSG3yYQ8fdY3jgtsYNGXazdsbAnoEk41DEbFlT9RflR2MhggQYOwP5G ZTSUG0SzhX3xfTkQKzucZThHVXE23rQghnmfY5GXaUFdBDEzU8BXQjbShO7ZwWfCD3phXL00Wh4I HVfXYshV292P2p+JqPb6oQDlXAxp8MHdMuR6315Utay9mAd062MG3lmCRVUwljMlFsK1TUadr/aa qp9uc+RTfkNH8eLs8Z3er1BXWL7MB6aBTp47sb578tmQ3aJHVbe+2vc99cbW+aQdO6l6jWQiyxGG R4mgTMRur8FtIdE4ndtabZtnJq+E6VYuffZrrx+dMtrHv7ql+wzZSCu+HvmxePyeD9ZD+lQ0XFp2 WRT076844QJrQlzvAt6fO+8ist2AMYrZvfixLiEWYfQHX/4IjxHMfeBKZIpvvQDbi4Oxb3VMblvx Ut/9U1hAFW6dqs2EQHEUMqeKyCYAlC42q8AwGhI9EwJNO/Ipls+QCBfR8mm7eWCCR0qtIM6hCS74 a9oVsAN5zSd+AmtYmODTCyAUyzbWfiz/Brb/bNrav+0nvOZ2A0CUTe5V9/pxI6ACh4kFhSOjCruE iwvjrDskZLFPnRXhMHdP0NwJ77EzTBtyeDwhay4tBX7z6OVgAZQD4Tcz4jR6LecM5i54wBfWFo57 BVdaRO+38w6yW65KEAaHtMuZA2xFnKNNKysnlO/lsOGcaMmP3yDZuf9vAkr0zSco5x+hbYTTPF6W tYJ+aPgFGfyZyfmdwLayV8huwDNQ4GPyn7+9aEIMw9wMHG18iQhVXIhK5Wz7Ib5ZC8Twba+UmDbM LosYfp3X7YbxM4fuNSKeJ6gn1v0p6mkFkHev39XRje8yV/ktL8Jove0h88F3dbTx5rV9V2dkGq+L LcHmQNyQdL+YjV9w4AtSxPDPy5bcuPhJ7YQTVal93C1ijYuOjNL34fBukdBl8wZvMdK1p0vAWHpG iUqzrRR7XKBycVUlsGt3OKS1k9EPFNtQM8vE7B1MfXhwcQWHMjACol061dWGK0IYAdQVTtGbMwJg uEKco2ETBO/PXWB5qwQBKCJ2OueClnKLOEC8Jkjrur/g0li/eTWS1s2b/FBWwPsgPbTs9Nj2TeR9 z9nKRFDsMzjdvFXbfy3L+f1+LcvH+0nSVA7lZ3B02DBtuDI/X2iL//0ytPc4LPirKU0QnroLCzsP 6fmBaVSTP4m6PvhM/nDe3fPDiyfQ2dhY1Tn0YqNL2VrUXB+c/izMqR/7bZs460b29CDY5z5MTuu+ gQT2l9nZJn7rura9adBYl4FVWBRdwHUAlSlV+wVLjfRA38EqLaZ3Lb3XgTZ91S824k0CYgcJCO91 3ScwvNcNjap2g6ZGeqDvYBWXyixN7QOKH/pUI0q3IfV+IK6/q5roOX2ur9Bz+uH8QLVOi/IJglat j3UbD18N0qCUrmVlQdR3aUYStlcVx7bXqmDbG1WwnQDCdgIJ21S1R6HmQN8BYds2lmPb1rpg25KN HTtIAGE7gYRtqtoNmhrpgb4DQNgPd6q7EbZVZjvCDqaw25awdVM7RpEbr+ogVhkJisqCsO/SjCRs ayzHtrWuYNs6V7CdAMK2JQWQEJWq9itnOWAsx7apGo5t3d861jcSBlqwnQDCdgIJ21S1GzQ10gGp A0DYD3eqOxG21y23QLyqlSBs+iGsk1GieIKurY1VW4NetLqUrUVNQdO3bULQc5A6hiHZG13Usjek o8MqE5CQTGBCcq7aLRg10gPKcCS3redIbhtbkNzWriA5AYTkBBKSqWqHV2qkB/oOhvT8gKe6m6AO O29Oz1WlJT2nH85jPk4tyqcskJiv4ytt4avKNXUuXcvK0gK5QzNSULfWc+nVurpIr9bXRXolgKRX Akl6UdV+5RwHrOfYbhrDsd1wtdx4XbCdAMJ2AgnbVLUbdMPVcuoACOqHO9XdCLtRmhG2a1UjCJt+ CPrfVq0on7JArIp1TQtf1aZtculaVpYWyB2akYSdN7wJ5Gq54Wq5kWq5kWq54Wq54Wo5dUDYrmvN sV3Tzcvdbsypgu0EELYTSNimqv3uLzXSA7UeIeyHO9WdCNtEx0shbEq3y4RNPwR5qVsjyqcktqli 3UbDV5VuSulaVpYS+w7NCMI2StcM20GZthnbRtHOOyw3AQnbBCZs56r9yqVGekDXDNum8o5h21Su 6GdTWZuxTUDCNoEJ27lqN2hqpAe8w4T9gKe6E2HrtuV7xgnC1rry2xK27nNSiSI3XtWq9YwERWUp se/QjCTsSjmO7Ur7gu3K+ILtBBC2E0jYpqo9CjUHlGPY1q3j+lm3VmVsB+4s+pmAhG0CE7Zz1Tjo 3EgPuBFT5AFPdTfCbhpuioQtqZeEnX4I8tK0TpRPSewYJtZNW8NXlYlhhlS6lpWlxL5DM4KwdfpG 2DmBquhn3eqyoyIgYZvAhO1ctUehcgyouH7WjVUc240p+lk3uirYTgBhO4GEbaraDZoa6QGrMGE/ 4KnuZmNrUzPCdvG7bZyw6YcUEmHFc+EYT3Ee+WIXS0lla1FzGI65RRPStNauYUh2uq4ykgPQZiQT QPZmAsnepKr9gqVGesA1DMlOGWFvKs3sTaWYvZkAsjcTSPYmVe0GrRjGqQNgWj/cqe5Gz5UX4cVx eu70/5YE3VkDhRw3Xu1Mh0KCovLQArllM5KwK1JHCWxZ8E1VLPimihTSBSRsU9V+5VoWfEsdJGzb RvPgm21UnbFtm6oE3whI2CYwYTtXjYPOjfSAHoszPtyp7kTYtnYizjhO2MZpuy1hG2cso8iNV41T lpGgqCwI+y7NCMK2dd0ybNt0nIqWtMrYJiBhm8CE7Vy1X7lWMaCIvw5UNcd2XZUYhfUUsIgdePLN 9t377AvuhuZZWCI30gOqxoT9gKe6G2Fb8qF1dBygWhA2/ZAMW14+Z1pbSw7CjVc7m5hK17Ly0LS+ ZTOSsC3tfBNI7lFXvkTWL3cCCNsJJGxT1X7lyFHbAZ5HlcMghRgzDRNjpmZiLAGE7QQStqlqN2jD InHUASDshzvV3QjbaC6xJwjbqI3yKYmtdMsocuNVo+LVkZkERWUpse/QjCRsY4UYM74YnmFJmRhL AGE7gYRtw2zN3EgPWCHGdOM5tjUF3mIj2pcoHAGEbe15FC5X7Qataw40IwHHBzzV3dzXrrWMsI1z MuBIP6SoCC+fi8sYVxv4ahdQodK1rDyMy9yyGenl89L15XWJwhnPXV9eur68dH157vqiRnpAuL7C IHkekHG2ROGCyVTygAggn66jNMV+aFS1GzQ10gNuJOXpAU91N8K2DXdfTxC2MVptS9jGGMUocuPV UKgYCYrKUmLfoRlJ2K7ieUDBOi+ur3hgomA7AYTtBBK2qWqPQsWBiucBGStcX8Yy15exzPVFAGHb CtdXrtoN2hoOjHn5HvBUI0q/Cd2YOuapUPRJtzaD6wRqm82jWDmDZwf/tbjYIY+8Wfhl3Zr4QcuU SW6dpkMxjY0fh42B0nRRxRcXR8eBNk3Mdn/nKB480I06/PMjtQyUWoefjuulsoGDD3981C6rsMSK 1Xs3PjVaucOfhGbc0oVVP/zpkW71svV1zo3/7U5p8OPDjyhVng//syMVqtfxzOVxGElbB2s0purn 52v2/Jw9X9GL/8J+lCcZqq7XeAphofrnoLNd7QJueufV6vzgg48O3v/oV4sXVzdPDt7/r4XSB+// +6I9eP+DT36xUAcf/dvi//4Y/4R/vv1B9cdv/xieDz78aPFb0aYPum9PbarcptX7afPAeh+zr6oc OQ3oIHCdQG2JD7vKGSTavTPiY853wxH/c4G28vwJe+Z1fk34ljj+7R4GR0xlTbzpKB02AWT5kj0/ Y88r9vykDLP8+II9n7HnE1EHvHguWsYvXtOLN4I78IvXiFnqiJpHHx88+hmb+MnI+E9G8HZCL3Lm fcye359j5MXIi09GRpKXejVS4XqXobLViETSr0bu4uXIeC5Gul72Lzp/+D9HfaPdCgfon3u6TSrF ta5iKoXApFJc02imUgrYs+V+VEkQBMa/UV2yHx3Cxp1552wETRm5G0tyHFR+bQL1HyvTof3xG1iF jenREPJdzlPEKWin1p7TTgKJdrxrOO1kcI+045tqaZvvH+3wcf8aSXrOyq/m5NbXQuS8RYRGxBIz y5wvcfjucFJlmP4P27icAB8rZ3BbYtlm0b1ftkm9rmntuBp9OqIlOTIgdzwdkfMrgTnw4guBTozm 9ZjdsRebI56FIyl2Tj3x7rkivBHDAorwGooJaxouJmw+p9eBzGcWK2dwn2IiWJOE+e+VmGDjXiHk bEdL6cX1CJVejhhXF0gwrYWsKc/vIWVRhE5v4T2+C+eNqdAgzwKKk710v6rzvTnbm6/kuUABWOqr Eby8EByZXhyztyEuSP5f33nvO04CGLkn6MX3xzFbLOH7xeyCxr3dvoCrgPTii9Gl7J+b/ns1bDU3 xT7CIBTZUl/hbi9e26YHTU5sE8foZGx3C7fCz0UjYB85uysd21E9Q/KSP0sZCVD9RKARjjMP8wy9 dDLSs9zGAzycjMxVSgTAgt+NMD3E/LmoDDS+rcm93ql4AtcEKsc0fgH3qPGdL7dFf580Ph/3FSKN 8xEegIgat0XHTAigTZ6PECORSRRc/S0mo1uOYPDR92TvV4xDobASXIVl093dcdDxJZjGOME0xgmm 0Y1gmgzuk2kCDdbfR6Zh4z5HGB6Toc8YCR8jFw6n/UuEwFGSb5p8B+f9kvyjedcUpuK8kpcjKzlG 8ifI5Bm3Q2Z0iXEV3z0SmNjCWMt3jwXcI1tYZb+XuoSPe8SpN2ZaAGto3JeNLQe4pRmzGaGVNMpb YVes7dvAW7+hOZ5usRO4EPPdIUizsx/ZvhWLc4Mo5wli97d9LsG8efS7t2KUI1HlmJWm2oWu+wTb LaO1f/i/P/zvH37/hx9c/v6P/zuMKoc2K28W2qcrLu7Q5t4CpPGajhS9/QCZqmM7s8eCy6Yj9DFZ rrsqT9058r2PdAUTUM/n/SGbyrcj1gnXtXATAW3RTfrWbSBAr98eLly8LVx4h1EGBlX6/mVFtdDV 3TM79kDfuopY07Ym+v6c6PWTEb5+urNm9MtKtfVbQyGfH35Jc/yfI2bz/T8v3ZukZW5kc3RyZWFt CmVuZG9iagoyOCAwIG9iago5MDk5CmVuZG9iagozMSAwIG9iago8PC9MZW5ndGggMzIgMCBSL0Zp bHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzdXd1yJbdxtpzYUmiX7VTlKlVJnchxinSZRwNg gJlJUqmSZdmWy45/tClfSL7gktzlWodciuRqV3mJvI2v/A5+IVU5wOCve+bDzBzy7K5ErbSaPoP/ /rrRaDQwn66qtZCryv2JD8fne9XqZ/a/x3uf7rVr5f7pX9Dn4/PVjx/svfO7ZiVsxnr14NFete66 TnWmfy9WSq3NqmnU6sH53kf7Hxw0606aRuxfHByqdSfqRu/f5MfT/Hjlkyodk2oh4nv3eOPfG7F/ mH/8SX7M+Y/yj49ofl9Va/ZXB4ey6rp1q/dP+lxN1dr8/r3qYgHu8VGq9Sb/eJgfn+TH01TUDc2f aj1EVT3Njxv6OOir+/GM5opFndP6F1f1LD/epKSkKxf58TFqyhXq9af5x2s61vG9G3VdyXVt9j88 +MODX+wpbdZdoy1sHpxYrJzm/JeofeQ96fVD9P6K8Tr+KlPSKv9IHtvU1VXfvvcf7P12TwqzMrWs 16ZZ6VWrV1ene4/uJCFarNt61RhpK3NSYmt78EdfmbDiWFV1VQkj6ePvflZ8dbUDcZVSrdt20Ban CFznRVu3ofO17/xLbYqwfxeb0hjF+fBSm1K5v3s19uOkxiKymqRm3CNRbidJDXGFIyopxFrtv59A +ALi/QkS3VMqWlmeTFVlnLa24abpx8eOgFwpP0K70OlStmtZ0wH5FVSWV6ltx1Rt0Wa+eoRL3a4b mRtPcCWFNmnQdLXTITM1q/WjfUEVUXr80esendaqIYNHR+k2j47Y6ei03bpq6ehIqJGrBKjuNY+T snqpZiJgZdomaG1L9z9KzfwNlIvHaLociK+xZliSX9HVuxzu2k60TATMa5xxajvxtWQk9/+QGqNa 3QB5vFttLa8NzCqm6fgE58b87jO86CxkRhrH1qdtvr4+YTpf4Ucrp17Rv3+wBZ5YVjyf4pR9qq2R YhpX7LkdRtEmcrP3If/Bva/4+wlOh7Q6Zm3ahmQNbxtO6kA++qHtmO/AXYo561v4eM9OpM4Ua1tf hid11Y9l3eqe6DxR60Qc29GRmdxYUqictB+5WIgfRl/BcRhV5U2OTSS19EldIaoOhKsgEDZfX30g bb6+aTFp3+hYiCd8BcduuNRaNabn9S/sf3+89112rF2u4Cwo1k1nVw1J5Goto5y3tdPPTSODzL3x 9b/5229885tvvvV3Tvje+Z2oaG6rt2sp4srjjYNDvTbSaGv5//O//NM3rbVmdZRuBX3zxoH9saqb /Tfffut7TqHbMVSKpvj44ltv9QuHw1D8oTWbWl/Ftz+++s53v2FXQML+VJlc2vdtZdZUqNv807/+ wzecvbhWtelo+f9sfzb2udGaNyw99k2zxVVSiUHL8opmF8rGLp8lUTZRhSZlE3/olY1m7yeVTW/k VwJmVU2n09sNTzxQNrcvhikba7ErInlSSJ0kzy5U6iR5kQiSF8kgeSlpP3KxEE8IRSRPVloQyZN2 aJLk2RmsSpIXiSB5kQySl5L2jY6FeMJXwJTNfe+qY+kSzPcNEV1bUWDrTnNghx/sOCnBXk/guq5t UiMMyuj0RHy3YSkZpm9bBMdzFWUikJ4lYSSlykwORGRyICOTY1LPOUGJShAmWwuoI0wW1vBNTBad aBOTIxGYHMnA5JTUNToV4gnVFfB8f7u6FZ6lVgzPZUUtZWWWKmopmYYdZJWioyqVJWagvksxHNha M25rQ7itG8LtQERuBzJyOyb1I2cooSm3Zd1VhNuybtqsveysnbVXIKL2CmTUXjFp3+hYiCe6qgDs +9vV7YBdi3YhsOuqWwzsWnQUkTyrVF1LEUkTc2DfoRgO7Fp1lNu1500c0ipzOxCR24GM3I5J/ciF QjyhOsptFRdhgTQmc9v56xO3AxG5HcjI7Zi0b3QsxBO+AgDs+9vV7YDdVGYZsEVXyaXAthOLJIgc ZBVtJwgEWWIG7LsUw4HdyIZyu1Fd5nZTt5nbgYjcDmTkdkzqR051hJAN5bapmL2pO2Jv6pbYm4GI 3A5k5HZM6nVvRwgT7YERsO9vV5cCu1rrVVw5ii6tDLfU266UqKIHqbIy7XVrVrU0MVDRtyuGI9ma LZS9UsnMXpsxszcQkb2BjOyNSftBioV4QlaUvYK5Z6SIKq5ffhH3TCQiewVzz6SkfrkXlW1PAI/U fe/qzj1RVkjcnlm/VfDGx1dvfuutg3otrLFj9r99cNisawv2dv87X3/rzYND0a3rrlbsxXe/8b2/ f/Ot7bw2VMzUrWcRL2ZeeQ9SZdXea/qs+GliMGHcrhguZkpSL6hUVIuqOntBIxGxF8iIvZjUDxLV oqGCiD07D1PsuW3EhD0ZC/HgZnavTPUFsSB2byzEE03JxL+/Xd29mNllTNXuRMzmo5qcGqnjfmWM CFjnvf/Va96kDJElpJk/z417mgITzmF81SpFv7ybf3w2ir9SOgYSuR9JUUfDpIOYIhJ+dEFjgmKM xLs0HCK+J4ERGxojkR6PU1Ky33qDwilY/SScgrKsVnJlhOn9asLN+TvYgbRzmguxy1wBW5Cmantt TbYEd7MH2djKlbktFngs3fZYyPFb2qjFWOB75wuxIDu9AyyApuAoHN8qixD03oL5GkWlXQxHpdzr FWrVJWzKMRK2IzpWoKprWlQfi2dxpKsm7og9ngowZFy7gY3OAYqP6HsW8dDjvpIe93HrfQeQF1be AuRJXNbpMC7L4fR5fswicZV//IRKR3x/QuUkcfxkmNR1/rMZnXUKOZJDJp/D/GTIzxBznyCcXUM+ PUvvL2D+T7N0PUuQP4VFQcjfoF4R6XsEi7pCRX2KWv2EZgJBNiX0AsiPhqqxqFnT9g3Rq22agN6Z cMSXPuVbMYpWEFHzTxJmr6nunsb8k/x4jKaBzejRjc7nSc3/aAYdJPaYRQnOTQMJiHlGeFkmwQCz DvPP4PsMtBPY6+ezQO0fBY1DX8FGweByoh6ywiXFf0IbDSAPRfJq2P3B1PMUdQ/EXvOR2KCRgP1b jSwy3Xr/lrLcz2Fx3nLSrVJ8BnmpgmY6ESKlP0roLdlT5PEZOtswJ2g3o6SZ0U7QLuBAf7yPghF/ mR/fS+8/Psi/jqXWidpDJLVQp+OZCiryDeX6QEE4UQMzFbOo8JGJZ0hA5kxOXNUZUiCf0VYDWWWn E4CsnSIBhYGhRJX8BxrqI9j/De3qNFdy/x/T8kdi19S9aClVm5HYNelQwMuNxA9i19r/eakjJ4Ze JKkhosRmOvCeCODj9H6Vf3xIpXYwZzipI+N8Mnw/sKPI6MKlxc0InU7mMqMfQnStkExe0lqnTzSd DDHnZC7+yA/MnM/MD3OCcIQGgABxZD+49+sxEI33JUml5C5W5EoJd8YkgQosyLWOMcE7XpAbI9Za eig/QBMIgSI5vHaU3h/DCWSDoH5D8xPURShjOz7bwWcz+MNL49GS4S52OtDpeCFzkqD8BCY9RlJz PYPPsX0oqHxiSya//xB26hh1ilUKZg8/EqqRtM/koMSPZvTLGWo0G8kgdIexYheAKn3lMR1bRRMc MkMFOIaIys2OpQ3NNNTeHKeY40eoy4/okINZcDw6DqdZ+VxClsAVxQaxvLRMGCR1OD2mXQE4nPMN TK6iLU7PUMpzND54xQUNKlYUwOnRLLjBPInBV7WxyIS+y4SeS6r6APoIOkd+6YGWHAM180G3HXcB pFnyvxGfniM+jRexg0e4NGLouMWYzskM1t1ztsecmTNSyIMBgkY0s1zJAIH8bJW9FH6j/nddQ388 Q/17DN+vUPuOINfAghbpVnaItOxh5Og9K+jO/r1hmYg5TPz783MQFFPA3KcQJ1BhXUA+Q084VFNH WWHjVt0k3foUvodHxVeoqheQ+1A5shkLAOmz8QBZ9bEe9dr++Cs6QADd1zPo3kbjL9S42XHB3Ibp 8XzWcTFnDwxk0833L0tNEvhMOABU4c4BgjnorMOzZJ7v51ZzRCM/o7UC8Rkbnna+f4wadU0bNW1s 55Z8UqgJQBKOBLNMFmnBLVxpeSVEYEQU5jvpPfFpE9VHRuQyIW5uPxDri0vEu6cjRDjE5cE/hkk9 uLVoCubGg9lFGRGJaS2QF/VHsNeQpSQ/yfU5Sso6uBRyxIJlYwkgdz6Dc7j7xvzTc8b8lG6MCqnR ZM1NdB8xPPNaiVyHsj54jfEhXR8yY9zRz5Ljo+4qtWPHRx8744JJp0JnRH78EgXUGOUuRyBt/yW0 vLIjkVhmcBZk3sfRLNhHwYCl6O5nQT61kPo/mHn/Lq11i6ooH7Ud/7r1Z6mElmInUTa1WddtZhWC dqPqAbRfqtNam/5urR4371JMM+dmbeq+VaLa6Q0bAbmkCWSdTPRVNuAuR3gsGnifw6Rz5nW2qoh9 c4XwVlrxgYnlIs+xbAvrFosObARskgH3eZaC1evU4uFCG8rbPPS4kf1FNwlpereXAzVmCDXomiPO ERidtIGczjZYKRYGGFZ4xb58MxMbBnAH8nXPULUwbkOag2FgoA1uNFN1U78sMNRKu3ZwMBQGq9fJ Rle7DgDTdbfuQuXR7mQLi8/gwiBrOvIjma+z+2XSvZI12cB1zbbQIpLWrxk+wo6V2+4iQ0YkZotV x/MZ4ZmLQoSRMkQ450KFzulAx/dk8niGmoK7wtY6Q73Kkz5BJhBci5ChwDFvc7PnWKdaFX9JOwh8 Gmc56SGZsmSt3J1QveRJ2crh7r59p1/h7r5WnfsfU14l3xOMXgMOpRQxUhbo62FRg5U8HHy2UJ6e OrCT8ghNWDeIjzh6zTe11bLY1MHc6EyXuU3BuYhOUujcSh6vBc5RVethfueYf0DbR4qa9IdiM+MJ kj64bYf30m5oV6cd4gXpHUYy1BbXpZCa2i6JXmEkm5ZdOiVCLuQ9Q0JDJjwYqcZmQTBLkjDrs+GY liPZsiSw6BYwi+LoFnIyoBDxBNj7YpSfSwKG9+i+3IHQPUS9woEwJ+j9eLdN6NCoQUwA3ErG0Tkv UE1sOwPI3PwO4LS9frWse7yomZiFLF6qEz5QtB4Fitp35lXOaaJb6/EphDxnkYmMSEre4cbe60sk fuOkGUhOvHB8xPI5Dy+XyH7KyKVsK10acM19op6L/ugqPYC1m1ts+4NYmTP7/F7GWspmoX/oZcfz 113X3xzn0PPrjJ6LGeWclS9e4lzMoG9k+Tr0YMsXhsSw6JdFRrZDDzSuWK2gKmY8AaBOGU+DY1tw s3pqN68cH5Gjb+bMPLhBPLLddhz+sDy07xo2anovOQuwUD5e36YcqWFRv8p4/dpfNDy0crJDHp9/ HMeg1pXu2y212oW7upVrSRqHvNWVHkRY7yYAtW46Pxz/k4cjr5S2CJQmKmTOaBwFSju9giOQ4KbC 3Eps7HLge67EqIB6ZU7YZxd1OZAaH26AvWIbnaBX4w0eFn2K4weviFymHz8ZtnTg0WCe80m9gsOm niINDN0g2N3+nI4v0HvMQBm6EFXX1Lt2Ifa3Ro88iDn0AG+AwCBtuA34Gc00TMrXRrdbur+Nlr7j yHwnJp/NWuRLmY9dA28PJcqJCbFDYbDL3KSJ92ry9JvjTnBoBgwiOEItwWunzfQRH9z8q5nmP0H5 7y5xU+EMUTOw0G6C7h9RoIM5k0R1PUSTCNl0HNkZg1CvUe/ctsUFHH0Y7Y5PHR+nonBgzU8RT+AR yBvY1C2sp09mZLZwZj49ssPkoCpm/QLxh35rIrOXdAAm4c3OTSyWTsi1+d2CibCxmINZdCSugkVj xPfEWcU2cuJ7komge7R/4NCLN6eX73OXYuaSbn40M2RwH3srD+8AMk4378rD26/skcy9i4qCZ4Xn zpKR/HM2DNyqgc7uM8iVZ0ikGADucoiB2M3ZiiB+HRgG/hS+PxvytBxSO+fVnl9PJqTefS9hGskj pNGLKIZIiyr/XdgUeGod7BCw76gRE5qFlABvJzwLxpQryQ+Q+hAh7XTY/8FQweO9k8oztpgpT+x1 zJGO40BarjzHOCR6NDe+fPpw3usIZq6xs8dBct5aBIbvnDNoaup3kCTW7iVqNfkRBspeFZraPwpN 5IQYCfDUG7ZB88Lg3+H4/3J6/YfNBbjTABelpcgwoGbxSBRu3JjSvZH7zIFKgMpOJkw7MrJuxg7U oyEk9NATPjFfDicxoDCBGrZaCi7P2eFvAOQ5wxUfoblGugneCDJnkEz3ShViK+B7fIjjGDWVGRQA 6VcoE/QZ4aud4DFi4itmTYErkwmNHc8Tb3WBG/nxRX6cuxloNJ04IOO907ufM00a+2amqFueLkXK Pe8EbEZN8ZgEjFx6h0guKm3TlpUflF6ivKE1zI42TOIYBzZl4XkBGzW3FkVBfVD5xvmQeZnJTYLk ug2ofJmeBUs8YrCMjPWB4Quj5PHxvbdnhu80Y/YaFcW+/QfZ/5q/+iiM2wpVXZNuM4Ib++zIJwDP 7Xz4MHADxwCUtplE68Llpf8IVSt2GjofPvVIBwcGFWGrcC70fC4UjC00gDokTYGa4WRmHLe6z3Hk a5ddu2tfu2qbcByJRf9ldyS5BoWYaldIW0CHDo7+g3tSc4EoeAP6kxmWP8/aYp5l0++hqTYXiDS3 J8VcK2AGnNSB4pYqcKtd90lvJGbKKEq4afT47qOyJQeP8kdLbXi6wkqGkMMLg3YgGqaJB8/IXUHL Q/TwmevsQBpPnsRnnzXMYLUOveOPIOeukNoZG0zc9istsV/zlFn130gnLHkMhwTuzFzyxpuuW6nK X8gu9U4/9StV7S58Js28VRjzCeQBvGoYJ52LzYUXEk0G+VuZw+oV3jRCjtxCnTm3lzbj5M1yX9U1 D9PYgdjrZq3CaQzyvXl49xJRAXB7mamI13zWpKp6u4r07oi2Lj2yJS3g3WjXwr1nxg7taKuskHXa f5ZSN7sUNqG1C9OjPaIXezCgyLbRO5wg+kPVSjXraupUtcyPX7pT1bTx78OJ6hRNVGTt9/nQm+ek /T04p8HlOrwUYC4cb/J6uKxEnV9n6f0KttW/zu/zrRIlx+HAcHVJ/7dgDQLpILW+j+YDPNNnGw7E g/bDPu1sh/c/Y28yHWtg+E0eK5dN20uZNG2zk6siW2Pn0QzV/XGgngzfa3tVx8qVXbs3IbI8ntZf 4NrO6yV2Uz14j2P82GbjtL3/GZqQ4WmLhbBzp50C7IYXjA8XARaK8LQB9q1Bh974CMkyDQDe4/Uk DISA6w32xQjQq9INJkBs4AbtnIYbLSedWsMXvEMXCTYz4a7pOIxYho8Yo8NS0kj5CsOI3YmEeJqD 3IaZV2LEkBl9CKIcdDL6JoWDLzHu1kjmtriK5yHC1BaSMBesio/VTV2K7y8VH7S6fEIRxinBaZto IoxPeJfxVrGFZQtCaHw7FrwxgJ08AEwJSZ27gqqvkXRo/9082dXVSDq0Wvhhip1Ih+z6u1fK6xUc MJj9ECzUoGzeuR/J0oZ97ib6KeZCIvAO6BXSWOOAQn4991zA4DEsCl54MY6Tsl15D2ls+A0hfNH3 ZoyZuu5xIeyw7tTp0Epn0VMc4LDV0yHLymbugkvqX/3KxRmCLesnvE0Nm8gwKBNe0EcyzalwvJyZ iwt8WlAsshU6ocR9jHGoWGr9Kk/vSGt9x2NwJIIOKEPlv+P5Ui5Roq3A8VEnSVORnU14E1zpZtdB 0sGMB0P2sNDPBZ/CsI+TrN5YriUW4QBk+PxK3os4g3i80/UBY2e8lO3wpq8dgNGYrV3xOdaTzHvP ETBwrCfb6J72vd7KQGSnwQnc4qILL8qezExM8PtmK1r+AM6DA5kwooN0de5TaXjC8QPorpgonUid ntih+mWrnuK9/aT9zqw7RDKEh3Je3EHSxZFx5DLLHFDE4DmA38AYG18+zd9f0vwDng7i59lXwcCY QKTjHXh2TzTgGQzXwirsdKYpo+P2Dskg6F3Ru5SIdcA+NwDsxvH6XtA9ZHw0G+6kzXWaKQ0AZKg+ RqHm7v3tQs0ZFADmF1uGKHCOXMCw/JxIKZQZTPVEeRPdtB4tSsYzlejqofNwyYe+Jyzf/hPOupE1 +fp3vGUtff07/nDu7+IkryfsOe1ujTKNRBm1zO82LCX7Gvhti2BfAtdNbcjnsXWjm/R5bN2YJn0e OxLh89iRDJ/HTkn9gGlK+ArC57G18dbEJpKNTJ/H1sYbnr4CE78m76s36ev1fdNi0r7RsRBP+ArG XwK/x111LF0C9dAQf1vsPJ6lsqK/ENBSiYbAcZBVyq4hEGSJGajvUgwHtlE15bbxvAlDqnXmdiAi twMZuR2T+pELhXhC1ZTbOjYjkEZkbmstMrcDEbkdyMjtmLRvdCzEE74CAOz729XtgK3ajgA7nmVP wI4/2HFSgr2ewHVdu6SdQRlrmd9tWEqG6dsWwfFci4oyuZYyM7lWIjM5EJHJgYxMjkn7AYuFeMJX EJksufaSjcpMllR7Sa69JNdekmqvWIgnior6/nZ1KzybqtYEz/H73gnP8QePKfp6Bs+mkjXK6MAY 321YyhGeb1MEw7OpDJ2NTdXk2dhUbZ6NIxGYHMnA5JTUD1hDCcNm466uKJPtmjwzuRNdZnIgIpMD GZkck/Z8jYV4oq4wnu9xV7fTz62h+tmW3zI8xx/O9zrFX0/guXMX1XeqQxltm9O7DUvJ8HzbIrh+ bjumtLqKKC271MxKKxBRaQUyKq2Y1HOuIkorVBCZ3MqWMrkVTWZyWzWZyYGITA5kZHJM6vsgKOEr APr5/nZ1Kzxb25Qa0rKK08+H/IfzPVF1FXs/AWjh/O6y0hJmFVVbpbcbnpiB+i7FMGCrqqPWpRJV ti6VENm6jETgdiQDt1PSfuRiIX4YO2pdyqZpCLdlY3Titmy0SdyOROB2JAO3U1LX6FSIJ5oGA/se d3U7RV35Le9oSEsxMKTDD/a9bAR7PwFsJVuXVmmYVUlTpbcbnpgB+y7FcI1d6Y6qsaqpshqz8pHV WCCiGgtkVGMxqR+5hhK6I9yus5nvSW8U9oXUXaMTtyMRuB3JwO2U1DU6FeKJzhQ09v3t6nbA1pUg wJ5wfSjjWrfM9aGMMsRnMciqjNDEScESc2DfoRgObC0l5bZWKnNb1ypzOxCR24GM3I5J/cgpSkhJ 5+faMHuzrom9WStibwYizs+1YvZmTOoXfTWxN0MFANj3t6tbAbtuk0buLY/OcGDHH6whIDvF3k+Z IqpyaVsJswrZ5rcbnpibIncohgG7bqPWDyRxdLm/ErcjEbgdycDtlNSPXE0JpQm366bqCLdr02XD szZtm9VYIKIaC2RUYzFp3+hYSE+ECsbAvsdd3U5jS+asnjBFer/aMkukd7MlC4Jn7B1yyWCgKcc+ vVsUwRW15I5bSR23kjpuJXfcSu64ldRxK6njVnLHrTX7qfaqCJN18i74eZ8tpLIjIlgMZO1UESbH CoCivr9d3W7NKGvqA5HKdFxRq+gj6U9gkNczm4lSxUU5z+h2AuO7DUs52ky8TRF8qSgb6hhwxndi spJddgxEIq6fAhnXTzGpH7CWEg11DChRa8JkJVR23Coh68TkSAQmRzIwOSX1iz6lCFFrjOd73NXt DI9OUh+1qmIzP+Q/2Gm/c19HI++nDI/OuLTRbTrIKro6v93wxNzwuEMx3PDo2NZx3ek2z8Yd2TqO RJyNO7Z1nJL6kQuFeIJtHddtS7ldt2RHwrYg70hEIs7GLduRSEm9CdFQoi0A+x53dTtgG9VSRR2C dbOiDj+4PWrN30/ukhuXttEwq53C8tsNTzzYJb99MRzYhjkG7IIyqzFry2XHQCQitw1zDKSkfuQa QQjmGFBK0vWTUlWX1Zjs8vopElGNBTKqsZi011yxEE/IwlLxHnfVsfRTW41q3L5QnJdkVydyE8m0 T+cTV2mZ9fvVxRZh3u3KrJtOuWNcIcK3tro1fLay7b+M3UiRjlZ+fHFwaGtSLtTrzQMXU2anuv1v HYi1EqKxPx02azv/KLX/zYNuXSlr9ZN0b7mnVgq9/3e2GL3WSov9bx+4C4uslkkhYL/dKky93H4t tPuMI23/fx4c2hZ0jV1m73+fPP/XgTs/2miz/3Py61PyfO5TGBfdmH4k8XXVunHieeiv7fH3Q4Yc z0iOm2Lx+TllpImfFDJesOaEjEfkx8vC84YVHjIes2bgZvOWhIy0GdfhuRXd/p/6yL4BzvxVUg9+ uffghy8fUgOMREZV8b7X0AHaqyvyfFoYstOY8Rr0nGGjx3SQat1oKtWRDFKtTUulOpNeqncizaZV 7iqUVynNO5Fi2u6E858WhOKK8QHgHMF1iPMjJmVAQE4LtRwhFAyYkxVGEIaTV8CPaVF4OKnhGIq1 NBTFgYwornVLUZzIXaJY58NmXykUk3Y/iuN9VUDx+VcTRw/QvHfFhAlPJknIHhcEiw7OI/YcMq4K onxWlNqJ+fsslkqrfVZQHLHUtj+1HTI+X9AEOH9vCompZvlsTq89Jk36sk/DR6gDJwUYXDBIJNZP sPIRYiWF5PPCIF/FjCdFzI4HvKw3K6Oo3qzSyteRdddpojczuUu9Wdnf5VdQb5J2b5DJ9rggajdL pWSxknU/vX4l+3hu8qCKipr91wiYdRuD5jwS27TJ2ZNNIygwE7lDYOqmTvdefZWASdv9Nlq3zU2C TjsfIvX0qPD89njC0GXFBtViuoV6l+29KLYRqFM6qX1aqP2UoRY0FUPZMB1bG65jNdex+iXoWGsO fyV1LG33+0hVnhagQVXo54vm4+M5ACHTigGIWj+3dlSUFm3cCBl2yHfDW02p2MsFbThnv4eM/7u1 YQFEaBmXQsbPkXpwndmKK89Yx7YYBV541F/eQG362dUP7W+QM+uqUME1GqGSNi2vEuACGFuJXOEC u/0EDXOve33/niEH0lYIOCpkLHk/ZvlbMnJvkMVVKmTBii4NRub2OerU54WOQD/cTSHxNeMwFXhg 2p8WMq4YL8AwrgrDSNM8xzoIqJWtlkN89gZmYUnlcfkIGZcJChh/mvhd8vxeSd2cIHHjq1qK3Zkq l621QcZla20gALOrCNdJ6EQ4L1S5RlL+bmFEIoe9x+HLK+VbS/c1atOSSYAWkpyZpVrKkzRAZUmj wkkA6jeIoKNCseesirtuBpVsqdLM/hTpkGWiNq3fknpLXC375bbQoEsYBRcey5Y9YBRXhQGY3S9c 44HJMHnwykdmK9HkmnrGEJ2e2Y4LjHjCqgDT9c2CkdnKqiubUUOBXmQkvyr1Oj9nHuUOlCZSPA1u YM8vETZLHeCDHTI+LCR4VCgQSi03xXCBN3NKc3bupkJ5qzk8e90p/H+GevS00JgrxEu6xDor9O4Y ZdwUxvCINJhvfAPFADe4d7OaKQHzgvEVgIO2r9RJOE0t8RvwZiOx2EqB7tpWBw4wJWM0We/xiuQm kukorU8cyR06wNz18F/FEAPa7udzEzFilBOhC6QsSlYqR+AQXZGrpnPHI0w6RuKCXwO5iWQVvZw+ cSSXcnVydIxy8VN0dMpGDxAz3p+78ipirGnT3eOLV8uOP3wDdwvTAO7oqaqjGyeRjMJWKbpxksld CpsFgvwKbpzQdm9l9fKtWjDrlGbFaVWO3NRQtR8vqmoCWA6FC7zN8xYl7/SMT6Q0i0PzGO4gkQXc VnPeH9GcVwq6Kknf9Vz/kC3b9p/5m8lY2jn7JPmmVyPfNJwdnoAWFExhze24pwv6dIX6UUID9AeV hKsULLoeDUC2Y7eSWM4aALfSWvCKdRXYiaWFDQzhWOIU5jvoS736rzOuJnx1x/1xt4uvhH82q1qJ biVNOJZ/vvfjD/be+eBXq5urZ6d77/x+JeTeOz9fdXvv/Pg3763E3gc/Wf31i7/++a9//suf/+/P X7v8vy/+8sVfv9h7/4PVb1mZlVHuCyTirmXuLDjdBdV3r8jWnIrI2O8/gfRlD86baaXq3PePX0kr p2DrLrQx20DM/rH/vPha9cWLL7aE2KSlIvtP88k6fTXyo6gSflNQNiWHRDmyyKwr0TVfGoR8tP+H 2Mc/5Ut50zEjaRS9pkGaOp69cbomXn+gq0Qc2xWJu+gmkG6BokxOamSbC/GEitc09KRO9494Mpzi 7QvR4QBPX4FOZ3366nU669M3LSbtG63JUeBYQX/MSMQjRve4m+6I0TLRsHI4IRu6c193dNdK+8+B 7//gBz9449/+8Xsf76dvwWXUtFVLh7MVJg9nGw+yuv606cxr39s2nXntRyIm7ccoFuKJqqXD2aR7 TT0ZjhT2hcQ7lkzNr2Ny1dPrmLrRdUyKEOQK1/vexR0jxn8TNMDlTQKX3+79PwGlobBlbmRzdHJl YW0KZW5kb2JqCjMyIDAgb2JqCjkyMDAKZW5kb2JqCjM1IDAgb2JqCjw8L0xlbmd0aCAzNiAwIFIv RmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nN1dWZMct5G2bPPw2OEjwm+O9fau92HGwWkW rjoiNjZCsrReOiyvTTJCD6QehnORUs9wOAeP/RP+N37Sf/AfUoQWKCCBRNVXVd0zzUMjilJlA4Ur v0wkEgnUi1kxF3JWuD/0sHu0Ucz+aP8ebrzYqOfK/dMm8Ofdo9knDzfu3q9mwr6oZw8PNop50zSq Kdt0MVNqXs6qSs0eHm082ry3Vc0bWVZi83hrW80boSuzeZ4e99Pjqc+qDGU1QlC6ezz36aXY3E4/ fpoe0/s76ccD/r6vqi43Z1vbsmiaeW0299q3qqK27/t01VAB7vEg1nqeftxOj8/S434s6py/H2vd RlU9T48L/tjpq/vxKX+Lijri9S9d1UV6PI9ZWVeO0+Mhasop6vWL9OMZH2tKd6NuCjnX5eaDrS8f /mlDmXLeVMbC5uGexcp+ev8EtY+ls14/QemnGa/pVxmzFulH9ljHrs7a9n32cONvG1KUs1JLPS+r mZnVZna6v3FwJQkxYl7rWVVKW5mTElvbw698ZcKKY1HoohCl5I/3/ziYdLoGcZVSzeu60xanCFzn Ra3r0HntO/9WmyLsfwebUpUq58NbbUrh/tuqsU+iGiNkVVHNuEem3PaiGsoVjiikEHO1+VkE4WuI 92dIdPe5aCV5Kosi4bS2DS+rdnzsCMiZ8iO0Dp0uZT2Xmg/I51BZnsa27XK1xZv57hEuTT2vZGo8 w5UUpoyDZoq1Dlmps1ofbQquiOLjnfc9OrVVQyUeHWXqNDpiraNTN/Oi5qMjoUYuIqCa9zxOyuol nYmAlWmbobYt3XwUm/lXKBeHaLrsiG9pzbAov6LR6xxubSfaTASq9zjjaDvx1WwkN7+MjVG1qYA8 Xq22Oq8NzCpl1eQTnBvzq8/worGQ6WkcW5+x77X1ibLxFT6aOfWK/v3SFrhnWfFqjFP2SVsjpaxc sUd2GEUdycXGg/wHl17k6SOcDnkNvVrVFXs1pFY5aQJ58HvbMd+BqxTztG3h4YadSJ0pVte+DE+a oh1LXZuWaDyhTSR27ejIRC4sKVTK2o4cFeKH0VewG0ZVeZNjQaSRPqsrROlAuAoCYd9rqw+kfa9t GmVtG02FeMJXsOuGS81VVba8/pP9+9W177Jj7fIKzoJiXjV21RBFThtJcl5rp5+rSgaZ++iHP/rx jZs3b93+iRO+u/dFwd+2eltLQSuPj7a2zbyUpbGW/2//7V9uWmvN6ihTC57y0Zb9sdDV5q1/v/1L p9DtGCrFczw+/untduGwHYrftmZT7av42ePTn//ihl0BCftTUabSfmcrs6aCrtNP//HrG85enCtd Nrz839qfS/tcGZM3LD62TbPFFVKJTsvSimYZZVPMzSzoFSmahukV0pZRr9APRxtSF02W7kqxOlaL pperKoTPJVXDC80yZyrkKsVkKkRKWTB5sosfGeVJ2hejPBER5InIIE8xaztIVIgnfAW7NICZPFmj U0R5koLJExFBnogM8hSzto2mQjwBVMh17+raVYcsC7fIaW27jx6f3rKyrOdC6qbc/NnWdjXXFuz1 5s9/ePuWFc5mrhutsoRf3Pjlr27dXk3MpuZ0WTRyOdmzc6bJ0kfn9HYt7UWn96qqGsMEK8vcmdMv X0wukEIojlIhTUKpUDqhNBCE0kASSimrh14oxBNCcZQWRnCU2qFJKC1UkVAaCEJpIAmllLVtNBXi CSMGBPL6dtWxdBnMtw0RTV1wYJvG5MAOP9hxUiJLHsG11jZrKUr0opuOKW2R5cwwfdkicjwXJBOB 9CwJIylVYnIgiMmBJCZTVs85wYlCMCbbhUbDmCzs+jIyWTSijkwmIjCZyMDkmNU1OhbiCdUM4Pn6 dnUlPNsJsl5OUfeMpBFAeysmatjOq97kSRYQzwwsp8sVkwNbq4ZzW9PM7LityyJxOxDE7UAStymr HznDbAutGsZtqWhJGMiyTNrL7R5E7RUI0l6BJO1FWdtGUyGe8BUAYF/fri4LbL4GUEW5HLxFU0iw BrACJ3u5IshE3Qj2UpY5Q/JVismRrCRfU0ulmsRepdOamghibyCJvZTVD5LihORraimrgrPXOaUj eyUV4i3vhrNXxvqCzd4kjlIhnqiKASRf366ufw1QKeeX/rDWAFW55Pq7J3sjU4sXjjgndF71kpQE i2cGAnm5YnKBrJrMkKgLtlKthUwoDQShNJCEUsrajhwV4oex4YaEXe1lhrFpmGFsamYYB4JQGkhC KWVtG02FtERZDK0Brm9XV7OZjMrWACM2kyzKpW0mma1KO69K0fBlaJY5t5muUEwObGMybpuSWcim YhZyIIjbgSRuU1Y/ciUnTMZt3WTqV1dM/eqSqd9AELcDSdymrN76qZj6DRUAYF/frq4200zGfjj3 lqYIKRZFQKEDsxS2dMKDoSj9NP34LD0+j+l76cez9MhCYV61We3Y8qiifbSTz36coW3MBXw/7P/L xrAAnlMe5cCyggAkFkH1hgcQ0Y97sNajNqtdwPDN12P+FhV1NtGr172usKqEYTn3YEk7Mf0l3BF+ hsaPpT/xAVIWRqaoaJtiMcGUFBrC4rtO+COo9A2PRWClhs3pbWqD25CQvh0s8OUkQo7hdMHRCYLy WHzfbkxnkX4YsmcRsheQOU8RTnbQ6OD0ZwmypygrqyqF32XgAtw975XficQ7jpAdC79zRd2BPN9F PGVFHUXI7qBGZUACwTu9lnbez8ILRyGbcRIIN/sxax8IdGRZJyFbhP23VzxuizDHgPYUYZYB9ZBj ktKP0o8M3j1MOsxi7u4vrZDOOcvj4zxhFrJvB7GPlf8EB6YgTlxwphNms64ANTvj8IjRcAcx/QD2 +py/NS60L2M6Q+qzJZvSvg9Am4aCwXuBGrXDawLinwky7iplxfPwqB4m1W4xnab+V9xeiI8pOJqZ FocondkTzIqYv+fwKyHqeT2r7IpHDIXxmEa0Dq63HhwabDi74CJXwcPEiKdoILMJbdn0r+GEybCb bLhjiK2dCeXy6URk9U5SLkl5BEzYSlk4+ANkwmUmGpBCHEJ6jGQLxs+ByPehWYrV+ngTDcAD2KzH WzFDjn+t5MzUftdAKiXXEaimlHCBzwlWCOK1ovjntxuK7SFeNiKEhT/avJ8gnpYhRz1csoMarU3X G7VKtz1QxVoDHGubXWbtZWou2ZjPoUidd9VgZzpZcCCB9INuujtBkB3WQJPoGZI+eMRjAWVqhgTl BD4ukHhCmeuvdVJT/bkINMmeoVa9gkUter1qT6uAUbmAVUHTEC/BDhCvTtF8P0M64+lAVwfCd510 VvGgxNpOiZS1/Z9H9KVWXbvQQk0SmnkPusLhLcz3PPFLbQcgDgNSiobCd2M47Xridy3g50aOzPDM vmLq5qx7AKQz+Kco/W7PGEjWoZvhGYRPkLRhfwh0rZz1gO1meLiknZYm0BQsQ72FZsdLM+WmyDQX aCr00sAl/+5ESbP3fdJAVQ7xDHw7aEAYG58PNV7WwsyMrlv5kEatc8pVZe1scd7OJyPsHj7QdIhU PvaKwbOAe4O9d8pB++idZDGtQS/Y/6lOl61eeIOWWGwJldKZ7UGds7PgEVLKTH9nPmEgjNmEC4Z8 hiRsyCXLfp1aywIVw7J6vVEbOaA3svUG6YUhr9m4ikrpTzhkEJBgr6Y8GAe8Ay69aSreqyPeKmBm TK/1AboXiKu7sH+nqH+7cChTU97w+sccaCSclcHmAzQ/2Az3hiMZmCfM/GADeRJnQOzRf4bGjKnG aL44sa7nWpiGbf9rTVZG6cLyZ6UWIQT4vZ7JFWXpghFSa5z9AbAzYJciQO4j3uM1CsQ+nDQXAzAd L+pThOi+2yFfmJCSz1cL91FRZxw948rjDLY6yWHuLGDVxgxbUBO9mjCWvsaMy+wOVdtZS/noemkn 8jR3B7NXyfJd+gKUmBd6uUkvcwsAVcC0xsuYni1PulkTB4fdXYnD2Kt8gRDSvzPAGcNQmthGXtI6 O7CqlefXji+dza93Jtz2ENeZm6F9FHyDIBOL8TnxnJdE6Xgnan98zuvvWlQVb9R/w0adDohH60uS qpUA2eiiJx3hxMo7cgaXVk6bcC6YXWnyGqGbSUdax7PZk60q7yDpYtcKPOVvAZwwkxA6g59OcB/v WRwh9MON2KlNL7ync5wEcS9KB977fzbRK+iOyvaEQavBPSJZUXiugmEKX3GZBOKRZAp7q6dc+K9Q o/G0DIcCStrX/KWe0IXTWErpsid0wlTvckqyyVUQOra9C3dgMvnqeDM7UTbTW2nxES5+oDd0F8Jz H0kS085zVNTDiaJmSXyg47UfpdNbR5DQ4SlraqcZRk9g+UyzF1779wxIYXhNCyQemTcEyFxyij2d aH627QS6j/3SGf974lP4M++qaFRPfIpKvss5y50Ar3sWXYqOYGYYe5wKQkvp/TCezgbmcbTo8EoD quRMUgDQ+saNkwSoKJl27+/v6aZuuSGkY9fVfUfuBoq6ZqMOXNm6KVTHlf1WIeAiesfDEHujUvuz WcKs9YKhqvUzsOYwb0Dyl+9xlIH0vpHUcSzAPbMpy4UB5iVC0QxmhTEu+wmQSQthZ9cKVS2ivh5S 7VOrkXGFlrmIgMLdiar5JSoJBrMNhXCBRmeT3Oju3T6sFDpDDwe61/UfW7w36/Yfm6qN4HEwJ1My i+Bh7mGmV5PTLZMNlhW8n0WtdaxKp3dX2C+GHqDR8MY8cCTUbytl9jNck58jvB3yl8anbewphHsH cFrHG1hwGwIHrcF5C7oHhtz3AOZ9q8ouAKdiUs/QUB9BpmesBO0b3CFrxaRSa78g0ZTt1aR8OnBy cjCh7qe2Z+/H9P9NP/6595gg4eQEb69CdZdtRI6v3tj265T/NnEPryQSerM4RYwumi7w5hDUvFOB pH2ZGYo4XsFjN71hAuQkVfp2gmFGIzKpyGyThNnBDJKLmM7uqKUFX3tlpKtEFu0NQn/eePj7dOli Nluw0pkUpC0WNlscoPRMdLoN9TqEpACNwvvaIlGVc0cb2cSDNFdnPLCIsnHIuiy0tYaVP2jnULBG a1g0lVsq8M5ByxXewov1x9TeJ3RaYD/x1FJqav9ndH9HDbi/cPlTugKG2+EYtj3Uq8zVAAboAA5Q 2hwGE6Xl8tonSmuimuAHYyHhp0gFvEyPyWDc4z/Gx7QM7FuRzPZM6HMqYipi5wkc0YRevBhgkchJ irFHt3egJI9UnoohOEVZs9uyx+UIRkYMXeQ7XhV7a0Afxcc5AvcnfHxGt2bweaBkcNIKKd98nbZi QVETcTtoTmV3K8MDjtnBMUq/AyH7JKa/gek9c9rky5UTPqTji+ozNDoMKHcSpC+l21ew/HuuXSMq cPAtV8hDjAK9vsq98p1ewV5j3y7cT4EXUA9cnn2ZCakXrcTFYxDIFELDVjFJubKdCRgiw3Ym2Go/ SUKm0eNj7/BFx8sKB/qyyhsgeQge446DNPx45/Gim9WtYvDabGoTYvQLCqlWYbB7DCpn1rzstCLo dIa50U2KMY2vKsm7NwuXj8p6Xpl6th0WD3vt9dotXqq0xLAgVOmR/fq+TftSua10XTXZTfMdT26K G8kslvh4iLwEbBOe+VDuo6E+QkgZOzfr9hP/AEEPfVBDXwABPp6PEaixzs1OI3MuGjv6doTr4LoX a9nQ0OVc18QosJuh6vrtBOZrf6N/C4+POXCJ50xRMusgBdhmh5VYVoCZfoRi0j5Opw6dhQY6NVt4 jHuGmMEL/ZJsyjlB6mkqXA9vJLyOOpWpp14wpkM6DvebPh0FWoVnVxjLyzo4dRXC3vi53pewUKh0 IdeGDlyCocBBlke4qu5y0d2puu7tB61rdrIgSs8F8ghlQbmUPhSpB6SLaWQ2Tkl6srDU+DgdPkk4 nPf5kGtM6KzMTm0DSKzgDZyyjXuXk3R61TvP1jlld9mrGMZlHkZwZWYskB74oaUV4iunYurHo/6g QU2jXxkGPxZfxx6Xv9Rh0iGatgWwwXyIZB9uauGVEQvgWf7IwB5syvFEVT13RWdb4Dl/BAYzDEXD EephrLK7c/A0NLW9OLVKgN6OqZXdAokEPG2Kd02gdC57oQ77IF5Sw8yIyXaEl8XxRfrxhKez3hGO p8CVbUTFxzMErt3e6OThN0PgmJrOge4c8yt0QkZX2JzdQ73qR69lOB7a3hs3Fy61vfU1al52Ocx4 oQmc2dw5pmXh0f/+fTfLHSwGJjbT0j10dUxsaEHi7R4YW9mX3VzLPodVTc18Uzsq591Wd8L94dzA z568QnWNnlUXIPRi0ETtRyjlCn0Ga4IOOKhmobNpWfcvC5FJuo85zeC5M7zlOnURxB7nHqFv4IgP XEtAOcPx+E8T/PavrCemDM/OJN45YrnWO8AIffDiryygYFx5Qms5DHXVaiKAPmhirnCb1AxxYh/y b1xlkmGY7Vlc9i6GzmKn4756mH6dmtrgNsxKni4wzazL06WG7h56gyb0qYvL4PbIEayq51Rexpdy Ocv0HIEWgnKflz+u8acs0wzfI4qW+plN82PX5HTMAKaIkxHKVlD4gC/cndjh3AG9h44UbLevcMXF 1THdgXcnJBceJpq6TQOv606jnp06FJ4E7Q3s9JTtAyE7pWjgYqrnSJx0f+YiNWkwkPJlq6mpYMAj lJ6FQwCg4w3jBGRs2UEx7cV7bYt6Lo2Y3rvR6fGD27tRpooXZHwMxzV9JHnJ7Rvm1uuw4C8Ii9lE TfMnu9kNHnfHR5DgTs9DWBRMHzuj5XrFrp5jEgo3DbNZu7u9YzVcG4LrPp+6lu0d/wHjxEuwwyPr yryVHR7lw/taBD1I8IY+6GwtQAzYTj+ytUAS5/9LP2bnbTtTWMeF2ouCY1UNWh1Dke1gCstgCaZA AEuLoKnY4alDqtAqx6saaCDjiWP6uD1oCrSlhsKTwMSUTt3gAz5TrsfXaDZl6Vm8PCjqAAEgm9e7 Ozz0rYZ17vC4myFq3dvhSVZZJhJM/1I68yf2D87mzpsn6bEX/NNx3vTWkcM7OPC6k/6tBu4RXpAw Fa6+koEJpANDEi4/IaQZuhYDHQQrEbgQx0cfYaRAhunR0+hTDk2c7hvlAl/xERt4I+zSZh3JVram zg5jM7Ns3NFzjt5nWXuWfGev8hQxagWXw0EPHvCSXTi8U5ZOZ6E7NqW49Qm2dFKvgHzax3toHuiD Whg8DaxwqRdclGWT02gYIAbqlW7dZpuOSSNmYSQAh/j2G3jmD5+VPkDrZHjKMduJZJM8pT+B4Ji6 /eZSUfts9DH302YN60rPO9BBB3SXj0acZGeRxuIJO+P3Ak0TeMkLo/ieo5GC5tS99CO7aIrHdY+p Rnh4m7kb2SSe9hexETAFyd6NKZ3bSbNF1DhOprZV2DdkoA8Pnu3BESVTdwUHLdp+p2Hc2/YsWi5T l65jfT+1wXKGGj3ljN+D78/7kNx8n9faeeNUViWdfmawhac6dzjsxmF7iGDLNhZ7OzPeNu1ebyCl //pTaZq1HuhS9gfJu77CKcgLpAMvp6R2EGKyjTrwPlbiy29+g3Rr4Z+gqphdNbWSgpPElJ7BLlC4 AYTXf1P7XwPBlr1Fn6z1uhd9Vid5aDE/PlTm0I/fN36ZPyV3j54mJkJ/CY5LWD6YBDtJpjZ84FWP Q/YHMIXGDjR09kt7Hr/hLQG4uFzhAOPUtUPwzOrQihIYKNMn/UH/WKNexPQLmN67yzyzZZI8iKZZ 96lIaYzTua1IsKUjhDybKKbjAMFE9RW3nzo46+wIrLBbeIyY0zckB4PEIU6n9hDxHmpPBXZEYloF ApwO7bK1j8JgH0ZvaT48hfhOuzMy+GLyg3GTfejI8SVG8ivIFBg2NI2PvvCItceIS23iCYsVzl++ 7+2nWlr7iredCS40JvuOTDet7fPOjbsnIA93EUaZgsSLweW9h5cLbGTXau4jGc6uhQRC8HXG3NJq allI47ec5Fo/LeDs5KbMGMlXwhn6RaPLzhbUOj66bVT20W26bDl+m5h+ONoQSussfeyj28ro/qv+ qzELSypeUpY5/+j2FYrJvk1sVFOwD/Ya7b9g3H4V12gh4gd7iQgf7CUyfLA3Zm1Hjgrxw0gf0A2k ih/6bUkp4wd7jaLPWbsKVPzydVu9il++bptGWX0fJCeUwt8mvsZdXe3bxPWsnFeNMuwafCOD4NkW +Ivni3BCaPOjH/7oxzdu3rx1+yfOcXD3vij466qeaylo6vxoa9uqA1kasfmbX//rjZuOtEIpNE+5 9atWo5SC//h460aS6nWIrx0hycSXbnGL4ks/HG2YWmXJI9JrGlewFuhFU6mYtshyZpJ72SIyqdV1 rRiUdd3oCGXdFDpCmYgAZSIDlGNWP2ANJ2rFoKxryb8fb1ucvh+v6yJ9P56IAGUiA5RjVt9owQkp sNRe4646li4Dda8+wi4xTUeVzvFMPxxtVKrMkkfwXGmXtSrQi5XTTCFtkeXM8HzZIvJZqBaSq+Za JibTFw+9bqwV/2w8kaSaKWs7YFSIJ6KK9YNpOJOt3DVJNVcqMZkIUs2BJNVMWdtGUyGeMAN4vsZd XQ3PZV0sh2dv3CwHaG/qRDh2XvV2UYRglhmYV5crJgd2VQjO7Yrm8nZIaS5vh1tKzu1AErcpq2eh 4EQhOLdLVXNul/4Lpb6QUlSJ24EgbgeSuE1Z20ZTIZ7wFQBgX9+urgZs418jYIfPjyVghx/sOCmR JY/gWmub1fiWdl909helLbKcGaYvW0SOZ2MazmRTFYnJpi4SkwNBTA4kMZmy+gGrOOErICbrpuJM trUmJuuqTEwOBDE5kMRkyuoN/5oTTTWA5+vb1ZXwrArD8Uy+pohn+uFoQ9alydJHAO3iRm1eVcFX ZW1S6iLPnIH6KsVkwFZFxbmtiiZxW4kicZuIwG0iA7djVj9yDScqzm1VCM5tVfhbHtpCZNMkbhMR uE1k4HbM6hsdCvGEGAD2Ne7qSsCWdtnLgV0okQM7/GBhZXuUpY8BWwmX10j4qpRNSl3kmXNgX6GY DNiyKUvGbftiHbktm7qO3CYicJvIwO2Y1Y9cxYmyZNyWccUaSDIxXSG1TPYmEcTtQBK3KWvb6Fpx Qg+Y1te4qysBW1eGm9a6UrnGph+sYWssjnj6mGldFu5VU8JXhamrmLrIM+em9RWKyX0gVcXtTV3V KnJbV02yN4kgx0AgyTFAWf3I1YoRFbc3tV1YMW7rOJW7QtxN5cRtIsgxEEhyDFDWttHRqGiJesgH cn27uhqwteIueUtVObDDDxZWpc7TR4FtbF4taviqsKuAmLrIM3eAfflicmDrkvupta7SQkrrOvmp iSBu68Q1xyjK6keuYqzXkWstqZqGc1vVaSGlFak/V0EgiNuBJG5T1rbRVIgnmmYA2Ne3q6vZ2LXm Njbd+RWBTT/4dRtPnlgzqlpW6EW34KO0RZazt2a8TBG5aV2Xmb1Z09rJ2Zs1GZ/O3qzT/olMJNmb NTcx65oTZWZvVprvu6hKichkFb0LroLkiGirT46ItmkV22qJhXhCD2wxXeOurobnUimGZzrhlEzr 6Mx2mOLJE3iW4eNT3RcdGCltkeXs4fkyReR4Lv0xS2JyWZaJyWVlEpMDQUwOJDGZsvoBC4V4wmjO ZF0azmRtVGKy1joxORDE5EASkylr22gqxBOlGcDz9e3qanhWTYbnELyZ8Bx+sNO+XQhn6WOGhygs yFRRwldFURcxdZFnzg2PKxSTA1uLjNtaMm5rxbgdCOK2Vhm3KatnoWTcDhUQt5XJtJfSTHspUmWu gkAQtxWtg33TFFdYVIgnzJCivr5dXQ3Ysua75CPA9h6I5YDt/RERkZ1XvfMiQjDLDHwglysmB7Yq +B6yHcS056YUbcC1wy35HjKRxG3FttliIZ4o+B6ykpljQEmZ9twskdZPRBC3ZeYYiFnbRlMhnhjy gVzjrq4GbJFFb9niiw6wi7DyaFSePILrRrusUqAXG5nSFlnODNOXLSLHs8gimZQs0rJJSRbJRAQx WWaRTDGr51yRlk1UATFZSL5sUkKkZZMSRdpqI4KYHEhiMmX1fRCckAMrxGvc1fUHbVlTVobP+T4+ 3tq2nVQuxPXWlgtwttbs5k+3xNy1xv60Xc2FtYzU5s2tZl4oIwXLd9s91VKYzZ/YYszcKCM2f7Yl GzlvysrFabngTR4GVswrVdaz+EFOYROrcvOLrW1bUFPZBboLZI3Pp+x5nz0v6EX+49nA8ywrELx4 xJ6fs+fzrHYe0/rCsl1VbquZ1tuy0ZFcBLJUcUPDZS7TjtIXs+M18bKqXADsO+Fl2/O/LRWvO9xu I1yoX9buc+LJ0wFuz+DY2/HkYx9IGvu0Z91mjuQ6x74s4rmR79XYx3azQ55hVHVdV2xUiVwQKRo2 qolc46iaqpm/I+W0zkFlzf6c8Px8CU3G87xEyom/eGdAqz2jF4+R1HSGfZuU8LZQbsBbTfx+54Go lS9Y+48Hnp9lv4cXDwdG5vlAIXHm4Tp+Uv+koavaT7O7tn9BJS03b/Hfw4vLzFsPwnPdXhQIuH02 0OnTfqdNufmXgfbx0XiVlRiq5MV9jYaoaj8w6L9C+ngTze8P2DNvh7s+dxK8UrZXGYTy3ytod6hz J6zdJwPM5uDYpRd3Bkb+2QAvjxNiwISo6opPiEQuiCz4hJjINapu97Ud8T2cEHm7/5ON9+/Y839F 2fl8SnvnCio9D+moCKRRPXMFyzUWzzE4rSPPkdA/HwA47NDQi0Nqfi8O8j+2gPALz6YPQfinYfJx 1q9eH68EE/wiB8arrJARWC2QMuKwOhlozhGycvYGmAznvVmGNYyUGcLj5DzNJ6EzeuvNwGx5PlDa 0QQYvfH0IYDxUwSpoS5ymYx245MBvg3PStEEQTORKvgigkiaiaTii4hErnEmcifsvocTEWv2BbIO LzJ1gMVrgfD+PVoLzJF6uDdoxk+ohyGJyOdCoALPMq2AQF7UmbkVSAJ5ITJzK5LrBHmp4uXJ3yuU s3bHyeDlgBb+nq5onyHxnQ2Ib74ABLr8cGBA+EDtIbnZQaOHzICLpNCx8LwYUENwNt/J2oWfoT2b jwTm9judeMMl1u6Pu3FiJvyzi+ASzUyGA267Rxuf3Nu4e+/z2fnpxf7G3S9mQm7c/Z9Zs3H3k7/+ YSY27n06++7b77757pt/fvP3b35w8vdv//ntd99ufHZv9reszKJUM0khElcoc9lrFaZVjBtsL6mf IKN+ZwCYnNH53WlwLKULby7Dxsxy/bZ/7D+vf1B8+/rbNfbbCNXeS5/6/RnryusBu/jZKrge1GKy sQAs5Qejxbx3+EPXtROttAIq5Ltp5ZiuKGayKD8EfMvCcU3qivD9iPD61wG5PhyYcIZn43JeiKb6 YBDyaPNL6uM/tpgx8/8v4I4XZW5kc3RyZWFtCmVuZG9iagozNiAwIG9iago4NTM5CmVuZG9iagoz OSAwIG9iago8PC9MZW5ndGggNDAgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzd XVtzHcdxtpzoYthlO1V5jeskTpUBF3G0c59NUqkybdmWy44tiY4eSD2QAEjQOgApACRF/wn/mzzp P/gPqUqZ2Zme6d7t3T0HOCJISKK4feayM9NfX6bnsl8smqWQiyb+Cw8HJzvN4jfhz6OdL3b8UsV/ ugT8fHCyuH1n5/2P3UKEgnpx5+FOs2zbVrW2SxcLpZZ24Zxa3DnZubv74Z5bttI6sXu6t6+WrdDO 7F7Ux6P6eJayKgNZjRCQHh8vUroVu/v1x1/Vx1r+fv3xIS6fXuXt7mJvXzZtu/Rm97Ar5Rofyqd0 1UIF8fFheetF/XG/Pj6uj0elqgtcvrx1n3vVk/q4wo+9vsYfj3EpqOoEv3/tVz2rjxclK+rKaX18 xDXljOv1F/XHczzWkB5H3TRyqe3uJ3uf3fndjjJ22ToTYHPnMGDlqJZ/yrUPpaNeP+DSzwiv4VdZ sjb1R/ToS1cXXfs+uLPz0Y4UdmG11EvrFmbhzeLsaOfhlSTEiKXXC2dleFmUkvC2O39JLxNBHJtG N42wEj9+/JvRpLMtiKuUaul9ry1REcTOC6997rxOnf9WmyLC/0eb4qyifPhWm9LE/3dq7HZRY4As V9RMfETK7bCoIapwRCOFWKrdDwoIv2Tx/pgT3SMsWlWebNNUnPrQcOu68QkjIBcqjdA2dLqUfik1 HpA/sMryrLTtAKst3MxXj3Bp/NLJ2niEKymMLYNmmq0OmdXkrXd3BVZE5fHWdY+OD2rI8qOjjK+j I7Y6Or5dNh6PjmQ1clMA1V7zOKmglzQRgSDTIYMPLd29W5r5J1YuHnHmsie+NrhhRX5Fq7c53DoY WiIC/hotjg6Gz6OR3P2sNEZ54xh5vNrbPH0bY1Wsa6mBi2N+dQsv2gCZgcYJ7zOhXPc+Ydv0wruL qF65/z4LFR4GVryY4lR40sFJsS5WexKGUfhCrnY+oT/E9IamT3A65zVQ1HmHiuZUR0mTyYc/Dx1L HbhKNcddCx/tBEMaXTHvUx2JNE03ltqbjmgToU0hDsLoyEquAilUzdqNHFSShjG94CCPqkouxwpI I1PWWInSmYgvyEQo170+k6Fc1zTI2jUaKklEesFBHC61VM52vP5d+POXG9/lyNr1FVwAxdK1YdZQ RE4bCXLuddTPzsksc2999x/+8e133nn3ve9F4Xv/Y9Hg0kFvaylg5vHW3r5ZWmlN8Px/8q//8k7w 1oKOMl7glLf2wo+Ndrvv/tt7P44KPYyhUjjHvdPvv9dNHPZz9fvBbfLpFT+4d/bDH70dZkAi/NTY WttPw8uCq6B9/enf//nt6C8ulbYtrv8n4Wcbnp0xtGHlsWtaqK6RSvRaVmc06yibZmkWWa9I0bZI r4C2LHoFfjjZkbppSXqsJehYLdpBLteIlEuqFldKMhMVcpVqiAqRUjZInsLkRxZ5kqFgkScgsjwB meWpZO0GCSpJRHrBAQwgkafgdIoiT1IgeQIiyxOQWZ5K1q7RUEkiGBVy07u6ddUhbRMnOZ1v99a9 s3eDLOulkLq1uz/Y23dLHcDud3/43ffeDcLZLnWrFUn40ds//qd339tMzOZsumxauZ7sBZtpSPqk Te/m0kl0BkWVaw0SLJK5Z9MvXw0VSCEURqmQpqJUKF1RmglAaSYBpZA1QS9XkgihMEobIzBKw9BU lDaqqSjNBKA0k4BSyNo1GipJhBEjAnlzuxpZug7mu4aI1jcY2KY1FNj5hzBOSpDkCVxrHbJaYbmC 0RxD2orkJJi+bBUUzw3IRCYTS/JISlWZnAlgciaByZA1cU5gohGIyWGi0SImizC/LEwWrfCFyUBk JgOZmVyyxkaXShKh2hE839yuboRn6eyaTpJoG7muog7NlEjD9ooK3wqkUklmAuqrVEOB7VrCbd8g d8ILWbmdCeB2JoHbkLUbOagkDWOLuR1MMtFepkXay3ikvTIB2iuToL0ga9doqKQjbDOmqG9uVzcD tlFEUU94/7Kx6wJbSuI69IqGGQf2FUhmOiW4QjUU2MYQbhuL1JhxSI1lAridSeA2ZE0jZzFhCLd1 22Bua+crt7VtK7czAdzOJHAbsnaNhkoS0TYjwL65Xd0M2Fr4NYHdn9ZOAbubd1ZE0qJpkloRiTMz c93LVUOBrVWLua1hLpWGtKnczgRwO5PAbciaRg5mdR0B9jKRCoJ4mbS2cjuu9xZuZwK4nUngNmTt Gg2VJCK9gAH2ze3qusDGURvV2PXgPXBIUtQm+QG9XNVL6JyG6kPgzIzvcblqKJKVxFFQqVRb2at0 jYICAezNJLAXsqZBUpiQOAoqpSN6Ky4jFvZKjfSW1ERvSU30FmRN8ReD9FZ+AYPkm9vV7Udtghlq /FaiNvO7mmJUSsN6JewIWNa1f1Mf0a+La166DLa5pY3/Zd0V9aQ+nvZ3LqRdVSgrpK/qj+jxcb+q uMqJlj4XdT/E7ZKOVkkv8OPEpp7w+BLXCpt2/sjupzia2eDFvuqQbfWnM1ul6l4ytNXqBdfUT9hd Xfe5qsjWDwwkEwBghe2CE1KorayWqiAiBmOFWS61je8sC1q+3M56qZNyqSzsG0R7awB2iwqwAw6W aN/geX18VtJP2H2FZ30GBWcWA4jd64Y2oD3GDGK5hjZ7dI+yNWhb3Au2qipBCIsEVmhbHfMqAquY NTiJuKqRHUXTu3qO8FD1WyVM3izZ2wF5xHUKFX/Qb2mvPKmq2zYYYGQaB4t3tXlZK7gAGrRX8emM VLIKYkwXMGrrHKeTLR2dsKQpf91bsAU5EXIpspygrbTHBedDcCfIM3KEdPY5l45E6kl/HKKcoHE4 wI/TcsAi7mKAKConJxgnzHa50xGWQPrTQf0sEKKcEJWASkFVz1mgnM306rjIyRGX88VMpw77LVFO 4kJoz+2Sk5NqfX7NjgTb/I2Ek6mKGOosHPvQsLjG3eT1cUBPAPKcQq9ARuh+Xh/vc34MAjrq82kB MuozAsozTjc85SBxzg7EeQXyrZGNX6/eHwyzrGWYbLigmcBzPue6fDCA7qgOPMXpDGIOWMQ846q6 4EaXF8hTLiuxcWSgTesXxqdYv2is2eYOO3Cc0JjWgXo8AAQdSPTjioXREafEWGeBcbdV3C7PmMBz dswXXNaHOL1v4oxXatsmzgaIer+eiUPW6qKkI3EnXh+owOWgfNSbv8C/QtYDjDJmyNHgnXGAXM1x l1W85xz3eWvAWgseCAccd084oPDCfchhdsyGvy76Lm/dxZi6zwF+TAwZX+ZyYnh1fchiZrCN2Djd SWRrVdVxafIWkuAwx7d7giLLsQ9/pSFHRySqgT/Eson7oVXohk0hJNmobapqZ5cSN2xRWoN8CKQ/ qjuBNM3H9fGP9fH3hSu/HwIg6Bd2Vv8cY4kBCO9CV/3Ezx9XnP5BWDzmsMb7tQtOvwxmAz3rxKrC B7h93KtOZvQLO4ArbgDHXPQNtCb40MoXH3rozVMVwXuRZJIEWT9PPwqD23cxJtZRdK3VW7ezTiyH M8knHOKRL31csEfM8PVq+bYLB6MO1bgRaiU6GjqYGvdgxzpFY5PI6XDlEYdgOmBxQ7wJ2jly2Iut HrbJ/j4aGlY4n7FdZ6Mjt1jhfDBT1XUjJB/JYjCvmHgZdu26E3xVGOM2A+CVNFs9qRNmiku5TVYh 68M6d9wE/br8NNvFtVDna4/4s5Jsj9kT2UjH86aVndbSEVGN8IXvNkzz+r6VKeeIXolvZcXSyDRQ MBtwBkVH0NIMUnsv+8o9QuNZTWdXgZA7hGpdDARlDbt4yqV/OaIwGA2L2PN5v6reKfVnGDS82u38 TO07voXh2+4R0HRqFvPpgoXpCWc+WMWK0tGcnI2T8FVVB+N4Rgz4aW9tKh+OZeeKZALKqFk+esT2 mnGLdNqfu1W3KPyl1hQtJBrP147AQ6VdrBbJE+2Zkv2FtiufabdKLJupJWxbH1+7JWzc+I/xsJbH kzLCaF37guMAUn7/yzKTnWoMZj29xVykceoMnZ+KzM3ViFCx08L+YrCRqsOLkNZvYzE4YDDeDVNH nVkMNiKd0tz6YrANyc4SXlMRRGE9wuvpCGEVUcLqPpaqVu2tDbCBcqR1Ca+Z+O8wGBjXBlhVeMBV tWABNLeCi359WBa57rNVnXFYHGy36GFxCNswra2NOmffdDDT6Gqyn7JveswtctVK+RBanfWTWC7T PWJf0fAwWX87Yyqn7VfjJPUatyA88XDvMO5WhQepxBdYjpiFtc+xdmQW5h4N5KwyLwoPfwHRc044 No9pR+FZ36VBkHjAvYqAi0PPyyI8RKKmHbGNvC8QnrmYf+0UMjnsmsFYSxjhecJJJHt3Be+k3+fK P2cHdd66covFMrUT+ukM0vfEzyqPNXiL7AWyBw+58sienPSHvLfpAXX0U65LDziW/ZLVdycV0guO e0fcQPNrtJVRzEa2Pk8Ye3CpCcOH9cdTXH4I6TM2J0bXNQcigscT1Gc8PaOzFl1yPb4zMvhM1stK wXRckt2aNoQUY3ic1Ysw7e3WV1oxWCbSbfNqLtpK9ioeWsp+PTTZGSS7Lwdzdu3TGUFhtnrRles2 pKDmIFXxYMa1ZFUR8jIf4ce5ePG0/Nap8Us2nYRjxmMLUdVMGZqg6upFgmN2BrWfD7Fcx41fwaPC XBzc59izYZOL8WGGyGthdpcbku7nZYY4drMi9QUbU2Dt7FYjUUqrJQfrngVi/WCUTtx8RpkPjGXP j+ZdwZPBiPcnL32XOYxS78KmV4+xrLhc55ScUKek+tn8BjbWz0aa5N7uUN85mY9hbHXbkggTBU26 wU+r0co4uwea3ePLOIlBloY+Mr2k85xDBoLLIOjbQ84hl87LOtmFwbzq7Nr1WHdzYeHO7r09enUh oOJbuboQgWK42XtUVW6wEkAsyoRBJJfI8rEEBMUaNpgLYKCNE2yw7YIFJesbczOXqq6c2vrtscZ2 9zZ33EFbZ9kNcuisxOf9+Ce/sj/q4wyuII7TIV4PzPmu7HbioZNBp0O8Gz0/72TcqaHHHbqyRDVF HqY55+937vz87u7/1GGuCpzEltGIMenH9ZHdoTzclV/h2ItCrunfUX+Hj2KhWedczICNrbExB35/ wAkecZh1jq1YMeBgl+j5taMs+sIg3n/OvqnG3pGOuLV+S2aOpPBMqauZY6FhBtAPZkaKc5nYrfbg kREgI0+EREogHTkDD7l0cvivr1oqOnBEsLunHNltZsw22Bt3qV2uSN+czrxq3Xhy6BWq6j9en0lR MOfRcKg2/tUZjj9zVpPExYkpkyb4nwE138KezLTtBbdtbtMfu++F31a7wf7o8xnksH7MQK+NL/qx VQ2jZSN+RJj3bHul20QHMg856KKxM5cb+QmM3hgev0y69moGjp0kDEc/Gjh2RYaMPsPduY3455j7 yMIyKwVky8R0BId1iIcRGmHGDECvJb2a0KcannHpxGUbPUvWs4ps4HKD+QC//FJjZce4UWvaurlj ZeSkO4NZctKdwfxwAl+BFDH9hOVJBRrZMDCieK/hhJiNt9QGFdEdaup9okJpvdD5dpHt3govrFtq 9Na7s4u0l0UXpD9iy5OJ37RPOzIFZNInV/zi49XXj5hez4nn3NzsjE2f0jnCbDb14v2jzt4psfWz 0/EObLhjYIvLiLU8meX11Uwdu6gbXrC8qfoYIZZd+R0Df7F3c8ft5+Jnc58iGcTPor2bOzl/WYMx tHdjlvF18bhhGRFBboOQ18+4rNwqnpSdlCiz3QOtTncmADWe3ZDEn25kD0wcs5w/ReNwvfzSysSY Gu4ye/qfREfIBnErbeEHWZnMq6pSule4qqrbtrt+PnYEvktCVieQrmNXJ5CfdL8Cs/pBSAGi77CR JU8mzsHaGf6Q2i84O8VHgM85BTIX1kWv4tZchEpnxeP9elvdFy4jzjj2hIb8Cne/Nm9v7RjnZfdx lMcPZ2amm2zkKKghGyiomRdavR6reTp9lWh4AdEAGY1Juw+arfq/aZczbsUGNx6xMxnkgpyzWa/b Rgqpl550mfgHpHHhlWjkt7rvI0p6o3tDz3j2c3EJPnB+n7OGZFMroybZkxL8+ZGBNY17DobXTlHD jFqNZLNq7GWVXX7TMXtDFevg8DuWWI3F24G5aAgbtjvD6dfsWTR6aTG8AkvKN6+Uqwplu/NpnfbQ MwolDsqL9bE8+tGyqL4b47e9uqldOzh8w66ZIf1WlyLIjubyWK+BQzGdQ1y+dPekTNH4PfKnnNvC LjGPrdmUKRrrVbLRL34PEasapqZgcYr2YKbV/P6uUy59KG9kijY32eN9lfOZTn8+HZLc4DjaRutL EzuSoZ413OuK41tD8HUbKJhQwmO2qgWn7NlZGkEM4hgzzkwcK7Sqjg7ZanE1EzZ3swWPjkPuVayy 4peDFhzP1/V0N12znDyiMouuySg2ikShx6rmkG+I4HPA+YbDk751xhvV4AYHNNHosbciDA143eFh hCtnvUI6us91eLEKdUvmGYFAOb3esSzwS/OUfeGXoWWLfdmUj7mxJyddfSQnJ6G639ZBZiOLK5Yf dSXtABcqj8PjpaXlTMNv14YNzoH3Kq7fMT4coIOeEx+eAELzFQoksghfHp9xYsiybGwRnrGnPGbZ qshVLYzp5jdp1JMT5IQQY+XmrCAfGn9e7On8tUDTixRPZ8ePUVNz69NzZw7Z6cGkEYUeOYNiTMOz mXSGi6Tm5cAyUqlB4B3sDojg/OuIlmLcHnb9eexWjQLOkRPt0+BjryJbc4Wnd+fv3AoQeyUBf/iS i8fz+wBTp+JdpeTsLLLczKCQqhhwzm/SnEZ8TeeD0uw+DRLCmjLXcC6IbMhEqhVZ5rohk/h1CKiQ /mSQnnZT9xRyb1bCzlp49G3Rht4aADU0dXDnXrRUPDrnN2YznOT3arFrYPxWQPaWTVY8edtSy79k 619Mn7nkK52P205oVOjH2PQZaUT2zALK+rMZoA6W33vT59VMl+bGeXgQKmpUVnmwMyByLmdao/L7 wuuOHt5JYS9/ZFUSKvRw0CuBbwOYuzbnBTt+dXyHy7aui2czOGSnx3NXDLBrxfxclD37vdHptymN C/ZyDb/2GScIZJfa9ARpcJdbb+vaQ25MCPqZjpJYZXlcVqDXCVLSItmnTzvTf117zx7RhyZ3k1fG az/DAwXp/IZe5IOxiEEcu88BngTMmPJTPkQPXFM+RNrtxwz0mC/bE9Mo5nOfgJiLkq0ZkBsPcw0W 0YXBLXnST+696Ww6SsZruZdc9zb3dinT+D0CT7imTJqzDW6CrrNXJNpoLsD6VZfbzDd3eeScV49m r1XJzlnGue3HsxeBPS04nzvcyt9ePr93aGjOkGFkr26fW9lfVhuWtGBUfnD7UvixqnbE6WPMVEa1 P8WPzKySxM56nIigGFuSYzQO6w3w96i97Kv+qdWEaaazcoia+tc+U3uzRhZ/vHZgI37EhxqCYoOp LtHIzLSArENORl7nZo1kbYyx52OfRljz2E0NXyDt9UV9fMalE798LvyBxmRae82pFPZeiaEVHnXG NzrxwLxq6vqb3q0l5FZUBh6D7fdxAsqLL7tywZsx1o1hDyHz4vd8Ovh22YuEpnUCe40Z76Sua5HZ S6PZ9dlDNr1imhQqj8Q4AKbJoiDTe+JuMLaNn6Cim9lY7s59NGeDuc6ApxHTl71pZ/pVp0X5sufi WeP6i8rfahyRxSR2kjG+LH+Hn+JB6q1a/PF51ZxIbnB5GJt1TtDmpsVjpwaBv0dsq1jnjV1PGFpU BBUxf33UwxmksIqcaF9GZc2dhJjzHQYrxL3PuA2Ono+HnKftMFRE1uoRUMk6HKQTL7I8snYcicdA UYw7jGz4iOzBgvRP2TEhS7DTxoHVWZub/FGkbDTxZpoyBu9pO8t63Kz6HJttM6BmvSM2wvMl+9Lk fbWtmzaj7MlL/mqBCjnyxTOEXsYMD+e4dUQiJMcikoyZYI9ZjQUAipqdOxA/990h9ss4U/5Y7+Ql +wUOXhCfc68axnKEQQGwubNhvByyvgWZA00icu5jLWMjVV86pSXR0gF7MBIZ+apF0dIAelzz2tCq cMeNyFX93sHSgDdyZGlg3omAdBLz5CBzn4PkwJ/tvQr5s/0tKd3ey3W+Bz+x07X70rcx6UR5/kg8 fGGmfCQefjjZsUqT5ImNsjZeKGW95QpaWdNWJCf5aPxlqyAfjDc2fXr1BEihy1fUjZWqfEUdiPwV dSDzV9RL1m7AoJJEpBccwGBq/BV1Y+DGrliJEfUr6kDkr6gDmb+iXrJ2jYZKEqFHPhh/g7saWboO 1FNDtG0xnuONdwTP+YeTHalNS9InAC1DrXEEBFtUal1TVzQzAfVVqqHA1m2DuW0Sb2BIZeV2JoDb mQRuQ9bEwgYR+QXAbS1bzG0tXOW2bnzldiaA25kEbkPW1IdcSSJkOwLsm9vVzYCt0jX7AOz8zYsK 7PzDyY5oG0nSJ4At2njc0QjHFhW+FSV1RTMTYF+lGgps5Tzmtkq8SUOq2rZyOxPA7UwCtyFrGrlc SSKcx9yWRmFuBxNduS2VrNzOBHA7k8BtyNo1GipJhFEjwL65Xd0M2IJ6IFqIHrBFTveeJk/g2scP /WoluYLeuZK2IjkJpi9bBcWzpGZZYrMssVmW1CxLapYlNssSm2VJzHKQOWyWdat8YbIOvm5hMhCZ yUBmJpessdGlkkSYMQ/k5nZ1IzzbRhuE5zDDkgTP8EMYJyVI8gSetY5ZpeYKalnTViQnwfNlqyB4 to21iMm2ca4w2TbeFSYDkZkMZGZyyZoGzGEivQCUlncOMdl4a6rS8sZUpZUJUFqZBKUFWTtkQiWJ cI7H8w3u6mb62TcYz/Ct76qf8w/Bn7UBrDh9yqO28X7Z3NZBUWmNRB0jmalHfYVqqKL2EnM71FG5 bbyu3AYCtFcmQXtB1jRyChOScNvBbDaTRlVu5483pxdkAridSeA2ZO0aDZUkIr2AUdQ3t6ubAdu2 CgPb6ZYCO/9wks6d4/Qpj7oxMa9r2KKiUTV1RTNTj/oK1VBgO6Ext13iTR5SZSq3MwHcziRwG7Im FuZKEiE05ralbqbFbqbFbqalbqalbqbFbqbFbqYd9ahvblc3ArZqLZ4qagkOzyf0h5AueukTwFZC tiEvyESvqBKNL6krmpkA+yrVEGCr1uP5U2honT8Fos6fgMjcBjJzu2TtnEioJA2jx/Mn1UqLuK1a Ue1zmHZV+wxE5jaQmdsla+qDwASozT6wb3BXNwO2NxoDW2jqisAPQV96I0j6lMb2Nua1hi0qvK6p K5qZauwrVEOB7R22z8r7ap+Vb6t9BiJzG8jM7ZI1jZzHhMP2OQwdts/KQ3AsVuLaap+BAG5nErgN WVOjG4kIMeKK3OCubgZsp7ErohtDXRH44aT7yidOnsC10TErhLtpQSNr2orkJJi+bBUUz85is6yc q2ZZOV/NMhDA5EwCkyFrGjBnEWGxWVauTGs70rbVLCvrRWVyJoDJmQQmQ9au0VBJ6gEEIgZ4vrld 3QzP8Yuxa+FZiKgX1wO0EFGlFjj2igqhBIIgyUwV9RWqocC2Bke8lLWqctu6GvECAridSeA2ZE0j ZzFhcMRLmRZHvJRxNeKljK1rbkAAtzMJ3IasXaOhkkS0I8G9G9zVjYCtPQTt0xSxcdQDgR9SgA0n zwT3TNNqrmCMzEHaiuQcBPcuUwXBs/Zti5isWyEKk3Urm8JkIMDNzCS4mZA1hWVzJWn06kpGJJ3D 1lg7W62xLlGC+AJnsDUGEiK4OBZQKkmEG3E8bnBXN8Ozg2B00ste9BR1/iEYf69I8pTj0cb+a8EV DJPrkrYiOanjcckqKJ6dVJjJJQTQjaTWlcmZACZnEpgMWdOAoeAAvACYbK3ATLamqUy2uqlMtrC3 Ib3elr0UXdMga9doqCQRVozg+eZ2dTM8G9gtMIdn6a1ZF9DSO4Pg2CsqvTEIgiQzDVZfoRoKbCuw NdZlf083pKpaYyCA21Zha1yyJhZKTAiy1KY9jgdo7XTltrY1HgAEcFtbHA8oWbtGQyWJ8COhjxvc 1c2ArQVehdElZPkJ/SH4s7JVJH3Ko1ZNZ38sW1RIX1NXNDP1qK9QDQW2VjgeoLWu8QCtTY0HAAHc ziRwG7KmkdOYUDgeoBU1ywo80liJwmZZUbOsqFlW2CxDJYkY9UBublc3A7aiHsg4sKVs7LrAlumr i4DIXlEpWosgSDJTjX2FaiiwFbXPCttnpWtgAAjgdiaB25A1jRy2z4raZ2lxYEBLbJ/Lzp/4gkwA t6XGgQGN9/eUShJhR2IgN7irmwFbtCQGoiHk8gn9Ie8DxelzO1G1aRRbtNtCCqkrmnm4E/WS1VBg S2qfpay7frTE9llS+yypfZbYPkMliaD2WdBdP0LVfcdayBoYAAK4LSQODJSsXaOhkkSMbXC6wV3d DNgNiYHAN3oqsBWMU3iZIelTrkj8rnWQc80WFcrrkrqimakrcoVqKLBFg/cda4EjBEKKyu1MALcz CdyGrImFOEKQXwDcbpTH3G5g3blbuINNyN2innCY2w1spM3LgWircakkEcqPAPvmdjWy9IvwGuXi 3ivopWx1IVdA1kh6lxnI451PF6cb3MXuF3bpWhU/X5avNtdGwm3sXsdvrbswTi5/Xube6d5+eJOK Z6Pe3YunsKQXu9/fE0slhAs/7bul0Eap3Xf22mWjjBQo33vxyUthdr8XqjFLo4zY/cGebOWyta4c FPpoo7vkx9tvwhwk+Di4/f+1tx9a0LpgO3Z/ip7/e0+EeoIzFD9VVn59gp5PU47ue+Hlx7ORzCvy nAs+JrXV50foGR1xa5ZOWb8IA2rLnWG5pvuoxMXI8xFpZi74kryKb/tTUkkuiDs69nb8xkMoiN/y Aj2PDUYp+GSkYBmhNC7pPrFzKHU80s7DkXaeF77/Xz2oliXQeFgV6kQOyCyBxlmFJLCSSQK3Inlx xxd8B+EVSd5WJA63+4JjzdEIDs847B2MFMQQes6DNkOlN9hVtoTqPtx4+ArGtzdw0IQGjvgzsD9Z Y8TuQ8FnI1I5VuF9Tp89Hil4ygkgkZVgn7CsZBJkxagWy0ohtykr1sbD6W+cqNRmv5gzFIcj3HnB Kdtz9DyuFXNBqhLfGKlZQ7dwWFVeYaxmErCqhMFYLeQ2sRrwr141WHUMcxpVFnx93GyuXI2WRVJU E6cQuW7f1wE86vsx59A8X0PrXXDqcszVuE8UHKP1cMGHIzJ2VmUMQ+qqWqAAQpSPmp9vZgp4YQ0i GqrN3tH1CumCG/Ixvl0QrcVop/X8yVxwXGGu6XFvwa9cjDTy4Ry0r8NfmnGzi/Scj7QH/77iXoHb 83SUfXhuBOP4nyOvxDUuhyUt+REXfDbSlDXwmocmDomE3AblaEYk95wzR7ptNDJHQGZzpL2yyBxV covmKN6p4fWb5zvhds9P7D8eAc0Jp2/H5rUAIC/i1SuMvzamEFgAYZXT1zgYnlgwx8xjkU0ae+DV Fhaxg75sxr6l2fDQqETL/ToYlVtz8YVjMjRMb48ZrqYMY0PGya4VFstuJkF2jfZYdgu5TdnVrnyT 942SXdRu1uSNRZkWhMmM/3i+pqSdcTZpPdvJFDxk4aE1juECCfBQDsdwK7lNeEgbR/vNgwdq9zk3 3qcjHGd89s4JezMmtMX32B9EI7WkqkZSVSOoqhHfgqrBn/9+k7CE212s5Fhc5WjkuYRKbm3oTj6p b3xD4ioBfHf+MtlKJa+/lXfDiDOzEbrswbPq3i6nrJX3WFkDuQJSYGVdyW0KmPHxc+pvnoChdiPH bA24xxjF9QPpdl0e43BhDVa8QAIujMeKt5LbxIWSb+QyEG43G9ym0Z5ZvDSvTvN0w9B03YlfUl+I 9Bz7JNqFdGkB4+Bk5/aHO+9/+IfFxdmzo533P10IufP+bxftzvu3//TLhdj58FeLb77+5qtvvvr7 V3/76jtP//b137/+5uudDz5cfETqbKxaSOvMVeu8+pJ5RpyKspkYd5uLDo3NJQ8Jc7EwsWMpQxuk TUHmNfsd/g3/fPmd5usvv95iv03ocFBhqN8foK58uUbUip1OsHORPsBlGwBo5WujEENLZ+z/G9DK IKDiNdAVzUI29nXAt2wi12SYdWd83wW8/mlErh+NeFXjht0uG9G61wYhd3c/gz6izR0f7fw/bnAn P2VuZHN0cmVhbQplbmRvYmoKNDAgMCBvYmoKOTEyNAplbmRvYmoKNDMgMCBvYmoKPDwvTGVuZ3Ro IDQ0IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic7V17byTHcbcsn3SiBdkOAiQw EmkTxzbpiHvTz5kJggCSrVgy7ESPA/zHnf7g8XGktXxoyXt9Cn8b/6Xv4C8kQOme7uqumqne2SWX oo6xTneY2uln1a+qq7trur+cVFMhJ5X/Aw+7xxvV5Lfu7+ONLzeaqfL/dS/w8+7x5P37G/c+rSfC ZdST+wcb1bRtW9Xa7r2YKDW1k7pWk/vHGw82P9qqp620tdg82dpW01bo2mxe5Mf9/DgPSZWBpEYI eO8fL8J7Kza384+/yY85/07+8QDnD1U1dnOytS2rtp02ZnOvy1VXjcsf3qsWCvCPB6nWi/zjdn48 yo/7qagLnD/Vus1VdZofZ/ix11f/4yHOBUUd4/qXrupJfrxISVFXTvLjY64pc67XX+YfzzGv4b3n uqnkVNvNz7Y+v/+7DWXstK2Ng839PYeV/Zz/jGsfeo96/Yh7Pyeyhl9lSlrlH9Fjk7o66dr3wf2N TzaksBOrpZ7aemImjZnM9zcOrqQhRkwbPamtdJV5LXG13f9TqEw4dawqXVXCSvz46W+Lr+ZrUFcp 1bRpem3xhsB3XjS6iZ3XofPX2hTh/i02pbaKyuFam1L5fzsz9n4yY4CsOpkZ/4iM214yQ9TgiEoK MVWbHyQQPmfxfsSp7j5WraxPtqoyThvXcFt3/HEckBMVOLQOmy5lM5UaM+QPrLGcp7btYrOFm/nt I1yaZlrL3HiEKymMTUwz1VpZZjWp9cGmwIYoPb5709xpnBmyPHeUaTJ3xFq507TTqsHckaxFrhKg 2hvmk3J2SRMVcDrtEjSupZsPUjM/ZvXiMTdc9tTXOjcs6a9o9TrZrd1AS1SgvcERR7uBr0Gc3Pw8 NUY1pmb08Wq1NbQ2ZlSxdUsHOM/zq4/wonWQGVgcV59x+br6hG1DhQ8m3rxy/3/uCtxzoni2SFLu STsnxda+2GPHRtEkcrbxGf3Bv6/o+wWSjmkNZK2bGmWNb2tKmkge/Mp1LHTgKsUcdi18vOEGUu+K NU0oI5Cm6nipG9MRbSC0ScSu447M5MyRQuWkHeegkMDGUMFu5KoKLscMSCNDUl+I0pHwFUTC5euq j6TL1zUNknaNhkICESrY9exSU1XbTta/c3//dOu77EW7vIFzoJjWrZs1JJXTRoKeN9rb57qWUede +f6rP7jz2muv333DK9+9T0WFczu7raWAmccrW9tmaqU1zvN/+1/++TXnrTkbZRqB37yy5X6sdL35 +r/e/bE36I6HSuEUD09+eLebOGzH4red29SEKt58OH/rR3fcDEi4nyqbS/uZq8y5CrrJP/3b39/x /uJUadvi8t92P1v3XBtDG5Yeu6a54iqpRK9leUazjLGppmYS7YoUbYvsCljLZFfgh+MNqauWvPel OBurRTtIVVcipJKqxYWSxMSEXKUYYkKklBXSJzf5kUmfpMuY9AmIqE9ARn1KSTsmQSGBCBXsAgOJ PjmnUyR9kgLpExBRn4CM+pSSdo2GQgLBmJDb3tW1mw5pKz/J6Xy7Vx7OX3e6rKdC6tZuvrm1XU+1 A3uz+db3777ulLOd6lYr8uJHd378k9fvrqZmY2O6rFq5nO65MdOQ9wvH9G4uHVRnkFXVrUGKRRL3 xvTLF0MVUgiFUSqkySgVSmeURgJQGklAKSQN0IuFBEIojNLKCIxSx5qM0kpVGaWRAJRGElAKSbtG QyGBMKKgkLe3q16ky2C+a4homwoD27SGAjv+4PikBHm9ANdau6RWWC6jH47h3YykJJi+bBEUzxXo RCSDSCInpcpCjgQIOZIgZEgaJCcwUQkkZDfRaJGQhZtfJiGLVjRJyEBEIQMZhZyS+kanQgKh2gKe b29XV8KzNIrgeYGTJCu7rKGWkljYXlbnmGGTShJTz+kKxVBgG0OkbSyStqmRtCMB0o4kSBuSBs5Z TBgsbTf4VkjaUtdNtl7OOc7WKxJgvSIJ1guSdo2GQgLRVgVg396urgZsLZolgd33/hcBu3PPMyJp 1uDLZ0TixMyU4HLFUGBr1WJpa3A5A0urLO1IgLQjCdKGpIFz4Px2BJiVQCpY64iktVnaflssSTsS IO1IgrQhaddoKCQQoQIG2Le3q6sBu67scsAWbSWXBbYbWCRCZC+raFqBIEgSE2BfpRgK7FrWWNq1 arO0a91kaUcCpB1JkDYkDZxTLSJkjaVtK+Jvmhb5m6ZB/mYkQNqRBGlD0mB7W0RY8AcGwL69XV0W 2HjVRl0a3mHVJqCqlypjroNgRiROzCD5csVQJCuJV0GlwuJVOq+CAgHijSSIF5IGJmHxxgpAvM5A YPH6bcQkXgmFhLUSMiDLVF9cZUEDMhQSiLrke9zerq5/1cb5V1WzllWbJWI2/LJUXCJ6L2/5T9KW /3EONzrlIpNQONMkP+6k97uDcCX/iAJznnZJnR+JQwJQiMtu2l5E248X3PYj2pM8xTv43aNszeYL HLjDJD3g3qNaz9J7FN2AYpyO+q12/lmh1TkmAtWPYpTOuaYcD1olCp065/iDit/DrGb4e4Lfd4FN DkamqmF7YSdlmrGcymETx6xQc/cPBu9rh79zLJ8FgWFdrrjpvA1t9BsNEtqZID3jgunm+fE4vUc4 Rug95YL59lhIXyRIH+F+IO4yIjsaEf4F5m6C9BGHfnZzno+9ycGCU1ZQ98Oj68ohF1V3jjMxkTI7 fab0otpKKgtJXwwb1VgEiSF6Qq2MnhKVZSB9tHT7x4R6zjZqIN8clUeQW8XtNRSWtZ+gh4I/keHN 1njOvt/joI2s8Wlfih66OyNSZuwaCdM8ZLlEdJhB+SH3fgeLjhHIIYuSY9wAxgYOFLZnjec4KZP/ ca5qyjHoD7grDDYRV5/gWhcHh+5z2M3Yu1heamzE60JrChzrwgN7MYFFSJ6x1nZ/JP9ggOpZ0xOu c6jzLI4QzvYGwvHW9Cmn47sjRZFhE96T9vfl2GnXAhNX8nqeYOEyMJmMCBeZQNbaEv+E6dRjtqpT DpFjrhQ7BKKuPOX6h4R+wckfNZoMDBykwcySkFfGTCJn4VIexFF+HCikx/RwWKcG57LDesL0NFQl 6jjYyKqL4Pj9xv1f5aDXLvaX8W9e5Mc8JTjCXU6PZ+n9jNXogeX3veclujOCSNacD0dd3/tjTo9e 9AXRs/xPRxjN+7xnyeVHkH7EtZq3U+MOVPcozBJTHkYj2IDrOHDV3ZSv0xHRTB1YJtsRJntdICuE isM455LX+RH9KhIIphg5NxvoWls3gDlva2okTHSZgHb0Cc5heo+mvAjqZM4LrtyHI8P9bCDJIP++ HXRN+ZQt6oyD6hyXOvbZCxaD693E6KZb3hB+g2wNkalSSv/pVWY1E5pq9CBUdD2xqVaLFOyCVjKy WUKOCLJQR9xKBbLvF5zZQ7AYzNm9WePn7KxRP+QEyE8bTrJZ2+VghdyDPK1DAPqP5H30PgYyMRgK yWQN8nAWpA0ByqchXtFvWkMW64CiorcQUEJKFB5ItQJv4j7nOJKxh3k/L8gzPT5ZNIh2n7hQLokQ vpuDqtfAJPe6XhOT/sgxAYH2MWfgLsrdrWoZu7u2L8SsD9Ft1tPd9znH7JTVUXb+u2he0puekZna SpjRbdOsGzN+Q0WviYkfYUMGTDrHKsIw+QhnQiNhL2nP+rBO1azPOc7/QE5qBjZS6fO+SpdXQrKL vs92gkyfF1vzsRkc+xXncInWW/PB8oOrlJ3A8bPKgxHHACWdcUkHn8aWVx5Zd5hf4s1OJvHsF7sr 5yPvd3FSZto55dr/Hlco37/D5YRG5T9clxZmZNaJvhc/4gY0hM53R2aleV6GHBiE/rF16V2uS+TD 7fTIbjUgB+YoQzoDiVmcI9qByj/Fj4sxj5Yy5mnetc8KKgORLLMxmL7UVgvLvydsS9iaCPoYSLOZ 2KWAE/xjjz3l/bOxefWEez+6vDLcf7mW1ZWhlc8zJY/zsZkSv+nxKWcFDgbc9Tifj4j0tP/eNQp9 GJrtVY1/TI9sUjRTZJZ07meWn46w/CnnN6HRnfWbiOnpGc6eaXncf9/jE0JZ9qvIQQhLs3xsF3fs eIcng6qy6fCmhaw3IivBAIU1PaVPZ8G05JTvsjXl9VLU0z2uU/zu0/HiXdyVXJhFAxtYQ4I+5GCh Daw88KGZCXI42RgD6HI+BiNP0nvcYTcEyTEhiw0fv2t1yhWFeD4b4eneaFMT0CcJffzO99W3khh4 8UDf4RjEBhGcF8pn4LfHKeoOVyi/yD2+IMYUVdpDWve219ORQQ5NWsDeL5wErbAIK7+zi7A6HJLw UizCou1bdpf/iC3qlMNsYTOtvxyrKxPOSnBiXs9ybHfGSWY6sxyr2lpfy3Jsd0rBYDX2WpxAhITB IkN5kymbhKGvX5zs8B7JLmeIxiIdUFW7nPUlIXK9onqbTAjqU4Qv9ONiQziMohF4UeKQrYnl30qj 08LJDj/tu+S0kRxL4lHfNO261zZ1OJSnQzzMTskZcAim5/gR3hPXB4F7MeKf92HUi6RkY714H3GH g+lwr5L64Lzje8hpxIxrCu/Dz/s484gvIZbxsclKAdPU+aDVwoxOfw+4mgZH3JX5e8EhfjBBLI5N /IpUXmgZPRePjU6Z3rBfoMO2XdYebpBqKkNX0a+pMVGTdYO2ipMm32gAaRf1yEiyNNtbPElhh8Hh 2LZmJ3zMuD8b8a3YNYQVYr7ISiUzTLL5S1xjVPmMY9URY1541zAPuPzMcTzODGuyVnKiatHpjSKH b0WdqmVFh8Dr1Sl/fkzcnV9h8Xts0ymPjmRITY/TIU9s+KzZmGad55EJ4d3d3MtNekCWip/GrnWH 3X/HKuzfIh56HsWCiIe0UOr688uXPyJByXbtu8uqqde2Rb/miAQlhVq31959afv/KCBBOWVaO2Rs HU8ou33xCJlxlV77gcnK1FMl18O5DzjOoJGUfIfHGKRTNukOhy7kc7CfsSFbz24+8vECDzfTKt4H +ddf58ffpvcPt/qeWBKTbG21dnzr2oc1rkVMH3PzAQTwI05MC8fhvADaW0Aip7/De7Rb/QWnAPO+ Amwr63xcOb4W3eRH9Gtemn2PdUZ2OCwe457d7PRUVJX36JS0Hgmdq/VZbh0Kjz/vC66873JO+tQ4 8Mj4+bhzE9fqlGo1rXDje16ptFKu3Sv1X+mboVeaw1QOWTSzkVkTzN+yUfNoHWwclueR7MouWdJh jFYp3okZnV9gUTOKSVCx2AFGQWJ5HQzp8ClX1Bnb6iOuqcNPRmivyLY68/4py0BWAGRNipk9l06B v4GDsWvtTR0G8tj31Oz3ymSREXdJCdH687VkT+evtI4mrL/wIDeaWUdzVdbf4pzfjcUQqOoGd2iM n4RLrUND1noEu/OmWotqfYACXNAQ+qhvKXpLeuSYAsaPB7E7o/MuNwQfsJrMrpizsVV85CYbZoaS sh8a8evYx5x6DwMfvNF5zi2+D8JO/PDOh62w0Q5kofCGVd2Nux6PGan38gjpxJqRutarFFRV02of bD5jUcMu9CH+PRvhP3LF2VFtEKvUuxXn0QiAUVHgTnZqwZvyzgZpo9btoMvGdr7piltveU0CudK7 g/eZuT2X5Cz3mI2PGRwHUt5MzrN45CdcsCLPkCAiv2E3ua396IMFwd4dhaxY3ql20znSeqtbfx5a BxM3ZF3HtS+onWRznEJVNv3YiDVg1VoyjaCRcgvjW+hMkRzMA++/KOTvjR1+xXaFg1tWOkmg57D2 dpYGHwD4D5N533jhKSCqpV+zQ9JnI0WNObz8GThjSdn9tBV2pshnBYxvzMaZTvqs7DncYwEoJKiR sUR82MxgE2/0Wwc2fG7sWwY0SSQLxsx7xiKn4a53kAl7lAMfA/7+iJwvMtDZj2IiZl39+UgU/vyF Z5xwx07rGfsmZRitTnFSCk5l+IPmeOyIxkeAsDNjciYMg/MMvhnbKHZietIXerl/j7j+LYz9hB2m 2vArEGj/PoMXBTmzZ6bxHzAMlLB3PMQKR3IsOl4LscyDl40/QU0ZCwNjo/EXHdjT+1BnzvVq7My0 p2xTciTPhAPnc66k4fZ+XRveiJN47YXR9E/ZTLlSPvxh7N5OVv6Lbrgsg5v5DO2QQzcC6qORqfIF lx+hGxSyOy2Jgcx7mCeMdNgQ/C9YHLAhbZc7p248JGWxY7CSeJmBd8xdWeRZlVcdxzyrvXKgWtvW owaf/4aC3evnlypPOU064ljJfZeytqtKVKPTRSCi8Yv09Pox+OF4Q4hWkveLzlOWlU8L56H2sgrR 5LczmpieQnuFYsgptKqxEh3Nqppap6NZVdPkY+GBiEezAhmPZk1JA+dqjQgLF+MEssJHs6q6adPR rKqu89GsQMSjWYGMR7OmpF2joZDQg6pwCu0t7upKB4XDGSwR2ErB1Uif0R/ivXr4/di9em46DFn9 hXg5a3xrKKm4O3guXwwBttFQRiR1vu/AaLi8TZtERGkDGaWdkgbOaYUIhe87MFLhY+GNhDtsfCFS 5GPhgYjSBjJKOyXtGg2FBEIVTsC/xV1d+/HKVhvYIbnkhXq/eucfXn3nzmvdLXf+bhH8ritxa1tO Ra2tf1O4PO8nd3/6y8K1dne3tv3+UyXJTXn/+PY7bz2cv/OWK1y7161pChfmdSVv57v84g186Sa/ xsfqhE+F//3h1tsPT151zXU/2opcwffuD+68+k++j3bamlrmgnBV7vW0ra0gbXm4dWe9V4YZYfHB 7wvGYaPUssOwQzQaPmlGhz40WuKUxFJdtghqpUSDz/g38WrCqB9VPuMfCFDdSILqQtLAsLZFRIPP +FetwPfZqbbK99mpps332QEBY1IkYUyCpN0wBIUEAq7rGlip29vVlYZf56diPBsfn4HxDD+E27rw 65GbwozSDZfR2x54NyMpBzeFXaYIepttRe6ssBU66d9W6M4KIOBq14rcWZGSBoahk/6hAhiKWnJn hWmQj+WIfGcFEDAUNeTOipS0Q2aDfCyoYIjnW9zV1dzJhtwU5vSzoniOP0R3Er8fcyedekNW7wfm rLEkQUgBF0713clLFkMNdUOuzzINuj7LNDXysSIB1iuSYL0gaeAcuj4LKgBpW0N8LO+3JGlbhXys SIC0IwnShqRdo6GQQJiSO3l7u7p+d7I1cMzhDbiT+ua9yXzyzMviTjooInPlhndqruCHMATi1yPD r3MHBJfRywrezUjKwfB7mSKolbIV8bGsQD6WlcjHspL4WFYSHwuSBn0UyMeKFYDq6oaMSelev246 adGYlO9eCxNRS8akdE1bN31FN/5BBYyVur1dXe3at7ZVCM9SwfWJn9EfjkOoMXq9AM+N9klBEWjG RuZ3M5KS4PmyRdDVyUoYJGRVSZuErCqw995pr9LQ0Ln0VRoaOncfknYTASgkEKECuDiqNeS671bn OYNsVZ4zAAEXR0USLo6CpN1dUVBIIExhenSLu7oanpsG3xC+AM/d1WtLArq7iC3DsZe1u7UtQ5Ak Hl7+dsli6OVvbUWuzW4Fuja7leja7EjAjWiRhBvRIGkQoUDXZscKQNo1vbSyttnHkjW+tLKml1bW 9NLKGl9aCYUEong/5+3t6krAVqYyGNga9O8z+kO8zxi/H7tRWerasFm7q5Dh7YwmHt6ofMliqMU2 ZFasjGqyGTNoVgwEmDFDZsUpaeCcwgSZFStNZsVK4U0WhWbFQMAqjyKz4pS0a7TCmyy6tABwi7u6 GrAVWQBYBGznYC0NbFMLjEia1V82jRGJE1NgX6EYCmxFZsVKWZmlrdCsGAiQtiKz4pQ0cM5igsyK lWzwxfBKovuzlbT5YnggQNqRBGlD0q7RssZE0xaAfXu7uhqwa9kuB2zt99uXw7X2O/UJjzSjriWC H05Jp4qXLILiuaZCrrGQayzkmgq5pkKusZBrLOSaCtlSIdswiIZCLBaypUK2VMgWCxkKCUQRz7e3 q6vh2Yp6OTy3qlkWz61uEBhpxlY2CH44JcHzZYugeLYK3zGsrKmykK3JdwwDAUKOJAgZkgaGmQoR Ct8xrExtsZANcjOVMSYLORIg5EiCkCFpcCEsJmpbwPPt7epqeJbL4lk21izteDS1wR4DzSobYxAE SWLqeFyhGApsSaUtsbQlrCaF4bDC0pZp4SkOpEjAEktbUmkLMn9SAktboPkTECBtQeZPKWnXaIGl LUpTxVvc1dWALcgW8QJguymCXhbYbm6hESJ7WZ1LphEESWK6pXaFYiiwBZ0/CbSBqgSePwk6fxJ0 /iTw/EmgDVSoAKRdWYOlXRmdpR3Pd4lLalpjaUcSpA1JwzKdwYQ1BWDf3q6ufUutdkYdTol+eOJ3 v6zygeWvb/mIZNmIzR9uiakSonY/bddT4bCnNl/baqeVw6JA6e76p0YKs/mGK8ZMjQPn5ptbspXT 1tZ+V8l/sIc36app7Xwr2KX7z61tl7+ttSvrZ+j5v7aEy1Qb68PW068X8bkR7eZ2SGF9hHhKcIqe j9HzPnpGAfuxLdvhQC7fnkMoFefYQc8zpjn+OWWcoB/nhSackSbHjPNCyUfo+QQ9P04s+stWYDSR vJbdcZ9h4/BvQr4+IR8XmnZCZBgzXhQSz4sCjxkfI66w8n4ZxPxhQVo70Msy43Pvd7mMJU1jceBb Hy6Aj7mxJJ4spYY9qYSq8vNuERMx43mh5L1CP1JTd5Zo3sIaM4DqaQos+G+OjyU9m3ACwD9+ip7/ Fz3/njynjFFCQT9De844DcVtw/w7IzyLGXeX4NNTLuO7xZ7y9mHGcYDDbhGaAZCh44mfjwqCeIrE iEtLlrJkEU9QRsoQRglOCoXs8e3PgkvtPysIaFaQxe7aAN4X3HFBiC/GRuwnBYZMxjiWOOM58mis YxcFXieVf4F+nBY6eZ8bpfZJb5fhDlPjMjpwznGE58J+oeizgnjn3MiJ2/Go0KZ9Trw7BYkVcJ31 8oJzRErGCf9+wLGmPFoxuN4vJN4rZLxYKAxk9Gdcwt0Cty5WYe2kwOaU8dlSiRkjhQdcLIqSuZwz w0yW6koOAKubk0K9J4UOsuPlwRLQ+BIyPikkOCk0mzXTrFEq+ST4d3rcd9VNK/3JNhMRnu1E+/NX tFYhXuB44/2PNu599IfJxfzJ/sa9P06E3Lj34aTduPf+x7+eiI2PfjP55utvvvrmq79+9eevvnf2 56//+vU3X2988NHkk6VPohmd7RqppyqeCfM/nMQvCsJ6xEG3PB0rGTamxmdFXDE1lhS9NPE450wm C4M09zwoVFH2Y0acnqNCO0fdrKVr9H7MSYEDe1xG7ABPtvqm4Jwz8CWzMCN1MawoNYxKhHH1SqPB E06+y4wGO1xGFgzXNxsqi4npCLU2fIEfrqJTrJePFY1CETktiV+zQtGlNZ00XJUMRAn963MWw+oJ 9OR6jNBiFRyR7aWd0LK6INGxEnhaaOuMpFlBuVgtKE0nymq1wsgyRayfJPF+AEU8L2g+ZjCdja0g Jba3uwU+Pimwjx05Sk7nOZeRNg+7I19u6ErV/owA2AmQrU7kLJJ1m3ZofeJEHm78cXKynvV1beJ5 /de/JNd1/JMrOkpGGH/PCWr2OaeF5wS1vBYeZzFF0fQ4lhfihEorcTe7cMnaqqcF5O+OY5LXCFzI F/x0eAmOKfld4NiEGxb2l4BHWuZZZiH8nNVuk05i6NTZwNEUgdRWYe1O5Dq1+1vcPVureqN2r1eA 5bU5Bt14Jb6Bk8kvbW04hChjMEJUCpHpSNnUGCGJXCNCVPpk8eVCCG43u8o5X9Vcaf2dMlflfRke aztcxgvORL1ETLgGm/3yMeG80NmTggVC2/QvTWcPORUu75jjjjPuCVaBJwWbwO5zvxgbBWBfnvWK XhT4Hbn87cQ3lFc7lb9owobgq6usduIyK6tcmeHr4+tfQV1iPJNujvRtjWeLIL0Zb3/6biveSCtV 29119W20chFsq4ms7CoQc3/cf8+/V339/Os1LtIb2d3/JHWaez4AM/BxYVngcdGElUyznVairb8z CHmw+Tn08S/56IUctdlq/Dmn88rgY4rWExDXWCVid0NbH1rYpuBz16+c1Pq7dqCQQGj4nDOQ6fin jmziiU9dIXA2k0XnNvlQRl89Psap7R3jBIXEM52aFLUpUsTm7e1miNhcRjXoESZ93XA9cxN+bRu4 xfDnP//5K7/46d+h237y985W4bM3pYUPxY0foSAA1vUHiMhOICM7U1LPo1RIINJX6h1pWovYKU2Y SIVCTPwAsqvA5G8lffUGfSvZ5qRdo6GQQLT564zb3sX1IsafLNw0CDFvIMR8svF//evzF2VuZHN0 cmVhbQplbmRvYmoKNDQgMCBvYmoKNzcxMAplbmRvYmoKNDggMCBvYmoKPDwvTGVuZ3RoIDQ5IDAg Ui9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic3V1ZkxzHcRZlk4CGDEmOsF8cYcXYMh27 Cuyg6+rDcjiCsCgSCtMiATj4APBhsQewwuyB2QFA+E/o3+iJ/0F/CBF0VVdlVWZ3VvfM7hALLkGQ nVPVdWR+mZV1ZT+fFjMhp4X7Aw97x5Ni+pn9+2TyfFLPlPunTcDPe8fTOw8mt+9VU2Ff1NMHh5Ni 1jSNaso2XUyVmpXTqlLTB8eTh1t3t6tZI8tKbJ1s76hZI3Rltpbp8SA9LnxWZSCrEQLS3ePSp5di ayf9+Lv0mN7fTT8e4vd9VXW5Nd3ekUXTzGqztd++VRW1fd+nqwYKcI+HsdZl+nEnPR6lx4NY1BK/ H2vd4ao6TY9z/Njpq/vxKX4LijrG9a9c1Yv0uIxZUVdO0uMTrikLrtfP04/nmNeQ7rhuCjnT5db9 7W8e/GGiTDlrKmNh82DfYuUgvX/GtQ+lo14/5tIXRNbwq4xZi/QjeqxjV6dt+z59MPlqIkU5LbXU s7KammltpouDyeGlNMSIWa2nVSltZU5LbG0P/uQrE1Ydi0IXhSglfrz3WTZpsQF1lVLN6rrTFmcI XOdFrevQee07/4M2Rdj/ZptSlYrK4QdtSuH+25qxO9GMAbKqaGbcIzJu+9EMUYMjCinETG19GkH4 LYv3I051D7BqJX0qiyLhtLYNL6uWP5YDcqo8hzZh06WsZ1JjhnzBGstFbNseNlu4mW8f4dLUs0qm xiNcSWHKyDRTbJRlpSa1PtwS2BDFx1tXzZ3amqGS544ydeKO2Ch36mZW1Jg7krXIRQRUc8V8UtYu aaICVqcbpbTNtvUwtfjL2OJdPIZymtzR39L6YVGBbYZN8lubgho0gXl8tZzVdiCsEWe3vokIVLWp GP28XG01rY0ZZcqqoQOeE8HlR3zRWAj1LJCtz9j32vpE2fgKH06dueX+/cYWuG9F8WpIUvZJW6el rFyxx5aNoo7kfHKf/uDSC5o+IOmQ18CrVV2hV0NqRUkTyMPf2I75DlymmKdtC59M7MDqXLO69mV4 0hQtL3VtWqLxhDaR2LPckYmcW1KolLXlHBTi2egr2AtcVd4FmQNppM/qClE6EK6CQNj32uoDad9r mwZZ20ZDIZ7wFew5dqmZqspW1n+wf/907bvsRLu6vbOgmFWNnUVEldNGgp7X2tnrqpJB59776d/8 7fsffHDj5s+c8t2+Jwr8tqpnWgqYiby3vWNmpSyNnQn86p//6QPrvVkbZWqBU97btj8Wutq68S83 f+nMqeWhUjjHo5MPb7YTiZ1Q/I51o2pfxUePFj//xft2RiTsT0WZSvu1rcy6DrpOP/3r37/v/MeZ 0mWDy/+V/bm0z5UxtGHxsW2aLa6QSnRalmY4mzA2oqkLZGyEaQwxNvCDxawSJHnA1mhts5ai5F50 7IS0OclJ7MxFiyA2RtoWIYWThVBR4aRlbVQ4IILCARkULmZ1DIuFeMJXsAfMVA1SOGH9iahwohF1 VDgggsIBGRQuZnWNjoV4QjU9G3Pdu+pEugrUfTO1qDGeg0uQ8Bx+OJ5IXTQkfQDQtlSbtwIWd16V qqlj6pxmJqC+TDEU2Fo1WNraiCRtXRZJ2oEAaQcSpA1ZPedCIZ5QDZK2VDCkB7Iso7SlWw0CaQMR pA1kkHbM2jYaCvGEr4AB9vXt6nrArspmNWCLppCrAtvqn0SI7Lwq6kYgCJLMBNiXKYYCu2qIGasL maRdC5mkHQiQdiBB2pC15RwU4tnYYDMmS2iGJ01TJGmbukjSDgRIO5AgbcjaNhoKaYkSzGYP2Ne3 q+sB2yjigQxYbFmUK1tsv+wYTS19VYqmxKYWZ6YW+xLFUGAbQ6RtSjQ+mwqNz4EAaQcSpA1ZPedK TBgibd0UWNq6qpO0ddkkaQcCpB1IkDZk9ba3qhHRFBlgX9+urgfsopGrAVvZicCqwLaMNgiRnVdV pQ2CIMlM5/GXKIYCW3gnEaQtpEnSFkonaQcCpB1IkDZkbTkHhXhCKCztwhAzZlmTpF0oZMYCAdIO JEgbsnpvWWPC5Cz29e3qqsAuZmb6GXhGRbkavHsOiSsFfI9OruQltE5D8iFwZsb3uFgxFMlK4uUZ qVSTxKt0Wp4BAsQbSBAvZPVMUpiQeHlGyorYLbffEcUrNbJbUhO7JTWxW5C1bTQU4okqZ6Kvb1c3 vhIl7TBU1H71/b1Hixsf3tzWM2FbUm59tL1TzbQFe73185/evLG9I5qZbrQiCb94/5d/d+Pmeqs2 WM1Es6Lf35vQejXz88hOruSztJPO5NHgzMzc9WLFUDWzThTGnoVKwp59MWEvEIC9QAL2IKsHlEJ+ b6gAsCfIKqgUMPdrTTFaBQUCsCfIKmjM6k0/zEJbgln4ve5d3bya2fm51BtRsxXOcLgOhsrQaYBp PAIwT8ePTnsnmZSBwymd9EMu/Tw99o4nWa8Wbyyi40ev43bkDG88xsdP4pGXOT5iwJ0ZuoUP8jDH n5Zc+jE+JwDpr9mmPObOFPFVnXDnDE659JfszusJLpU5PnQy0qslrpVJR0V96086WRyZooL9hb34 0lPMH6b9uZ1jSA9MEwa/vuSaz5yOIviIu9E70Fi35SB9g4H37VEXBpzoxF0CP0LsMcY5pD9jj/lN MUcA3HOWTem4CYLZrMumdJ7LGjm3/fLfkwe/eWiRH7s0504OLnDrh/XxNdflZa93Xh+gS1O2S2ex S+hIEOr9EYf8vuhlY1BWohnsQaKL6OvTblY7WGf0LQkCKfkpbjWjDzyDEvSRlXqNO8geQWIww3Pl lNPXF1ylPaC6dFTSPncGcpetlNe9ImwVopHlPCLtdYIXOi67F9OfskhOyneCf4yPL7rw6CCVtdG8 DXvJnSs9xYKISP3tiLmfcUasp+edg7dPcVM79s4h9aKDFNMUlH4W7XHiz4LtVBo49tn0PQ4z5Igw A9TXHCfRudwXXPNJ+5j0/RFO8JzaRU0ZGFlASyvgWAecyIyyB7yRh5VGnj0W3L1R3YE7dxSb4eNa ZjqCm5XjkmM5b5ASuB9tsZBGivAkopv39g65uhZcXbvs+28P3VMO3QsOnYe4J0w6sthPh07Nc26f qiTu/inHyWHbja46PI3w7Hs7Hp5MOoL/q5iOMI1s+7OuHB28z3GXGN1csox4tB0z3GKBcJrwveBU 5RwXOzA2roC5425RDt7nbFWpW2Nu85IV6jTCm3VI2JLGJiCoJmJqGHhf3uis5BuuZnQGTDa8kpsM IMyymD/iTDo/E37VZWnHH2HnhEcjXc6xJEL6ZdeO2EqJQSWXQ4z2B4rQ8c3LnxUt7f+U9CsLX4/Y EDRapiGQzMgYG4OYvJ8eexB3/MbjDhk3huE65bSxP9w6hr/gkE3MDaQfsuknHJyRjeldn3A2xBo5 rqyEE74AVrUR5A6jEWGdqXOOQbzlW3CIRu8/44wIOz9iV2lesFJjr4OtYyRg5IuoIZ7dLGHtSXqc cWYAmYkEW+IOxkd22pJr//DIlmbFx+z7zxJqD0aKOuRYyd6cw1DkyzqKsF2ONJv3Z/Y5WPT1VhjE IF6t59Ez2mV7dTyyrHDAofacax65QDE87VpyBmB61RcbROlu1ZVaxBXp3VzrlK701Ci/DI/v2vgr CTal9GPMD3wHL4w+SsyK0OR3fYI2x9BCgMTc1XYoNVK1LHQ7txu8WSNKd4CbcIxfKO4tl3WGEPTW HofmF1zn+an5Ln5r2OVlR05i+Zjh4hw3JT6yaw+HXFFIpK84rqB0voNHIwxk155Y1+Qusnuc1Nh5 7gmXTlpCLnY5/Q1bb5u8QFxaY9GE61zIJWdd6rGxFHmTrBIjfV122eiU9BWWDWOVn+aY8/atsjCm VVjCvZXXD1mndwwPiDusEjxjQTzu1KYxk7BUNnYoCdutTbnRe4TueEQHeqjF1uUbXqh9gn/tLaBc 7c1O3KclJ/DX/euawGVhNjqmKDuYlHWOyxlfh7Pujzk07mJdZdZmiNs2vF6Yv8zqbJ7wF/aSz7IB m2eTq8ASUAXimCCbhszXUUxH3giyefujNrPj1Dubx7MkseyiKy9xfsHaiqvWFtFUrVOLBLGLDBFv 00iTS91MTeGvespiw3EKpItmgxt3ykqBGHeWyxcyw7wzx/htqCh2qXSNswZjvRqaxXVgOjaLQ+r+ kquKd6HQYjIMBe2WKDEWuqnrjS+iuVsFOhy5+32yFskaoGkMmbEw1gLtt97irAXZZO24385a8ItF 7EGPtRzZaC0ejxie1U6CGFHhOD9oOQ716tVIUQkRvPu+9nJdfjXhsvu1L7nVCNYkkPKv2GOpyxlF Nz8jS/biFV1skLKY6rqpvQnebKQJb3tx4/j1+sOeZK1VIMaMlVzXy9BNoTY9s3JXk8JcHgX2SWcn +gvm/kBQm16SBXdyoIhZu+cPFM25vpPwWIxZ6MXsymvNKadg/FS6t/TubA3rjeZ2yjpZ3RrmEduq A8RAOH9Zz7QwDTrvaT11MhWJsnKzj/Zi/9DsxTjfBYl3bPDkjcr4+gyyasPjMLund4CzDvmAO1Lq magM3p2DdpDdOTQ69RFr0896oxddKkDYRG5xzwno7M6t5boM2+ndBL4LuS6sw8Zvfu/hBjKIZVfP 4gq+NWLsyaQHbAFTrlnkjF7Hlegggd2SPuyxzRfFjHRjZ3aTSl50x31oi4idwSGfi0CNMZ4I1a9H jC/y9MZU8iWn3Uj+7PuP2aKWI1BbjBiaXnBKh/9dtlUn0X3jN5DYc49rhYFkkEbO1jC6voZNJCcL B/c1iaiYSomoGPXifdKXmKtMVVft8wXPRDezRlKfjxxgRtqBHs9ien9Rw2/FphlNd99EmxDxwJQb 3TcpypkpSYd4t4qdAu1xgkVoHJho6lpscKLZBoo0sonXQJRnZSViG6ouV68MPKiZ/8t5CQgcz9Pj iwG/1TH4XkzvHyTubBCy6409y+Ks+D3WXj7nLMvY5nrurB9jmnuHM1xTyKm/numwDPicM629QbQz 0/kkpY/t0bHTXX494ZRjMKmVcTfJaTLG9I6fK2M0lPWSzvvWRfngErJpxEbC+4XpZ4T6Vj++n1Y+ 1AUyAZsJ8OcCqqmw7vh5UrA0cUTXYIguQTpyWIgCMQqGiuqJYpXTL1d+rpld2Rm6SuDc8NzkgCkK VfWCswXE4WgfReYwa+bYL2c1Ev/4CcURp1/sOaE93NN3YrkJgTsXVHzYOGUWKPorU24Z3+qnMqZ7 DsYmVXS1ZzOaq5umvRqGO0dmJWQ87Ixn+Ql2ujjGH9dcdtWhM4FmxzP+Lhy7vNt3dZ3mjm0grn74 +ZxN750QcJqbG0WZqsjQN7wscBI197Ib7+OuCaO5u5y5JJZzWLPHh3N2EO1bBu6YNglPzixdkhPb kI6ujbEj1BmbvsC9AxwfsF3qna3u4ZQBZ39tjN48uOzNmmEXT+GFoDVUAs3p2VXW/vcMhAnnIvzF kyufMbTBkr1VfJDQNHaRhV3oRss6uzGdTA3iYw/1pm4ym6tjB8PZi5u8KWH9GXZzlm/KmFUd+2QG mdEML/WxVpHffGW9LPYKNc8Vdi0HlT8yYcD2GWk70yZ2U3Stbe7u1ELVdRsfSQkcS937ETatoX7E D6tH/hMEZMuh/YAEKMJjVlGS+4G06zGXzseZQMPfv/fZU/mAMGVRb2LiJaS2piJ1lJl3WaN2kTjn bQwSY2WMwtcYCZFG7tMfjidCaU3Sh8JWKuPylop9VSiVUuc0Mw0ddYliSEwbU0kcpNRUEGTLrZRV JgUpBSIEegEyBHqJWT3nNCYkDlJqyiJGFHOkaVJkb2NqFQO9ABECvQAZAr3ErG2joZCWCBX0Y9pc 466uFd2vLATEzmtxHKNk3qc/WFiZpiLpQ8B2Wm3KGEiVvipMXcXUOc1MgX2JYmiU/kJJJG3LKh2l XRYmxXIEAkLWBxJC1kNWzzmtEaEklnZVNVjaVZkChVnIpLDSQIC0AwnSrlBssFiIJ6pMBO1r3NW1 gG0UtdgFROW8T3+wsKqNIOlDwK5Ll7fR7Kui1il1TjNTYF+iGGqxFTVjCqJxOZYqbMYUNWOKmjGF zZhCcbqgApC2LHFYaSNNCitth5wUVhoIkHYgQdqQtW20NJgoMxG0r3FX1wO2UTgeKxxzTsAW8FUT KU1F0gcDDZcub4pRTF6VthMxdU4zdwINX7wYCmxjcJBSY8oUpNTYgTZJOxAg7UCCtCGr51xpEJHM X9HubOIgpUZDJGlXiK5SkFIgQNo6hoRsmwZZ20brGhMQxroH7Ovb1fWArSHM4Ciwq1KvDOzK3WxM iKSvysoojEicmQL7EsVQYGuNw0obDUNyy9Iyjc9AgLR1icfnmNVzzmAiBWFsrVqMe+5JPD4rk2KW AgHSDiRIG7J624vHZwVx1nvAvr5dXQvYuqqxj61NWRJgww/Hk7qmyQO4rpt2ultxL9ZVFdPmJCfB 9EWLIHjWIVb/MZDoiy26Rl9sASIIGcgg5Ji1ZVgtMFFgf1OHSdYcSJmErCuRhAxEEDKQQcgxa9to KMQTOoPna9zV9Qy1aHDI7AHXWlVVvaprrSp3Njb6xJ1XrRgq5ASTzJ2I8BcvhhpqKSpsvaRMwaWN hEjTrcOXvrwiEwnWS6J40rEQT4gKS7sp8QqBbtBnzlyY2CTtQIC0AwnShqytgBv0mTOogDHU17er 6xnqugHgtna5gTWb+/QHm66lIulDwNbK5ZWGfdXOQGRMndPMFNiXKIZa7EZobMYaWSYz1iiTzFgg wIwFEswYZPUiDIV4Qmgs7dpILO1ap3DOulYiSTsQIO1AgrQhq7e9GhNGZiz29e3qesAuyVeXtJQ1 BbaMgfSVIMkjn8fTIZR990X3bTudot5rTHU+j3eRIiieywaHJ7fTkhSe3I59KTw5ECDkQIKQIasf a9EXiKACCE9eazx/krVK8ydZS/Q9i1ri+ROQEJ4csvrPJuGPW9Q6M1W8xl11In1uq1FuS0jBcORi CQA596Rp4vduXOZEPp18PT3Z8Oc77bAVNqAfnWzvWD4pt911Y9ttOMpabH24LWZKiMr+tFPNhJ2c qK0PtptZoeyQh/LddE+1FGbrZ7YYM7NzDLH10bZs3Nevq7gx9pVjgWzc8quMI7JtFJBzT9o+x29I 2syJXJcF1QAL7Ox2JkrMgum2sNmr0u0B2t40lXVe3WZufD5Hz0fo+QRefIJ+nKLnF+j5DD2fwosn mReX6Pkpej6AF+m+7Fcb4k2ER+Hue4fj8KHGZYY5y0x/z1NTccfT82G27+FF2nGcOfS9cuEcQtzx A46lLzOCW4zJ4jhT9QnXztUEl55f94ToOnAMv55m6jvKVBM7EIMzdWyAD8QR+PRD63sHYNYmVspK KV6MGpVtet4bk9IyK9L0PO8xewfatOPx48Mlh1x5YfNVHRA9DIbeGFMjQw8kGHr0QTSXOZLeym3E wJdlEeNcvjULvwGrjNu9Fla+Rs/34cX/yShEQoBVDffT/ltg04qKsSCGIjfupOcnLACV0hiAKn7h rCUlrIb5zJHcJACVNzo/OgCidu+CTPD4/2wlmYyMDKcExT8akE65fn3SBaBqISYE8vOABD9PxOlP m1noZj0ADgrSupQuEJlo3KX0VpDzjOuygP4cZ6xKzg0455CxSxAw8mLXf9uI31YKOQvG8ylUhFv1 MtOqW6T7jBvyOFPIEcF0eJE6gXgk5i3bLQ5V5xnNWZDaw4t7mczIUXRs8w7QnOvgq/Bci8bFaWHb vMt5wjl/YY90tit07LguONfjecappk4s8+Jajitm8uzddx6j8swJ7PpS7KONQdgiw6ldIkVG5GuN xLqGz3C2Qy+QYSTWlarRSJzIDY7EpiriBxLf7mRfV7Cf0lp9IOdAIqdEIXIjg4AfzXHfWXcSy/Kc WA4GBLlZ7wEBATsx4y1ffmZ84VFiFUC4szpvyTUbVuj/QH3+NXr+T99/U27dyS46jNhijuXeuOem gGdD48JQ8XHlYT8j2v1MIS/hxSOCtpznkDrxl+3uoPZ7rvGLLKBH5tU5P4GuRozMmHMdmXLqdJJh F2724MDdGe7j6Br7d7aCJFmEUR+Hb/Iu18w8y3NuTmdYdqK+xfcvSf7CsJ1y3lOug7idLziv+Yx0 ZMRDzK165lcHGb9pj+v4CWIdbTN2kRjk5nTljORhatzP1LI3JNluLceZQtjFV7Jq+JjrDC4az1cP SMfYonPKMKK/+MWc9Yjsyw2BebeOWy+dcz3P1Q1F1+0X6pien67AhYi4nAeRbwljEnLso1xgNIZu NjAm4TEnoWXm+cISwh0/5GSRMwPHfc6YNroXW+UfMxapvxOCjcPRmI3K9WTU2csPB5vc7sj7pUgD Drm25ufCzNids0e5XQx2CoxfvIeeP0HPX3Dcyc1VjwkHR31oxJHRjuXEHseE3CYLbh91UC7ozRyN sfKY8B13nrOGUR1W8d1wNaMDCN23ZKxy3i8eYdl+tmS+2b9dfRzIrXqttXubc4bmY2YyZ9pZM/kq k1mg5wJeLHLIf8y1KQfg8740TLmSsaL6Har8gsnsBlrqFTPQz2GVHdX2ufXFRVa2eLzs2J7af+6J tXDsTCW3inmQeT7jrN1ZpkZ60IAByAw1G2Z+aaR7sM4uGetb5jLn8TByXGKZ4fPBWrb8RzIfJxxZ xfzRSQIjg+x4H/UmNzPLHdGIBiu3EXLhGVt+XsuMbrlBmQ6drPCG7MHpShJi8JGbwT8mrGNe5BYa 3kHhjCpwXhH4GleHKxbUhV2TV2OmLadusYM5Hyo3VMQX805PriVDs5E5Z1hOMkWxhmV3pV4zaoQb n11E2OUklOMXuyWWV5n+OEY6lpve5Wcja4xaoy8uchxht09zbj27fZqHGN/WxZhS5laolpyoqYef wwujrOyqWs6MsVYVW5rDTNXs4hjmWN4zZMCXn24NnRPMtTM3+I8ueGPOsJBYzefEfRlZ4cr7Kew0 uD9orXVKYC3Q5Szvt5y0jzN9+j9+8M0p+BowZ7eS8+78yAiRd+dH2v8q03HWcK0yw6SOJoM71t2+ yi3/EMrI/XExoabCP7fhZJuprMLFrOPJnbuT23e/mC4XLw4mt7+eCjm5/fm0mdy+8+V/TcXk7u+m 37/5/rvvv/vrd3/+7idnf37z1zffv5l8enf6FSmzKNVUlpW5bJkbO2rdfiXP78Xe4WYRq4w/S7JL zPJSutsKZbg7sVq/7R/7z7c/Kd58+2aD/Ta2w02J+/0pMQ+82o2ee2EtXfdEnWwsAEvZnqhzCL/q E3VbU/9plfy5vx9BK62CCvl2WjlkK4qpLMp3Ad+ycFKTugJ8PwS8fpnR69xhwfzJ0HJWiKZ6ZxDy cOsb6ONfcHTNcJFN1hW+Xy7rGiLcNI4I97ZNEYm9iS7b21Y1nI6y/UpZS1mnQjxRwf1yTyo4aORJ f8koFBKubJWa3u5qq0e3u5ru7a5QSLjqVcaLbAIusV3jbrpLbKuphtXDAd0wjTvdr9yY3p7K2vr4 44/f+7d//Af/jalwyOn/AWfxqCtlbmRzdHJlYW0KZW5kb2JqCjQ5IDAgb2JqCjcxMTQKZW5kb2Jq CjUyIDAgb2JqCjw8L0xlbmd0aCA1MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4 nO1dW5PctpWOk9iSO6kkW5XHXVfvbqp2lGQo3EHuy1bsuByn4iS2tJUH2Q/SXCSlZkbqmbFlbeU/ 5N/sk/9D/pCrvACBAxw0D7vZGjZ7pB3LsnmaAHh48J0LDi5czFnFxZz5P3BxcDpj84/c38ezxayu pP+nvYGvD07n79+f3f3MzrmrqOb3j2esappGNqa9z+dSVmZurZzfP5092Pv4jq0aYSzfO7uzL6uG K6v3LvPlUb48D0WlhqKac7jvLy/DfcP39vOPv82Xuf7D/OMxrh8eVZu9+Z19wZqmqvXeYVvLstrV D/dlAw34y+P01Mv8436+fJovj1JTl7h+euo+9ahn+fIEXy69q//xCa4FTZ3i5w9+1Jf58jIVRa9y li8fU6ycU2+9yD9eYFnDfS91zUSlzN69O1/c//1MalM1VjvY3D90WDnK9Z9T/KH76K0fUffPi76G X0UqyvKP6LJOrzpv+fvw/uzTmeBmbpRQlbFzPa/1/PxodnwlDdG8qtXcGuEe5rXEPe3+X8PDuFNH xhRj3Ah8+dlHvbfOR1BXIWRV10u8eEPgX57Xqo4vr8LLb5UV7v7by4o1suyHrbLC/H9bM/Z+MmOA LJvMjL9Exu0wmaHS4HAmOK/k3ocJhF+TeH9Kqe4RVq2sT4axjNPaMW5sKx8nATGXQUJj2HQh6koo LJBPSGN5nng7wGYLszk9woWuKysy8whXgmuThKbZqCIzqnjqgz2ODVG6/PWupVM7M2Ro6UhdZ+nw UaVTNxWrsXQEaZFZAlSzYzlJZ5dUoQJOpxsplSu29yBz/OfE8UPsQylNXtJf4+KwpMCuwJjyVpqV Bg2Bke9Ysso5whpJdu+LhEBZa0vo59WeVpdPI7yMsU3p8HwXXN3j88ZBqGOB3PO0q9c+j5smPPDB 3Jtb6t8vXIOHriterOopd6Vc0GKsb/bUiZHXiTyZ3St/8PdZeX9FT8eyGqra2qKq8a4tSR3J41+6 FwsvcJVmnrQcPp45x+pDs7oObQRSs1aWqtYt0QRC6UQcOOmITJ44kstctJUcNBLEGB5wEKUqQwhy AqQWoahvRKpI+AdEwtVrHx9JV69lDYq2TEMjgQgPOPDikpW0pu3r37u/f33jX9l37XB750BR2caN IpLKKS1Az2vl7bW1IurcW9//wQ/ffuedW7ff9cp39zPOcG1ZV0pwGIm8dWdfV0YY7UYC7/3rv7zj ojdno3TN8Z237rgfmbJ7t/7t9s+8OXUylBKX+PzsR7fbgcR+bH7fhVF1eMSPPz//yU/fdiMi7n5i Jrf27+5hLnRQdf7pFz9/28ePlVSmwe2/53427tpqXTKWLlvWXHNMSL7EWR7hjGFshOI1MjZgQpOx gR9OZ0Kxpri/wti4Vl1ZyzhZVcimTndPysKFsblKM4WxEc5fIs0TSvOkeUIZljQPiKh5QEbNS0WD 5GIjgZAN0jwhwQRG0pikecKPnkHzgIiaB2TUvFS0ZRoaCUR4QGFs3vRX9V06BPOs0nOAt2RmGLx5 w0Rx37fy2P3MRadUAhmvG44qFYULJF+lmRLJUmAfIqRscvdKlX0IENC9kYTuhaJBSBITAvsQ4UJi 3L1+UJa6V0Aj/gEiPa99vEjPa1mDoi3T0EggLOtB8pv7qqO7S+FCbVaHIcJbn5/fcv5LVdxxYvZ+ fGffVsqBvd77yfdv33IOqalUo2Rx46dv/+yfbt0e2bVY07yi7q1wLUE5kk9Yqho0KSsWLkwo5Ks1 UyqkbThGac1ERmnNRUZpJAClkQSUQtFWctBIEGN4AKDUABuB1A3LKNU1yyiNBKA0koBSKNoyDY20 RHwAoZBv7qsOdS2REcmGAVsIZgbHTCFRmoKdsqrgjcHBDi5cxkxXaKYEttZFb+sQ60eRWpl7OxLQ 25GE3oaiQXIGE7robdUU5ldZZH6VQeY3EtDbkYTehqIh+rHI/MYHEMB+c191I2Dzpi6ArRtdAjv+ 4OQkeXF7Ba6V8rENN1RFP7aCeydFyQLTr9pEiWfGik5mHHWyG2flTo4EdHIkoZOhaNtz0EggGO5k 3sgGdTJvhE2d7BxKnToZiNjJQMZOTkU906mRQEAg3sHzm/uqrzIG4M3AOKQzxA1jgDCyXCqVbWg7 DM0WFhcmRrOv1kyJZGfUcfe6ODZ3r6uYuzcS0L2RhO6FoiHalcgPxweAueJFHklwGA36RjjKIwEB 5ooXeaRUtGUaGgkEkTp70191/DGAG7ELdc3GAKwRw3RPWq2HhkoOIBrFOEtVpVUaKVZRuMxlX6GZ UiF5sI2AUi50RimXKqM0EoDSSAJKoWiAXmwkEFxilDJdBMZONBmlTKLAOBKA0kgCSqFocBIKExCv dBTyzX3VJ6tBN8LKEeXTwm1S+1dpIklJMXcBS5hIQnO1YUor3Zk32104oa2fTc4cPohLkfx6CLRs q7jc8H5Y39Rf1M+9oqVKxeVV74/YVP990ejyVzw/q2qZepNry/OcqEOgmpuYNXJxAatZIk8iySE5 Gwon8snsL/Ozq83oK+McAMZmnuT8dAUOFyWjjm8uC75bEvFdvEbge1tLIzwPtLb1z5P7ETjmEa8q mVgX3WixWtbFYVjMGjamWhTrEq+1BnbVroAhV3aAhV3MpGEcIVsazRGyA5mgHApPg2znLPyq382h XTC5Q2hHR+icsQ5LKP9WOkJmVHSEaolDuDN3bU3gCBOHD+JCWO/I/ju7rAu81Bnuz/OPB/nyYbpf VOo4h/iGyoUr6urrZbhPstZY1N0FM12hglXnWmKrHkmw6rEaWPVETmHVKegMsOrwpmxnwIpWvQBW MlqfrVmXjdZ9r1tneko1hdaFXxL2McrAsGYM6LXTaq8AvWikAHrRzgL0ApmwFgpPAz0wuxtjr2By h9iLZpc3ce1cOfzQTVoqusSguwMr6iYZfgCDWxh9dO7vbvRRazHFo5YdDHRzO/pQ5eiDGYFHH5GM Bh4qxtFHJscbfSRkUoOPLgoXJZ+nyYwJ5KYw28VbTOGmCFVb76WSInYsxWSKGL0UVsTXeES++6FH UjplB1jXRfIYAvvAhOuWzEBuC0+Ea/CBmwK74HGHwI4ukDX0yEPXdUOn4HQdphq3vo0qcGiappI0 h6xnbKRrWIc+iQyNk1SYZ1jm0IqeNKa7Y0oZXnllfggYUnc+iJsEvcevsm/n+bJCw7Tdbpyoa9/D mPc/ZDafJjYf5x+f5MvL5aJL4T3asjJP2yJ/Q+5Ye57qox2saDMp2gv2kNoii4o+o1iB8U1t4nbi zn3cD1aapIWcG7M7PWyhlfXwgRMf9MnBio7w95/lH8+6AVjUYMnUGMOspp31w3zOEcQTH93LsLEx sdZvRhYpLKlRmAUkhFmxzyDMSuQUYRZlzgfEWWDsO4mwLshABnWDMyJAJhkwVciATZcRIR3GEBmw nlFpPw5q1hQyYDjXD9YfZJDIKWRAuaQBMgCH1cXB6A4rBtbI6MtsCSu8qw8sZdVnKXex2dT45cWY +3uJzy97nAvhHFDG6nLZT/n76KSDY8qPfZR/7DsfAZp6vsaPXWBWirBdui5Pjog5eYyxe5HZyhb2 qpsS69qecTCHPQSNOUljLjmLyfva3/+E7OBHVCKUDl/yARQvd71T1q8aKUJ7qveXre5IvZ9MY1/v m8G9XyhSujyh1OsR2SUn1JklCB277ii/ubER2J0QHdVxDYs0yIWtdHGYXuNRe4qLQuFpwiQYtW8c JxVMDouTYpUGp+9znBRJpgohTBInRSFsHigVTA4LlKBKUwiB4anjHBmFwtMESiCEjSOlgskhkdJ2 kw+2oddQaTfs6UmPmLD4c6JJjMzhzSzGNmYxYj8TsxgOigrNYgAJA5JYEWYxEjnaLAbCJjmN0cHh omT0NA2kgO+WRHwXrzHFuIrStgHjKtDFrsmcShdj8FPo4ms/u7DTiQzQO2oig0A2uA2FHWFCdiAT lEPhaZANjnBjaBdM7hDa0RGa2nsbIgsf95oRWXgdTmKZylX787tIDlXY3k+4amXFuIOg6JOTsHrm CcT1nSfAvH+I08vAJjpq8zxfotmDl/gkRxjVfbAmeY/yI0fUmP4rcixIHkqJhu9nFCsPqfuHK+cJ IsbJeYLJUB6glVD+YO9PqU+er5knOMU/psv/Sfef4o6m+jTnxD7E0lvdZ2huaD0miD5BmECJoFMq 51ZMExEpH2J2JFoF52DYGNMjQqpK4v6hxvIdewMhmVEMh2SRhJBMw6aUUDiRU4RklN0fEJKBV+gO 4Dr6skhVNJZBJEEGsbtABomcQgaUZxkgA/A7Xd89ut+J8Sey3XTyLR9tSyffPqCVhzLTl5TKP6T0 8Kyrp8Ua/0dkfdIjHOb6xXJWguuNzi4u408apTEgA02NMaViOMRMqhkKD9TULaaCY/S5sRYX/A/T YqiisXySFgcyqW0oPFCLty+fjTW84H+Ihk//bjEsVjUclLyUwZK16AncZT3NSc4xpEkc3mSwtpHB iv1M7AJ0KIVzW4LDskWcEStCBiuR42WwMjbJDFYHh4uSUQgVMt8tifguXmOKUIHStgGhAuhi19BO pYsxgih08bVPK+00gwV6R+wCpJAdPQogO/pLy7H7TFAOhadBNvjIjaFdMLlDaEdH6A9Xran8kGhs T35Ismm+IxA5FHVFLnQVvHO2emRQ8LGPoA4uOcmqJ4Elr3ECC/H+SWbzWWLzKzIZUuQ9lpMV5cgk J0OKfXREhgINRy7JormpdckQVL9Yi0QsSiESWBHibQJrZyAP0AKQ43Wu57if0uWX6T7qnMNugBPV w69zHWHtVFznmnSRSON0tG6R3LjBcUkkIS6JnQBxSSKniEso4zcgLgHT2B3gdFCTZMBEIQNWbJKK fZVkwKfbJEWZ1yEi4J3PfmzL+MYYDBmwmwV0u1xAl5WGMAIdBRip97N9pDvfXjGF9xV2RKuz9uSG 7gPqPnKU98nOzT7xaNeL7mr/eY1N7TvEsgZH58m+BzIZ9FB4GvsO0fnGBr5gcpiBj0JgohACK3YL Jose25/EwIMQNrXwBY9DLPx2439eV4LK1PFwcDgxQInnmk0VuwGDN4m6bSTqYjdTS80EtzhRF0mI omJFSNQlcrxEXUImmafroHBR8nmagj+LY0HEdvEWU8SChKoNiAVBEbvWcipFjEECVsTXPnW20ywd KB21zozANXgMi11gwnUgE5BD4WlwDS5wU2AXPO4Q2NEFstq/BZEDYwq2oy87aabZhE5aNx5jBIeq 0Q3tpVVjdCnDkbJ0SVg9WTp1jbN0iPff4OwOsHm4eZbODX7QzvM8Mv0jmXp7QdWnB7H5489oPH2C WyWauo+bIu+nTljMeKN9ACAl9vKRBP8YNeAkFk7kCF4+rl1CffKEfjsMnZhajHxwyevdqWarD1k1 Yb+oB9LLDBl0IN4ltZ7xtBOTgVKPuocemZDu4LNrLBYlHCCYyuhoyQSHJbBMEUxRRntANAUmvTvu 6uBmkaoURwNEMsoAOivKIJMTyIB0C+tlkJxGx/GO7zRi6IiU/CbBtMUEU1YKIsPUAfg4nYstIN25 9ZrO/STdf0h2bvG14ixx6v4jatVdkfol5rZ2nfp1EXzFzeYmOobRstiNmkx0IJNNDoWnMdEwLtjY RhdMDrPRUKXYl5xsdEtmo9wWnshGRyFsbqQLJocY6e2OPWrr/9fNEKrawm7UpW5Sdc2nDMESh69h itBPw1+DHMWKFCH0M7GWz0ER70YFEmKhWDGmCDM5WooQYZPKEXZxuCgZPYUYzuDdqJjv4jWmCOko bRsQ0oEudkzmZLoYg4FCF1/71N0us4RJ74i1fBSyo9sweDdqRnYgE5RD4WmQDY5wY2gXTO4Q2tER +m80U0vllG3gTMhlV20bM6WrNrbS1G5UZZnpcdWWi1KG46QJs7B60oT6+qYJMe8fZDbzYj6UEEQ7 H8+Xiy6tOiFHIetOtXyfHOVc4ktiQIQGvngT5PIKPQBuY+TukBvgkpDbs8O02AAM9x+S/ZC/VYHS uWi0+Rec5CX6Ae3Kzf34ghy45jVPT8h+Qk3lrMJFN8KK6sk512OsJuQN9zuLkDkgxpMdxV+kUAKf gAgkxEa2wScgZnKK2IgywANiIzDP3ZFUB+SLVAVvCwUyyYCZQgZsum2hpIkfIgNmepzo6A4gBoLI iNJZIUVnha7FKZCY+3uUMT8iL/Npw317PonU4h8pe3NItn/RPcUR0G35KDvKpeWVwO9Pmo6u2kCo hs8Ey6YjkMlWhMLTmA4IPje2HQWTw2wHVMGbUbPtiCQzhRAmsR0ghI2NR8HkEOOx3fjWBQuS+rqL MgLOg1nuJiPslHFM4vD6pKJet0/brUpFxX4mVqs5KMJpFsHh8SJOiRUhFZXI8VJRGZtkKqqDw0XJ aAo1OD6FA/NdvMYUoQalbQNCDdDFrsmcShdjBFLo4mufH9ppKgr0jliwRiE7ug3OCkfI8akVGcqh 8DTIBke4MbQLJncI7egIlfVRGpHo0RK2lS67aq3klK7a8cFIDpUWPa5a6XpKGQpLsSdN3SNAadWU AuSmIuUn6p4P2bk7S58ZGimVl8DWk8qzdCovRR+/o3IzKHdzQqZxniQzRR/JfX5t1l5w5y45lhM1 Zuqo3yK5S7x9E0jw/1Gfwf8ncgr/TxmZAf4fTFB3tNArA63w0RpAggyixQAZJHIKGVBmbIAMwMh1 HUXHyC1SFbxtAUiQQTRLIINETiGDjqEcIAAwo10QdMwoCEBavIcXSBBANHsggEROIQDCFA8QARjq LgZGN9Qx4EWG+uYkNorVoSexUZbqyr2TTMnNDuud7rBGNp3w0x37PJJuBiPa1/X6OufCgfXfrVl7 eUJ1OpoYI79RRH/gmzztZBTtbnPm0Ts1big4wnSbbLT/8gj4SQJUHZ83EqjAMd2sqt7mqurs/4mu 7fjyRcoV4G37Oa4PZArkQ+Fp4nrIfmwc2BdMDgvsYxWFTxbLgX0gUyQfCk8T2IMQNo7sCyaHRfZQ BW/czJF9IFMoHwpPE9mDEDYL7QsOh4X2sYrFpzfk0D6QKZYPhacJ7UECm8b2BY9DYvvtZomYqSx1 fIPiTc+3npVgU35jNnN4fWbEtpGP39H5DdDP1OJsUcO+tTgeLVIIsSLMiCVyvBmxjE1yRqyDw0XJ 6Gka+Rf77RDfxWtMkQigtG1AJgB0sWsxp9LFGC8WurgxFgdNJP9/mREDvaMWZxPIBreBdyllZAcy QTkUngbZ4Ac3hnbB5A6hHRyhakz364/BEXI4w2HZVXPBJnTVTn38PmyCQyZZj6tmcuQvNAefnIXV M6NTr5nRQYcnnFAzOmgp9Gm+3HU+gwvlYj388veyjr/EqUdijyh51Gq5Ho87PhPepNZjrMfjxlYF uokhaAfHyZEyWThSJgtHyovNWomcwJGS2jrEkfKez5T2y4DzYjVzJEEGUfVABomcQgaUPRggA7AW XYs7urUIUQNWmJuvKw/7uvKGCjtSRyVE3eQDt5kPRJpLdG5HC1Pwx2QR/DFZBH9cFcHfJNY4Bn+b m+OCyWHmGKoUK8STOQ5ksr+h8DTmGISwsT0umBxij7cbX1oDX70uU0GyUT1fjZaNnvKr0ZnDm1TQ FlJB0M/U4mgmi336kYxhD1SMqaBMjpYKQtikUkFdHC5KRk9TuIb36WO+i9eYInqjtG199JZ0sWMy J9PFGCsUuvja52d2mQpKekcsjqaQDW6j2KefkN2SGcpt4YmQDY5wY2gXTO4Q2tERGuOXY9LhmbTx y0BuZN2ME3z785b8rF5Vp7n41jdZnqJsq/d4vkS/7jolYmTrmBHz97Lj/DJfPqf2ZKOvpuQ92WgF 75wsetwJ/N3A46OsYefUGKRY8LR6MFmsUcPS1U4q0jTh+1iMj/LdFl5rv6QoC5CCnIlHvWfIbRf/ whv4tjN/lZF2E3CN8ijFt+d5loo2jd3ao7xSSAcjzaxDzv3DFJGP2GvWoe5X+bzZdiiiBXw1aZSV V8rP3tcZ8ZT2aTHl5xQU1/Allb9hMw/L2VDmHJnXfDDsk1Xm1dX/j/wjOlgWWdozynwWeWy4/5/d FJDEKz/nPfc3KPrq90Wju0W98m2LlUneivuXInRv4zatJcSzVP9v5QjRq5+SdVK/ESYnQP0A85T6 KTXlUe6KaX+CT7/+3c+aglQtb0tCmoT0K38UDoU/qyKhMHnUkb/UrTCMbnKy6KNWVlcKQiRrc87o 3REM8lLwYxJb+UyK4hN/rxZ60e++g6XL/jSMdfJAiWk0A/FyWa08bOjjfS4otSMT18/JR6GiB6ko fczTU8qsn1EWoO8+apVYm02uvd7AwJXGhlufDo1o51aMEmuDtUndSpkbNxSd0Nv7ld98lblBc+KH +BLMCZooRydcXaT7yAat+iDBUmddULiiOxvPrVCdXRzIDEUPu0XdGC5P3V2QTWVt+RLzly4Rg79e o1iXa+5fUFJZt33ggmzqcI2A1msT4e8vKEOK+Hu+6qHt5qdh/l6YZgv+PqOe0kBhpzydWLoBOFsV cBeZBxQwE/kKFBA8pTQQxQZImZ9RfYkARmrY2TKAlrCKLH/heoiFKajWMeUECq4IrBfHS23gT9ZF DQSrGxyKVWwLgvsLUsBPKVYKE0doIDk9fYlFsTxTXu45HKqBbYJo9AFvRj2lgf74vwl9oFXpxN+u BjoN+iPp475K94ujHdMlOSRGRTtfwtFGYgCjy6t7k/YyDEmJMI1UiyIMJAz7MxLrCIEP05CXRmh+ 1HNcCbVKsHqKpdZecr32CNH8JDSCeEY9qc+C9SqgtGLMYTalgIxtwwUm0JMKyKY89Vca5U/77FdA 5KyQAh2n+3RkmV3gJf4R+b2lyNArIIpRio3F6wCyOsZCe0D/lIr+If/4BwoWxaKydPlyLdYJv0Ir ILkC6hg/lQgMjrKAyCASSe0F1RR6FIrCyYHoV7g+oYHnlK0iXTgRz28QhDqkb8MFJtRTGsjElOcS +oGuXqWB6IQbNCJ8ucYFkkHqC1IDQ1FdNz1Llslh4BnudkJtUPtoYd9TSoMuKFhs4C2ekEXXDU4P KLXphNb9QepJ5rraYta3dxi4lVRzVwNFI/k2fGBCPaGB7plTHogmlYpfIu/RQDR2Ky6ven9ZA5EP HBtARBA60WTI1udd+BQvtUMFrJXdhgtMoKcUsNZTnvcnpUpnD5EKiNaVFHOccB/NhiJvebicHEEu FMVQueiSs0AxUvZb9OQFOQoiMp1FOEafvkNuUiBPP6GTI8+yrsfQmhdLAS7wUwmuD6i3PiYfdUCB +bDDSulti+wWCjdWx8ukBj6i+F8XZL6CBlojtuECE+opDbRmyvMspVDVqqmIAzLGJA9k3OBjGiin Sp45tVH+n+hK+hz8rKsPSVRnBUSq8l9XcLZb8oADcorTuMANZ/teQQGNrbfhAgH0lP6ZesoDWyVX N4vutvOom0V3V1l0J3Qjl33fGMtOQAX5ch60VT7N9dKi16urmBtUpvMrYMWw1WjxMZrsIxcvIx+I 3F2ebkeO79ddd5fCKT/Ku8raiv6J37PseMh49GvqUfQcN5l0XZVn8VrWtwiA8NyXuCm4f4orLRfl eu0ylnVTNWSis4gRCCXLkqAnILvni/a9Pr2wYX0mO3rDfWBs3/3fHz7muQM5OSA/olLyaDREpuRf YqAS95/h+0uC9ECmJ6py8veEfNEsk0KQy+jyQCbzyMWCK6JP0aPIiSz6UNoMZHp3ODl9N1+u35Pb zJdco/d/TL5/ftJlRyhDOHm8OmO/bn3eepNAQVLAYxIic/iPTCcC53MKsSibfUYhsrukwjP3gkIk qVrrFvLMsUQQjBIiSStETnjSBmPdhCnq0oOEyL6hPqFHHakssdJdHVIk0OjFI+SG+8eY/3XgWplA 684slwr1iLx/TtkGxN/ne8u+15etcqyD2qrWoBsMLrzzRpEDSjQh+B5R8C7q5ze5k/BNnL3gLn9D 9Q+S/0UHdO15XAhpqx0WaZw2mKIpoELglz6TmlzXSh4jvnLtRcn1Y7LoV5RWrlubUdwnAH6PavSA 4p+eRD3rvJ/rNYFBmy75Mr4xQFwthppKAf6DuVD0v1+4Vzh0Q94Xq5Zfuys/ecLgeM6a12kN7cns XvnD6YyzhhX3V4yoOfebQmXNyaq83Q0d756UhU9mx790LxZf4ArNPGk5fDxz0vM7EUTccRtJ2Q5Q VK3bXQqRUDoRB046IpMnjuQyFw2Sk5gIDziIUpVGQL2W1CwU9Y3IcBBueEAkXL328RIOyQ2sQdGW aWgkEOEBB15cspLWuL5+01/Vd+kQzAdGtIXjh1scRzIDG91n5f1Vu51DWQNVbW1R1Xi3FgVpusC+ SjMlsOP4HnrbMJV723CVezsS0NsGzpgJHQVFW8lBI0GM4QHQ21oa3NtaqNzbcdgfHhAJ6O1IQm9D 0fAOsZFAhAcQwH5zX9V36fCsTD03lW2kn36PuRKlBeRlauUPsvEqGvckv/X9H/zw7XfeuXX7XZ+j ufsZZ7i6rCslODi8t+7sO16F0XzvFz//5x+9F9JWS0/cj3X2BWu32vuKnztX6tAqfTR06473oqLm ez+6wyvJuXU/7duKKy3l3jt3moo5MXBU7ra/qoWLY991zehKO5nt/fiOaETVGBtYsAXXrLLS1NlP c3fTGh+GuIYaq+o2/CKvn6Hrc6iYtix13jU+ad9qv1l+kpeNiWz/xyen5zxc+zO2eTMXVrbr+g9O Z+9/PLv78Sfzy/Mvj2Z3/zLnYnb3d/Nmdvf9P38w57OPfzv/7tvvvvnum3988/dvvvf879/+49vv vp19+PH806JNZqRP0Ourtjk0o7gWu5JL2EX7PvTPOeq0h+j6DF0foutyCxopSxeNu/fmfIP3dn/c P19/j3379bcjvrd2L9wY/N4folf5ugfHTykcH6EfL9D1vA/fonEAdK5t3z9c7V6ZQya5VwtfDy6d gnKxe1vB5oKZ64Bv5yiUD9Es4PsB4PXPPXr9GF0fDcGx86SMN/baIOTB3hfwjv+bB2yfzv4PC9fb vWVuZHN0cmVhbQplbmRvYmoKNTMgMCBvYmoKODI2NwplbmRvYmoKNTYgMCBvYmoKPDwvTGVuZ3Ro IDU3IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic3V1ZjyS3kba8q8NtwfYC+7pG 7QV0G9M1STLP3Sdda8nQwDpaMBYzeqiuPq3qY/qYntk/4X/jJ/0H/yEBWjKTR0Tmx2RVd02P3Bpp lCwyecQdwSDz+SSbCjnJzB/3MD/ZyCa/1/8dbjzfqKfK/NNW0Of5yeTDnY3HX1UToV/MJzsHG9m0 aRrVlG29mCg1LSdVpSY7JxtPNz/bqqaNLCuxebq1raaNyKti8yo87ofHi66pKlzTQghXbx6vuvpS bG6HHz8Oj+H9WfjxgL7fDVWXm5OtbZk1zbQuNvfat6qs1u939apxHZjHAz/qVfhxOzweh8d939UV fd+Puo2GOguPC/rYW6v58Yi+5bo6oeMvPdR1eLzyTclSTsPjIZrKBVr18/DjJYW1qzdQLzI5zcvN r7e+3fnDhirKaVMVmmx29jSt7If3z9H8SD1Z9S6qv2C4dr9K3zQLP5LH2i910s7vk52NLzekKCdl LvNpWU2KSV1MLvY3Du7EIYWY1vmkKqUezHCJHm3nz91gQrNjluVZJkpJH7/6fbTqYg3sKqWa1nVv LkYQmMWLOq/t4vNu8a91KkL/HZ1KVSqOh9c6lcz83YqxD70Yc5RVeTFjHolw2/NiiAsckUkhpmrz E0+ELyG9HyPW3aesFfipzLJAp7WeeFm18NEQkBPVQWgdMl3KeipzCpAnUFhe+LnNqdii07x/CpdF Pa1kmDyhKymK0gOtyNYKsjJnoz7dFFQQ+cdHbxo6tRZDJYaOKuoAHbFW6NTNNKspdCSUyJknqOYN w0lpuZQzFtA83SiV62abT8OMv/AznlEdiji5x7+ltsM8A+sG64R3XmRcoDFifLOQzbUirAlkN7/1 FKjqogL8ebfRaj4a0DJl1XCFZ1Bwd40vGk1CAwmkxyv0e+14omy6AZ9OjLhF/36rO9zTqLgZw5R+ yrXRUlam2xMNRlH74mLja/6Dqc94/QimbdvCvVrVFXnV1la8WNjiwe/0wroF3KWbo3aGhxtasRrT rK67PrpikbWwzOuiLTRdIS98Ya6hI0NxoYtChaYt5FwnHRi7AeYWqqozQRauWMiuqelE5bZgBrAF /V47vC3q99qpuabtpF0nXaEbYG7ApaaqKltc/0H/9+cHv2SD2uXlnSaKadVoL8KzXF5Ix+d1buR1 VUnLc2/9/B/+8e133nn3vV8Y5nv8lcjo26qe5lI4T+Stre1iWsqy0J7Ab//1X97R1puWUUUtaM1b W/rHLK823/23935jxKmGoVK0xbPTX77XOhLbtvttbUbV3RDvP7v41a/f1h6R0D9lZejt3/Vg2nTI 6/DTf/zz28Z+nKq8bGj/v9U/l/q5Kgo+Mf/YTk13l0klejMLHs46hI2syoYIGydCvbBxP5xsiCaT rH5E2IjG6MQqE/BVUTfC1y54YyZs7tINEzayagThPI046TlP1kJ6znMFy3muaDnPN20h5zrpwNgN YDlPlm4aXbFoMs952qzNPOe5guU8V7Sc55u2k3adtAU7ABM2D32pBqXL0LydiMqWI2wps3JZwpad N+sosveqFE1JSJA1ZoR9l244YRcFw3bRCWQL0koFbNuCw7YtOmy7ph3kSlooGLbzJqPYzqs6YDsv m4BtW3DYtkWHbde0nbTrpCs0WYSwH+5SVyPsXNRLEnaeNUsTdi4aSpH8VamamlIkbcwJ+w7dcMLW Hg7Fdt7hxoE0C9i2BYdtW3TYdk07yNlOuoJqKLaVM1ptsSwDtk2802PbFhy2bdFh2zVtJ+066Qrd AICwH+5SlyXsbFpMnEGisnI58h4YJKYXZ3v0WgUroTUagg1BGwPb43bdcEpWklr9UqkmoFflwep3 BYdeW3TodU07IClakNTql7JicsuE0Tx6ZU7klsyZ3JI5k1uuaTtp10lXqGIi+uEude0OjtRqKKu7 oM5bzy7e1R5HPhV6JuXm+1vb1TTXxF5v/urn772rXYhmmje5YhW/fvs3//Tue6s5A5TNRLOk3T/Q Ih2bdcK71yqI9lbSB8FPGwOFcbtuOJtpI4rSniaVQHv6xUB7tuBozxYd7bmmHUEpYvfaARztCeZc S+EErulEEOfaFRztCeZc+6btpF0nXQHEEx76UtfPZlopyvx+2Szpc2eNXI73VFUUy1pwmkAKYnr1 XlVVXhDGYo15gO8O3XCGFEJRKhWyCFQqVB6o1BYcldqio1LXtCM920lXEIpSaVYwR1SDJlBppogj aguOSm3RUalr2k7addIVnH8wYMiHu9SVXBPR1MznLpqCE7b9QcNJCVY9Qtd5biwtUaIXTWzO1S1Y S0bTt+2C03PmeMIWBfE/M0n8T1twSLZFh2TXtMOcoIVMECSLRjUEyaKRlUeytjdrj2RXsEh2RYtk 39RM2nfSFZxbMKDnh7vU1RRMMhfEaLTcpRqAjKizkMZEkptCqsEc1l/2UxHMj5NB0y7hxzQtSqU7 JRuUvSygsYQiV09SGeaDJAHZFCSB4QoOFRIgTmH9ka8n44M0qPYt01Rbe3SpMPcJdzVDUz0eAEAU Fn42y8lVkySJD3z9/8JFwSymCZ10mzClyajIKrdNcYle2usvvzf9M1r/hnd+s9yQPaX+GaSeI0Qd ZM0vUDoaX51SlZxoidyKa6WNEb+73m36lqJqRclrz3KyHK/N5Nyu2SXLaY4/9hx7Etj0OjwuEEcT jj/19SRx8mzQVcgjKmpGZjCvD+ME5g0S4jpFdHgAh4LZjGRWM8Rch4muyFLP0VTIVA9Q/Slc1R4C 0CWjtFxpQsvqlpqkqNeaVWSzUCj1TOnkedZi1m23kLyCNRCukFNRuuReT7ghOZdM4v4lSpWZYAid 49eB+D/1zPHH8OM34fFzX/8xQ2ihl1003T6W0nbFGvEpsnKqLQ46YaKfd8Pj/oAF6pJL9QB/RPdn hFgHWbpcqQVVtKDEvpxWYQm/M8g3e5RxgTBnEwSMP0NTiUmDcQNlggB0AOvhVOcQQEFFvYD1FwgX ZKjvsAwCBsBN34DrgWo3PL6KpY1qutPEXVndt770Zi17XFyS5PsfIQVFSP4S1ZPzAHuo/mLQVZDP xqTFaIAQI3xwgOoJyR8Fk3bInTFdeluK6bGEMWnJUHuUTsBUTlE9tr6/C4wcAET46Ia+Bboiphq0 nhksAUkfIT57hQZlIxFTcNyQ3kVY2Yeg8oyy7eZoknBkN08ncGJuGjHazhHN7lGadfVE4L+CNH3l afqIrgNA5xLWB5TuwXpybmJKCKkFgnaKZSEm2zLzSUzKp8VPAzhkeCS/TryC+iisjMArWK6X4Udi 5MLTPcdQRgwOCvXwPksAaQ/p0q8SWgU7iAHehwGyb9RC6qRzqf+nZCed/ycg6cwDeShSzeMcUTqB /IuE9B4cljKUTDhu3q+Pq35IyaTpIkjnIPJuYNNQfw7pIehrMn4sIOCk8ymc9QKtao6mcgmHsr+K YvMR6gkafDeJRcVmAoTzKZoecbROECQZpIBGwVGeiD3Wd7SKPOs8etHkfZe+yF1e9Ws+LWR5Khd+ i8gBkvEUYQQi466Ry8+MG1dPGPF8YPwEmPWCeNcUvUBaMRsU+OHXg6aGp64Q+UDdCmwLVo8pZeD9 G54aq+8NBSNCBFSvBl1pnlog8oQGD/aMoO2xoO8DnoIxSLi82wbEwPyZDzXgKdVt20KeUrK8xzBZ qcQ0szzlABnjqcOERUXshisURhs6FMFvMjw1VC4c/AcQ5jBMNoxWG56aIkL+I1J52LQ9Rux7PjJr w1PDGH101mdoKhNYf+B5KuUkhEljZ/gA0SwLQwKemqDpQ0FnJ1W1ringOSBytAX3FWpK9Bj0x1hs c8BzUrV8pVReDnjOJljclx7T3N/YYNQHgeeC7Uc2mwjPBM+dKDeisp4g25CoPEI9F57nhmLaPD7b 9BY6wcQH4fGJr3+2FWEVQhaAlCGDn8D34fl0bJOmaAWS7RWqZ3tUWKmltAKYygr7UeeI7Za3OVP7 VYyBnCiB0a7/HuUqmx0ENZkoqvvUZLq6KgeabB+5tS/CY9gQSmk67JEtKHUATQaDqViT3SBGIedI s6DJMtQUBiOv4FCQJ8c2bIwmGxMFcT9ygXhuaD4xTYat6wvU0+AijbF4ImApaEdfounvQ0ieJ9xE qPRwWGQ6ZK+sO7CpNM7XcjY3r4wHFVgFHM7Nm7rubWq9Vr41R4hyG8feCXybimMHr45oQ9YU8O3B oKsgig3f4vADVEADC3YsUuD59ibR1T5iARaHHtc6hDHmnm/x1k/gNnwNRhiKObiAb6EwgTE6HHMJ fMEu6CH1o17dCgb06oEgDikWHgOQGirIvG7qPgcHTsvu57IVy2h1NrWeniMu5ukxUxPwEY44zpAn uBiwZICj4TMsv2HeEtQkC1h/FfgsHQcD9TBLAYfxGcsBTy+lalMxjaHNKKjwwHsT0Pojg5706bhq E2LIoKOe3lCicaMFSzQY0sH430csiViqS1BENqeua+7R5iyqdruK5lWx7SqsusJODFFNLIFw3GSd 9YnPsBRmiVSqQToi4lkqFWeAhhQhlKsk9fZoxrAU3oKEWxOPEM1hQgssFbQAGR6mIF0MXueLwrHF 3aVNzhVUE2CJSrZkL+smG7BEpfL71DJle99hyxPk7sEDT9PEBiPsEYIfhBHI7iPc+Lpdpm0APxH4 5DHojjn9sU+zhidOEU9AQlyBZ2Iax/HEMSSaiPAkowIjJuGGxZJax4MkLxMB2WPEE/+X0F0p6QH3 5bHMgzsjgKfKPI+qmbLI7lPN5M20sTzl5sxcJJaSTtjL1RNGuaHsBXjuaMBewUTvhTaYlw5oBkbL 5rB+HngKOtwscghE7g1Cb0xk93iil70+sBJNlJNEYf7TPrYZHJxiiu5gt9DvrMNbtzfHBewjbz2v xb1660bR5Czzk3sReI81mDR7sD6IdyLzh2HwYE/3SBE6fosRUjRIvaH07R8He6i9PBWW9rys4xvL WuutKm5mQx962ZxRzgAwSA71YyqtL6b0Rm0ekk5NckqhIQpjp+cQFQQqR6SrgVBXjY1X0+v/LCtp Wr9PQ0l7KoWNV7vIreakaySUySPcmR1GDnN7OwM5iHGXKTftGd0wZSSJpKx6kmg9t/rlTdPmw/VE DjzJQdI2wkkObDHu9rUnSfjuwXw0wYFdBn07HxlG3VLZpdhMhNEGnEsUklWOKJ8BOYEtyhBOIEvF IuMEAYCsCia7MEEHRNYlhQoQOaks8LN+p6Kg1WE3YQaRNkNN0eWjKLkVBuBINIBkB4Zt36G7w6MJ LOO13xW34mJ+8Zs9rqYnYZJR8u7uWnZ0K6aCGBEgNPGjQ0LbZpM8K9TgkNoajprUhTGN6OwZtwDG wrvvMC0cp2aldpHDUGRzkLlFgPFSbt+MQhdIHpwSAnk8RodA3t41KXgao/NWeWVFve4DGnnVdFTw cWD24JIRTcUC64CZj1E926Im1kEPCD07eeD8xEkHUuFQ6URDg4S2z9FQK4VJek17+b9sgsuuajSZ TxQ4fxemreAoXUpnQTM5daIjtVUGk5Zx4B3utqRk7KhSYzf3OzolmozQeTDOhscwuJWL8+QH0tTQ +XdwHdAigtHWU4hHcrAepveOWRS9ekicOIh26ukcBzGXT2rFe9IXns47OlWVpIc5UvCB4VLizrGs jVF3MLU8bHxBiwsjJS3HnJOPNASj88yeyiFJe6lE1xMk8FmIG7hzQ9keYGIIHaN8jhZ6Qh9d/TWF Tl82cELHGRFps2FFL6S317My+sa8FEfoEbPrTX/1oHWp8+4TGnYncVzKQJtvmZ0iTeRqoqrGXre3 VuNXlbU5YE3XgR3c54gKiVpKbWIvEJWxJLDY6vX0VN0dZglx+zWYeXk9LeTgHC4MT8CI6C6sDxtm 2C2EeRX4MxhXiKBGzeW+LvGCIZU0dNcwphXBrdFqMGePQn6+sfO7p35fmondIwg9eKaHHVUYj7IN sipornQb8SFKFQio1H5EKj13BeM2dbwolb58u1O+6f04oJdmFGrAVCE+KiFPmEDKHI3RtJUxb7Zp Kj4TIIYwz7CtYUDz8KhHMjrkDAw3UFUQj28Y0+GWMjkQvYKBMe3DxFD6TvgxtVuduhpmCD6+cY5F zjliGphMcgZxwj765wyMN63rpfkix8TcCt67O8VM81O/IpJ+8014/NzXu3ACP+gshVHoeSleQ2RL Y0z7eHTiK2AdUs0gf64nHkDgTC93hiTBIIGwdy59pSO7YNZMPg8MCvtFnbUaFFnljweRz94FRsdb qDBOTEJHB6ieOCVnfTgaQXC7C2ymHg+9C5OUbPq55XeHl6or+0HDlRLIU5dKBBMDX4LABJeD19DD 5nSHlRH03NixVi84w2kLIhuIGNlJel5AWWFb7cILTnxGD846lc6LN1DgjYTk645hg20Xvp++p290 f+gu322NO8Esp2D5rla2C9jmMKF0V0/2iub0cZz8B7tzvUjyCnuScO9+qNcNecNI8UUCJ6lg37PN 8PxRePzC0zdhJRiVxndfwv1PvEGcCsumUi7grRYsc33UBMabrtAxOaTzd/UMKEiqrHJIaiSAnCJv 6OANE6N5gJkkxD0aKAKu7dhXqQGc8O7GY18PDND2lidi9oyjBF41wK5vGffKGEkAkmEXHACzC4qk mMgCjIKlM4w/wHMLBKr0XPF0SN5dAsq2+cxEVdTpO5NUeIR3JpFbDOHFUkNDiVMhvv+XHT0D+HhC UXdXL9gTXKftwG1S5DpJ6FbO6CJAgIUsJ8S1sXU12EjqXRMHI37Yjkgnj3j1AeUsPEGENxqhL3MI m4aNyBVSu2ESwJ8h/4YNmuOE/Ln7WSagPGASfErRwvgJllRwA+klHAocr4PGEcmpCdvs7KS3f5wj 6mWKAnDHMEk64NlQNw7vLX9TBg7hk6AJPP+W2vN7geovBv33Zn3lqRunqKQu84S20VCwiXS6d/rE a4pQAXX/F4LUAVoeziHfRyQ7o8v3j+cIaUtfGYSsJNc5SxYlJy6Hwb8QEOn5/OH9C1hPBD50sVgc ENSfIJBiIyC1kQmzBcltioOIXw+7Ke7DSRLfoVUNrnwY2wgFQ53A+qFt2E9acrj8AEIF5kCmD92B +ZP6l4g6Y5cfpWxTKDLGJDqh9BD9Irs4RKKnsn3htbZD5RDIz0j01C5LiqZwlJFsp8GLD3eXhynM 4WL2DpDoR3Sp48oByqnRE9HMXkmZDpa6q9YSH2z3/SlgP8TyGMr9IzzpdITqZ/D9QVqcwT6+uCtl 2Cx5QwPPskgRGgb5kjerhFn3Tg+mYlks7AEIdZjQwdLmsB6AaXHwCqbYDjMQcyGquYCdpnLAIkdi RpQw2ekPoml47QF3EtkFeePEy3b4CJgdccaUKKAYmPOH98peBOJMX+oI9Dk78Jki7l7T3k0lMLrL 0soASeFksmBswgNZ8JwBhg88eE7efzQeh8MbXHe3nMZ0aOqiVHgDNLH7CE3DkPL54DEAshdTG1yy 3kPENQJ0TAp4QoX5F3AbIiYlx61FeBUWPnkGtzFgoAybgP2kzLhdORa9qyqap5OFemJMFuOEipNz Unb5Hno/nSA4ImXJBQJTT3zD5AVOnIQiCZ2m74si83TEmzprHrvFF1DcfIgHvoG/jg9WFvpv8l2/ wn927Wv+Q/dtPVqd+K5f0fhPX7MXzUf5XN2CtRx81+82XbDv+hW6JfnYXZGr8LG7InefLM0LX7Af u3NF+7E737QDmFKkIOnH7nRfbopdUYWP3eW1+/KdHsAV7MfuXNF+7M43NZP2nXSFvMbf9XvAS13p O5V51X2gPE3PdV0vS891UxNi5C/WVUXIj7Zk9HzbLhg951VDP8Kd1yLzSHb3GFkoC/oRble0SPZN O8yJ8G15N4BDcqXo5+Tzyn231HRSifA5eVdwSK4E/Zy8b9qtwX1BtS2oCtPzA17qavQs/Od6Dfnm WcE/KOx+ONkQRV6x+hGCFkVh2rpPuvZeFYUKtQvemBH1XbrhhC2kpNj2H9Y1INUaMGDbFhy2bdFh 2zXtIEc+uesGcNjOSvqV3TxzH5Q3nfhP7poBbMFh2xYdtumHdX0nXaGMfFD4AS91JcJWhaCGh0uL 84TtfjAfji8aVj9C2DIvTdu6ga/KPA+1C9649+n623fDCFsViqplVeThe+6qKIJadgWLbVe02PZN O8jltKCoWlayomJMybL02FbaQPXYdgWLbVe02PZN20m7TrpCFZHYD3ipqxG2zEpK2KpWnLDtD1pe qjxn9WMSW4NCE1mWw1eFUqF2wRtziX2Hbjhh27s7HLalagK2ZR70sys4bNuiw7Zr2kFO0YK3G9vP Smsnl2Bb1k0QY7KuG49tV3DfRa8dX3afuHZN249fu07agh0AEPbDXepKhF1KkRPCLrOaS2z3g5aX pRCsfkxil9J8BDir4auyzISvXfDGXGLfoRtG2KVUBcF2qaW7x3bpZYUGdxnEikFGGcSKQZRv2kEu p4VugLlzwCuK7SIvArZ1IehnV7DYdkWLbd+08/6KhhSqCGE/4KUalD7Xw2gLtJQ+iiCb3BcXtijC nExjXzza+NPkdIWzEJr+p1WjzGVHNus8L6TNOteraD8RrJWZ+3LOs9Otba3alAkvvbtl4liyFpu/ 3BJTJUSlf9qupiIvlNp8Z6uZZqqQgrR7zzzVUhSbv9DdFNNCW1Ob72/Jxlz/VvkA0ZcrneWIz78Q hTnHQee/t6UdnaoqTZRLT6WptHNlIr/++Zg8vyDP++7FC/LjhDxfkecj9CKJ/2XTSpX1ZLtL5++y kGyrRWRe1+T5ks3XvnhGfjxdao72xVmkAX1xxmYFpuoX1y2p29e8QMCeR4B9jha1H1nUVQQak+7F gqNpP9KaDnnmhqTD7OEVGmLrVnjp3qIrOYmgbcEWAKB/GpnzGevQvngZ6fmVfa5FG3/tg6Y0p6og Ai4j8J0hyFz9ZHFf9sCVJm6P+gO8KL+mPYTtGKHNEbYnkRdjVHCIgEE7OYl08gqNeMoWnURmIHOI zFl0sQAnV5Ghk9JpH88tENqzTdf0OrLU2ES/Q4RNJ3cTYTEv0vcYqjAd0DbPtgbKwCzhEOmWGBWf s9UAKRLjYygM2Dw+cL9yKKUJ6AaphBgQDlOQnERWTkc/RlNdBgqQvtdrFbyKrOUJef7Gvfg1+XEn 8uIuGjEGpcsoCvoop1x0iZhod4lun6MXlxHd3ox45ebTM0aFMsan4/LXbHf2DElnodn94h0316PI IicRSHltTbmWmx1YIUCNQRtDXYUsy2sk5Sg9xzkIyO5HkUUfsnUkFPF5dHRg2yxjkp5iMQLofDcl amm3rre6/eRJT9SaH5ebJ5CNl5HR6YvQQL9cBRpMuHuJeRLBREzeQSVzFWl8hucRaxAzBJLsBoT4 DBEBfY67BIDsjiPzPGTTAC/OGQrxiCcpsy5mD44L8Rki7tgQ0KmI2dbHEZBCbRT3hFcAHZ3eOR6R EHfEhE/P6RjNYxJZ7RmbK9B7J5HVch24Ashm+EWy8gMkbOcMtzElnlh5nFMBsSyjGJN6ISZUvCDh zEegAB2U55FhjtGc9m+LxmUkMg86JBzjGA9OfWzjr1s/bXPpiVviN2T63NDFJl+wX2rRfltn7x5C juNrgaL6KkIgFwx19AoVG9RVhQ9dmyiuK9qgbtiq7Rr7YhfUXUswNxeVv4z/noK5awni0nlfIvsg JlSoWbOHZO9+RDQkwxEXSBohExzOdxbpCWrJVUXtAolaZNr2X9xNkftNZHSvTk4RVKiVcormthfp Fgb4lgkmnTPwgkXFHFqHC2Pfv0hEoYLx6eEWM5LjIsO7wWk1fIGgEdPTKCjM5j9UIGE9b1bo+rXR iMgydH+CgJIMBSGehTQTc5Eo0j0lxGJhsRiwt2GXM4nC82GQasvGbmP+5zWizPlSgKfQSJD0brRD wETjbvyd2c2w+XZkbjxwbF/8LtIzlWCP0KJiofoYWi+9vbe95ezcc0TfMZHMtUoi0HoZQeZZat3J bcKYoqOjTCMySYr2kt37kUn2Iz/mj7n/cCK6Z/O9JNFMZNVtwM9PNj78bOPxZ08mVxfX+xuP/zQR cuPxp5Nm4/GHX3w0ERuffTz58Ycfv//x+799/5fvf3b+lx/+9sOPP2x88tnkS9ZnVqqJLKvirn3e fZvcWobKeBCdgfUhCiTEYxKU7ajRC2EpTY5PaTN5llu3/qP/efmz7IeXP6xx3YVecFPSdX9ClvIy YkwkvUduskQcHdloAizlZNu6bW/a0dlsbxmKumN/H7PUDHpfTuOYrMgm0uUWv1n6lpnBmswrR99P Hb1+EeHr2CZmlI5VOc1EU/1kKOTp5rdujX/dIj7o/wPDGQG3ZW5kc3RyZWFtCmVuZG9iago1NyAw IG9iago3NzUxCmVuZG9iago2MCAwIG9iago8PC9MZW5ndGggNjEgMCBSL0ZpbHRlciAvRmxhdGVE ZWNvZGU+PgpzdHJlYW0KeJzdXdtyHLeZjrNrS2FcSbZqbzfV690LMiWOGkCjD7VX8doVK2UntkWX LyRf8CxGwyE1HJLSU+RtcuV3yAupygs0Tj+6P3TPkCPKS8uygQEah/+MHz+AV1k+YTzL9R+X2D/d yLM/qb/HG6826onQ/7QFNL1/mn26s/H42ypj6sMi2znayCdN04imbMtZJsSkzKpKZDunG882n2xV k4aXFducbW2LScOKSm4uQvIwJOemqpCuqmTMlevkwpSXbHM7/PhZSIbvd8OPR/R701VdbmZb2zxv mkktNw/ar6q8Vt+bctG4BnTyyPe6CD9uh+RJSB76phb0e9/rNurqLCSnNNmZq/7xBf3KNXVK+1+6 q8uQXPiqZCqzkDxGQ5mjWb8KP15QWLtyDXWZ80lRbj7d+mHnzxtClpOmkopsdg4UrRyG78/R+Eg5 mfUeKp9HuHa/cl81Dz+SZO2nmrXj+3xn45sNzsqsLHgxKatMZrXM5ocbR7fiEMkmdZFVJVedaS5R ve38zXTGFDvmeZHnrOQ0+e2fkkXzNbAr52JS152xaEGgJ8/qoraTL8zk3+lQmPpvcihVKWI8vNOh 5Pq/rRj71IsxR1mVFzM6SYTbgRdDscBhOWdsIjY/90T4GtL7CWLdQ8pagZ/KPA90WquBl1ULHwUB ngkDoXXIdM7rCS8oQL6CwnLux7ZPxRYd5t1TOJf1pOJh8ISuOJOlB5rM1wqysoh6fbbJqCDyyUfv Gzq1EkMlho6QdYAOWyt06maS1xQ6HErk3BNU857hJJRcKiIWUDzdCFGoapvPwoi/9iPepToUcXKH f0tlh3kGVhXWCe9C5rFAI8Qo3jNkC6UIawLZzR88BYpaVoA/b9dbHfcGtExZNbHC0yi4vcZnjSKh ngRS/Un1XdsfKxvT4bNMi1v07w+qwQOFiushTKlUoYyWstLNniowstpnpxtP4x90eR6XD2Da1pXu 06quyKe2tIqz0maP/qAmZiZwm2ZetCM83lCKVZtmdW3aMFmZt7AsatlmGpMppM/sK+jwkJ2qLBOh ags514gBo+lg30JVGBNk6rKSm6q6EVHYjO7AZtR3bfc2q75rh+aqtoN2jZiM6WBfg0tMRFW2uP6z +vu3ez9ljdrl5Z0iiknVqFWEZ7lCcsfndaHldVVxy3Mf/PJf/vXDjz568PBXmvkef8ty+rWoJwVn biXywda2nJS8lGol8Pv//I+PlPWmZJSsGS35YEv9mBfV5oNPHv5Oi1MFQyFojeezXz9sFxLbtvlt ZUbVpouPn89/89sP1YqIqZ/yMrT2X6ozZToUdfjpv//9Q20/TkRRNrT936ufS5WupIwH5pPt0FRz OResM7KwwlmHsOFV2RBh40SoFzbuh9MN1uQ8Kh8QNqzROrHKGfyU1Q3zpdO4ciRsbtNMJGx41TDC eQpx3HMerxn3nOcylvNc1nKer9pCzjViwGg6sJzHSzcMk5VN7jlPmbW55zyXsZznspbzfNV20K6R NmM7iITNfZ+qRukyNG8HIvLlCJvzvFyWsLlZzTqK7HzKWVMSEowqR4R9m2ZiwpYywrY0AtmCtBIB 2zbjsG2zDtuuqoFcSTMywnbR5BTbRVUHbBdlE7BtMw7bNuuw7aq2g3aNmEyTJwj7/k51NcIuWL0k YRd5szRhF6yhFBl/ykVTU4qklWPCvkUzMWGrFQ7FdmFw40CaB2zbjMO2zTpsu6oGcrYRkxENxbZw RqvNlmXAtvZ3emzbjMO2zTpsu6rtoF0jJmM6AIR9f6e6LGHnE5k5g0Tk5XLk3TNIdCvO9ujUClZC azQEG4JWBrbHzZqJKVlwavVzIZqAXlEEq99lHHpt1qHXVTVAEjTDqdXPeRXJLe1G8+jlBZFbvIjk Fi8iueWqtoN2jZhMlRLR93eqa1/gcKWG8to4dT54Pn+gVhzFhKmRlJsfb21Xk0IRe735m18+fKCW EM2kaAoRFfz2w9/924OHqy0GKJuxZkm7v6dFDJsZ4d2pFUR7K+mD4KeVgcK4WTMxmykjitKeIpVA e+rDQHs242jPZh3tuaqGoASxe20HjvZYtLjmzAlc3Qgji2uXcbTHosW1r9oO2jViMsCfcN+nun42 U0qRF3fLZqNr7rzhy/GeqKRc1oJTBCKJ6dX5VFSFJIwVVY4dfLdoJmZIxgSlUsZloFImikClNuOo 1GYdlbqqhvRsIybDBKXSXEYLUQWaQKW5IAtRm3FUarOOSl3VdtCuEZNx64MeQ97fqa60NGFNHa25 ZSNjwrY/KDgJFhUP0HVRaEuLlehD7ZtzZdOoZkTTN20ipufc8YTNMrL+zDlZf9qMQ7LNOiS7qgZz jGZyRpDMGtEQJLOGVx7Jyt6sPZJdxiLZZS2SfVU9aN+IybhlQY+e7+9UV1Mwo7EgWqNZ7fJ9CCV4 4UMJTkIY05QGR7nyR+HHLCRPUEQVKV/QTXpdVZaCblCeoZ39N3Tvmuxlgm3PaS/JG0mq7sEgggUK ozocGIoaNAlNOqfjdzWvR1oiPx6gSR3A769Q1MY+rEqjNtCkZ6grUvXUBEwpMpJ55bYpdkdCty5Q 6NZK8AFRXtH47M7xthuY3qXgZnCuH0XHU0+Hl4H43J64j1br0HlEsq78NPx4FpIHIXnpxzldHg+n FCWAzknVPQQS3FSA7lUg/ojQXPkj2FWPO9WqJQ4fIDgdjhkKXZ3BoUbkAxh5RkfVmTWTlOQD/C7g SDJExyfoowz1+YL2lB5TD3wQaYh4c7s95wbShqgCKUpIDkrZY0S9pLxPvWF0WgpncPQQuhH1ATxf 9RChCfEAweya9gpkyxQDcimYa+olVaFsuYBNZV6MkVkdQQBASjnsNqXLZ7A8fE9AEalBQL4vEShW wNoMYS2a/4CYdbwXmQskADqiSVdOoqoJIU864a9q8a53q7/c2PnDs80d1A9ph5gVIRCbUDmR/IsR cX/cxZdmiHNIOkHGLiC+9hFop30sKCX0la/6XSh/GpI7CMvRqIZ5j7BR4D0sziEb79GmgJIj7RNY vBlh8xMEwBddBHTsGjKqGWKIq6GQbOFCyjvlM4Q1DJ8FGj8IhE/yjpPyDqaRlCcGNqHfa19OKD3v MY8ql5ApInXoiDoF02FbMMwZC8GzIOVniFLeIPSOq0v/I9bsMy/lsbE8R02tpNvaJJN9wypp7UzM j1UlrUjTkuyPAeljqnmGjpzMQzIQzUX48Xygqc70CM9CnhlTEhjSkGfhWiPrfa+JZkwm9JDaUe1j NjI0F8mJFExf0GAhXUFJxzzRPN8aWYFBy/QIWcORQQTGD02bDH4/Q1i7meVq7QFyEuHMUydR8kRl P0IijYekBVmnArEtyJyOvEwbA9TYUhurtFkgT2huQfE5tJhKc9o5JQ9H3mPaEZsf4zh15AkN04jT hwcdZOIclgtE3UvwBNCukXkzhtUV5FdHaI9r7yeB1GeIUhchOWayHiGTlAj6aGEC1mgEvddoopH0 AyKlL/I0pQdnRcpDcIPVzhD4JatGBfUMDgWewuurF5187auew/J9xDRjiiDiP0DqGeKPQzQ/Mqjz Lnw6WMOstovGPyizyZmyILP7rrKYkImZ+obStCuPqL8r/gN1aEK+oIP3ydMRlE4RofctDk3I8Izp mMiGTqmbORtmCJERzw4L0pch+QiI7OuBkSxDctjgPUF0DF1dK/ApdHkTSFyiqlFTQxI5OhHpCJFQ 5/WIRIamdbSh4ZM9y0kT8gqLmJVIwhNygMnLBM6GwT8usTvspQl5F2IKnoued6GSXgVceELuqd6w XvJnlBSm21gDckbp1udrS33kxIYuCYPuinn1r8ZQhCT5NXvP59VKoQ9M0sE/DWQJd+cIhZ9TYgaL z8hv7JN/Wdp4uoiAI9WkiqZuMVextZyfY0UzYXT64ABd0eSiQyzvCBdm+1TH/BcRKuJdp0OKFIKK MTckkEB9P0EwSTq7pxeIF08hL8K1Kyk/DxLoHLE9PIKdso6Gl9E9A0FLIGw+9rwjHQkE/frnA02t 6B1BC4WWDgvBs6I2cQK8EGs9SSsKMakpxe2EUYxZ4am7OID6gcbPcWrCLdPVrHNqdQ2MVbU26mm8 nQv9+8TcDDbsfo9bjIwEjPVVSEb+d8dYO6m5370CYKKa5BFwgi4mnPgSccKoG2iBRD1cXRC1HvmR gUcqaj8CHisUq1S8pZy6XO+lEYXikZqC6QYurvd1K4IadEz/UNtiX9UVqkp4f8z/TpoaW4ONCXbo yyEiFm7o4nt4VpRIXFaesJhQZoCnLGsjVKJzpc67NRHK9p4ry61elO16UUSWHsQGCzYckW+ROQBE Yd/barRVT0WVRQuCUi2f1mGZ8UJrJj9RZJjJUt6pYSYa/b9ITy6xgRz22oiz+WUPK/G2DPGXnNNW gecBilu8irpCkh1sIEcMiLfldhGDRrwIhkK8gb07gjqWWW/b/ObeZHK7z3e+arQXDroaMiI7wjL4 vS+QkwMGaUEPPo5RCn2ewfLkHSwtVyoK1Twi8kb0hJYysmIb692yjxafln1gQBK2r4JQioI7ehMV 5gC2kHId4qdpz0mEISPxI1jXiXDbm1VaR4K+yEKUA44EGZI/O0cCHfwXPc1hdtyAzxdubuzTj3yy 51WjnFWXm9+OWI8w3CISPD2fA+ctohsm1qLZKjGRnEAK0ZYayl2qtsLcYGVvhxvmTYKLS19+0cN1 uC0xHep6QSkASEloTWPVBX2RY15l7MoOEXp9p4VJdpWAmurJSFfYIj5DFLiSqwVUJbOKVk0AwGO7 FlFM+6ADf8nodg0qGGiP11AnFCp4OdUK/1y27CJY0ddyuazv0DQvqsawkaONiI0I7xBtdoFcCNAF 0Q/BIhZiYJNONBaBYggBwQQ7trP4Klhwl6gp6DDDwWwzhHu8eXTkLcQz2NWNAr/6/ismb+q+ArIB u8cWiIuCFMAhdMaWFhWPnYSeoUKw5xmEJNq59byjCLhOWYiiqYo7tBDb2+wM9zjkpbgnsh1cOdkZ Joyyj76PrIgOHckauaux5I+pA0ZD3EDyRxcN38zJPqWtDjvhxqIdztH3czjBoO/24FAO++RX1y2J cV6v9U5OweVElpSkVjqq9J6v55Sl9smSwY9FfEG5e0TJDejkVGwmaCoVERV5yRotRiw+yQadlyZ1 3dylJjY35XadZFCZRlHSwzZvEDfY3dNzUmpljJfr14iHIfiJ4DimlOCV8d4Ij95o22ZoK76jjKG/ YhfS1xEaSt/EiJQxjqyHa4bIZB3eh4Pumr5rQVTmVhCF9HIdC0Ch2Lp1Xzr6BAtAUefyLjVvUes1 acsrf0G8gh3Ge4gXov1nV44jAXqnNzWv3OZ0q1604eDOXsxjeiV0hMpXCLld4UDHo1t2NesCsKPI xs6KXqCu8MsKU8QsMHoRDmoBx98zPZikxZdo+MuoIsO2zLg+eSF7qqji+V2qIn1jqnV9kqgyuO4j likMnyScuGTMTTBzNHuNx9z4H6PVhiv/AvLMdVBFoSl8oCVwMo4D3kP6YwGTITwSbEhGD4fgQI1r RFRjh47XyH6RaQ/YCxr5YwdS4Gr1Cs6fWObjwe89/irNRSmQv5SqvEv1ZV50aPnLTT8VR79G/urx h+avz8OPryl6gSI4p5gA4O87Q+IDTdEhQ9DUJcTk+CmmDtF2TupD9+TNgobDoXu4nQgj1udwJHA5 HRmdgzdO9O/2SPIsgeQlGtTQu0ND8Qw99pJFmWQveynrXakv1hqs3cipwD4kEjqKfwbstxeSIXKK LK/IoutlF72avfBOzgSB9wnFxJid5dkrceCBcApQT73zsGmZ3LsKQLPXCj6eMfHfnxUbnxQ8zwTP cOMDcfDg9IV3W76rC216PFOUZhM4L3iPZ+x7DHelkvJK74e2PDN2IoaonODs7J/Xik/ELOvMjA8x XlFCA96Fabdcr6hSvjygB8ZcTpFIBpRABOk1HQpo6iBBicMO+hXOLED1AIdyCr+H4W4XNDmok1LP 7ABOhoc0dz33A0axlxHzpmE9RhE1v0PlIprKvtb2bPP5ZuCUPUTpC5oEvgfCCW88+ZKwKqJ9Ip3j YPYSwjzY/s+3IKahSTa2Izp2Zwtp/xgRZb99rb6uu1W1esG3P40feRv2CcIDz2PPMq7gcjnwBAwP j0H1sD/S5xxND4edgb0Kbq4ojbfK1vCeFRcRG1BrJoqKF5wtGxby7jYnLNtqAWKG+1lgWnjvCHEI Xi3HtLHJSAJGjrokp9Ubdq1B5y88EIhf4iQ8BXeqI0Id9ljAxQ2+/CusuG52hn1sc2fueQrGfZOe XqOWIMun3PiAZ99JzMAKNgXQhIzb0JGm6GlCxps7NBmFMlCLlMVYslGLkbAMvNCNmJE41HLspiO4 Hlnp+iIipzsKQ/NZ5BoBLDV+gyMa1dnSLIUJGd5fhTVi75Qqk5swxGoBJ3WGWDJyMgGW+uuI52P5 axXw9MbcOYClcnOvLGSpvLjLgxJCVhPBeyElIQYVX4II75IhamwxUt5zkXUCsiJ3EaCJsZCSfsh+ fC/BChdLQkb4hDIiIppwU1LkgwOUjoUzVD4k+Ylnn7GreGEw5ymaVLTxO8xT8FhadK/A8KCCZR1Z 3l1GUUgrUqsw3pT5XeqeovInipxEXYM9F74fDN7ntXlRRKNgHRHWOjC/JnMCG+zuwba7irAWvPSH h+gy97MRCAb1fUXBSqQWEEVHvaaCeulYzBmi6tRtt4Ar+k7QeA8QUL19GYGxslznKoophFZlBGjy DHNYU9UJ3fqez2hyromVjv6PULas4IB6isQQDITASyBS9flWDJ9aMo/INd3FIPJWVwcIIK4t+Ts5 c6Of15JDZ27KkIzO3DjbnFyaEYWNAfFJHE/Bx4WvxO+ZHBSXbZCoxgirJ1yhY9vecKsV2Je99UN8 qPMl7QPYQvDCZ+yH65maWsCscIPXJSU9V45P382DgOlZrarTnnOgs7UQ6Wpgf+C4mGtkQBBbIBho eNJj157daEMEe9FgEF/ksR88wkEmDY9oDN2U2ikHQYiKXOF+asILOHQxk9vESB15JmwD91vgfgqh /j6hB+hq6sbrRBjLBR9VwBEiZCGcIcH8CiGa0CQhJLjzgF3TYQ8Snz6FcS9w4z11rKhNRpb82JWh OG4UrsMjUA46ifHqeCzqDYadYUaGK7nBm/LgKVhi25FDczBU7FVIhpN4kc7wSbgvOHaTGz7kcIHm 2T9NFNMxdiiMbUsH7ODrPwj2w4oUuytXkT1IdoYjQjBq+7ZSfIyOrxDzRI+zACk8toGPt4WOEEvM UVNLX58XpCw5okPMkVNE/VFMPZDii15TYXSdXW/ooxyLXk/tz3nqhnejRvcsAkSP3QM5FDOvqTuK yCVJ6HAg5AmGSmj20lP3FBFKL+Qy7Xj9BBHiWJzjHMmBTxBSiPDoIZ1I6YrY6WNS2F0PEdnKZLG9 Qjx78AtGd+0TOu5IAU2nkZACUx57KyJyq3WbChfv6ttwx+4rTbkYgVlO6BBejH2z6Ax4gzoOdIAS bQVGHw+9B4Q6dvlmMMwIycOILXzb7g2MYWJEBCOArEGjQ5HAG0ckbvDmEZrf71UN6rRzb/RKL08B u6ovJuPd15udkYAbgUOvOnS2isaMBBj7lwp9d2IWGlljuzZwqYevO4YBeQfoI3xL6jpedC1YLsjD l0Ul4ocv3Q+nGzzPRVQ+4GTTTyaqurKEn7KmCaXTuHL8xPItmolewCz0TVXhWciCidI/C1mwQvpn IV3GPgvpsvZZSF/VQM42YjLcP4+qs3np3g82WfLucJG7x4t1B7l/57jtPvfvHLdDc1XbQeeSZkqO X8C8x1Nd6UVX0Qj6VLGomzwibPeDIqtK3xlDyocIu2rDgBiDnyq2DaXTuHJM2LdoJiJs0Uj6fq9o yvB+r7sYoAW3y1hsu6zFtq9qIFdKkpH0/V5Rm7dJpy7LSo9tUeelx7bLWGy7rMW2r9oO2jViMqaD PmHf46muRtgFl5SweVPHhG1/UOWSF1H50BvcUqi6wj3P3vlUSBZKp3Hl+A3uWzQTE3ZRlBTbhawD tm2UuAG3zThs26zDtqtqIGcbMZmipNi2YUQO28y93asbYXl4yNdlHLZt1mHbVW0HzRjN8MSbxfd4 qisRtuR1QQhbMllFhO1+UPKyZCwqH5LYJeeqrnuXvvMpL3PmS6dx5Vhi36KZiLClyCXBthSs8tiW el/NYdtlLLZd1mLbV20h5xoxmVwSbBdC5gTbhRAB24UwiDL6WTisGf0sPJW0+tlVbVWya8RkZI4J +x5PdSXCLrgjG2NS22uzg41tf1BkVZcyKh8i7LrSdQsGP+W1DKXTuHJM2LdoJraxRZ4TbBeCMY9t BVLmse0yzvC0WWd4uqoGhYxm8pximwW93maNmWitVykCtpnX68bulYJi21U11rJtxGScHdGzse/v VFd7Zb7OyknVCL0rb/fsC8ldwHzdXs+pDyC7Y/XPZ1vbqlOhvRcPtvS6l9ds89dbbKImX6mftquJ WncIsfnRVjPJlfXASL2HOlVztTD/lWpGTqQyJzY/3tLx/k1Z6VWxDiEgA1I9V6KsM/8gkzK+qqrU d8mqhpQdWLeeF58+JOmMpC/ch7TCLknPSXo/atx+SLxDdkxqpnqQxjlkay0STdKuFtF47YfH5Mc3 iUmckPQsjAu3nIaK/ZAO74ykLxMNnrgPZ+TH46hlC6GqfeTDvAB8PtbdIvH7vvuQ/jhNQOYajXO6 xId7CBcvEoi7SoLUTlxP+MC1QrF1lEjTVuaIRGcJSNH5vEGkcJDo5RxNeJb48CQxkuMeU+iZn6Hm liFPj7EL8GFtthr976+jyQCQ7Sd6jFkQIOksMdtJCtU7iGAOybizCL20J/thmtdGAY9RmuayDjfp 4e0nKk/RhI2wM0z91LX2Ban5V5L+jqS/JOnP0PhPE0h6iUiVfkihdwFQEIk7OsGjqEKKQAFtEWh4 CXfkKtKxp4gwQzhJyZvUh55fUvOYJRC7QFDcS0AOapuEvA+ksetq0manSeQMUGi3QkqiTREvp0T1 PGocIG5YiaVQ/DLRnZ/UoyVU+gKNjVZA4rHLQGdIli7QBPXEIOxSkxnVOSn5DiXvje2WFKenldiy douGyAyRYYr0YiSAD1NkSBv8HwSRZWxHKKHmieHBD3cT4BvmbNrsUWKclJ6mSNvNlwCpp2XKajSd ahCaUgeJXhJWNRADNxbYNyYqD4EUWlOGQkK2YWaGEHgZfbgOMw/q8PMlQPliTGZQsF5HDQLwUbin JKqXGa4XbS5NwrbtK7WKF5Ve47uNOt4UPju1WS68D0xX9tkXG99ns/UszfXrBvUdLc3bmX+z1CGA 9LglkxNWRuN+iuTDeSJNUT3vYqnPPlhSwbV8aQM9vh4Tq6k1A1z57SfoO7ax2w9lqY83jH45i9Kg S6TnNP3+Y8s4WCKyYqJ17RgB936dOxdroAOL184kA5p53t6/evDePVlQRaUWZMdjKE+tHc/Qhzfm EOftmqGxnyTGSzXAHtKDlLUuEgiUoj1y83OgUuhzeMfiYRnP43LiYkmz2Kg7LFR3vLR6kZh1SquO +gLpHA6jBqGDCJho6/VMpDwr1McDPcu0ctprOOLvSzXonUBvEDQ0FPaR9ZeytPYjLAKNmnJH7yIM pdall4keoW0Xt5yY5DkSJheJNCVPL4VitwSWPMWdiR17AFP/0WdcM2bS7d5Uk/HKXPawf7rx6ZON x0++yhbzy8ONx99njG88/iJrNh5/+vX/ZmzjyWfZT29/+vGnH//5499//MX539/+8+1Pbzc+f5J9 E7WZlyLjpXm07jZtLnuaeNSSFdoScS9jATmRkmnUnI+fqYWw5FKfbjX7dEvOW/1R/7z+Rf729ds1 zluqCTclnffnZCqvE5x7EgkFIEEgv3TtId4oAix5tm3Nv/dtD222R5CTVtv/j1EqBmV3ZFsOyYo8 43n5c6Bv3u4a88LftvTM0evXCb4+jgTyEnSsVtQ5a6qfDYU82/zBzfEfW2TN/H/CcdZUZW5kc3Ry ZWFtCmVuZG9iago2MSAwIG9iago3NTAzCmVuZG9iago2NCAwIG9iago8PC9MZW5ndGggNjUgMCBS L0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztPdtyHbeRcXZtK4wryVbt66bOeveBTJnH gzvwGMeOo5TtlW258iD5geZNtEiKJqlbfiJ/s0/+h/yQqrzAAA00ZnpmzuE5EmnWWraFPrj3DY1G Y/DDrJkzPmvCH0jsnmw0s0/9f4cbP2zYuQj/tBk4vXsy++j+xodfmRnzFeXs/sFGM3fOCafbfDYT Yq5nxojZ/ZONB5t3t8zccW3Y5unWtpg7Jo3avCzJ/ZI8j0WFgqKKMcgPycuYr9nmdvnx45Is9XfK jwe4fuzK6s3Z1jZvnJtbtbnX1jKN9fVjvnDQQEge5F4vy4/bJXlUkvu5qUtcP/e6TXX1pCSPcbIz 1/DjI1wLmjrB/S/c1dOSvMxF0VROS/KQGso5Nesfyo8XGNeQH7CuGj6XevPrrW/v/3VDKD13Rnm2 ub/neWW/1D+jxofy0ay/o/LPK1rDrzwXbcqPKGnzVGft+D65v/HlBmd6piWXc21mambV7Hx/42Al CVFsbuXMaO47C1Lie7v/feyMeXFsGtk0THOc/OrTwazzNYgr52JubWcsQRGEyTMrbZq8jJN/rUNh /v+DQzFa1HR4rUNpwv9bNfZRVmPAWSarmZBEym0vq6Fa4bCGMzYXm59kJnxB8vsRJbr7WLSKPOmm KXxq/cC1afHjMcBnImJoHTqdczvnEiPkc1JZnuex7WK1hYf55jmcKzs3vAwe8RVnSmekqWatKNOy 6vXBJsOKKCc/uG7sWK+GNI0doWzBDlsrdqybNxZjh5MauckM5a4ZT8LrJVmJgJdpJ4T0xTYflBHf yyPewWsoJckd+dXeDssC7AusE99SNbVCQ8worxmz0i+EFmF289vMgcIqQ8jnar3ZujdildHG1Qte IMHqKz5znoV6Gsj3p3y9tj+mXezwwSyoW+rfb32De54Uz8co5VPSGy3ahGZPPBqZzeDxxtf1DyG/ qfNHKJ3KKqhqrEFVU66pQZXAgz/4icUJrNLMo3aEhxt+YQ2mmbWxjQiqpsWltKoFXASkysCuxw4v 4LEHmShFW8xBIxGNsYPdhFURTZBjABWPRUMjQiYgdJAAX6/tPoG+Xjs0KNoOGhqJQOxgN6BLzIXR La3/6v/7/tZPOZB2cX3nmWJunN9FZJGTioOcWxn0tTE8ydxbv/yXf337nXfevfOrIHwffsUaXFvY ueQMdiJvbW2rueZa+Z3A7//zP97x1pvXUcoynPPWlv+xkWbz3ffv/C6oU49DIXCJh6e/vtNuJLZT 89vejLKxi/cenv/mt2/7HRHzPzW6tPZfvjNvOkhbfvrvf3872I9zIbXD7f/e/6x92ihVDywn26H5 5houWGdkZYezDmXDnG2QsmHKqUrZwA+eZwWrskd0jZS+qGaaqhjQCXnHVclKz1y1iUrHcD8iJHC8 YSILHPeozQIHQBI4AJPA5aIBYbmRCMQOdgGZwiGBY96eyALHHLNZ4ABIAgdgErhcNAw6NxIB4Xo6 5rZPNZB0EVaPw5TMYn5OJkHh5/TDyQaXjavyRxjat+rLGkBxpyoXzubc47pwxdSrNFMzthQOU1sq VqgtdVOonQCgdgKB2lA0Yi41EgHhELW5gCU9gVpnavPgDQJqA5CoDWCidi7aDhoaiUDsgGDs2zvV RRm7mavZpzCcRi/G3sw1vMoPrRz6nxnvlcpMxqxjqFJVuOLkVZqpOVlwbBNxIVwhr5DFJgIAyJtA IC8UjUgSGODYJuJ+i4fJG5wMmbwcGgkd8Nxf2z3P/bVDg6LtoKGRCJhmgJNv71TXbv5xv3VsbNzy vvXw/F1vj8k58yPRm+9tbZu59MxuN3/zyzvvegPLzaWTosr47du/+7d376zXVOJGuyvK3sjSEoUj rwmdqlGSimDhwoRAXq2ZWiCNqwwJ2/DCpZbxwqUJAC5NIHApFG0xB41ENDpsSHANw4igck3hUmWb wqUJAC5NIHApFG0HDY20gAbDpSeQt3eqy9lMSlR7gBGbiTd6YZspOv6zsVNX5cxpbOzgwrXNtEIz NWMrVVFbaWQhK4Ms5AQAtRMI1IaiEXMaA6qitnSV+pUGqV+pkfpNAFA7gUBtKBqtH4PUb+qAYOzb O9Wr2EzMLai3e1uCaDNFS7xTqvBca7YXjsSFCev/as3UnOyFAJPXr/uFvL5iIW8CgLwJBPJC0Wgd CKS3UgdAXlb5kTgD6zk0wpAfCQAgL6v8SLloO2hoJAKE6+y2T3X9NpPf4XB5w2ymxvHFZE8YpRZd WjyDKLQmdKoKIxUSrKpw7cteoZlaIFl0lACXMq4KlzIhC5cmALg0gcClUDSyXmokAkxgLm1UZUh4 1BQubQQyJBIAXJpA4FIoGj1GEgOg33sCeXun+mic6dYQORKUQhLQ+yXw4FEOPNivTvSk4DPNdIsa ptYaF+D3bX53hcczo+KxnpQfn/biuXz+UfkRhX4dlmSJITrDwQZEONQl/jEnd3M+HW6FYoQ+z0W/ KT9+HZPcKY9wFM4UftQiRzu1gVXESM/IQZ1TgyajlRR5Nl6QskceLz+jYkp2yaIX3Ul1IttOB2JO ruEYXroQNYVZDmHvEZ4dMaVTKh/Vf06xFOKzx/WJvQuhYUmylLJrPbBnOkRk4XnOMenr8LTGtt48 dIC8egQn53ORggVEjn6CMXh1Y0oS/TrLIXR/KuKL5P80C/0zMsizKI1DMh/phyLU+6T8FElFnHzS 5YAS7cfsnCs22/aGHBzS/RFP7HoZ35t7Pm0anv1ZzwsqjigEIqwdY1xC/kX5ESXreSo/PmXTcYoy 6+Rw5vFtqwk9orR0j2AdkUZRNk8nVoETXIsoekRJ/ynmrWsO1fI6gfEKZaeUDFxZoTHbsExu4a3Y dUZ8xSg8PPgZJaAXGN8goNUCiyJ/c/J7Cg+7GCUE61xSyEH5z0guO6dG/YTiwosh1gk6W1kBoawT UbWvj6GiOakdS8G/D/KU2pBWQlFcluROzv+OVETHlHmHQmLRr/sIZV3LVRnZ4kkrt1bt4+14b0fg uSPKl0sBiN32u5w5rGlmmJ8JdkHxgEWCEY8dU11dkJxLRuKfkl0VIXhEDvUZNRTU/hGWh2X1p6f4 B9SsTkgEkrYrPStyb1BdBSAQ+AQTYNwM3olXFTwjqcZAgFCh2h4eSU/ITQ6dX9u9AW39X7Xl29n8 obV8XBof98wCnU08VD/Q7s/l16fUQlIZ4SMXMtplmFjm6Vj3DyZWfJJgU0Pp7wfCvi7OSrLO3RJC uM7JpgrHH5D5e1RTFZujdYsYdW9dHL6xs0tx7DnVKIlKulOSFNNbryQR2zCaEMbG44hAXKurX2ir gJaVVdaakHzZRZ7yu3bEfQfd/CAIO306ekE4pbiX3oDPKJbYwSSHfKTv0YJDkowWhOOekvNDfUIN ZYhlxi+dLMoovtd5j1Ha+y+BC9LO6rON+38oN0jaS4DEzT1kdTzN+edYY+VkuXKDNB66+dfzFAXy n5A4JdfIqZW/f3MwaJTTHk3qPcgRlX9B5dOrVU/5BOVFK58dSnjPqHxkMz/uIYAphJ8PVsTfAR4+ YmRCdx1TmHhOYWrIRKDUUJM2+TBloxIeO1dQK0dFhxEDbx9S+ZWfguJZkpEqR8W48JPKAd3AfEqh hxZusiu0NF5SjErrobPMiGeYpjn5Mjc1LwiMyiHohAFvNkIakumfr3fZKk54l0Oy512O7RNDQZz+ jKTqeSbF0O0jaKqSpHFJJlaP6oovck8jd6VCnjZK0+1T6qdSeoRS2KNQhcZ3MOEAJrf8p2T/e5SA ULt7yswB7LUXRsedn7Ocf1J+ROz9jJKJvZK8ITJVm1mvVaaCeho7sfl5yhRTqCXem/SgFTY1qT1c nxAp0krs2cYdoi1h+MOKC+OoTD/ay3RErag7uCjBksAyrblOqPklpHyJHd4S+84zytNSmV5EffqU 8BHVFLlZHPK0EF0hRunplGtyfkfnh9Lt50rSp0UyFxVfJdJm32GGgHzEWo8oxbtLcllvrVL1qS/p 2Xp/FW0TFFsx8Wht8z6l2MjzEsQapyNcEhTb+yTDTTE0ebjQd3gyRdvqO7jTce/QtBQTio08OXqE +x+3cEljmz5KL/Ojl5C9vo7Mvm6pZRvNIjz1i7M7XkqWWjWLnResR9DiOXsraOg7F0VQ6J34Rc4/ Iy0Y8lChb4wU+y0IGv0JmxOKpkuw7F4RtH2K/JcUTad4lj4SqjbtIGhLLEJIJud9plHxRhLzeF3H Bfn0QYjCAMQNeSkt6wQcrHpFvg06UNzlcAcy6MCWJBl08DmpvgvXoR/JbTvKH/M0dkiNWOUl2uoM BBUsYZC/cb/nYrYdlf+kiNOU62L60Hp8CXjcHXUQp6GDOEKykWukGGJDMVqwbpEnyAsGHxhP6vJF riX2uAcUtx1SndIfL1taMXWKTu5xwaKHNv1EDyhbrDK7xnm+OHtRpf5+uGyCAk/TtnHR2yeY5ONW y2UPk7Uzt7/s+/5Jp/ddjGjIp48KSAOB9rCSx2cXFM1nZPvIb0O6UJ528Tt8kkcev1U731FnLu0i Iw9YKvoSe2jE85XZdSUTYcSZgz5X+IIydchItmo7m5MXE3Kw00VJ4PM9EmWLO90RnzzGdMp8TlKH 3E5OKdyh03i0+IDuptU8aeAhrBTupQN1ijOFPFDdowY9pJuJnX+lkQk+X103j0//lMLEuJZG8QJT rr7vcn4VO0hwL9pGP+kly0QD9059YLKKcM1a6j7F3ZWWGufOKSOG9EpWH8ikaF7Ic9gfdWVZ0NsX cp9Ls98xNWoynuCCHOohtX2pJGHUF0gf1J1Tg+p9odQ5Q32hFKvZa/UntV8D6+1ySRMEMfcJtV8g nZbV1rer5WvVflVbuNC+uzMU1rbuBKfX+i05ps28wlx1vpWT3+SRVb748ZWClEU6SoYUAFpVkutf hW+i/tQ26YBsigyMm4rpoJ1OpNcBaYhjSlntTdQvjrjUU9ib/H3CznuSNfR2ffHAc5hbd3ybjIHC LWdNHc2jGI8ic2hjjxY08uvQfcusTDfI5Fi0xdhBwJQ5ls2tc0q8l/44c4dzx+RpeKs8euJWHfIO LQiEkBAxVGLAAfCcqr+qj3cqxJsM8BsyNwl7a8ieHNlCICOs8PTVtsqnVD6q34v+73hT0RZgjvxW +cc/U3qLvlBx3cs5M63nUEo7V9ltvaqxR+rPap7SmZkwLF47VXqtFyaEDBew8IxI83Jqa07vw4q0 0+YtuYumHRLLrB7UOrbURosgWbW9Gp/VwPaqG7YtDG/WvqyFT0Am1zbIzVDoI1rhLhZWEfSy1gsC DCpgKiBmKpx1FzfabSosazNKWyBdW5a1HZJOS+x9iwd4SldPfU59NLiNKdqHh0p+T016alLVPnXR VW31a6zjZg11541aytBtoRKHUd0lzMmy1KFri4jPP6D4vH/DsTBP4OP+8UM0nwiUkBETSImc9Che e32n7kVfYpIQqyZ9GHzanVXg4yl91YvI2CYOmcjTM1eS1enZTbjZKhsT/mr149ekKhs7DAvImD4M 695sFekTiuhm6+o3WstEiINTwZ1d88FpXF6ENenZjFse8RcovXzEn6/0ej7SsLjrHS1PaCU8wnMl 9nq9o+UlNzhHGAHE+lIqIVSTXuqhOyg9M4p0PSOT54haKpBIF5MIuZaRdfPsKjx5tZA/krp913Nt 8tDsTzppp5aKsU1/WCquFvlCStp5L8lwYMwu2RNp551Rkx46AyFYcvreC5FfeWKu+T2LRoataLu2 jH+hZGDIflniM8HiF7SZEt1QMJ/1Wt6nEK1jtx0xOs8ng85R9FdZltFJEUqWkLGhZ92Q3QriOuXs XsgGkpQNVB0s5V+n3o47oHTObm+Sfo97j9RZlzg5vl0+RZ6YgQiij8vAi7KkT6GLiwjdEzii8qsL MTnZs0A7+8eFT9Ovyy+kVECb4DpweMvbU7c5pk7OOlPiLnygNX7Pbc3fzGDOhK8T4MGfUSsSaUTQ 0SGVniaa6kWMjelZwjSasoLoLdvqEWOEFURveMl7zKh+MWiq5xgHqB/UsS+s1+0tEkzPTVo9gHpG JQU5vMXZpUwn8tQeiTiKrdrBjEBI+5S7fCrOve/VC6bTlFevdDUV/kJ/gqN3JhZMJ9obRLpFyfuL Q7MG04l0DZDbIToMivQ+VzMhTKdymYM+KC0bn6mPjdC7gSqMbtxvRsrhqDcJHcCXrTxibjK2aolb Qf07d0VhBj5Hqo+8z0GjjAzOeN7D3mBsVarV3ieB7KnLY9XjihQbk4F55IVLmrmmA6KIUQ09aruo nkDMVXnjFv38ypWi1KoDygVviZO3vBGjksYkaRGjHxGjHmLyAndeLQqJ3OpV1MvcSZ7wkbqB5omy hqMNIH2ytk9p4Up8xo2cXSqf9NkfUoSe8skvISgT1yinDvWXWDqXWkVGtCwZUoFMgMoaIPgcbSOm zqZ6Atc5fu5p4Y6BV4V1jqMEhVSQ5v3S30JVzPQ/uFl9v2Tq+iGS/SLw9CasILLSIt2i0QIDRI6J 1rCtVFaGl/hHSiGUppA6JlfGJYIth76aAgoBWYgHEzQjLUD6cGUvK4SpL0YtEyVyI76Ey7WuD5Vr XXNMEQnx0xmlqwZOuHrfvuXMxWfRm7V+GVT6DKPLzLZHKEUEpcE7DdOPhL/u6FKu1BwuUSIHeAkv Res/GT5KX6Ik78SjLyvOt6owUM7iO59r/kJxPO3CUywK4S4phVNhYWSY/tASOG6VF4Xxd1LJkzdf kBqslCMhQeTXc+jwmCOqPn2cPPD9QQKBJ2T9F1T9m+kkF9rOmSYlhFJgQcyvqsAQ/1Re9kbbIhtr 1mDcVVNbWoPFiLLr/zYslyoH46Lv9RXLkT6Cu+zFovMmvs3A1Vpj0S33di0eJG2AkV7w6xYBFp77 shSKS8BMx5UzyMy+2deFYt/bvKk5YQl2vga0tqdYeLhv1jJiwqlMizXrFc7tnNeTG34VwBtn3VcB 1vKsPKteetbMsOopHvjB50sjqvyxp3ikDWWdIKsKqUvucV24fopnhWbqZ+V59Q6y5ugdZM15edMP AHhjPYHwxjoUbTHH0TvI0EF6n0Y5Ce8ZR1CU52KVl6r8Pg0A6X0aANP7NLloGHRuJALS0k/x3OKp LvV8obIGv4kLH2jPjA0/nHjpUqrKH3u+kOlQVimyKmey5B7XhetH31ZopmJsZZ1B1FausZnaKr+i 3aI7P7gdiZEf3I6Egre5WxI2CEgdALWNwQ8vKaNcobZR5eElAIDaCQRqQ9F20NBIBMzAG1O3eKpL Mbbm8D7plMZWdmGF7YUMKdq6ojJYr+KSFU9ftYlaUYvqITEtuCzaS6CHxAAA7SWqh8Ry0RZh0EgE qofENK8eEtNcFCJ7oBAZgERkABORc9GocoVDwNCbabd4qsu9M+vy+h7Ylzei5mf44WSDseAhQ/lj Dyh7my284sbJqozZkntcF64fUF6hmYqxRcMUorZoYLkL14waWO48ugFI1AYwUTsXDZjLjUQgdgAv 5DlVPVnp4KnL8EKeE+jJygTAC3kJhBfyoGj7KB40EgE18DrnLZ7qcoxtLX7lcoyxXbM4Y4dXuhFH 1lXbJ70RR+LC/ZfBr9hM/cqla6qnHx1DTz86jp5+TAA8/ZhAePrRIc2VG4lAUz39aCVWY9wK9PSj 5ejpR8urpx8TCNSGovGNb/wOpJUDGvsWT3U509o0eM+ojKyfb4UfPFs1rqnyxxibheeqjGnIqqyx Tc49rgvXjL1CM7VpbTjeSHkTpmyklJFlIwUA2JtG4o1ULhoxJwQCeLWR0sohaisty3PZSgubqQ0A 2JsJBHsTiraDhkYioBzN2Ld4qksxtkhLQGJsYeEB86/rH06iWwjnjzG2bHxZxxhZlYkQIJhyj+vC NWOv0ExtiqTlDNZnp4saE84UNQYArM8JhPUZikbMaYUAhdWYHyRH1BbWFjUmrGGZ2gAkagOYqJ2L toOGRiLgOM3Yt3iqyzG20djGFkkcC2NnBcBceFMY5Y+aIjqUlZysypwsucd14Y4pcvVmasY28Qs5 QG3jkOFpG1WonQCgdgKB2lA0Ys4hwzN1ANQ2HBuewrBieIrwNGKmdgKA2gkEakPROGiGSJ86IBj7 9k51OcaWEjtDOG9qjQ0/BOcxF1X+qPtahLIgE52qQgZrmAODVoU77uurN1MzttQcU1ua4ioQ0iI1 Jm2lxhII1IaiEXNYp6UOgNoSHrSPoLDFVeCBYngCANROIFBbYM0FjcQZgA+5x9i3d6rLMbYQ2MaG M+TC2Aw22c66KnuEr50LRYWhKjpT8o6rkhVPX7WJmp+FwvamEJoXIntNUIicACByAoHIUDQiTGMA XFER5Bbbm4KbYm8Krou9CQAQOYFAZCjaDhoaiYAdMK1v8VSX42fOzGL8LJRRizK0UFYhduxUFX4b gFiwKlwr6hWaqRmbxx0JUJuD7z+itCnUTgBQO4FAbSgaMacwkDdELciMwdRmYJqGRpgqh28AALUT CNSGou2goZEIGDPA2Ld3qssxNmvwOeOIl08HvlnMyafboANwztUVtVHIF4dLVjx91SZqfmYcn7kJ Bu7+FpOw4W6xLC0mMiuHwi19ZDlmy41EgOMzN9FohYncKFmI3EhZiJwAIHICgchQNPqfFQa0GuDn 2zvVQNIffDfChDMhmGW46QrgcQK5zItHKJzBRxt/m50uEfNiZ3punFecOepF+k1diqbzlpmUM+OX rXQL9uHp1rbnPhEiut7dCpccuGWbv95ic8GY8T9tmzmTSojNd7bcvBGKM1TuTkhZztTmr3wzaq78 grj53hZ34eELk2NovlwqZGd4+MovC0zj4d/fCtc7jQ7R8n4kzkjbfnUlpy9S2rI24j7/PoOKl+hH 3Mg+hCJ1MLrtbUMjtJ1tM9F+hmzvDWCxgxYYQgPX/dJcZsTEuwj5DqVPoeI++hEjpH4jpWnJEILK Ziymw2M6PBwvR2bdPdn46O7Gh3c/n12eP93f+PBvM8Y3PvzLzG18+NG9P83Yxt2PZz+9+unHn378 54//+PEXZ/949c9XP73a+OTu7Ms1cAcwt4h3SwbZY79ig5I+R+knUPHpAGaOKjSW9CFFi7PBXnDj qSL+cXeg8HE1hUSj+NmieKXma2jtL6jk/6D0Nyj9GUp/vAwvnVVpYvznA9jDjXOoqNCPzUA6TzZM co9i32cDRMKo3IeKFwNjGqJu1ho7AxWHpS5VPK2GgbGDJS2tGMrleLKwRACYVowStBQLZzCuGOtZ KXyP0r7RpWI9SwQa9z2KTc4HiPakojxB7eMByv+xapzocYdi47KaROkN6vyLKa38fGC8udvHA2N8 uIlWw3vV4FPNL1CBh1tbxPqXVr2oZq533TuihOpiAGk7lDQeDRD2aKCRl5NGAWc88N8NsAoy22PO /GJ6AuXjONc7/q9g/HjZ+qxKT81FxA/+Xv9cdihOfUmpfCEgMLXV8QAmlS+4NUjlF3CNKl84lT8f +XNS+XjcJ5TmrnFf9NycUnM32cwnmejmj/8JbQP9//jf0PgXEIobNJfhHadgbsaNWHnHidtstJhx bdSN2cWG+OHk4/gI6HY+YM5gGu4N7ilIXPIQo6bjWfCC8/Z//D8vftG8evFqjfNWfsJO43l/gqby YmDXiQ010uqud3gD/M2dZ0DNb4ysxs8d3wQpXGGUXkDZGzK+xnRFM+ONvgn87Q1rGQ4x8pdBHwC/ 3huQ68NBp9WQntbzhjlzYzjkwea3MMf/3UL23v8B3lyHLWVuZHN0cmVhbQplbmRvYmoKNjUgMCBv YmoKNzMwMAplbmRvYmoKNjggMCBvYmoKPDwvTGVuZ3RoIDY5IDAgUi9GaWx0ZXIgL0ZsYXRlRGVj b2RlPj4Kc3RyZWFtCnic5V1bcxy3lY7jyFYmKSep2qrdSu3as5ckw6w4agCNRve+bFmx11HKSWyL qTxIfqB4ERnPkDQvlrh/Iv8mT/4P+UOu8gKN20H3h+4hObJsrmWpGgM0Lud85+CcAzTw+bSYMz4t zB//sLOcFNMP9N9nk88n9VyY/9oM+ryznD7Ymtz/RE2ZfrGcbu1PinnTNKKp2nw2FWJeTZUS063l 5PHs4YaaN7xSbHa0sSnmDSuVnJ3Hx734eGqLCumLSsZ8vnk8t/kVm23GH9+Lj/H97fjjPn3fNlVX s+nGJi+aZl7L2W77lipq/b7NF42vwDzuh1bP44+b8fEwPu6Fqs7p+6HVTdTUcXxc0MfOWM2PB/Qt X9WStr9yUxfx8TwUJUM5io/PUFdO0ag/jz+eUVr7fEN1WfB5Wc0ebXy69buJkNW8UVLDZmtXY2Uv vn+C+kfyyaifovzThNf+Vx6KFvFH8liHoU7b/r2/Nfl4wlk1rUpezis1ldNaTk/3Jvs3khDJ5nU5 VRXXjRkp0a1t/cU2xrQ4FkVZFKzi9PGTD7JZp2sQV87FvK47fTGKwAye1WXtBl/awb/UrjD9b7Yr qhIpH15qVwrzb6vGHgQ15pGlgpoxj0S57QY1lCocVnDG5mL2fgDhC4j3QyS6e1S0ojxVRRFxWuuO V6qlj6YAnwpLoXXodM7rOS8pQX4PleVp6NsOVVu0m988wrms54rHzhNccSarQDRZrJVkVZm0+njG qCIKj/deNXVqrYYqTB0h60gdtlbq1M28qCl1ONTIRQBU84rpJLReKhMR0DLdCFHqYrPHsccfhR5v 0zkUSXJHfitthwUB1gXWSe9SFqlCI2CUr5iypZ4Ia0LZ2acBgaKWCsjnzVqr09bALFOpJp3wDAtu PuOzRkOop4F0e1K/17bHqsY2+Hhq1C36/1Nd4a5mxfMhTumnUhstlTLVLjUZWR2Si8mj9AeTX6T5 A5x2ZaV/VdWKvOpyVZqULrn/az0wO4CbVHPQ9vDZRE+sxjSra1uHTcqipWVZyzbR2EQpQ2JHU4fH 5EInmYhFW8r5SiwZbQM7jqrCmiALn5TcFjWViNIlTAMuod9rm3dJ/V7bNV+07bSvxCZsAzuGXGIu VNXy+nf6719u/ZANa1fXdxoUc9VoLyKIXCm5l/O6NPpaKe5k7rXvv/6DO2+88ebdHxrhu/8JK+jb op6XnHlP5LWNTTmveCW1J/D2v/7LG9p60zpK1ozmvLahfyxKNXvz3+7+1KhTTUMhaIknRz+62zoS m676TW1G1baJHz85fesnd7RHxPRPRRVr+3fdmDYdyjr+9B//cMfYj3NRVg2t/239c6WflZRpx8Jj 2zVdXcEF6/QsejjrUDasqQuibJhsZKJs/A8as4Il2QO6pix10YpV6EVDTp+3SEomeua6VSQ6huse EYHjBRNB4LgmbRA4n3AC55NO4EJRQ7BQiU3YBnY8MUVDBI5peyIIHGtYHQTOJ5zA+aQTuFDUdDpU YhOi6emY2z5Uw9JVoG67WbKa4tmZBBHP7oflhJdFk+QPAFrXqssqT+LOq1w0dchdpIUTUN+kmhTY pWgot0vJIrfLqojcdgnPbZf03PZFLeVcJTYhGsJtLvyU7pJVFbjNTTTIc9snHLd90nE7FG077Sux CdsAAPbtHerVgK2qZjVgs6bgqwJbyx8niOy8yuqGEQgmhRNg36SaFNiqSdRYXfDI7ZrxyG2X8Nx2 Sc9tX7SlnK/EkrGhaoxXvhs2KZsiclvWReS2S3huu6Tnti/adtpX0iYqrzZ7wL69Q70asKVILJAB jc2LamWNbcOOQdWmr3LWVFTV0sKpxr5BNSmwpUy4LSsyP0tF5meX8Nx2Sc9tX9RSrqIJmXC7bArK 7VLVkdtl1URuu4Tntkt6bvuiVveqmiSaIgPs2zvUqwG7aPhqwBbaEVgV2JrQkiCy86pQpSQQTAqn fvwNqkmBzayR6LnNuIzcZqKM3HYJz22X9Nz2RVvK+UpsggnK7UImakyTJnK7EESNuYTntkt6bvui 1louaULmNPbtHeqqwC7mcvqBt4yKajV49wwSU4u3PTqlopXQGg3RhqCFge1xvWpSJAtOwzNciCay V5QxPOMTnr0u6dnri1oiCZrgNDzDuUr0llnvCOzlJdFbvEz0Fi8TveWLtp32ldiEyqno2zvUtUei uJ6GitpG3197cvrmj+5ulHOme1LNfryxqealBns9e+v7d9/c2GTNvGxKkWT85M5Pf/bm3atFbaiY sWZFu7/n0Foxs35kp1S0WVqnM1o0tDDwXa9XTSpm2oii2NNQidjTL0bsuYTHnkt67PmiFlCC2L2u AY89lkRBOfO+X6uKSRTUJzz2WBIFDUWt6vdeaJsAgd/bPtT1i5n2z3m5FjFbYQ+HGaBr7M90Y4Df ArCI24/I4zTkn8Ufn8fHw+4WAvPjTnw8oMuJpqi2asOWm3ZhEWwUIlt6yEajS7o7J79cyRuzx2Fg o027DwBsf0qWO0H+0KYrLfxh+1S602oH9fo53XIAunrUJ1BdkV6TLQvntFWf/wXsKtyetBvrv2d3 OmkcyUL59YVIiqTToNEdmB9Wjjd9xWZ5gNvKye66ywCkE4ougimwZS7BrM+/pOhFQNwOQCR7WU4o EAAQzxA69iE6jiMQl4j7292qJFN0x9tRtyt2mxdi+THqFcZ0lIkx8duH+RBoYEtfZ9/PMIFPYVMH CIixfxeQ6vNeo+1mphR6eu7wq1qfROztBewsI2CO4+N5yCd7PAm2IjbJS0f0/c62I4M9vJsSkq6H 3Y6M7/WoaLC3jao6G+HiIe0V2B6CGXYelCBWkhB7S9SVc1i/ww6TWHMngAfQStQpeD+RIgC954gS vS2weUrH9w9hpxPNCXQ0qepef0tdolgLh+6nEd0XaIruTSsm/zTmJ0AHmpdM8aTWG81ACXeWfe7o rvb28nY0Y6KPQVNk2+/FyLxLdkRG9l7GH+ddzDjV8uFk69ePZ1sjyuWEUhqQf5uS1+dfxB/7nDId uR+UC6H5IaIJ1suQZme9R6NcLpCc9bqS36sekQJsnbTVvaBc8HR8jJrqTdcGKWewq6TWXUQgCCoy lGW3q5k5VoPmOdIu4xag738C32GVdwiHuouE5ml8vBzRLn2z7WBkaozKh/gPpGj8EoKQ6Zjmd/RQ x9KEkwwe3N4o+kFR0tQxagob/c8GbBUjPT2WGHTnLLzhuQUaq4lKJUAFQNumtQ5bWLGpvtnHjNMF wH0+JBEi44klwgemzhe95rvCOzQ1+oqU9xM7UyNE5xdQNy8Qugn6n8y6c59RzpfxR7iZHsM7zkKJ T9wlWup14O9kLhDRof3+ZMP+qns97/NHi+rvQ9FjOlQwKuzgTBE+sB48Q1WddvPzvlJUbgnVw+MO wu82ovpYUOIa4pm494PK12uc5DM0gkliZfRspE7wBipv4rdMaa3r4vMhpNOYyPf4jFWGQX/UA3uw q3uU5V754nxoD8ApB2tcWBQTEFoBp0G59mIOSsnUtALghQo/CUP5/AM4fDijbq/OX0KUBe7KkJ72 UprY0MQeIMGh45C/C9H7POSTl4jKP+gOxKhpMjoYZgEuin78Ag20P1+mUUo890VIJJM06MoeJTTi 1EkAOlazEehAzevHrRGkTANQDxAQnqFBYR/jHGEuCaAMamnsIsAJMXFsQH5fkRmZ60aURhQzUayf x8cLlE8Ubwwo9YOZZqogKI8TzAnkDFRREEQ5xQ1YkwPBtXQAAWkQjejzYZ/mGI2KVBUtnBzeh3s9 FjHqLWsMWQAAsDAglpg1UB6H1OWjCL+oDhNjgGg+oA77dkNq1t7rI1HQWPr1QsUwJPG8x3ODCWgA Q3hizESnDH/jdtrluYHfNmxqHzWVhASGkX4e1CWMKECjFwdpzxCQEkEZRN9116SGOz1ov5JjFF6M uF/RPduF+fH7ZTLXn/SKRpwZnGINDy29BIfDWoCs+UDvaopYRvJhkPSCvoSqivbrAazqaATykZH4 /bOA03FbA0xD0A8iqnfenVZN6PTdiI/oXicr0uFxH5mFvvt6mlyiaRZ76mcjkIdmySGiNNaDYxMG IXo8JSIxKzvv15LT90mvX3S5YvBBtMcJZeCwMQYFHQd8Y1EcpYQC1Hu/aRRtPxEwoMhOUaX3Rubu JPwC5v7rhl+GJmf/TuLLECQmoARK8YDi2+djT112h2+U3lPYZ7gcM2Yb9leHjdI7QUi5ROQ7huQd c0A+pEgAvsw56jVeno+qKrd63Vd6eJ6DkwZUChjz0JfZR0yBUVjSkx2Un1vD6FCyQ4nBydszrz0Z yeOQgHMost/xuWHwikC65751Ju9k/XeYZHBRfUkREXAM43kLRN0EvMMaJwkfkA56HOM41c1NQ4/j cfcWGJHz7qCE4rOHsCdw0Xwscjq2nANn5GQlfEXdS86+cX51xWafQcxFx4lESYntEXU3MUifxcee D9UR0+SYnbVoqbSqvuOUikcS5wJN5TaKhMf/HXFsxjYRwab24QCfB16NrVUOLWJ03k/MGABaqDwv upV2xk+20PU3IQXx2DT7w5Wsk01I0nZSsSBuKlkJ/WP89WQkZjR9xWej1FxPElI0ZrOpO0+vq8uj od3ZzpCY53QYVS2npR692YErCrnOc2YYq+c16fAsPelEM6791oOcdHLzY1Uka+bSHWtDWHutqTSJ ZANoLHvkT03CsV2ET6FUQZNot/doptLx3SQDspQ0lQvMEQ3ip1K8cj0WuYRRqL6fwyQJ7+NI8tg6 GDRFEut6cA8u9ihjozhMsIs6RWZdQjQYucr4wQN2IlxjJ3vGyJwaY+E4yPNfRI8n+6z0YH6lZc58 tueFrpozbaZYsll5TmSScZ2vhCfrh2jiJ8Zospbk8x/EH/FGZLgWsYOYlZxcCWBPdw88io+XiFt4 hWksJLqDpBlHV2MoIbeQ7at6N/54RnsNuopNm6FeMzna6ScbwVztnI1ZFtIfD7m2szFL1bSzx7FF 2zAaX9HUrFpj2PX08ewDNLOQPVdkYj5BwktwTyZ2GCHbpQwGpiF0lrGTB1d/+tOBgf3Y5sIxgzc5 3dXDHkfAVv+SZJf2H2vhvDCzzGrxf4/pja34+CA+vhfLbiT2ltSI1rhppYRLIddxjJ1QpdHYXlD6 h9iJRvkja9d6iF17ft53RTh9Xx/P/oSM5bEPD7BM9qbRDuZ/i2QKK+UIr99AIEMbAX8UA7fLO2+h 3XcBrBm8VAKDsmN23SMqfcPWDjwvNlFEPeGp6xbLvNBwX4fwWI8hQhmIT1036ay2JvGxh9GuLD9D ptYjikkwpSRb230+3qtD9uA7x1o7clwy4lfb/vR/fzyrRvxtsoh+834Cp+031OTsTH2dLyOTPRTD 8U04CfVDfemeo7MgcMRK+ubVn8WangLcqd4hbmB4sAy2P1nVhfE4vNEB7u89pPnh8RlSFXABEztO UD/gVafeFrLOlvColcZWdbEPuqS/evMlt0JBFVgp+FRwe4QLU6p8CYdMU0aTLn0SH/8YRkfWfD6k 1HvFpysXbC7SgcDPjQnv4z5LvHP5s75TbX0WDczAkHK94S9zjkWTDiMx1sMjjHjA9aazbxGTmtp8 7U5HF31lvEKZdlkITmRBkiPq3aTLm/pl2KyiVu5OgciPZDIiqw3JpofhIEqMX+DgMdwp8yxDJwD2 ffo4jBeyo2tsKRMuxg1tv063oUHncgdKIFzWg9p/Cnt6TN+Kk/G34hz4CClt9IQQtznCXfDCgpit 0VQlzQFbVfO9E1V/uXZFpeZuOYJ8kjn20dpYVATun0xsiY60dM4agEvwOB6/g6aOfoTOSBM0GyAw E2enZwAU9lAjJqpmrQYAMy4D5QhcAsUz5KueT3hZzcuadj6xWIidAowXojLi51J/gg7pVhc5+TAn 3FHzHL2/AnWBG53U6s1wcq/SCQIxaR+7KuD7dauPCllG6EnOehNuUXbuNXq5ikMqY+W1rCabt3ob BOwNVkHy4UkQvSBpxykcukOsQ1S4RfwzCDXoNJJthHAZYGgfmNlxeL0NBgv6lndI8KaV1U8IwPFa GE/Fix+2KbPjsP8VZWoz7MGmdtFS3VlPn2rVbCNClajWasBX9dzIBQFq70yCsPLBa7uGvtbVbCHU vHDq8KMoI3D2TDZ4g8BK7xCJ/Gkq8OuDZ/THDto6BubYx0YXFAJhdoVVwYNHcP7YwnAvqjnktANj dkEHAGSkHw5K1hSusKu5dzxRx9ZPPvYCIgL3N5+OMA0ukCY9QURf3fHO+q6t9LhjpcevlXvpcTJe hf01/l4zLXJ/CiJDAq1bfVXkDi/kxVpvbFLVnCc9i97mUzi1xXwS1iPeLJF7GH2Aq4r97wpiiDhy suJ8jXqwvXvPHArrN/WokfgyiW2+G4jwhzjcdxGR+kHjNLZJ7Avij/SIZNQk/lwJ3qs5uD80UBbE 2KGjRToG97rvwjFGc4p4X/1Qb+xjZ2NTotWGYw3RnL7IAC1MBXAPT/K1MMgfu4b0otdU9Nk6H6jD b97wHuOHIZ/syvhDfHw3TAV252Jn08Q6rtuRTVGS01xL5g9QfZT+4O72ovljd3uVRRMO864VedXV xJKkK9y/2+ua1SRHvMqG+0uDbFJU4dxT2ZRVOPfUJ9y5pz7pzj0NRS3lBE3YBty5p1IJelC2VDwe lC0Viwdl+4Q799Qn3bmnoWjbaV+JTYjMmeC3eKjrv9OrKP0a6jUv9fr1O//4+jt33mhv2jK3LdC8 tsaNTT5nqqxMTuYCr5/d/fmvMldr3d3YNLszCp7c1vVPb7/z1pPTd97SlWuvW+u8OnNpV1vzZrxP zN0CFm4Tq8mZaP/5ZOPtJ0ev6/7qDlZFcg/YvR/cef2fzSCreaN5E2uibenseaMqlnTmycad9eqr qmD0kPeyrDv6yv2wnDR1k2QPqCuNDXOxpUAvNirmLZKSiaq6bhXpFYSFUER2q6KMp6BXhT9d3FyI 5xL+Pj6X9Pfx+aKWYORIdN+Al91GSSq7TVVG2XWOsVMOsqSy65Jedn1Rq3AqmlASq6lbPNQr3clR BnXdwlcUZXrdnf9hqW25okjyh25RqpkpW1XwVaaamLtIC6c3GdygmgTYpZtNlj7pGWw2zzSVCtz2 Ccdtn3TcDkUt5QjrSzKZmWTN6fH+Ze0vqDSVqCYe7+8Tjts+6bgdirad9pXYBM/cZHCLh3olYMtK 0msC/IpsBLb7wd1hRPPHblESwp9i33m1vf7I5y7Swv1blK5ZTWpYVn66cckmHqgvVRHvzPIJb225 pLe2FLkmK1RiEzW9WkiyoibclkUTbzmURa2iGnMJr8Zc0qsxX7TttK+kTbgGgGF5e4d6NWCHmcvh mJUdYDPnUZlLQmn2yAWlgguJXjTmos9bJCV7F5Rep4oUz4WXWpdU8UZgTcl4uaFPeCYX4U42x594 uWGoxCYkvdywbJqKMLls6jgtl25GderRT69OeYbp3CpWV9Sq3LokiabK4Pn2DvVKeBaMBw9fw5er Ir3d2/+wnFSiTLIH8Fy199T4O33SFyse8xZJyQTP160iwbNwN4csfdKbb2YrBKvi1W8iXCTS8kCQ i0s0f0JRSzBZkkS4uKRNEnC0ySrOxsLhwTYQwdE275KOyaFo2+miook6Y3jc4qFezaJWJTU8eOOv XX2U/qDziyrNH4poFcqUrTl8VQ8i5i7SwmlE6wbVpBa1UvQmn1LVcTbWtlycjX3Cm5ku6c1MRSbg UIlNqIJwu6xK6j+VlRBRe1X+jmbTQBWuc26br8J1zm3XfNG2074SmygzruItHurVgC0VDdX6ZS+i qMP9rXryp9kjhgevwzWCyYvGavB5i6Rkz/C4ThUpnuO17pZERQxblu4ydUdlRsOWZbx23fKHxUhl qMRSr6FhS8EaejOVYHW8mUowFW+m8gmvvVzSay9f1KrcmpFEk7mE6xYP9WqGR1EkijpveDDeiFUt DyYKQeyGzquM14LYCknhNPRxg2pSC6QQ1G0SRRm1l9b3UXv5hJ+WXdJPy76opVxJE4K6TbwuaTxe d5Tc0Vn74Hx7bXO4qs1e6hziCPbCZxKCD5XYRJlZerjFQ13/0gOzwXezLP3kyKwSVMKspL65YbZj aCU5+9EGmwvGlP5pU81ZKYWYvbHRzAshOSPl7pqnmjM5+6GuRs6lkGz24w2zOb6plL9+ji5mFHMl tN1R+MMAtB5RqjIrv7qiRpU1S54vyPNeUsbtYOgMeNM3sKlZp9yRA692jO/7MR6R/u+Q51PyfEme T/yL5+THQ/J8TJ5p5VP/Im1lO1s4HNbgSWd3adsNOa6mveQNzJMl6vsi09/LTCW7/kXaynmmkilq 8TRT+IsMFXfxGB1VLC3sMtWOL5kj/P5VmjjKDPAwYRog42HmRUrSe5GMYSAGnXYghwiS5xmOPEug 6l5cpQ9TNJCjhCyQ4IHe4aWLTGsHmS4fjUlOTjDO0fjyYkbLuBf3MwXy3R5i1BIBJ6crtxOmjbw4 zVIDiNFphoyjgrsK6QLNc9yEsvgcceo0U8MCETxHxmnmRSg0n2UqmSN1/G4G+7sZ8gYYP0PUMFQY pd1ZlqYjU8RJ5veniO6raKfDqyAyVfhdCRkYOd3X+Lk2zYSayqLy7iFvypBc2GTZNMHh1oVj8mDy 5+nReuwt3SnzQeU3Ym+1I/94pa2L+X5LJs0GctpvKG+LzPN01DrTfrj56dVbZ/eQ2jpL4Dcyo+Vw e5qRoJ4xULNmtrlBYasEN0utIfIkY3LhkrXyC1Rt4ZBcFbaD7K9UeyRdrebC7V6lVNhPnrvCuRYA OsGRqpmHb3SBLXCWIf0UKaycCbsc5xNGs8OwnY9eLYrDpEYHQFX7QWbwZ/7Fk0SN4koOEeNzZhX0 K7zMb6NmTzLaJG0BDHQ1/whMDaVsGjI1+KSfGmTcXdgW9sk1Tg2ylOGi9+/S1ED7/R5yi+jzaQZ8 C/QixVDOuup7N8h5hc7TdqZfy6SPwETMuW7pXAGM55yNkzrk7sWMSxTtXugR5AxIaNhfO5qwmyl8 JR8EujlBfX1OSl5k+nmScO0KjjWcvXMuQy7I8QIpoGWme8DvkFUHEH239zk2bcfdHIjbnEmSshs6 GuPg30FkvMxQA3oDedQBnKwQRcBQvEDgz0cPaJ9Hprn8PDQ6wGj9pUoJmIf2wwuqB44Q8nM6Afrp 8wzdtrIkAgYvJQUd6TJ5BiKzCgfPEQ0TL/ACASIXckxnFjCY7Uw/UsUH+pSb4CgVLsaEMzVaId3J yF9hbCyHsntjujY3E6ZkohML6OrV4h95rLoXlyv04yih1EjgJD+9AqhCLQc9Flrt88xg93ATuJ9w iqcFVrOaRrznvNU0KkYD8eDVlAeVhREfcCfbZYDAnGO/WDNFATRGVyDysz2whReZUdMX56A/cRb6 H6SFTrNcAFDN2eA5XIQXc9omzykQoc8t2EBHNgvBHI+pIRQAf5j8iMeQRltG4kx51bc2CJqRhwFc ZgaQWz+COuJKdkNeF+dmrWu4OtTMAgswVw07HSFJzRWGAP8iQ89RlZOGaa6tHYG439yjXgX9aQxr hJVfZF4ctVaQ+Wsw8Ldw3eCHqNPPEsLlWAs85sMMaZYJm0fiBzmlB6PzuVnyGL2IZf0gQ92cc3E2 pp1zKv7aC69niM/5+AyFKrBK026DCfg5am41fLwsSyknRntIdKiazDmA0F+7xJTp+6Or6Lsj1M2c oObjEMASXy0OsSLWjDqgRLKqob8KYA5Z+jasAqwwWYEguCjCdzsm6u2TLgjOyaeBunBMrjEIbg6q 8sekfJeC4LTfQed/lEFjfivSyGRBhQVuBKCxbxf6/v+3U8nI6je8U6mvCDSWvyFF4I5ONX/M6VFT Zp/N5WSsmXJlT0vcWU4ePJzcf/j76fnpxd7k/p+njE/u/3baTO4/+Og3UzZ5+N7066++/vLrL//+ 5V+//N7JX7/6+1dffzV5/+H046TOohJTXrkvw25Q56rHSY1rDENsK3gPkM20SqQxVYaQltzs0K3s IS8rjlv/0f+9+F7x1Yuv1jhuqQdsPgyO436fDOVFZqY7RAKR33+T2bTBGw3AirebNgzCX/WmjZm7 UyK/teQ70EstoOwb2p48pCuKKS+qbwO+eWG4xstwiu5jNKGmy4vYLsxvPqrmBWvUtwYhj2ef+jH+ jd6z4T7e4LWi31Ty2n/1IhuT8Cc7FCGxMzEfd4WkttjMuaKhaMXrWIlNhE9ubFL4T3xsktvP1W0l 7jOFqky/aGibJ180NN0vGrgiCRE/h2b+w41bPEz74cYqopGe+NSVDdm010qYOd2env6LX/zitV/+ /FdPZuEU9Y8n/wcxshf6ZW5kc3RyZWFtCmVuZG9iago2OSAwIG9iago3NzU0CmVuZG9iago3MiAw IG9iago8PC9MZW5ndGggNzMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzdXFmT FMcRFpI4NCh02LKxHWFFW/bDjMLT1N1djwYhCSQcaFlbD8DDag9A2gMNy6FfoX/jJ/6D/hAROKvr yurJOZZdFmmFIKq6qrKyMr/MyqrOnh8rVnNRMfcnFtZ3Bqz6Av7eHfw4aGvp/usacHl9p7q0Ori4 0lQcBqpqdWvAamuttKZr55WUtamaRlarO4Nbw6ujprbCNHy4OxrL2nLV6OF+Lm7m4sR3lTp21ZzH dlfc9+2GD8f54We5mMev5YdbeLyfqjXDajQWzNq61cONblTDWhjv26WNBFxxK826nx+Oc/F+Lm4m Uvt4fJp1TE21l4vbuNhbq3t4D4+KpHbw/EtP9SgX91NXtJTdXLxLsTKhVv1jfvgQyzq2O6lrJmpl hjdHd1avDaQ2tW00wGZ1A7Cymcc/oPhD7WjV31Htk0LX8alIXVl+iIptWmrV8XdldfDNQHBTGSVU bZpKV62uJpuDrUNZiOZ1q6rGCJjMWQnMtvq9n4yDOTKmGONG4OLKFzObJkdgrkLIum17vDhH4BbP W9WGxSu/+FfKCod/Z7LSGFnq4ZWywty/nRu7lNxYRFaT3IwrIue2kdxQ6XA4E5zXcnglgfApiff7 lOluYtPK9mQYyzhtgXHTdPIBCYhKegkdhU8Xoq2FwgK5TjrLSeJtHbstzObxI1zotm5EZh7hSnBt ktA0O1KRGVXMemvIsSNKxX++bum04IYMLR2p2ywdfqTSaW3NWiwdQXpklgBlX7OcJPglVZgA2LSV UkG34a3M8Y3E8RreQylL7tmvgTgsGTB0OEp5K81Kh4bAaF6zZBVshC2S7PBOQqBsdUPY5+Fma8vZ iF3GNLbc8JwKDr/jcwsQmvJAMJ+Gcd183Fg/4a3KuVvq/ztAcANU8WSepqCkIGgxjSO7A2Lkbapu D26WD1w7K9vnaDr01XFo0zZoaGhtyqoO1a1PYWF+AYchc6/j8O4ANlYXmrWtp+GrmnWyVK3uKtZX lE6VdZCOyNVtqHKZu3aSi0S8GP0E60Gq0ocg27Gqhe/qiEgVKm6CUIFx3fShCuM61mLXjulIxFf8 BOtOXLKWjel0fQ3+fn/il+xUu7y/A1DUjYVTRDI5pUW081Y5f900ItjcqTffevv0mTNnz73jjO/i Cmd4tGxrJXg8iZwajXVthNFwEvj4b389A9Eb+CjdctxyagQPmWqGZz8594FzpyBDKXGP27vnz3UH iXEgP4YwqvVTvHt78t77p+FExOERM5na32EyCB1Umx/946PTLn6spTIW0/8YHhsoN1qXjKVixxqQ Y0LyHmf5hHMUzkY0xiJnE11ocjbxwc6AWyaK9jnOhlu3JzaMk0N5a3lq3S47F87mMGQKZyMay5Hl geJEsjzRcpEsL1aC5cVqsLzUtZNcJOLF6CcIlidMZMNXtWXJ8iCsZcnyYiVYXqwGy0tdO6Yjka4S JiiczUlfqlPpMpgPjEi2HLCFYGZZYAt/mo2I7A0V3BoEwaJzAezDkCmBrXWhbe0dchBpI7O2QyVq O1SjtmNXLzmDK7rQtrIMa1s1bda2MjZrO1SitkM1ajt27ZiORHzFshnAPrlLPRiwFW+XBLZidmlg K24xIsuhQtoWIxJ3LoF9CDIlsOGEg7WtvG6iSFnWdqhEbYdq1Hbs6iUXiPiKtFjbMgatoWpM1ra7 70zaDpWo7VCN2o5dO6YjEV/xExDAPrlLXRbYrNZVDEgkM8vBeyogcVRi7NHrlaOELmjIMQTuTMQe L0emRLIUOOoXUtqsXqly1B8rUb2hGtUbu3ohSVwROOoXoin8lrtGS+oVCvktoQq/JVTht2LXjulI xFeaWS765C71yA84ArYh1vpLnVO3J2fhxKFqDpyY4bujcVMrAHs7fO/Nc2fhCGFrZZUsGt4//cGH Z88d7DCAzYzbJeP+qV3Em5l33r1e2bV3nj47ftyZ2DBejkxpZhBEYewBVDL2YGDGXqhE7IVqxF7s 6gElUdwbJojY48XhWvDocB0Rjg7XsRKxx4vDderaMR2J+Apxn3DSl3r0ZgabolDHa2YLz9zMiuVs TzZaLxvBAUA0Cr16Q2WjNDKsonN5wXcIMqVBci4xSrnQGaVcqozSUIkoDdWI0tjVQy8Q8RUuMUqZ Lg6iIJqMUibRQTRUIkpDNaI0du2YjkR8JZ4Ppgzy5C71QEcTbtvizK2tLoEdHoCcJC+a5+BaKRdp cUMNdHdzsW276Flg+mVJlHhm0SZClaPzJxPo/BkqUcmhGpUcu3rNcVxhHCmZW2mRkrkVTVIyxJtt UnKsBCXHalBy6uqYTkR8JR4LpvB8cpd6sA1mUbaU29DC5tKmTIM65xRUOZPgX/npeso0+CFnOaHc qb3U/iQ/3Ma5VbF9Iz+8m4tFapHrqo3EmUH7/aSEnDkDAhSaV2PY/+OF97XMeJ0mrvJsN3KRbP9v Lq6l9of54UO8MJToFBmf4Hfu6B1sfF17LT9EiVK71OtctPCQkyWsDly5rruYfip+mdpR9tV9zBVK lIoPr5A5W54riGJTolXJdU4P+4Fk5ZPUPot+V+R4UffwcEJ+X5GL2unaZSNKoafidZ8IBuahWRNf v+QUGLS8IqOEUAoi+llq35vSVC/RbpPKtkkv5seRMff2RXjmiqwfwoAQZK9TGYkFZGP7/Smr8wbc k7PDMZ15czet4y6phz1qnYj+fsYxmRAYVgXzr1GUNilEIE7o3EoytW8rFx+l9m1SeT9RFoPoI8j8 QBknWv+TqanA1yKuNqhVFe0EjrMotshJJxT/hXMh5HOflCoNWRZ8bxQEYDZvCmin2M/FCYXJ73Lx UT+9zT1EXad8p8PsQ8woof69Be33yOU/zJjNkt4gJb1O+d6p/a0HD6SJOsHf729hX/t6sPrpreFq lu49SnrI4ivKY+zlYt7SH5EeYZOS7j4pvYzotSmRlXaKkg+nTdpJ9wFFikwB3iBZyXb8kFTkVLax 29mKvN1kkjmx+dsFJrWBB6X2x5hq7FrnhwzrnEjnLnKQCQEi77RGuQTS5aH5Nyib2O8zlQOtsbvJ bHRbhFp2QQy5kp/mGBBlyqOk++wO0EPkOdap9iL7+zVmlvm0K6N4urpB0XPefNGOvYYXSbSjRT5N 7etk+1QKuzPV+yRoc5BJB0kv5Qhp+yLxN6FY2STxh7jaSKY678uJnv2g8esU1KfdbxGE0ovCKdHz /dMWfoi6EpZKbgnrFNGX2932Fui34I9O+VZSVFr6O1YJ2s8Zoz6REdq6G4hXnrkfDE3ymgVDi4oq omQUMZAuZu53P6UhbuDxCH3R0LamcFQCpSZ1srpAEVU2tAllKGvUVDS6SUOdhyRnaPfIqfYp+C8K I6ctheslDIWgVJgH0V7EBHNPe3TsRR7Rdqn2WX6K4L/wU4QkC01M2ZyQnV1JqcyUzYW3Ia/8E5Vg c2D9NuR0o5MpuW0X5hPDCNT+GJtfHI/ui1Cc+qDfdXbwR6oXtS8KLtHTbeo8uEm1I0NFoNhbaCg9 rns3LFObX8+80e6QQ17iA71ZW3I9jbTwekvw9kiy38NXDBk1RPo7mKbwCE7p6K8Wwi7zeNYXX8q2 x/PxmefFJQyq8Db922xO9yhz2sWWFduRYUyw5cT26dsd/GmqxDettDktCisW3UKuZMv4PHW9nNvJ u1HaRjYpc6IvhbaSOdFh52GDretpC/tP6nkT7+vEor6bscUTNwUolicvetYoSZG3R7TjIR3TSi5+ nouXF0hijW7vOxbV2nbWFqYsO56vLIPNtawOUeOTbHLkDoSK2eSQHU2odvQQWe9OX/rO5B4vrz0U NUwok9yZ0k55tzorwJx/uZrPVLPsCO0w0eTWyXby0PQQd43taDzC7P1kcnuU8U7vZar1b+6EkPxo 9jJba5PhQ+0ejVS9reywn3J1L+y06X41ocMsednCc7G4golR17/JbSBHbWibQFcS+SSEbheLqK0H f6eTlZcE0iKH3APS3Hd/t7IMVtIaPs/cXs5Fkdp5foiKNrXfCUTzN/6u/VJfnL3IEu2q5F1H8ZqQ sJCbGOLzu6LXZF9RU/1E2f2T/HBviivnQvK1C70BbFHeaEJN9QjrcL43ou9dSJAdYK/ap/ZSci+8 SmkNqRLxt05pnd6W80uTLnMT3BJ6z7eC7SqSRD9xUbzEne+1dyjt04fdLNKvSVKPKVLbWJGxHaGP uFUEo7lEhX83KFbQx8JqAeYXAYG41Ycip6ayC6Y60E8QzF+VxcXY3kxb+jFdaKtFEROztfTHt1PT ex5wfKTHt0XcKP8tf7cZvjkaq1qDNTfDt0awLxvVCDN8e9TWmgs9dJ8x6lq7jxHPjGQtGrcjnO0y KbWSw3MjUTPDtB6+M3KfSnLeqtTRuNHut0G4wWPQNLd3oStzKfXD84nS+dHY1k3LrOhPpG3b5Wi6 LygNl8B7UwvLGRCa5KfvjcYgMQFElZiaVivVummB2dbllBcjA+NMFdNpWJaWcvh+kBTQOuvyRBtu WEH2HRhuhIWo9IPYlc/i5sNOMrbRzfB3IOsOs793zyTX1iBOPnLjRdNo2QnWqpopVUZpzISfEGlA wUtHabNBIrRwYM0oITArbdOP014xZt2vAPymIIuRhVDyh4yNxHIEmSiRxUEPzNgD4jU1vx/MQ9FU 0fILvHKQN4eVokEFWlPxJfEqW6s8Xu1R4VXVjckIoeDaMn28cFWgWnEUeP3jiNdGuy/Z3+7kDa7E 0Rm7nyZqTANjYDQHzhNM4GA8vHAhQmIJTJ1P6DlPDbqQIIEHeb6MlqiEIIUQfyGjEy2BnOpgmIfT qWW8h3nkpLP59jDPwNseAPMfzsG8hgUugfnG53QDFtmRYF7y7s1dhhkFeiPN8YLe/+jUb8lJ/ymj YEaAEOwLCLin7tUtzFHaRDcXHO/CDNyo/rafUJWhNmN7+LPHkmFt4aH/4saBjakSoiFymAdQ5JQ7 ohGgogSo9t90wsAjcspKdE45QYICaPj5mON6b6FYM/slihS2fambpyW+RepSfsI7vw5FtfsBFQde d5IWrYMpuHPOG69erlzAeWYEAZjUgqN+51yphVjBgQN8ipaag/8T1v0mWJNU2v1MaCc0EElXBlVI bt3Hhz4ffmdw6erg4tXr1f7k0ebg4rcVF4OLX1Z2cPHSjcsVH1z9rHrx/MWzF89+efbzszce/Pz8 l+cvng+uXK2+KWhC7FkJ0+jD0lw2K3+xqLmMd9OXRhy6g7uYOPjDnqPa7nIulXdReQOV94ubUFKW wn0QYTg/wLrhD/z39A32/OnzI1y3drugweu+gpbyFJUfoPJ9VJ5EOW2ihw9ROd269MA+FhYACNY5 9i8pu1uYV43vnjQkqxtpWn8X5c26z2Xs8hvhEgyUi+Phcp6vYJVg5teAb9hyVfcrHBHftyJeb8yw 67uovLkMjiFOYtw2vxqE3BreiWv8X769+mbwfx1CCUVlbmRzdHJlYW0KZW5kb2JqCjczIDAgb2Jq CjQwODUKZW5kb2JqCjc4IDAgb2JqCjw8L0xlbmd0aCA3OSAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nN1dW28cx7GOk2NL2RhJDnBeE8w5J0CWgTnq+8z4vMSSZYdODMgygQCR/SDx uvYuSS/JWM6fyL/Jk/9D/pAAn+7pS1XP1M4sybVoU7Tkvnd11VfV1T3dza8KVnJRMPcTA3uLCSs+ tH+PJl9N6lK6P20GDu8tioe7kwdPq4LbiqrYPZywsmka2Zg2nxdSlqaoKlnsLibPpjtbVdkIU/Hp yda2LBuuKj29gOABBJe+qNSxqOY85rvghc83fLoNie9DEOo/h8RDXN93VZtpsbUtWNOUtZ7ut7Uq Vtv6Pl82sQEXPEy9XkDiNgRnEDxITV3g+qnXbaqrUwjOcbAzVpd4jGvFpha4/7W7uoTgRSqKhnIC wSOKlCU16q8g8RzzOuY7rmsmSmWmn259vvvRRGpTNpW2sNndt1g5gPpnFH0oH436BZW/zGQdU0Uq yiARBes01KKl7/Hu5JOJ4KYwSqjSVIUual0sDyaHN9IQzctaFZURtjOnJba33S98Z9yqI2OKMW4E Dj79cGXWcgPqKoQs67pDizMEbvC8VnUYvPKD/15J4fbflaRURuZy+F5JYe7f1ow9TGYsIqtKZsYF kXHbT2YoNzicCc5LOX2cQPiSxPuMUt0DrFqgT4YxwGltCTdVyx/LAVFIz6FN2HQh6lIozJCPSWO5 TLTtYbOFyXz9CBe6LisBxCNcCa5NYppmG2WZUVmvz6YcG6IUfOe2uVNbM2Ro7khdA3f4RrlTNyWr MXcEaZFZAlRzy3yS1i6pTAWsTjdSKlts+gwofpIofo7nUEqTO/prrB+WFNgW2CS/lWa5QUNgrG6Z s8pOhDXi7PTzhEBZ64rQz5v1Vue9EbOMqZp8wnMiuPmMzxsLoZ4Fsv1pW6/tj5vGd/iscOaW+u9z 2+C+FcXXQ5KyIWWdFlO5ZheWjbxO0fnk0zzB5bM8f0DSoayOVau6QlVDbpVHdYge/sEOzA/gJs0c txQeTezE6lyzuvZt+KhmLS9VrdtI4yNKp8ie5Y6A6NxGuYSiLediI56NvoO9wFXpXZB5jGrhi7pG pAoR10GI2Hpt9yFq67WkxaIt0bERH/Ed7Dl2yVJWppX1R/bvF3d+yE6069s7C4qyauwqIqmc0iLq ea2cva4qEXTujZ/+7D/efOute/d/7pTvwVPOcG1Zl0rwuBJ5Y2tbl0YYbVcCv/3v37xlvTdro3TN cc4bWzaRqWp673/u/9qZU8tDKXGJz05+cb9dSGyH5retG1X7Lt7+bPnLX71pV0TcJjEDrf2v7cy6 DqqGpN/915vOfyylMg1u/7c22dhwpXVOWAq2pNnmmJC8QxmscDZhbITiNTI20YQmYxMTFhOhWJPl Dxgb26otWzFOVhWyqVPuPC+cGZubNJMZG2HnS6R5QmmeNE8ow5LmxUjQvBgNmpeKes6FRnxENkjz hIwmMESNSZon3Oo5al6MBM2L0aB5qWhLdGzER3wHmbG560N1Il0H86zURYS3ZGY9ePOGiSzftXJk k7nolUog43XDUaWscIbkmzSTI1kKPIcIKRsQr1Qwh8RIFG+IRvHGop5JEkcEnkOEdYmxeN2iLIlX xEZcByL113YvUn8tabFoS3RsxEcqtgLJd3eoG58uhXW1We2XCG98trxn5y9VckuJmb69tV2VyoK9 nv7yp/fv2QmpKVWjZJbxqzd//Z/37m94aqlMc03dG5havHKkOaFT1WsSKBYuTCjk9ZrJFbJqOEZp zQSgtOYCUBoiEaUhGlEai7aci414NvoOIkpNJMNHdcMApbpmgNIQiSgN0YjSWLQlOjbSRkIHhELe 3aGuO7UEQiRbD9hCMLO2z+Q3SpOzk1cVvDHY2cGFc5/pBs3kwNY6k7b2vn5gaSVB2iESpR2iUdqx qOecwRGdSVs1mflVFTK/yiDzGyJR2iEapR2Leu+nQuY3dEAA++4O9UrA5k2dAVs3Ogd2SLB8kjzL HsC1Us634Yaq6NZWMW+elcwwfd0mcjwzlgmZcSRku84CIYdIFHKIRiHHoq3kYiM+wrCQeSMbJGTe iCoJ2U4odRJyjAQhx2gQcirqiE6N+Eh0xHt4vrtDvc4agDdr+iG9Ja5fA/iVZacU2NB2GQoWFhcm VrPXayZHsjXqWLzWjwXx2oog3hCJ4g3RKN5Y1Hu7Es3DoYNorni2jyR4XA26RjjaR4qRaK54to+U irZEx0Z8hNg6u+tD3fwawK7YhfqBrQFYI9bTPVlpva6rZAGikY/TqSorpZFiZYXzvewbNJMrJPe2 MaKUCw0o5VIBSkMkojREI0pjUQ+90IiPcIlRynTmGFvWAEqZRI5xiESUhmhEaSzqJwmFI9Ff6Snk 3R3q1RRy7CCVMwBBGZt0CKGE4wYCgii1SCdZduAAFDpWdZgOKZziA1QpuKDOUl1AcAbBv1Pnb9Ch m6dU/iH+IDp83gEdRdrrNiUaHY8aGRkO7Vg77PbY/zLZ/cOz6XuJZZfAHHT87BiCp2nIiA+/h+B5 yi8g8T0IwkGyfZKlB92mrGOfzklRRzzgHJJ1Z4TmxXYY2n74gGiBI2Cg6CxKJHSf7B3OyWWntFL+ Q4oRCAYn1Jizsy4tzazdSPLU/Q0f+CNO+Z1D8JsudS7xHQgWKZ9GNjp4Uno21w2QlPj1GChaUPxC Q79M+WcY9Yi1Mf8LTGYKopMNpk8RMOkRhcUzUoQg4mNSREcp/4Bk0jtYUyMW34fEP1MnCdE40OkB OKHBCAgkfr8/goAFHgeBvy+7jWdqTkoT8QOZq3nKf5eUFvT+gkTDH2Ho/0isI8xVxjqk5t9QJ7lK SET4Rec1F12LEIFj47+/rYMb/lSDcR+Ow5bxR/hwXOTjl8A8NNm8oMzpQ0rrlmT9k+zUipKiUE3d +oha15s4KMKt1a3R6IiDIrbH13My0nPabTmqwOnbsqg9ptdNywLDNsN0oSzTYaAk09nrOQMamF6z MvhftzVn9HnuXdvN8jyOk2J5zZvXifOqnTgcy3/8c2JPeJVoedkYuRHhGbvuBo5Rwqukep36YtoL Ja30bj7p97hnVDsYaZfYG+Be0254AMkU+7TRnn3pcN73yz/ZuP+tNjjXc2u+oNyay9t3a3oCtoN1 7Oacb0TCvNZu/QxcpURs7dvrNG/OAKykRfqPmghumzl86g77yXD490PA1WxkIwCsJgLbKYZYzH9C 5i8xBCKuLgFMnYs2Svjd+k1etFFN0y4V3Mh3KYs0J+eTPYozC2rkyG26wBYtjXyeRo6uWD3vMgEv l55QEkKa/w8cJPKR5u9T894RthyJpFmiE+3fvAfBw6TZh/1xZNc/0DizebUNul0bfxVL84paCaM9 LZao5z3vyAUltYz4GJtIQsr9zQxaCjtAxwXFZdTkN50FmoNlXSquG7TTbueaDJiqLrWIpp6VNVO6 VhZjKWj7ctcOjLDjSIlzCL4LwSIVPQqJlcG1TiG47BW1iXTRMhU9W9FUCu6lopeQ+EcIor4uU9ED SDyH4AVFAEo8IJlxkIrudWk1UmjM1xnV6nOyVSj6HFNF8e0izmbD94Iad9UOZO8ngW1hl5u8EsV2 0IS4yZf2OdqV/nZvK/BKV2zna9s8ZMguseJEBZ+TtgbNActkS9B8j665kdu+6N6sV6haC2yLPiWL AlUXuP3O5klnB/oEN5XbojQbScFlZzK++XTUHkPtzUbHlJVGnN1J+Y8hcReCH1B2kJ6NvqT8O+TK wYVdxKNTKv+MzD8HKz+jJDPDtYiukLyXlOSOsOQ7RRVv4oq809VJauqI7AquGR+TIApFuUYfPLIp vjOLog8BHUqgp29ISk793WiLIs2qItxIAE4UpNDg08iYuhWk0A4p+T7H7OtoZnYBdTtSu+2nT2+W ErhPKLOCcH5zs0S4WmicT7owWYdPq8xSAjfw6Skp5yMKURdYesMiWXZF4sB9SjZ1TOlJr35nVBmp EdzHlMaSxiHrftgWo/EtKHDPKN3MmEZw6sUIuNGKc07RN8NEEU3tY/opnLMw/6KpFvaokBXOtquI XY7MShOrLbRh0rNXnfn1SvZsmBFnAPQ5hS6SZ9mkOoyJbBboWGkH9FU6QUgaPWZxTpHab8oC/ZBq aUylSP6i/OzWOwF0PzxZiRXPfpxSipDNEgMGNwI2W9uiLf89CC4pnKGNIaiPtrcRpHvzasfgknyc YTERONwnJb4HOLxMRYlHT7IpnrY9wN3lCpF2qHY4pKUPkH9J1h9TCfAmAEe0Hn9N6fEM84fIR/Wf r8bhahdkTgltb2R49FmGYduJTmWsf2wBARHBGz65IKCjTwE9t7KzH3PUlf46k+CClMkRYJZs6gqY XFCSGJolO7bzhOqKJoV8SCdDUsQs6QEj+uZU/gsqH/X0f7jTQcwO+UirDQlg9pwcHumhDxpc9BQM GEw022eHfwiDTH68Qt5AfyUH4HTgfY4pHp7YyfzjnmwRznMPd0EW3R9FDGEmaIszS+A9we0T0suc dcL276/I7xvcgixJbnKSLgitRhcUeE+pTmcjnOxtUXSEeriCqTdbvkXTHLWk0muYVsKtRZ4FfERA lRDQ0Tm0sscom7hDyXlMOjRkMw+UMCgnFCPH8umlEOlsn2FSCdO8R9YHeFyS9Vc8D4WcCGLUNNXk UjFrn4D32YAzvErlLqjhh/yq0itXqusvqgdMd2wx8zuQvX0KQdhZe0SaZvi+gr4TIT1BElsk0z2m 5fQUtTei2uj7ythkfkiB+xK3Sq6DKZGQa7aHEHyUmnpCNlWl/HrFLBJxNEbUw5T/CBKzTmN+BYkN BMs+tsPufIIQ2ncfO5uCDCA5/SMMQf1DMn8HDydi6CnJAzAV9HoLMJStO6np/3LUFBBqnZnd4Tm5 t5rubHBdazcDseoxBHcThj6giP4UN0qYYvK5y2yHAxUd3OAa89loxd6niL7Z9I4eLzyn0Im2V8mH VbMDgjE/O+PeBTJYeofeQ1LOG1p4+nsBV5x0XOLYpuKQH7x6twAU4e9k/Rmlk/2lE1+xFdc7ubbO ImmVz0Kgd9wlILyTOWY6wcnrfXsYnNQRpOFzPf3FAY5TIYOdLb1ifnZGDU36HZys3gAjcXaKhTts UGYA6ZMRMwDcox8cPKHQQz97PKcmdfIjF+2xQlertoUipMd2QEjfEhUld0jOcXDQII/59mPLjFX7 h8N2ZHzLesh2R0IqjZ6nvu6u2PDGBfJpzyhBjT1/TZ4OorcAslY7QPZbaYRFoR3lFyNdZZ88ItDR 0mxOjeoKm840UnszEtejmBoDStb8oO0eM7g0emc0pwesMNo3OKMcA4RDOJx1iBNRUcLx6N9CzB0L +iTB+NIp5r8gxYiWVqdUUfJzF/2g+opPjJR04FBDdmj2CtM5Aam+h2xxuJtKfkAS1Tup4Zbo6EF4 0nHLBj0IzmyBk4JPKfJJX3zwJEqO4wuy6ArjtKYHDe4GssLZXhfhjiCD+27KfwCJKIj2b75OQEeJ JTVQhN7s9xHE/HIFIxLQYa/lAWk6yQkhtJqu427sCQCphEZPAEjR1NkTADFhMRFVk2UPPZZU26Iy vg2RVxQG8uZZyfw5jms2kd38l0rFV2l8ND73pl3EVOk6fIyE6/AyPZnb3mRPRT3D4sNzbUTFVxPb qKzjuzc+Gl8cco1Io9J1+BgJ1+FjNFyHT0VbomMjPuI76N/8v8NDvdIjSUpU+JEkJUSO55jgHipi WfbII0kqPBzYragES3nzrGTvkaTrNJHhWYnsiTfbCrwcFK84tFyOkSDkGA1CTkVbhsVGPPeyJ94U N1jIimuVhKy4AiHHSBByjAYhp6It0bERHzEr8HyHh7rxp2U0q8sqHH79zHoHdsTSzXr3ttz8Kmo+ /cUWLyXnlU3arkqutJTTt7aakkktOCp334VqYT2Xn7vfKlNqqfn07S3RuN9mUMVD2PiBZ1ZW0tRh V/dfflc3pNmeXKGY3hlKI9urQ/5KwO1T3aEODaIujfdMvm8iw40l9+NuRBXch1u8N+4NUf/I1mLy cGfyYOfj4mJ5eTB58NeCi8mDPxXN5MHDJ48KPtl5v/ju1Xfffvftv7/957c/Ofvnq3+/+u7V5PFO 8UnWJjOyEMZfC7tJm+u+xzKK4vZXQcTfC8Nt8co4D8gyralU3e4TpfAJCu+j8EV2843kpXDvzRjO rzBu+2P/vPwJe/Xy1QbHre2AG4PH/RgN5SUKn6HwDIWXkU8HKPEchQu4O5HDWzQWgMbdi2h//8Zr wfegEhaDSvjjoNIqKBe3bytYIZj5IeDb+uSqfT8z4vtZxOuTFXp9hMIH6+BYmpLxpvrBIOTZ9PM4 xn/BQu2Tyf8DwmDAVWVuZHN0cmVhbQplbmRvYmoKNzkgMCBvYmoKNDczMwplbmRvYmoKODIgMCBv YmoKPDwvTGVuZ3RoIDgzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic3VxZcxy3 Ebac6PDaZTtVeY1r4qQqS5c4HACDOd4iSpRERwdNrqI4kh5kLkXS4eXlypZ+hf9NnvQf/IdUpQAz A3Rj5tuDh49Q8gFM42h0f91oDHrnuyiJhYwS+9cVNvd7SXTH/Lvd+65XxMr+qQi8vLkfLQ96S+t5 JEzHNBq86CVxWZaqzCq6iJSKsyjPVTTY7z3pry7kcSmzXPQPFhZVXIo01/0xFbeoOKqbKu2aaiEc 3RbHNT0T/UV6eIuK1P85PXzB+9dTFVk/WliUSVnGhe4Pq155Upj+NV2VbgBbfOFnHdPDRSruUnHL DzXm/f2si2iqQyru8WJrrfbhDu/lhtrn88891Usqjn1TtpQDKm4jVkZo1d/Rw2Mua0e3UteJjNOs v7HwbPBlT+ksLnNtYDMYGqxsUf8jxB+js1V/g+ijQNfuqfRNE3rIioVfalTxtzLofdWTIouyVKZx lkc6KnQ02uq9OJOFaBEXaZRn0kxmrcTMNvi2nkwYc0ySNElEJnlx/c5E0ugczFVKFRdFixfrCOzi RZEWzeLTevE/KyvC/HciK3mmQj38rKwk9r+VG1v2bswhK/duxhaZcxt6NxQ6HJFIIWLVX/EgfAXx votMd4ubFtlTliSE08IwnuWVfIwEZKRqCZ2HT5eyiGXKBXIfOsuR522Tuy3O5i+PcKmLOJfEPMOV FDrzQtPJuYosS4NZn/QFd0S+eP3Xlk5h3FCGpaN0QdIR5yqdooyTgktHQo+ceECVv7KclPFLaWAC xqZLpVLTrP+EOF7zHD/neyiy5Jb9ZiYO8wZsGpynvFOdhA5N8F3v15VsajbCgkm2/8wjUBU6B/Z5 ttmKcDawy2R5GW54VgVn3/FFaSDU8UBmPm36VfOJrKwnfBJZd4v+eWYGHBpV/DBNU6aUmqAly+2w +0aMovDVvd5G+MDSk5A+RdNNW+265kXOujbUPKzqpvriC7OwegFnGWan4nC7ZzZWG5oVRT1GXdVJ Jcu00FWlrCup9pVNIx1J1T1TFYqaVpJzg9RirCfYbKSq6hBkz1W1rJvaQVTaVOwETcX0q6ZvqqZf xZprWjHtBqkr9QSbVlwqVnlW6fpL8++3F37JVrXz+zsDijgvzSnCm1yqpbPzIrX+Os9lY3OX3v/d 7y9fuXL12gfW+JbWRcJ7qyJOpXAnkUsLizrOZKbNSeCzP//pionejI/SheCUSwvmYZLm/aufX/vU ulMjQ6V4i6cHH16rDhKLzfCLJowq6ik+ejr6+JPL5kQkzKMko9H+YiYzoUNa0KO//vGyjR9jlWYl H/8z8zgz5VzrkDFfrFgzwyVSiRZndMI5D2cj86xkzsa5UO9s3IP9nigTGdCnOBtR2j0xTwTsKopS eOpe2DhwNmcZJnA2Mi8FszyjOOktTxZCestzlcbyXLWxPN+0kpwbpBZjPUFjeTJzbNRVXSbe8kxY m3jLc5XG8ly1sTzftGLaDVJVmgkCZ3PRl2pVOg/mG0ZUMh+wpUyyeYEt69OsQ2SrqxRlxiAYNA6A fZZhQmBrHWhb1w65EWmuSNtNxWm7qTptu6a15DJe0YG20zLh2k7zgrSdZiVpu6k4bTdVp23XtGLa DVJXymQCsC/uUk8G7FQUcwI7Tcq5gZ2KkiMy7CpVWXBE8sYhsM8wTAhsc8Lh2k5r3TiRJqTtpuK0 3VSdtl3TWnLNIHVFlVzbygWtTTXLSNv2fafXdlNx2m6qTtuuacW0G6Su1BMAYF/cpc4L7CTWkQtI VJLNB+9OQGJHcbFHqxVFCVXQQDEEbwxij9MNEyJZSR71S6VKUq9KKep3FafepurU65rWQlK8InnU L2Ue+C37Gs2rV6bMb8k08FsyDfyWa1ox7QapK/kkF31xl3ruBxxptqGkqF/qXHo6umpOHGksDCdZ /6OFxTxODdiL/sfvX7tqjhBlnJapCgifXP70D1evnewwwM1MlHPG/Z1dpDaz2nm3WpFrrzw9OX7e GGwYpxsmNDMTRHHsGagQ9kxHwl5Tcdhrqg57rmkNKMXi3mYChz0RHK6lcA7XDiLY4dpVHPZEcLj2 TSum3SB1BbxPuOhLPX8zM5uiTH9ZM5t55k5KOZ/tqVzreSM4AxDNQq9WV5WnmhlW0Dh8wXeGYUKD FEJxlAqpCaVCpYTSpuJQ2lQdSl3TGnrNIHVFKI7SRAcHUSMaQmmi2EG0qTiUNlWHUte0YtoNUlfc +aBjkBd3qSc6moiyCM7cutQhsJsHRk5KBOQpuE5TG2mJDHW07+YcbS9oGWD6tEOEeE6cTTRVwc6f iWTnz6bilNxUnZJd01pzglcSwZQsSlUyJYtS5l7JJt4svJJdpVGyqzZK9k0t036QuuKOBR08X9yl nmyDmZkLYne0ZncZUCrBjk8lYGlQERVXPX2FHg6oeNvTWaddKrIsn++rpjpTPAtozK8t3bXmMb/A ZEkAjs4Gfd1pKkvNEhwOZkw1KwFiDOlDPqttaqI9nmAB8xXGE7gG9MPOqoRmWUiM6SChytG3ofwo y6k7fD1UlTBlYKST3F1TjOdWyniGpLEmdvmiQVN/gb3oGLO3FLJmLsiOcTh8DXG86emH9PCIiq89 fQRxzES643HM1sGkc51no4HsGyiyLa5Hj+NZ0j9EkAhmBZkCk2Z1OB7PUPQRXNVeJ8evyHiKTsAA SAc8bLPSWvV1ZDKsUyAAAORDJPUdLgooSoS+pLlfc6sPEksxvIjOMNVNPA0TSxkSOw7Dwg+7gW2/ kB2o82MEz65MLPwgUlmvfQQv6Ns2oaK/b4vfwg8jGaZoBhlgwHl0E1+FZkDYnsE0BspsoQD0Uafu hjUxw5TRR4jOkmFZsu2s5L4h0/8U38oSqA9n7PH7ns4Qv8dx7uj7EPwHbTVbcE8CJ3Adx0h5x7D/ cwI3eZlhhx6KvKEbpuL2TDaRd62DspbEnyOmthDTz7magMYmRSsnMO7pOIOB0wsqHiJwk6T2oSTn 9/eY6UMkqllefLrrXiV0r3h0BmEtCyKAax4j+iTXzgRZobuYlN1/hBT9d6SdLSgopqh4xh5Ju4TD dJVCXAnMHE2kFtGiTHwqyS2fnLxLkjum4iYV95C8oLdgQhq15ck4b/3Ggvmgf3pvwdC2h+Q1hPKu gVlo6bxy5XesDIAI4KGJresYQWJID9lqKBh9yeXSRg/ZRivYnHUo6hxPphmMd4gRMtPADUyHFIwG poX6drc/gKvaRFN1tonWVF2uhWYOYQhngg4R/vQECwXGms+RHUOH32yYea7DX9E4+vdweUPEH17f OR2qmNF9TsUbnr4B7XMV0T/vNKUAqGXKx3z1p3g50BWJxfnAN71L9BWknZv08CEVH3j6gB6uU3GV isse54/o4YCP6oZi/eFJh3Xqci248T6ETN3x9Bt8JYxpR/83PbzBmQY4X0WTPkDsY0kvefrGtOVN hqzbzt1Cg+18jYC2TsUVhEn2busBCge68CbtWcyuc0aBTDcgfcPT1/igbUlazG7MUC/94ucWnGrZ 07+G9Kf9NtsWtLdh2xt+LKZqNuzTBd/gOhxg4FF717dcmSHBB53u4bLXO2Kr6QC1ZP+BLoBR3uSc gEkHnfVbR34i+53rLHaqaJXRGfwfIfg75uinjOTdW8K/dbrFITkGKgU4CFQK6APEygoc/w5ZEqE7 wMl0SK0iVu5MA3doKAxd/0BcM0ML7BsAMTAUgO5bvhNjms1/09PvQUdPJncfro81vYeGmu6oHxOS KXhg8GRFoj/oIHXizQQDdccMraNm0vsXFdeQzle4+KY78ocEr/UZoL+PfP49JH42PzO6zqoskrFR QU0/4qMCpHSNJgguluFI0KM+4PIBniLi658aXNwn37qKJsWSgu7pIZx/1o421TmfI6S/RvE2o99t s2whjUU6f5DL9LjRaRqeC5n0bs8Q9On2gdse0jjMIesJQlNgPZMCUgdpGHnAgApzSot+DBcFIX3v jHYCw6HbkH/Y9A5WyjSH7eScaxYZf02QZEBd9/RVeniHo/fcIuvZBgu0x/azNUL3PdQ08ChAZ48R K+tQEcFxy6E7gCzQyaRtBsQLUWeBQuMghgURd5EdwXiM0Zc501PRHXhpph8gSRjuMPptKKkB0v/s DXuKF3fzGJw/RF68Exe3vPQaorP+QeDS2qItzpkXDuIyoEcmHQpcHnE5Ipw/RCJhIqtfGGuRT3kL XLNr3wIfkrjYLehrKsILz20q0ivUMRQyaZDR8Qv4LS9E8KEaxa8Xgq9lTHjNe5PWQPdeQaKAL551 jfzQTUgwx+fpG3r37e1El9c9LVko3EaGxgyV7nPYtWJwnwb6u8WYFQTfWXBNg2/geDWwdwWde4hG Kfd6gy9+q2/fZ72VPEaS/IaK35JS6EXuJpc00O+0mzFrv1Nf9IdDnTWDAL/fgTcwm5AVmOox4Us0 /uFz3h9sREPUCb7Tx5fEhH8mFKwVWh++qABf0oFhFrs/I6/DvlEWOEEA/+BzZgD+3Yv7EN7Bq8KW U2odVlnT3NMLetjFRJhKMuueimn/FRc/oB9BndC5GF8lwByB4EIVwCe4A6+KQuPcvh000wlyjhgn MCPvYIb1jZH1zso2eAkluYPQPeJCnY5u6fIDPLgJnHhb30Xgj3hTR2f5JXudpiQHC24sB5gnA1Nu AtfY1uPENL3Y74eTA6obPqBiDuA/VGTf/CK38ANcOTR7Fozstw2o5TacPnQxOTZiQfJLpKjhDEVu c0U5OrvaZ5t0oBOwCU/I+fAPWRBM4c5NqGj2qmOIdB7st9MxQ1fkzKCYwws2EeelTpAUEyQ9ATob /yXwUtjLdOPjcA9/jWZirnc0Pd1y0hU28OdwP/iGc3I6hzdnJtABck5BkgrANEziDA4ybXjTdtbK hYd7EFtzJ0I2//vbfL8tsz9GzZvvcj013MvYfhBH968uWJHIQvQ/XBCxEiZ8vGp/UiZSrVT/ykIZ J0pLwdpds6VCGlx9YL+1GWulRf+jBVnab7zl/sdn1Wdfq892RaIuZ1GqRGl/TFr/vmG/t7zaW1q9 H41HL7d6S48jIXtLd6Oyt7S8djMSvdVb0bu37968e/PTmx/fvHf049uf3r5721tZjb4KxkwyFRkP qs865ry/spgtatF8gst+0lGY5nlmDc8IrczTotrtfPmAlYesPA6+lwZlKe0PXDIhTrBu89f8efVe 8vbV23NctzYLLjO+7hW2lFesfMTKu6w8cnLaYg+PWdmbcAvsi7I0AMyksejq03mVRf/c+G5JQyVx rrKidnz9qP7yU8ila/J/wqUxUCF/GS6n+Yokkkn2W8C3iYDS6qsqDt9PHF7XJtj1NitvzYNjlcWJ KPPfDEKe9J+5Nf6XflH8Ve9/fZOU/2VuZHN0cmVhbQplbmRvYmoKODMgMCBvYmoKNDAyMAplbmRv YmoKODYgMCBvYmoKPDwvTGVuZ3RoIDg3IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFt Cnic7VpZc9xEEC4IVwQFAQPBOUDAi1SgYbp7Th6hQigeqIpZnjAPwQ5OqDgQJ/x/enSO7Z21bK+2 yux6y1WfRnNPf92fWnqeSwGYy/DrwN5hBnzlSHtyAzg6yJSRuQGvhLG5kkrmIH1+9Cj7M5P5ff4/ yJ5nTlD4q3uK8d5h/t0s+2bHcalU+YzbCO+9AlffhtyQcCq3Sgvn8tlh9lvxQRnmZA0Ur5cg0HiL xfslCjDkoXizrEgYQPTFO6UXiGBcscVIOetUcb2sQAppJUW3PywrJ5xWpKKaHw2FQ81XuLkgS0YV r5bghUONxTUuVEIhj/5aWYWJWK2byVnJNd8oAQVJC4z4tuEpa54ncE8offFWO3fkcX6f/ZQhWoE+ bPpsn5fbLNI5KD4ueYul4mGu8RZoaazzbRvQJDx1TbbKSgulLKjiZr0ew51/EqbuyfDKt4f7t+bd 7xodq7ndF94eCpudUQriMbf6mtd5xs6QdXFHd6Lb/WFszxuyWdu9WfagNj3JtiXBYAw78yNJvfmp zvjGGJ7N2b4Hs2utzjqBbHWEojW6WVlJQVohUPEwwn9E+EWEv41wnsAQYRfhryOMibZ7ET5MtI3r 70T4SYPRsyUdROWPI/wy0c9XifKfI/z3iH4ejqhzjr0Ca+dtlTHGzt8qVFwnWFewAOaO6W2AvDpu BNI1RsANZn811sgVQUlDeWN92tjY+bnz2N8Zjs84EmQu7PjujnZ8Nxc7vnfLSgnNNmOK94ITk+jY dfE8jECpbHEj+DgvNfCMKobWSox8XOvZ2E06qTs39WlZWfY4xMu40fRpwRWflVrwcfLoUWHrbCmc WmUEeQ3QjWn67jVfOtt0z2XDaenuoKzD5bsJY6VQzRH9cJpmNX4U4acR3k+Y+/cJOu0n+ky1fZyg 3LMIHyT63D8/V4wyzU4s4EoIVXOEwjK4grKe3ORcubsWXEEzBVek7YXcmpNFs2t3JyPLAomtDOFE zNHaseRaAXM+38jrqyivlVWwfF+g+aGu0zb3RvDtacJfvEhwOOb5bhFd/BphEeFfEuW75QXYjdAu Lh0LFQBMxGjltWAjn57Rd9YhFvLBy+Xbv2Ix6jbCsd4KDkDupHJcEAv5Qk7FHCKxilD4xSYUXsVQ SMb7CVwB+xfC/2koJG/axaVDIbE7nojQxI/nl8gdj2f0l+sQCgn4UJdu/6St2DwV1jvB4eeMdCNq 5SdKN5J0q0k33l4HrqBhs146V5Cl/UY11jth4VS6cYFoRLaiiWIM8qPsSlKPtxbzZvdZIA4BIcUj vV0CTx+gLyTcKMSpFCIb8xzWB1vZud+Co0v7gPBmsg2YlJBqMUl/TBD8cATBYyL/G+GXI/pMveZ7 kmjbOor61WRqDv8kcEoT711+Pq22NlL2RmA05uChfpcBzkQnPfaTh/nnSxLF8fMVifPd4FE4vBq+ EHQLutAhH6T96ECF8nSq/4SqAyvtVNGJe15Jen/4emb7vPrOS4gSGbG+G+Y2yLsKDBgl1NJFnTJW 2C7gzRV14FiELl3Uhc+nOuG95qqOiXA6c75A1gG734mIA0qtJos+ECfxARrrEAtIPpUXDBpMeUup vGCv9YYU4XzVx8zi58txSo8cV8JeHa6f1IPwLLZ8X0DQvxc4MxnIvLpSyUAIHwCcfGh7kP0Hcrwj u2VuZHN0cmVhbQplbmRvYmoKODcgMCBvYmoKMTI1NAplbmRvYmoKOTAgMCBvYmoKPDwvTGVuZ3Ro IDkxIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic7VtJbxxFFBZbIEMEAbM5CzRw 6T5MUW+p7QoKkZA4JAwnwgHZ2ZBtiGMHwa/ndbuXmsyUp+1MD4M9sSI9V1fX+n31vfeq/SzTCjDT 5U9j7OyPQH7zZAL5zjh8PGKrMwuBlXUZa9YZ6JAdPhw9Gunsrvx/PHo28orKf1VLsb2zn307GX1z 30up5mwi76gQAoOvHkNmSXnOHBvlfTbZH/2Sf1iUY3IW8rcKUGiDw/yDAhVYCpC/XYxJWUAM+bUi KESwPr8tFnvnOb9ajEEr7TRFjz8qxl55w8T5Vlvz09b6uHvcvfPgoBizIiCkpk/C/N2CpHE3VXal AFSkXTk2AEWoQ/5OPV6UFn+d/DBCdApDudCTXZniycS8h/yTQpZVs0zsDZm20db5UL8DhlSg5pWt YmwUs4Nm5FYa/0xmK3WszHa7e35j3vPmpama223hza7wZA2YIe5zq615VUbsLTkfN3QretxuwPa8 Lk/mdmcyulfBTQueNFiMzQZypKmFHDeAKzFz/25tHPaBnssE4R3watyFUOGOUFWwy6mY/H4yLE+Y We1C2bdtez5vP6BdCfyuo6zsqKwtu2vb+hR4emCo4/rteiXoabyL6emXTU+ZBNkNPTf07Ohpgseh 6WlFdPgEdpNirBUZRqD8OLIPI/sgsp8myh9HdhbZf0T2o4Qd1z+K7CeR/TBR/8lsXxgEV/Fcnvdo 568e/R4k3t1L1P8tsl/0WkOrdYuT8rw0zlTnJU6Boe/pMx8CJD6BjSGgoiFcIhucW7ppRF6sCYKO chsXqpEVqvNLaiQVgbWlrD4OjKF5DuIS1MdaXw1uhepz+3T1ea8UHyMEtvn7xRiVxqDrETltOb9e ak7QBqbG1qjPNRmGBSu4zj8vxk4UgGQW108acuDzLwqjZKOI48LXC5C9QCkUSltFwQA0HdlGlNg6 5Rohk7Jus0yzT9bOObbPz1LnFcoWmc5//z5xgsQnTnwS7SZOq+8Sp/Nuos3Uu/EpGZ90KVV4OK8v 5MVcqZeCoF6KU8iiCYcii7Yi5Ssly5cXlyzAsHyyiOPeetOXnCzGhnop+sU5LPs4EHEEtUrAsEri 3JpPHHHGHSCF/LUyPiBHQpIa0AbrQISDo/zNEvBgnTERna6UhVbGbBaGPsIsNNwv3CEvlbANkS5f vMO29JmWfhaQLsFXoe5OD77tJc6L5wkOxzx/kEe//JxwOn9KlD8ozsFu0SK/wG+kEPRAjGaB7GqV 8KsLq4SsQ1g++lk8e8KNEpZLwVwvRT8lJLZhKN6AX3Uy/utNtm+91Y+MwHTgbB9ro2rY0ZQKvZxt InlSDgbw1dPzwBX7mq57pudJXPgzpOcJOAyYnievV52e3xB23QmLxg1NWBK3oXawYhVN+bGxQh4m VPTvhDLvJFQ9bj+VPo/7epFQ9TidX3sfVXq+7ssw22RaPeUdpDyUePx/nj6Gyt5PlP+TKO9z3ZG6 LljlHh0n5ji9JlXwWQINXMPmp8mOZpRCU6UUhMu7l2AvZ3mM/fXJ0wtQZ/L0p8gSevQD+ZDEsOqc /c1NNmWuPOE6yhMGmiNPrxpPEnaRy4XLppDmhRcLKPgciNHowqovFm5c2HQKMtjlwx+t3Vws1EvB eKaLBXDeDkUc2eqVXCx0n0xtb6Kz9Y7OwAczdHSGmtqrBUroUMzWHxNM7/dF0OLQKC4/TDB9PzGG o9n6VXh21vDjKDGGuP5ej7mk3j1O9Ls7E5mIo1ndZELwy/tiirya3vc1+ozpv7LXICyDALP3YKeJ EVszkBiJzq3kTqzToq35WnTpw7L11CUTfUe+NL8UBM7NNd+FC8vKT4RmLu5eCssCy6paPwihYUV/ OdMxesGn+f/jsAy0mfMnJ68Mf43qUnwbWa3mvdG/DCFxKGVuZHN0cmVhbQplbmRvYmoKOTEgMCBv YmoKMTQyMgplbmRvYmoKOTQgMCBvYmoKPDwvTGVuZ3RoIDk1IDAgUi9GaWx0ZXIgL0ZsYXRlRGVj b2RlPj4Kc3RyZWFtCnic7Vpbcxs1FB5uhRoGCgFK2gILvOw+WOhcdHsEpnSGtxbz1PBQmrSFiUub hOn033Nkr3flxIqdzq6ndZxMZo61Wh3p6Pt0jj7neaEVYKHj78x4OB7o4o78PR48H3hF8WfyILUf joufR4Mf77mCVLDF6NFAqxACBZ48hsJ5hVw4doqwGI0HZVGN/hncHg3uxp7A2pI4YKsLEwIr6wrW LC/qUBwdDB6t6N5Lq+bGPYOv3VtSXtwjKO+j+/vlZ1VcobNQvleBQhsclp9WqMBSgPL9akjKAmIo P6qCQgTry6/FYu88l1erIWilnabk8efV0CtvmLi83vRs3/mifdy+83E1ZGUMBlt+Ug1RaQy6npHT lstrFaAK2sDc3AAkijpObQgWLCsuv6mGTgUiWcW16UAOfPltZRQ4R5w2vl1BUB6lsaiGVlEwADNH Ng765+g32QmnXIgIGO0PpK3dLFPvkwVNzT7xRXbJFQKtdo/mEaIlSNMd+rUaakWGEaj8O7EPEvsw sfcTu0jsXxL730z/gxXefZLYDxL7aWI/zozZ+MIY9RjgpVyxnqeRSKgisVKeTCDfGkc1bdiltPEd 0saaoMiulTbfnU+bvaeRNwSENPNJWH5YkQzu5tquRFyTdiltPqjnizXWEZ3CGdbv1wvzHsovKwmp ZlnYO7Jso63zM36Akc2j2Ss71dAoZgezNVgZ/CtZrfSxstrd9vmNRc9nL8313G0ab7aN0xgwQ+pz p+l5VWbsLTmfDnQredxswO4il9O1NVDTgiUNFlNzBjfj8Sz7I2bu3amNo1c/C0KY4I6t4gkDqGGA l/RhBPjRt208v6of0C4Cv3U0odo51KwnRpz2X0rNCJYFGW3VpLqMnqgnk93Sc0vPBnJo+6enkGdW TaU586dMjt3P5PNc/iwy+bbIvJvm2xeZ/oeZMceJ/WxqYxBgFZk+uTriv4yvXH1xkhkz1+fJCmMe J/bLqS014FzzSWaYcWW1bjA2OWs1+QgkKRcTIK1+HVgEH/Kg7Bx8VDKHN8yOoe3aNHKiS9G1vFKc EtEEU0cyf6ti2cyeblWxEmBea/65tbG3Kpbwdn+rMrat4C/5tcqwqUOxWvHGBNAXcQQxAddKnO8X E0cqDAdIoXwrFj3kSEhSA9pgXV1xcFS+GwEP1hmT0OlKbLQyZ7O0nhNmoeHVariYJhCbuu/yFXHM MQ90fhZoG8E3Qd3tFfh2mDkvjjMcTnm+VyYf/sgk0t8z7XvVxdnNkov86avZqVRILuieGM3GqfVm wh82NhOSD6F79DNzrUBf+kwYT5dlYjwJcHviikxn3WL8zc0li6Sj7skSM/BWjJ9EQg72C4jx6Dj0 JMaT3OPWLMbf2Kp9r3ehiF7g2bPaR3JOLRLjMYrhXYrxraPVxHjB00XEeGT0PYrxGGjdYvyWnq87 PQ31Tk/0eqEYn8u3aZ5M1eCjRf0lTx5m8vxFhfy/Mnn7JGMfZOb2MjN+usZnK4yTm8PCeuGUrxcr xGE/M7fcFxS5W/WDzJgHrXB8fEa8R2H9RLw3vjPxnoUU83DbivFzRLT+rBh/Xj6Kaa+fGxYasx5h vu25u9UX36C8JPvY/aVRCqzmgrJx+iKCP/vtwSnNBIy3PTEaAq7nG4O2587GaiYgB0r38AcXGnn9 kosmIPlnmRgP2pq+yEJ6LWJ82/P65nIFkv8u7Y4r4LZi/DQUgeIun1bj7w7+B5vXIthlbmRzdHJl YW0KZW5kb2JqCjk1IDAgb2JqCjEyOTEKZW5kb2JqCjk4IDAgb2JqCjw8L0xlbmd0aCA5OSAwIFIv RmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO1aS3MbRRAuXoEICgIGgpMAC1x2DztMP+Z1 BCqkiluMOGEOKds4oXBChOH307Pa1Y6wxpJTK1WsKK5UtWbn3f3119u9zwutAAsd/zrh6GwE8suT CeR7YXI6YqsLC4GVdQVr1gXoUExORr+PdPFA/p+Ono+8ovivmSmVj86K78ejbw+8tGouxjJGhRAY fPMYCkvKc+HYKO+L8dno1/KjKu7JWSjfqkChDQ7LDytUYClA+XZVk7KAGMr3qqAQwfryc5HYO8/l zaoGrbTTlDz+uKq98oaJk5699En/uB9z+LSqWREQUrcmYfluRTK5m2u7UQEq0i7uDUAR6lC+0+4X Zcbfxj+NEJ3CEC96fCxHnB7Meyg/reRaNcvB3pBjG22dD+0YMKQCdUP2qtooZgdc3m52bmXyz+S0 0sfKaff753cWPe8GzfXcnzXe7Rund8AM6Zp7s543ZcfekvPpRPeSxzMF7C9acnq2++PRw8bctNiT Boup2JkcaZqZHHcGF23m4EErTFYxPVeIhfeG19pdCI3dEarG7Eqqxn9Mt+UJC6tdiGvb2covug5o Fw2/X6iIC8Xeol0760+B5zeGOu0/u68MPI13KTz90PCUQ5DdwXMHzx6eJnhcNzytkA5Pza6oaq3I MAKVB4l8kshnifwskc8z/dM5/03kJ4l8nBn7LDPP34n8TyJPLq6FQezqJLPunxn5USI/TeSjuX1a rWd6jP7MONP4MzA2Udaq3mGxilAIO1GQSjawkweTwbllor9K50Y0wi7WBDHcaCVLycgK0vkKZGQM LYoVByAia32z0Q0S0VeLiUg8pgOkUL4WnTg5sly+XoHcFxps2YKDo/LNqo57csZM9+m09LwRG63s 2Szlp1p8ruHVOIm8dEJ8hUnJ2gWk9OI+znmFYnWmfzu5n/G/pxl/nfr0lBseZ/jjsEx+/JLxDT9n 2g+r7gfycnC3hyNoD5egW3oCa0tFe62acF2I1la0vFFE37s8tHw/RpZG2NmWH0SYagwaEuzeioAN 2sDc3jroNoAFK7RYflHVTpBEcopb04kc+PLLyihxw8RpY+s5KGqttoqCAegWsh262TrluihV2npl mU5PwDC8+Ytvn0X/P2ZM+yRj/scZM/8hE0rlwq3c2BRGudDoNDPn8dXBYmxoryIPFhbdrQksYqlK DGCTYPl6a8HCNkZBg4OFdNTUDixyFeLa/RXiRgpBrwk4LIHRZknmm13YeH3CRtYhDO8KWF5WCLc0 bGTm9nB5JiS2YV2ABr/pgsHdrWVCMqLT4c1fG+V3RCg3Ef3rkjcsDBwWJfAHgAoZu+nk/Z3thYo2 bniokMT1u5ixuQnR0hVCRmT0a2IYDLSZVGOfYNzf1bxe7jgRDS1A/1A1L0CIqTD0ukvI9UVp0DIC RfcDVaUjbOaWWlaW7jZn/cVs4WUAjfXv9X03gsZsJnu4A+n1AanoYf0gZZwFVSl1fpfI5wn91RlK Tan5bAVqfpzp8ygTHpxnxqZzTjJz/pXZ5yQz/5NseJCWoxtPBiHgtB6tB6tHk45VylQxL1EZ9zrK q1aTL4iXFaRXLj13QCN9MeN+CeHI6nZdEaH4lY1k33uy2dtlEa8P8YAPZvh3Q9Q0KyhsXRYRXLhY IvhfagTQmjUhGgxvpCzQA/r21mZGgJJPUAez/ljQ7nLor3hqBMAtzbg7Fh1Yvw6shPiZiN4s/S35 CPgao8XHT+Q6RbVoeTj6D28Oex9lbmRzdHJlYW0KZW5kb2JqCjk5IDAgb2JqCjEzMDIKZW5kb2Jq CjEwMiAwIG9iago8PC9MZW5ndGggMTAzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFt Cnic7VlZbxxFEBZXIAOCgIHgHDDAy8zDNl1HX4+AQhAvKGF5wjxEjuMEYaJswv+neneOttn2juOd VeysLUvlPqu76quvuuZZqRVgqeNvK+wfFbq8K3+HxbPCK4o/845U3j8qf5gW3913pcyaPiq0CiEw zPugdF4hl46dIuk9Kv6ofqonWpFhBKqeJPJBIv+dyA8TuUzkHxP5aWb8wYC5jxP5QSL/k8iHmTW7 vZBl/T+nv8zvgVSw3U1Q4ONXgdRchcyY/lXcmRb3Crkt5ckE8r0wOyzY6tK4wMq6kjXLIjqUs4Pi 0UCTeGnVnBjFN6pYUp5LG5zyfmGVT+podWeheqcGhdKF1cc1KrAUoHq3npCygBiqD+qgEMH66rZI 7J3n6mo9Aa2005R0f1pPvPKGiauvu5G99Fnf3c/Zk0tnRUBI7Z6E1fs1yeLuWNuVGlCRdlE3ALlR Har3Gn1RVoy2QHQKQ3Tl6UM54uJg3kP1eS1XqlkO9pYc22jrfGjmgBHrUTtlp54YxeyAq+tzza0s /oWcVsZYOe1u339jWX876djI3a7xZt+4uANmSPfc6UZeFY29JefThW4l3Z0BdpdtuThb52pafEmD xVRs3S1o6tyNW2eLPnP/biPMXj4aAIJoVFovp5lDgHoIaJlgrAtxd9vt/fI7eWXTneZgOwWdrWoO 0wkr0ckuRadvL2xo0FyFUBMU2S1CtwhNEGo8jo9QtooXfpfy5veJ/CLhvkmGT1NePhrAy48zYx5k coMXmbllZt+nGX5/klkzHT/LjD+eJ1ite0POQ5rEi2guMDYx1/mSKtKyZGojleiwlQfJ4Ny5RX9y NYNaScxenQu2MCNemHAg28TYN1IuKJqHzTLNreVMIyHRAVKo3ohRmhxZrt6sISiPBhs64OCoerue RJ2cMQs9nZaRV2KjFZ3NSgKaSFA1PIx0yMsgxNeYddAuYZ3zvgut7l8gdwa8vdLYn8bg5wN4YK9K /vk9Exx+y7Tv1Wd/6RlPzeESdMtIYG2pXFwrW8KREC15Qgwxm0T0N6fnjh/G1NEYDLb6KMJUY9CQ YPdaBGzQBo7p1kJ3DliwEjCrL+uJEySRnOLaYiEHvvqqNkriMHHa2EQOilabWEXBALQb2RbdbJ1y bRoqbb2xTGsnx7B+9zdsuvT+NS+LGCHExVUMo0IGgJGAw8GogBsFzrdbKrw4VChurdcfC1hedb4J 19MES79m8JniFs+ONxZ28CdTzxPkJIDTY2GMSG2Wm25eWm4iG8II/ihOvi3Zz6+Cgj1TyZ7EeiPh hpzedMn+xrYg+GrzEYG46WgFQYkt0e+MU43bUeaJ5DLtufEpuH9eU91vPzN3dnqAwSB+NcsEp38z ++ZrgMvPuJ9ZP537PLN+LkDO/n/eWInKqZnfNi1beol1GMz8uwaKq62taukleqSe9ApVAzdVMTwp Di4YNjCUB+OKigI6Dsu+SK2DfAg38zWqrwzuXtqsDb0AYe1ZG4luvE3a5CYkgp2ltC4vWj9Szibg 2ExpvYfNzraecHHyN5Sws/5IgMZe3tI6ChOtKq2D024sRMvKGymt94i+fmmJEDzY9bs/BN6W1pur cPpMpXUAb0cCDjBvprTeA+f2lgovDhVCzNrWHwsIutL6paNCiJ/QTya694r/AAZBxqFlbmRzdHJl YW0KZW5kb2JqCjEwMyAwIG9iagoxMjQ2CmVuZG9iagoxMDYgMCBvYmoKPDwvTGVuZ3RoIDEwNyAw IFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO1a3XMbNRAfvqnpQCFASZvCAS93DxZa 7errkTKlM7wwLe4T6UMnSdMyuG3SANP/npV9H7JjpWfwXVLHyWSy1umk1Wp/uz+tfJRJASqT4bcS 9sYD4E8OtUfXCMeHAzIyM+BJGJuRJJmB9NnxweDxQGZ3+e9wcDRwAsPPZKRY3htnt0eDH+47bpWU jfgd4b0ncJPHkBkUjjJLWjiXjcaD3/PPiqCTNZC/V4BQxluVf1ooAQY95B8UQxQGlPL51cILpcC4 /BZL5Kyj/EoxBCmklRg9/rwYOuE0IeU7dc9va+mL5vHVYqiFBYU+f4tHEmjRUP52AV44pVX+Duum JXmL+bvFMOhktZ7qaSX3fD80GtZZswhKoLRBZeCRlPT5h+UyVJgIjNJUrtE5yL8s2MI8NpSzGOvC Gh+Ofhmg404q7NNony20FbQkskD59ckqDI/4VdDXo+GVbzfPbyx6Xr0003O7brzZNE5tSATxnFt1 zyussjNoXTzQTvS43oztRVNOF3dnNLg3cT3JviXZKrFYuR9KrN2PKudr43g2Y/9u3K70OuuEYq9D JUqnGxVDKVCTAsx/jeSfIjmLZKhkRdwelhGmQuFNPRl6mp1Nuuls/MLoj+myuSOQNJhNl6mNjVHm llnoaxBmHAo0vSJsZzHCqnc+LoYktFbe5J8E2EjlJURYuhYA5KWGGd0qKE0ABIYE5V8XQ8uejbyK a9OBLLj8m0ILsBYpbiyRjGHThkag1wDVRKZCGxkrrC/Rxm3NZulqn6xTq3dHY6Wg6Q79HLna00g+ iOQ/I3k/4aax+z5P9D9o8e6TSH4Uyc8i+TAx5v7yUDFkppaIoHJGctKgcVFyWgVslJwo2iNsvjsb NrvPAm4QUGE1J6r8owJ5cDvT9roMFLZCKSuUrzNLq2wUrO3x8iYjrcwC9AefuX+3FI7/dyyQtiZE LgKTSID1x0RgiMF6HMnjxDgvI/lVov0kAfTxTH8jZW1Qo1WmJbpgNW8io7Wlj4tNFTjprKlEwlQb uQeZ4/s5zMs5fuWi5qhvtG+brrSvTi9pakcOVUc5SjMZIeo1R32/ttSO2Lyrp3ba+Jp9X3Jup/mo PzVFO3JHCNAVcNhj2Bn6BM7NDbm72OSOKMT+rsid9xO/kyb8m/idb0HubicQepKQY4TGpO9VhNZh 1P4iEUn+aTHmwmgwp38qIv2diIR7if6zpJITakbgTdgt0KtjlYpTebxD586r1lNuwcXc0iSvNXGb ApGTfbnN7XIRei87ykXkQPTL4W5sCuBvUFqS7LErp6Vk+I2SAN1pQf1iWhoH7Lg6ENPJOAns5tGH B4nY8FuifbdYnmgSUbm49KkMyfiuAA2unyutpl64vbanMtTWdeD+Ulf3P5f8UBbi63wB44w8qDz5 ju6pUJt+7qka2GxtEuGbkwhRarv6SICEFfta9iZY/Qe0sRPNs865xKRIuY4Sk/LYz5VWg7Dra5uY lMYO3FE5WXOHS56ZFOeDU7X1M1ITeGm7Ag5CP3X2Bji3zgbOplx43ulI8Yeuy4WKTxIVJaIW5cIH CVTG0eMokv9qEQFSJb/UOE9bvFveFyvPjnWQ0Dkua75M6BZHs8eJPk8S/cct1v4oscaT02OGMtQ4 8epJwjzPE0tPqfAiIacO53ut9JmQS053BLZCc0qx02VY4CQZUICKVlaGJcdHjBnfvwgXviUipTl9 hzXH4EA701EiArZ2L/dWTSJKfFt2DRgc8BFt9QyOEVFfIFxyBgdaL1VkB2l0V8BB2UuRvcFN4juw m9rCRSRzANHXr1cXCsCub5HdY/C5+Sr7vcG/ePymzWVuZHN0cmVhbQplbmRvYmoKMTA3IDAgb2Jq CjEzNjcKZW5kb2JqCjExMCAwIG9iago8PC9MZW5ndGggMTExIDAgUi9GaWx0ZXIgL0ZsYXRlRGVj b2RlPj4Kc3RyZWFtCnic7VrrjxRFEE80vlajKCoeiE7wgzOGbfs13T1fURANkUD2G/jhuAcc3B3H PQD/e3v2dnZqdvq327OPCzkPQqjM9nRXV9Wv+lfV8yrhTMiEl38rYWOvx1khNDcqedrThidGFJoZ m2iueSJ4kRxu9bZ7PPnD/3vae9VzTJV/hm9TeWMvuTXo/frQ+adcJ4PtcuKi0MINfxaJUczpxOqc OZcM9nqP0q+yUg9rRPpBJpg0hZXpl5lkwqhCpB9lfcWMkLJIP8sKJqUwLr3uJe2s0+knWV9wxi1X 5Oevs75jLtdKpzfGI2vpm/rn+p3Ps75meS4Lk36R9SXjsuAjjSw3Or2UCckKnouGbkIwJXmpWl8Y YTTT6Q9Z37JCKb+LS6cTWeHSH7OcCWuVpg/fy0TBnPQPk6xvmCpyIaqFTDnpP4O/vDcss0Xpp8Fm zz8bPO/dHvQeeLvmla8UV2Nf6cpTMV6yiQ+A2kcjF1nHpHeRkmzkoTtZnzOVaylUukPkLSLvEnmT yAmRfyPySzB+K+LdZ0ReJ/I+kZ+COcdrydLqpYFLMyhWmLEhVKGbluDu1BL+hcr63lbMqbxQrhYO T92RG0uh47o4ZAZsjFNMmblhc3kO2Pw0HTaP90vcKKGkqtZUMv00U35y23j2YRnXilsKm49H+spR rEtpmaxi/dFoY86J9NvMm5Rrv7H3/bZzbqyr8CFy7zxVvXI56+dMayt0emWoufGTf+d368cYv9u1 +verod+rlxoj18YPr9UPT22gtaBrXh6P/MRr7Iyyjk70Pfl57IC10JKnexuHGvexxIWRVKzCzTq5 TPTnhhkfaZYzXcd8OfBeKf/cG/zyKL1FAHUYAUYK8OMGAPtCWx8It8mAt0Q+AJnnEKD7KJQ9YpA+ 2rXSdNczkV7GXuCQXAbSJR8qeoZIv3aB9Hcc6dKsAuncjqlY0oBPFGTyomJycZjRTskVYSb3iVDr C8xcYKbGjPZRsnzM5KYY87B5MJPb0esEMxMFmPa1wKpwor128kxxcvXcFl+6PKmXXnzlipeeOl/V l+dhm13AMjIFNyNTYLCoouArAot2gp3FmVLXWWvnFyu8KJaPFW38G/KcYWW+ToXWemSKODKmtClW hRvhFunw3ZgDOJcvyNi7TcZU7sN0+fjnedWoHADoIai+AfA8AvPsRECYzr8H5t+In18WPpIC+uda m6h+SwKe70TsdxFbUZ0PO9rnXzD+OZFPgA7H4F2kM9pj88goQ1z5A04LW+F3N2KSl8AIL5pNsFL2 h271aik+q8WdWtytxa1aTDLDS7TJUst+pWa/hEyp6AFQCO0WeQtFDB2DInsLeILqxtpGGT7vimp0 2G8BPY/B3nfAeLTf9QgbIrRQv5wA/RGq18H4IzB/jL/QXppkJYAKFDDHQLFh7Ibj9gnQ5xjIKIYR EUQxTG2139FuM+J8mM2T9vO5sNnESxRB9Cdwl6ssaXWxoqsspeTZXGXV/PDKBT98t/mhdD48l96s U752/f9dZUmnulxlSSndiipBj+dFrrKuzoH06xdIf8eRrtQKkC79f1XP4W7EobwbwjI90D3cYgge IqKH4HA/Aet2LS83wPz7II3sEBKCOlkoByI9Z647TllSlNj2/M7zkGHY34kw1R7Y+jp4/pDI94l8 D8iIiyGTHE0fPzQtqi2o2V6DtW525PioCA2G85RQpfOPeHdZWb5sq2yMsY1p+sBddMw4Mnw0dI2k YE90ivoHobLkANgM1XgzQp/YphT3a/GoFmeU5V2bHzQMT4CtOpUx3hfLKrGozgzoE1PGo713tdUi JfEToFtM2XYI7BaAV0u3wFplFHXt8R2Hwj+mMUefb0/fnzG56dCAQmiOQfZxhMd2wZgYQMckxKTt glZb9s308a21aOKh5zv11JPpXpiaIWL4BvEgmjKmF4JMtQ1Uo2Z4BdQMHh5isrsbiHSU0QI8qPWc VdFt7Gjydiz/DYyD2s4om3Tleos0imbgbBjLe2D+mNY6Hb8NxnQlJIglIIZxk2ajuZYdun0fbAvR 5SbNDZstrs8biGWUE5GSM2Kw260Bul/pSsdQl3XVxVHASFMLn0AiaM15F+iMQIhYPt17kPH7aKL6 IJpAZdRfQrZClcbSKaHfS7+hZyDSl5zRhHWKknJC1TeDWFgda49hk8hdNHyohXbBmBhooivmVUMT Xe6hdim1LbU5KuRiLnaQnhtgzhNgT+RHxDdR+mzqGYAFhUJXCh/Ixx3vimN6IDH8cBuYBfUxkPs2 gWvQXR8Nb3RKIO66rDtzVOyhr0FegHVPag9S5KGD6s8ItyBqhJL+IpEejG50PTxn4T8sSueiOotY AnGxmE2gfERJZfPonD8oY86GOevHqQkCga1D2hrKryNsiADWoePSSlgxdfd2HWnN4TNSOrIH+kwr cLaOatXJ5DDxBVE8FFB+Rqqi/jwq046AvN7e2lQXxbSF1kn+p88fpyA2VkF30fwo6SOcPs7ALlGA xCiNmlMo2T2NMBZqiq2H0IBY85wdvYlYJ1x/RtjHZLuZHY8JZotQjDIfujZCGbrr9+Ttz4XKi7h7 w68gfgfvoKuSmMIW+TamW4TSB+IaATrY6tDOvJuaYvdNoAPq8dN3EaOIOSVpQwB16LreRCP/0nXf gvFB5uB1w+3dAOips2KAMcNxE8ceOQzb5zJpdUdkhUX4UNfPrtFd/iJIC9TorV5vTC2LLuQpH43h dovc8QRQMXlvgWIGtUi7bh0lChQmFFztq4UJUNwHC83ZzJ6I+Zm0cAwKVxVrw894HvT+A3TrSlZl bmRzdHJlYW0KZW5kb2JqCjExMSAwIG9iagoyMDk1CmVuZG9iagoxMTQgMCBvYmoKPDwvTGVuZ3Ro IDExNSAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO1a3Y/bRBB/QHzU9AXKV6EP pgjhILL1fnjXFk+tVJAQFfQUngoP11zuenC5pnfXu5a/nrUTx5N4f/GYpBVI7anSyJ7szszOb/a3 430Wp0KqOC3/amE8jdL4R///KHoW5UKX/6oXVB5P43uj6M6ei/2vRodRKoqiMLJ6J2OXC2ViZ5zQ /u00epQ8GQxToTOjpE72iXxK5AMif0fkmMjHRL5g6JyHdJRJxuT5GWN8+nwMfDkB9tBxUByQL/vg +W0iz4g8AX7RODwF8afjH4IxT4B8m2H/CXhO7ZzOZekcc0n/GP0UaeuEkc6n3ujA5xodewxi/Jxh 40K2NrPJS2qXTVORpqqceljPPSxxUM5+wIgcdeeSsXr0+QGINB0TrSrKxAnQXzxXRSEhUsVczoyx i+W4s5fHWhR2WRd0YVYLg5SLwpBcH4z+jO6PooeRrx0i11mh80Y4O4qMTePMFkZYF5vU+EHSIj6b RIfMApX7p6khJSpfmGK1yE1s80zk+bxGfTgoa6CzMnl7IIWyhVPJBwMlpNXe/3cHQy2sVKrwRhdC KWnz5IaXTO5yk1wbDKXPCpdq8vqjwTAXeWa0Sb5aan65lD5uXje/+d0H2ggttdL1nFol7w+0H9yt PHtnIJXQqSttqyKaFsl7C3uVH7FcC6WcUIWqoTF3LM9l8snAhzQ13rG3vNtZal1eLH4jM796uv7J jcEwE8Y4aZJPK8utH/wz763Xsd7bm837z0Pv6x+taN5cPvyieTiPgTGSznljqXnNW5xb7XI60C3y erkAN0NTzn1bplrqcymVVlGxTrc81ct0M32SLbwbZlZYn2lOiSrRPEp8zpeKP5fyN9Ho20fJPYB8 zl65RLXf1zx6pXE+Ee4ThRdgszhmlBu0gdZQdwjqC6+1pV53Il06ivR8l0hXWmi7BdKrTPKjLNJr Dvo6Ja+Xr51UuvCgtz4NC6c95pe/uUVAX78mv0Ggl94lKVdBP1TCepOzN6jfLepVrl4B6r11Zp50 9wCsL4CMyMBLgsIhQDaleFc7IhiI2FyCijLuqijLKqJkCTfPoTw3qLLvB+DKGTBtDPRPgZkToHPM 0EFuIdZ7SjgUCu0JsP8K6FMdDvtH6XbMiFuAHa+zcxT+czDteU2srYMHvW2yGdsWOC2cAoPpCWEK DAvEsozN00Y8bUVsTeGQfbDoTHKPJ44DnKjNgA6d9wDMhY5cQSaxZtvztn4FHHQ8fswA419ABy0k AnLfI3qg4JSrHCzlW9aDE+AiqnnLk6114SP0BTAA+U3XnB4sCShICC6DTwk+9tmgQJGiqD5iJM9O NuQNq0IrLeqtXJCEp/oB8FanbQHm/QXEAQEEzTVj+IJ6YX13GbS7HQId1Mno7P2tjYl7RQFU9Goy NkaWaRzo+1V9JaJC8n+vEe824gM2KlC5n4Ioc7KZ4zDKkil4jtAV4EkVKjin4b7d4ml7ZTbGgVNf UWY/bhW+lsrrZPFofGr+9yvjBECB9p59ECfUpzwiqAhTJcKlCBHld2bRRo3qMdptJZFTIKN9hmYV yn7UcuHUxT0i3yXyAzAm6n1zOtQorSiJQ99WOvdnb1vfbvU58GUC5BkYZwbm3QdzTUKwEMSROW6a hKyPuaOeDgbY8UZ9TsJ0kqC1hehLgv53XYm18Tn2oNMPZ3wECnR2Bsfx1W9rHYy+LyELnDyrMn3e zE94DHnaoyBztnO0d3HijLZnasPjdmw34iuwdhVN6bF2Lfl1kugO7JQruA10tmFKtDyg0oigGaQp iOZxPpsGaliV/1dNnNoH/J6HV2QHJ9DoYzrK29O2P618Q+Nfbo5jlf8onzn46nuo3ebzNvL9SWtd W6GNwVS7utvCgfUZGD/IR5DxnE5PoMu2TtPHjUgYe3iD6EAFDfkhkKkO6jf2pbB9dyOOnRQVY2Ab KofUF5QyfTN+B2yJrCsbCZzwcxIRFfEXwPzVvkMAFX/3NKwjxuusiBC0SVCcsVHR/1AS9uYKhAp5 yel0Iy5MxwyeD9Yu4lEd+pzDxTgtc04x51zWQ8UZNQa+JnLgXNj6/PkbmIuu1zMQcxSfAC/QNlVw HM7dENRmDFSxFi/uy1WfAH1kA8pblJ9ozAAfX+fFHDpOh5kB+VX32M/bFXB+K6fzwp6R+fwWA+++ nlaZfkX39XShKkO3v8Vz61/c4rn95hbPf/wWj9Z2p7d45vmvXbG8JUpR/SsokhSBiFodgOecL5ec +y4BGrqRAtIGBqosnG4x2vT7nnqCTUe/aR6BmHNs2IbuczYRRA+RX6tVvuMqe/9ukCeU3Y23I+Bj 38Ykh6dzdjjkGmp+0++D6F4UakKjRgtaL04Tl0Ny+HeIWuYEwlld40B9k857uosKZ/SiwtWUYGM9 lMWKdlWZH0b/ADi0eaNlbmRzdHJlYW0KZW5kb2JqCjExNSAwIG9iagoxODAwCmVuZG9iago0IDAg b2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQg MyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0ZvbnQgMTIgMCBSCj4+Ci9D b250ZW50cyA1IDAgUgo+PgplbmRvYmoKMTMgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFsw IDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsv UERGIC9JbWFnZUIgL1RleHRdCi9Gb250IDE2IDAgUgo+PgovQ29udGVudHMgMTQgMCBSCj4+CmVu ZG9iagoxNyAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRl IDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDIx IDAgUgo+PgovQ29udGVudHMgMTggMCBSCj4+CmVuZG9iagoyMiAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8 PC9Qcm9jU2V0Wy9QREYgL0ltYWdlQiAvVGV4dF0KL0ZvbnQgMjUgMCBSCj4+Ci9Db250ZW50cyAy MyAwIFIKPj4KZW5kb2JqCjI2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4 NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvSW1h Z2VCIC9UZXh0XQovRm9udCAyOSAwIFIKPj4KL0NvbnRlbnRzIDI3IDAgUgo+PgplbmRvYmoKMzAg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVu dCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9JbWFnZUIgL1RleHRdCi9Gb250IDMz IDAgUgo+PgovQ29udGVudHMgMzEgMCBSCj4+CmVuZG9iagozNCAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8 PC9Qcm9jU2V0Wy9QREYgL0ltYWdlQiAvVGV4dF0KL0ZvbnQgMzcgMCBSCj4+Ci9Db250ZW50cyAz NSAwIFIKPj4KZW5kb2JqCjM4IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4 NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvSW1h Z2VCIC9UZXh0XQovRm9udCA0MSAwIFIKPj4KL0NvbnRlbnRzIDM5IDAgUgo+PgplbmRvYmoKNDIg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVu dCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9JbWFnZUIgL1RleHRdCi9Gb250IDQ2 IDAgUgo+PgovQ29udGVudHMgNDMgMCBSCj4+CmVuZG9iago0NyAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8 PC9Qcm9jU2V0Wy9QREYgL0ltYWdlQiAvVGV4dF0KL0ZvbnQgNTAgMCBSCj4+Ci9Db250ZW50cyA0 OCAwIFIKPj4KZW5kb2JqCjUxIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4 NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvSW1h Z2VCIC9UZXh0XQovRm9udCA1NCAwIFIKPj4KL0NvbnRlbnRzIDUyIDAgUgo+PgplbmRvYmoKNTUg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVu dCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9JbWFnZUIgL1RleHRdCi9Gb250IDU4 IDAgUgo+PgovQ29udGVudHMgNTYgMCBSCj4+CmVuZG9iago1OSAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8 PC9Qcm9jU2V0Wy9QREYgL0ltYWdlQiAvVGV4dF0KL0ZvbnQgNjIgMCBSCj4+Ci9Db250ZW50cyA2 MCAwIFIKPj4KZW5kb2JqCjYzIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4 NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvSW1h Z2VCIC9UZXh0XQovRm9udCA2NiAwIFIKPj4KL0NvbnRlbnRzIDY0IDAgUgo+PgplbmRvYmoKNjcg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVu dCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9JbWFnZUIgL1RleHRdCi9Gb250IDcw IDAgUgo+PgovQ29udGVudHMgNjggMCBSCj4+CmVuZG9iago3MSAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8 PC9Qcm9jU2V0Wy9QREYgL0ltYWdlQiAvVGV4dF0KL0ZvbnQgNzYgMCBSCj4+Ci9Db250ZW50cyA3 MiAwIFIKPj4KZW5kb2JqCjc3IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4 NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvSW1h Z2VCIC9UZXh0XQovRm9udCA4MCAwIFIKPj4KL0NvbnRlbnRzIDc4IDAgUgo+PgplbmRvYmoKODEg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVu dCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9JbWFnZUIgL1RleHRdCi9Gb250IDg0 IDAgUgo+PgovQ29udGVudHMgODIgMCBSCj4+CmVuZG9iago4NSAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8 PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDg4IDAgUgo+PgovQ29udGVudHMgODYgMCBSCj4+ CmVuZG9iago4OSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90 YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250 IDkyIDAgUgo+PgovQ29udGVudHMgOTAgMCBSCj4+CmVuZG9iago5MyAwIG9iago8PC9UeXBlL1Bh Z2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJj ZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDk2IDAgUgo+PgovQ29udGVudHMgOTQgMCBS Cj4+CmVuZG9iago5NyAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQov Um90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9G b250IDEwMCAwIFIKPj4KL0NvbnRlbnRzIDk4IDAgUgo+PgplbmRvYmoKMTAxIDAgb2JqCjw8L1R5 cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jl c291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0ZvbnQgMTA0IDAgUgo+PgovQ29udGVudHMg MTAyIDAgUgo+PgplbmRvYmoKMTA1IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5 NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAv VGV4dF0KL0ZvbnQgMTA4IDAgUgo+PgovQ29udGVudHMgMTA2IDAgUgo+PgplbmRvYmoKMTA5IDAg b2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQg MyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0ZvbnQgMTEyIDAgUgo+Pgov Q29udGVudHMgMTEwIDAgUgo+PgplbmRvYmoKMTEzIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJv eCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NT ZXRbL1BERiAvVGV4dF0KL0ZvbnQgMTE2IDAgUgo+PgovQ29udGVudHMgMTE0IDAgUgo+PgplbmRv YmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL0tpZHMgWwo0IDAgUgoxMyAwIFIKMTcgMCBSCjIy IDAgUgoyNiAwIFIKMzAgMCBSCjM0IDAgUgozOCAwIFIKNDIgMCBSCjQ3IDAgUgo1MSAwIFIKNTUg MCBSCjU5IDAgUgo2MyAwIFIKNjcgMCBSCjcxIDAgUgo3NyAwIFIKODEgMCBSCjg1IDAgUgo4OSAw IFIKOTMgMCBSCjk3IDAgUgoxMDEgMCBSCjEwNSAwIFIKMTA5IDAgUgoxMTMgMCBSCl0gL0NvdW50 IDI2Ci9Sb3RhdGUgMD4+CmVuZG9iagoxIDAgb2JqCjw8L1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDMg MCBSCi9NZXRhZGF0YSAxMjQgMCBSCj4+CmVuZG9iagoxMiAwIG9iago8PC9SNwo3IDAgUi9SOAo4 IDAgUi9SMTAKMTAgMCBSPj4KZW5kb2JqCjE2IDAgb2JqCjw8L1I3CjcgMCBSL1I4CjggMCBSL1Ix MAoxMCAwIFI+PgplbmRvYmoKMjEgMCBvYmoKPDwvUjcKNyAwIFIvUjIwCjIwIDAgUi9SOAo4IDAg Ui9SMTAKMTAgMCBSPj4KZW5kb2JqCjI1IDAgb2JqCjw8L1I3CjcgMCBSL1I4CjggMCBSL1IxMAox MCAwIFI+PgplbmRvYmoKMjkgMCBvYmoKPDwvUjcKNyAwIFIvUjgKOCAwIFIvUjEwCjEwIDAgUj4+ CmVuZG9iagozMyAwIG9iago8PC9SNwo3IDAgUi9SOAo4IDAgUi9SMTAKMTAgMCBSPj4KZW5kb2Jq CjM3IDAgb2JqCjw8L1I3CjcgMCBSL1I4CjggMCBSL1IxMAoxMCAwIFI+PgplbmRvYmoKNDEgMCBv YmoKPDwvUjcKNyAwIFIvUjgKOCAwIFIvUjEwCjEwIDAgUj4+CmVuZG9iago0NiAwIG9iago8PC9S Nwo3IDAgUi9SOAo4IDAgUi9SMTAKMTAgMCBSL1I0NQo0NSAwIFI+PgplbmRvYmoKNTAgMCBvYmoK PDwvUjcKNyAwIFIvUjgKOCAwIFIvUjEwCjEwIDAgUj4+CmVuZG9iago1NCAwIG9iago8PC9SNwo3 IDAgUi9SOAo4IDAgUi9SMTAKMTAgMCBSPj4KZW5kb2JqCjU4IDAgb2JqCjw8L1I3CjcgMCBSL1I4 CjggMCBSL1IxMAoxMCAwIFI+PgplbmRvYmoKNjIgMCBvYmoKPDwvUjcKNyAwIFIvUjgKOCAwIFIv UjEwCjEwIDAgUj4+CmVuZG9iago2NiAwIG9iago8PC9SNwo3IDAgUi9SOAo4IDAgUi9SMTAKMTAg MCBSPj4KZW5kb2JqCjcwIDAgb2JqCjw8L1I3CjcgMCBSL1I4CjggMCBSL1IxMAoxMCAwIFIvUjQ1 CjQ1IDAgUj4+CmVuZG9iago3NiAwIG9iago8PC9SNwo3IDAgUi9SOAo4IDAgUi9SMTAKMTAgMCBS L1I3NAo3NCAwIFI+PgplbmRvYmoKODAgMCBvYmoKPDwvUjcKNyAwIFIvUjgKOCAwIFIvUjEwCjEw IDAgUj4+CmVuZG9iago4NCAwIG9iago8PC9SNwo3IDAgUi9SOAo4IDAgUi9SMTAKMTAgMCBSPj4K ZW5kb2JqCjg4IDAgb2JqCjw8L1I3CjcgMCBSL1I4CjggMCBSPj4KZW5kb2JqCjkyIDAgb2JqCjw8 L1I3CjcgMCBSL1I4CjggMCBSPj4KZW5kb2JqCjk2IDAgb2JqCjw8L1I3CjcgMCBSL1I4CjggMCBS Pj4KZW5kb2JqCjEwMCAwIG9iago8PC9SNwo3IDAgUi9SOAo4IDAgUj4+CmVuZG9iagoxMDQgMCBv YmoKPDwvUjcKNyAwIFIvUjgKOCAwIFI+PgplbmRvYmoKMTA4IDAgb2JqCjw8L1I3CjcgMCBSL1I4 CjggMCBSPj4KZW5kb2JqCjExMiAwIG9iago8PC9SNwo3IDAgUi9SOAo4IDAgUj4+CmVuZG9iagox MTYgMCBvYmoKPDwvUjcKNyAwIFIvUjgKOCAwIFI+PgplbmRvYmoKNyAwIG9iago8PC9CYXNlRm9u dC9Db3VyaWVyL1R5cGUvRm9udAovRW5jb2RpbmcgMTIwIDAgUi9TdWJ0eXBlL1R5cGUxPj4KZW5k b2JqCjEyMCAwIG9iago8PC9UeXBlL0VuY29kaW5nL0RpZmZlcmVuY2VzWwozOS9xdW90ZXNpbmds ZQoxMzMvZWxsaXBzaXNdPj4KZW5kb2JqCjIwIDAgb2JqCjw8L0Jhc2VGb250L1RpbWVzLVJvbWFu L1R5cGUvRm9udAovU3VidHlwZS9UeXBlMT4+CmVuZG9iago4IDAgb2JqCjw8L0Jhc2VGb250L1lU QlhOVStUYWhvbWEvRm9udERlc2NyaXB0b3IgOSAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgMS9M YXN0Q2hhciAzNS9XaWR0aHNbIDU4MSA2MTcgNDM0IDk1NCA1OTkgNDE2IDU5NCA2MjkgMzYzIDc1 NyAzMDIgMjkzIDMwMiA2NjcgNjQwCjY0MCA2MjkgNjU3IDYzNyA0NTQgNDU0IDYzMiA2MzcgNDMx IDYzNyA2MzcgNjM3IDYzNyA2MzcgNzM5IDYwMwo4OTAgNjM3IDYzNyA2MzddCi9FbmNvZGluZyAx MjEgMCBSL1N1YnR5cGUvVHJ1ZVR5cGU+PgplbmRvYmoKMTIxIDAgb2JqCjw8L1R5cGUvRW5jb2Rp bmcvQmFzZUVuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9EaWZmZXJlbmNlc1sKMS9GL28vci9tL2Ev dC9lL2QvY29sb24vRC9sL3NwYWNlL2kvQy9oL24KL2cvUC9vbmUvYnJhY2tldGxlZnQvYnJhY2tl dHJpZ2h0L2IvdHdvL2h5cGhlbi96ZXJvL25pbmUvZWlnaHQvZml2ZS90aHJlZS9VL2svdwovZm91 ci9zaXgvc2V2ZW5dPj4KZW5kb2JqCjEwIDAgb2JqCjw8L0Jhc2VGb250L1JDSVNORCtUYWhvbWEv Rm9udERlc2NyaXB0b3IgMTEgMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDEvTGFzdENoYXIgNDUv V2lkdGhzWyAzMTMgNDk4IDUyNiAzMTggMzM0IDM1NCA1NDYgMzAzIDU0NiA0NjEgODQwIDYyMSAy MjkgNTUzIDU1OAo1NDYgNTQ2IDU0NiA1ODkgNTQzIDU0NiA5MDIgNTUzIDY3NSA1NDYgNTQ2IDUy MSAzNjAgNDQ2IDUyNSA1NTgKNTg0IDU1MyA1NDYgNzI4IDY2NyAzMDMgMzgzIDU0NiAzODMgNTUz IDM3MyA1NTcgNjAwIDIyOV0KL0VuY29kaW5nIDEyMiAwIFIvU3VidHlwZS9UcnVlVHlwZT4+CmVu ZG9iagoxMjIgMCBvYmoKPDwvVHlwZS9FbmNvZGluZy9CYXNlRW5jb2RpbmcvV2luQW5zaUVuY29k aW5nL0RpZmZlcmVuY2VzWwoxL3NwYWNlL0wvZS9mL3QvY29sb24vb25lL2NvbW1hL2ZvdXIvYy9t L1IvaS9nL2gvdHdvCi96ZXJvL3RocmVlL0Ivby9maXZlL1cvZC9IL25pbmUvc2V2ZW4vRi9yL3Mv YS9uL1QKL2IvZWlnaHQvcGx1cy9OL3BlcmlvZC9icmFja2V0bGVmdC9zaXgvYnJhY2tldHJpZ2h0 L3AvSS9TL0EvbF0+PgplbmRvYmoKNDUgMCBvYmoKPDwvQmFzZUZvbnQvSGVsdmV0aWNhL1R5cGUv Rm9udAovU3VidHlwZS9UeXBlMT4+CmVuZG9iago3NCAwIG9iago8PC9CYXNlRm9udC9FRFdMS1Ir VmVyZGFuYS9Gb250RGVzY3JpcHRvciA3NSAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgMS9MYXN0 Q2hhciAyNi9XaWR0aHNbIDM1MiA2MjMgNDI3IDYwMSAzNTIgMzk0IDQ1NCAyNzQgNTk2IDYwNyAy NzQgNjMzIDYzMyA1MjEgNjIzCjYyMyA2MzYgNjM2IDM2NCA1OTIgNjIzIDk3MyA1MjEgNjIzIDU5 MiA1OTJdCi9FbmNvZGluZyAxMjMgMCBSL1N1YnR5cGUvVHJ1ZVR5cGU+PgplbmRvYmoKMTIzIDAg b2JqCjw8L1R5cGUvRW5jb2RpbmcvQmFzZUVuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9EaWZmZXJl bmNlc1sKMS9zcGFjZS9kL3IvYS9mL3QvaHlwaGVuL2kvZS9vL2wvbi91L3MvZy9xCi96ZXJvL29u ZS9wZXJpb2QveC9iL20vYy9wL3YveV0+PgplbmRvYmoKOSAwIG9iago8PC9UeXBlL0ZvbnREZXNj cmlwdG9yL0ZvbnROYW1lL1lUQlhOVStUYWhvbWEvRm9udEJCb3hbMCAtMjA2IDg5MiA3NTldL0Zs YWdzIDQKL0FzY2VudCA3NTkKL0NhcEhlaWdodCA3NTkKL0Rlc2NlbnQgLTIwNgovSXRhbGljQW5n bGUgMAovU3RlbVYgMTMzCi9NaXNzaW5nV2lkdGggMTAwMAovRm9udEZpbGUyIDExNyAwIFI+Pgpl bmRvYmoKMTE3IDAgb2JqCjw8L0ZpbHRlci9GbGF0ZURlY29kZQovTGVuZ3RoMSAxNjQ0MC9MZW5n dGggODIwND4+c3RyZWFtCnic7Xt7fFTVtfDe+zzm/X5mJpMzk5nJa5JMkkkySQjMIcmEhIQQQoAE CCTkQQCB8BQUG3wBBqxe7cP6aNHb69d6rQ5JxcQnFm2rX1vFVr1ya7XV1oqk0pZ67xVy8q19ZhLB +rX9/H3397t/cPasvdd+nL3XXmvttdaeZBBGCOnQfsSg1sVLwyVIfualQ7a8d3PPULJefRNCeH/v 7p3eJ9UP9EPDLxFi2YGh9Zt/8NP3GwF/ByH+hvVX7R1Ijjd/BSEXO9jf0/fqe0/YEBJpY/kgNBi2 6lUIafqgHhjcvHNPar2dMP9VV23t7UnW8+9CyHBmc8+eIe03lAKMPwSN3i09m/tT41nInENbd+xM 1mPv0P6h7f1Dxz9ytsP47wA9Z/gM3sqd406xB9he5nFkRGj6N9NvSXukPqmTuQc5Yc3luBtvxLvx DSj14DV4vYx8G/fgTfhqdOnTjB5Dz6LT6F30x9m2acxiI04D7LfYgq6T3/45+hV6G51HFzCHTdiF /ejvPXejR1LY63icKGRMjY6Qb6EfYQl670a1qBaoOUP2MTcztP8Aug6VQvoCD6Mjt+HV5Gp0FN9P akkHeYs8dGk/VqJm2Pt2fMdfv4vtWMBhXIXrcRteh0fwRySC56MP0J/RFHDCggX0BGjHe+gsJliJ rXghvoUsIhewhDfyI5yJ/dNls23ADbCT1XgHHsSD6GPAl8rcAP1BW5AWuZAwu24IPQeyKsZaZh0Z ZZqZa5g/cWpmFCHuFHLxRnKeDKBH0TC6E1In6sQFqBvdiK5HPwX+n8MXUa7Mx/tgxCZIb7O97F7m R3gUDaDlaADKn6OV+HbUi26B/S3CaeR/IysaI79F96M38WpmPrqT2Yt/ADs04K1Az1fgrV+iMXQb e+qLyODK8//zYU8r0hVn0ffQIYCH8OPsce419CF6EL0piu0NVdVzqiorouVlpZGS4qJwYUF+KC83 JzsrGPBn+rxChifd7UpzOuw2q8VsMhr0Oq1GrVIqeI5lCEb5OOGs7TiWpgi5fT5fZ0Gq7rq8nmCC xj/5Esh82SD3Z15K/0zd85l6xmy9JYGsiXp/bR2d+Biq/10CWRLYmkB0FWxZBCulXor3bfTHNyTS avu6u+GNOr/Rm6g/F06RIs99TKOu9df2qwvy0TG1BlANYDB26Biun4dlhNTHq44RpNQV5CfMoQQJ xilsTIiHuwHx18FM0GP5tGd8+sSRS7sQvDaDWZIYTvC1CYW8rndDQuxJoMPeY/knRo6MG9G67pC2 z9/Xsxo41wM0HkNMMD7YTvkYp9A96E2wMLmcuaHFGx/0jvgpO+KD3ZD76+Ctz22HZlVtx0HfCXfC DGU8YQolFsCIBde852ZG4s4NXlodGTnoTRxd0nFpr4/mnZ2dTiB4JO6HCWGy+MYa2IozXJCf3FOK AX3dG+maG3sonfGN3pHD/TKtR2Qa5KHxQRBMz98bNTIS7/PH+3r6apKz1ybEdrlA7Ss75A0C6+o6 U02pAdDDyj3ddZ2+JLOb2jpqKWH+njp3UuyzLd2pFmiIz3R6KQWNMEHC2+tNoLYOPwytoFl/BRrp rZCVxwdWNL+p9dO3ElzQ6PeO/AUlcLd/8uzlLT2pFj5o/AuiaL2/vntkpN7vrR/pHukZn96/zu81 +keONTWNDMW7YdXWDnhrfPqJw+5E/ZHOhLF7EFcB76kG1Ld1xNw+U+dMtXWmikClQLE08naAC/Bp TBXAZdTe4fMCo5Z1dLqBTx0Ubwc8WVJFAsWtABmn2EZ51F8xy57aFOrzUe08PC6idVBJ7F/Skax7 0Tr3KBLDIZBHN+05MdNjW0Z79s/0zL7e7YdVvo9omGVLKLNmPwaj3RIfrEpg+9/o7k/2Jyy1HYyb dCYx4mYopg7BSa9OOEKA54RGQAiv+BPGUILrOOGu7vQaTWABqPSW+puWrOzwxkdmtSDZktop1QNQ dX/P4EjqKFGl//zWpqUzDKcaC0f6MHB8/7qNoDTw6TlCzY9vxJio/9jn9o2Y/GZvZbgzqdXGV/wv YjBcYNaMCVwtbwvLNg1Wakwwjgro/MIrXL4lsGM1x/z40JJjIj60dGXHBER+3kPtHaMEk9rums5j AejrmPBCXCq3ktlWWvPSGmqip2eUKOUu94SI0H65l5Ub5HrvOEZym3KmDaPecZJsM8pt8BSAZEG6 Six1QqA9+MmmT5bq5JbLnlW0RXEeHYEotR8pEYFSRMvAswWmpyE2J8fa1853gDeCYXgKciPkIsDt AAyK4b+gtTJ8jF4BYKdP4NCoVlc+AUj+aDA3hVh9SWRMZSwXx3HOqMslN+SM6XS0IThWXy+Xo4JX 7giOutNTiM2eQgymFKLWykjmaHZ2CsnISCJjajWdJnNMq6Wlb8yRRktm1OGQBzCjaXThH2DbaIaQ QtRWGbGMwrsT089h++jSZSmkZXEKicdTSG1tCsnNTSJjgSy6gn00LU1ewT5qt6cQkymFqJL8SBst Lk4iY/n59KW0UcGX6vFkpJAUoeYxmAaGmEedyXnNoy0tKSS+IIUEs1JIaiXzDOeFUY0mhehmWlJj hFGLJYWkCBVkNuJsjEdLBFiSHzWb5Q4ympOUHx7LzqXEkDGgDko8Q2Vg1OlMIQZj+dNYjzlkQgLw hRvTyZJmx2BdWo6q1PJIdoZR7Gj13BSycGESGVvRSceGR1UambnKUZVLRlSjYm0KkV+iSGFRCsnO SyGZgRTimnnLapMR62ggkEKyspPImNZSbpivxxFQ4QiobwSUWcAmhOFOZYDbjYANo2yrQMlCoqBx lk9/IAhnPnQJRR/iD6wu4aOzRuEPAOhj8WMCDkZ0fqzRln+MXcLkWY1gPHfbOSKeHTr77FkGzP7Y J0ZrOZRi1X+ZreXv/84l/K7MJYingeDYv+FTb8SE199wCftfw69B0f3G0BvkpRfzhJderKx4CWt+ XPdjkvglhteP/xJOz9CrFBVvflVtKQ8caT+y88hNR759JHHk+SMK8SSOTpiEDQDPATwL8AzA0wBP ATy53CQ8MeEWHgP8+IRLeBxgHGACaKmOmYS5APMA6gBqAWpiNmE+gAh4rMwklESsQqTMKpSVWoVS KI+WyZT4yjQg6W1VVeVvb8PiNpWl/LahxBB5eysWt8JuX9kij7JvobQP3D6QGGDE9SpD+bf6caJP 7prTR43CUez9auKrJHYHXnvb8G3Ee+uJW4l3k7iJoEEsf1oHuweZ4R5ctEpcNbxq/yq24l6TQN// 871aeP8FLI7hYyCZhNUmPGo1CY8AfA/gYatG+FerXngIIJRnEobycH6BXiiw6oRvemsFwZohgOMW vNZq4fuugPAtV7/gdpUIw67bXMRlzRR+ZGkQbNawYLF6hSKzaG41325mh8z7za+YGbPVKZgAkBW3 WrutQ1amSI8RDzc1+IRxDG/Fw/hR/Cx+GX+Ep7HagEC5wiiGtsJl8FG40r+MPkLTSK1WRQUDMTDk ZfIyM02mGZa2qJR5AsvlCYTJErS6So6tZEglRpWtHB6H2RLmJtTUXpOwYCiX1hxTlYSaEn1tNTff eqsn8TUao+z3dI4rYQwEOwn85c6Ekno5GUWh1LNjJ3x27Eww8QQfH+xJ8P66HbSipxU9rejjCQOt GPx1OGGNDyas0LozFNq5i76/KzQ706fYDgo7YF75ofUdMHAXzdAl4/762bEDQ/8OJM8QkjNM2+WG 0AzA2n9rki/wUFpD4A0JdY8KxCOwBgrkEQ08YRFAEfjEVmgLd/30rZ+iMGTFRT6TzxSEDOSNPtnP oQu0RICAk9xCeIZj0uENj6jCz5HF1H0SagnUhigJhyLhLhSeLC7C8D7DTW0gXyc8tsMQ1DL9a/Yl 7iPkQH7UIKa5J6rMC817QdOIb6KMj/O7eYZX+32IKr5epYsiFDQEhSDJ8Gnp9DpzVBsOTXaZIpCj WNckfGAZK1HwvD8zKzuLlJWao+XlkRK7w27mjFn+TN5ktEdKytmX5tXVnf7mfafjdfPmLqj/5V33 vxGvmyvdsuqqTatXb9q0mnzwnPSrnp7e3t51WDjxQ+zs7+3p71snvfMktr79tnRGOvfuu7DLkxA5 3AN3YAOqF0PccZ7XMnpmHCs/gj4OC9iLwphBWr0Xe5lWhhhMgokwjMloMleGu7oik5UlXWHKndhU SSxCWeSjfPaVlZQD1VHA2Hsu5uAq6YfxQ7lFZSyuxxHMMpY/w0lcUn0hDKt8HSh4i/sD8qIvi3a/ rsrdqF/oblW065c7V3k2sNe41dbx6Q8gEIkaxqcfELP0xigy691Gs8cddq93X+1WmM2aJ+wkDEGb MIGV3cKQQGRD49AYo+YhoNyr9AlmkpaWacgUMoksV5gO5Er5bq6snIQdQAXFJiu7YrRSXBQKdfl8 ZeV0F2WllOsgEIXfVB6IeFmbVa752LcuPHH4rfbN6/ZtrewvjTSYPTGs3YdV2LTv9pUPZZGr/7zl +Y4dj6we3JpudxRpcTwjdvb1m6b+qfOwB/a9HjRnnDuHatGjojtfFwhlzS2prq3umNM2v7+it2ZH hTq/FPYKavL6GJQlwARxMWiQ0gG0z5vrHu9Ox+nppfziIlxUlPtEKRHVWK02PMGrwyKM19RD5vct q8JV7nCR1VfknlvFqhCEiwShuCEuxIlGJWu4MaoCDaes6DI7KidBnOGuSTjDMifkTBb2VGUlZQsw Bsv7p+ppitipLiaZlJ2V5febLqtewjaqwHbKOZudYuz4kpbFr33jkf9qCbS9tap8OJSZW1VUdCAi zqnbnpNTkCcEujOj28vzVtuFRZg7dPPJeHPznXvK+osK5uCTm78fi9VWBXBtabPFm9ZYW7PAaGIx rzVb6qoKKo1mrctqjOhwzDe3MD/8T6uGn03XK7NC2dfC1gumL7J/4E4hNdKh3WK5VqeL8gorEKnl FSrdBI6xi9m17DALD6NgmLAiplil2KS4VsEhhVbH8KwXqWQvaFZpo+A1DAZwBDpeNNmjfIqLoUhk 0uSopCYjRhkXmSoxVVYe5ApD7HXG5+F0++kJMYEtiUDO/uFF6etT28iNeNeLUz+TDuJV0v14LbYz 3Re/hi9IHGjKHtCUJ4HmQrRXXKRW5htK2BJrHVtn7dIvK1Dq2kHQyjRQCp/PM5GbywcnMhlZF0yg C/6gkClq9NFMh8+fKYvfC1YOFRmKhCKiSp0EVfIkdNGjAHYoPCN6oH6qJCwfhpTMs5Iyd3xG7JlU yLApW8pS2dknFy9ueeO+Bz9qyUyvryzbXFt1IDcjM+SP3F7adk+llzk9dTBjqWPT8fpla/B/7vxh w4IWHM3EcWOO3eb2ZGUsnFfa5Mi0uAxMnfT+fxImVBCdoNZ2HXDiF9wkykRV6FqxWqvVp3m0Qlqe JqzNT1up2a7YXqp2MfnjyGP0EI+HMVgsjolOAzaQisfLmXqGMOrlCJvNWUmDbFAZwCBXG6qFauIq 8cns0JgpO6ZKkiZZNm3UKgMf5FMAPCkuAm4g36fWWVZukz/JhxkO4EuZY+Vt1hTT2F9Ir0sXb/jJ gmUr29euwlkvNt7pdrv2LHr0GXvj19e23hpdtEpq8QgBn689nL00QAoyXbXBjHp84UPpVFPjcmx8 +nlctGvrdRZe+nedb/zhcEUod84J6ZbAsuUNa9LTbVaDutC//94cb3oG9Wy7wLo+BbrDoz4xk4Fw +ZuEsRICF0VmgmOIksGoD2HSQe0h+M7x6XNj1EtR7mhVGuCO0qAUlIRNaQqb1JRQCHgRovqCYrEp E7CEqvfB657H2Ed9JPvU1AGpm3xjqopdwH73wgp2nP7hA66f079i3+T+jIIQsdejo2I/F7aFc/Th imLv3GiNd1G0nV2r74yurb7WtMujLyosLREL60o609oL10aXz+8u3BjdWTgcvWaObk5Ul1lSyPO5 j69Pw2lk/uO8emXmANqg3WAZELgsr5DvtRgsQiarLfOmfC+4DdRgaBAayDyv7HuNl/pesHzhyfAk 9QEgb6h1yWKeMXRZWWWl5dGyZDEj4pQ1w7J/SArYUV5ukaWezdOW5CFh31zc3Pzvt37tNw0L6m49 cONgQ0PdqRtGflpT13Dt8FeOSEN9y9v654rpi8TsgDBvwLM5L3vuTVd5mjzebPyt7n+prq6Lz5lz tHP/Q5W8eHyo7fbK8vlziooPL9n4r1V89UmS07yqrbq6UdBnOCNrp65rbCnW55mzd8QH91msjnn0 1NRNv8sehxglB6KibWK9kTGafMTLeE3LyQ6isPrnjBscgoM4HHz48Up/o5/4iVqtn1jGY17d6cEq a65P5Ul5jhpDjVBDynweykGDOepJcRB0AY4IPSxQUA5eclYgmGEv9xbRS7k6G91c4jNmj0u0tJw9 3tHVLb37cv1daZ709asaDxVH6rSttwwsurVq0crFjQ2vXn/DSw3tK6Qv5wZd87N8MY8rEPR620ry Ot0MU/2M9Py2HdeaFTio92bn5d/UW1KWG6p++ms7X2hsaGtsWiadP7D3vnxvutvnGapt6Ep32x1a TS5sFSIjEmR75cgyR0zDJwnHn+SURpVXRRQowSO4eXoxg2UDL+tNKkCkiQSlb+J1FMhpfMuF+/At cBZrp9/lbBDpFKAHRB+rVudZ1e68uc7i9EVOMb3DviJjL7tTsy9X5x8Ei24an76J+n2IVo6LKjiT 7ELIKNvFfEAcImRhnTebyNlWHdbprGXXgMhIdzbOzvaW7YIV1bqcpK8yRHNywoawGF4bZlw2ZqDQ eD6p+NXUvFFjL+ddXUkXDwaf8yKTEflkRZeN2+fIBgQZMfG0jUmXjkm78WG8uPPL8yN7glnuttLS 6+qWHJxbsWBhddVtCxYeKCxpTs/Mvaqy/hoP/ipctNbhf7GaDaUW6T5nrddbEIlV/uCmw09XVZQU ZwhimvSApdhks4Mc7kaI+wlYMD3yoJgY6jQvdw+QDTqWZ3RaYi9TMo4yhVIJNt52NY2qBFFoFYjD qujLMH482WU835U81JNdn+oiCKiE/VTjZoIW7ifHD++UPrpbKsQ/uw+b99z5kLS/f0Pz/9qpUHzp ey2ru8n7r0iPdzSFuFM5i9ZIz71256k5ecqLq1XFVT+BlYFOdhjoVKGloocrKyIi6SYMIQoMNCqU iBHB/TD0ZiHfr1UmsEcaUYMNmiIoGMIByWrjx6BLsmC6ZNcTSx6kTxULbOvw1G0kNvWcdIT5LfuY 9L703tR+WDbFKSugFrCvLaK3jCvzx7m4fxe3O5NPL1Orte4yHaNVrkDrEbHaZDJMMhnZhmwxm0Cg re3LkimQTeLM8pOzlpAaQ9nPy1rxGe5RBlpr5mWtikavb31eGiE11z/Z3L5a2l+dV9aztMxVtsaf UWvOcjMXBp+KZdc4HC4pjTsVjlQ8ORJbZXIopBrCcx5zsBU4dPP0r7k+2IkJxUXdboT1LKMqA222 6mXeWR1Rvd4iWnARZMC4l9m32ctc1GTXzI1qMlYNgqfKDHTLBrkMEDBl56VfSE/j3btuun4v3i29 IOBM7GAev7j2nrvuuJ+5/+JCaVJ6Eyh5UNrDuHgr2IBi0ck9QzD/DNYYVJgxIAGFaSjFP4zllSEc TAYMkUuNgY3eGF1TR8hO6Ukcl/Yo7j37STXMe1DaQy7MzMs+o8BMat6HZyfmLpk3AvNOfjpvGb1i +ciFqSMw55Mw956z3PNnqQ6UTP+GXcTeiLRgZfaJVpJnyVvJrUzbyG1M26ncnrkrT5UFF4rHtMYo rk6nzIxqddH0dEuOEAgHhgO3BdhAwBvLYQuU6phF7UEFrvytYDiw3QjRgHxzDQYVLvtQIRwuoCnU RfWlhBI2e1MIAYkQMJbxKWMBPHfwKUcq2/tANHWlgotBOb1Pgb38Y+eWssLIsqWF3dmByqJwZ+tX X+hbsxYr77rllnkPLs4o/f1uEJBK+jYOnlHpLMb55Yvn5B3KKHI6nD++67q7CwoDar5rQYEfAvLc 5344xQInDkyfYX8OHNaC3agVw6VcqbZUX8vVamv1S7nl6QPpw8phs4apcbN2bFOqRaMauXXbBKfC 4rJtyZC3BXuUdxaTj0CSZpNs+oJGRB2Ygp5I6r/MzOaBjeGuAv8C//B1eEA692L7vnqDdAyvWXR0 w/Ovkarv3J6RMfUTvfo7j0rnpceycip469TpmjbpZ0BpOUS1NwKlduQHSgsguvE065o9QxbOnweC YmhmQ+75cMdR+mqUaqsDu9DWYIZbMxQAEo1TsxKIzVxcU/wmpln/avJhU1YqUKFh6I3SA5krfHlt lSfeaa6d+0hPx7YmvEZ6wNWe8aXh/m2Fa3ali0arFc/D6jv/rbVxWTAb/+pCJsnWmRLffPArAaC6 FDTtDvYAygBrs170B3WluvlkMTtftzSwg1xjU7oo2cFqjQZlzuPZo07spOoMHo2WYhqok9NpEpEq LU1wqbeBCcJBjYsZShogcE+R5DUE9jNjhWadEuQ2n/2vvZAl6aLIC9IPpO/hapyOCWanMFdRWLBn wdzdxaFGRzC0YF7lXg/T0zewg8/ARTgNW3CDdEaa+lLLBkFwu+2WfJP0tsljMJjIO1t3XrOBnqpy qZO9kb0BGVAlGhKXVPNNvGipDQyRvZ5rMobKlbl0r06twxl15umMUQOtVnLs/FJWVxNSGF1eV5Fr yPWKi3O5fPPtEF/nuIxb50BQkZamcBcOVSUP08xRku9eKWHSq9es3JIb5i67fn96FSv7jMSjPibo as760rDFlbYkFl6FD65saTl989CLC3NdCwKhtlDn1RkZzjn3tJ2ebJw/L7F2+aEKHV4KfnlKa/zn Oxr7s7OyvSfvPT13XtRjwWlqp1qjD2b61zbYSmPA2cybXl24YFF+sITeMg6A73tA1uBKMUCsFmup Oq4esnFGnbLOwuox1impyjq7ndiocem2OJJCpserWnYycL58PtNsAGiaOVd2G/uAdFRjMNdVhjpK pAfwmuX/3PvwcVJQd9Cb5fP6L74H5+jnjW1v0nO0D0j5A1BBI7Y5opUXQRR8DccRDivZb3FrkQsn rwJ6uLmrlEUqUdWqYlI26zzQQr/BCiW/wqJfXeH36IJq6ct4O9t7FJtmdnoG1tCg74o+JeHUnAJj ThnQlGrqNG2aAc1uDa8h3eohNcTQsou1yDcPnUEn6EQdo2Rc3BbtrJMFUVdWdslcgMvUMZ7UtndM IOX0O6MqSxQBLW4xD25rOAcmAQ5qkNKlwqocVSCq+j5D1Bo1r7Fqkosv0/DUSh00nmBPcH8JbWdP AD4VUp7o9PmwIvWVA2bPSN3SK+V0Y7gZ3yddjT9olLp568W78ONSemqH+D2Zi9nHCcbKy7jGsUWc yLVyM1wDniX5leQVvJacQRGA0xJC68Qw7+WzbV5bNquw1Ll9AaTlnBlsGudUhlyox+fQuLRuh8vZ s1+b0L6iZejFTDRCaKvVFuQbC8IFYkF3AZtcrOv8VIlx0lQpSyoGV7SpEqo2l2nNZRqU+jZi9rpm 4p7nDYZYZU5LoXRUAVhFqC1b1qm71q6/N7d/bHXLvlA4TIqXbg8EfH7vxfdIcdsOQHPcF99je/c1 tq3rWdNfUlL+1T1TwRmth33+X7Se+yJab/vHtF6mBpRetsNvsU+BHdaA9wiKNrOoYjNEBoI9tC0Y C2Knm5e9BDWpM/FD0oTKOf7cSxfcWZ+STkkfQhD0Mi4GC2nFRdI3fB6hpSTc7M0IZLrT2yN5K1yC lxTDqOdwDNuwE8+VnpN+33dzTp7Pk5t9aP364azsQCAQ2pvkFbOHXY9sqPcxrcoMnEt+xQDxWp0Z TpFKeUk86pDvo1qFS7XFPntUqNCnQvLXMDPnRDt9YvacTCA9PTWaKFjNTuy/jKMpg8js8VibC6N7 KylHncv8Wf0FpjwT41QovPYpI9t7v73W6vARQnXYNn2GWch9G7lRh2jTUE+iVOrYmFrBOZ3WGFI5 NZRcL9Cv0XhinsUewqt1LoWBF3gvw/CIMTKPMgxDo8EIvRjLh51+Sx6OQT0SBtFzEA6Z/GURUzJM nGV+xMbzpPT1kwcOwBldIj1KDPoFdemrzBmV++2JHxPdeTxfeva8tH1Oh9+f61T/h8EE9BrgzBng tqpFT4gupMJKlQYRhud4jlMuRHGeqNSUrBmmI6T36kU94ZOU0e87gL8mKJK8fYzxqqxR2OM7Y1Aq xylrrVH6Vyhqkpo0WMWwnFrJadzYyuVjP5etjOIKrkpZpqnDTdxCZZ1mJVnGLlOv0Gwifewgt14x TIbYXcq9qp3qazRerQtoVriAPlBHMFPwwV2dGPsYxod9Fgt8FAZpXDrywg+lIxA5Dz38Gi578bts 74X7yOtTeWzvVBp5nwL9nwj/30minI6iX+Mu4iTbyX8wtzNvsHdwBdzyv0p/5OOQDnxO+nAmKYou SashHUompU65DtLTqgikk2peXQHpu+qXNPM012t+QZM2H9JNNOnIlXQlXUlX0pV0JV1JV9KVdCVd SVfSlXQlXUmfl+TfP5DULyLo95P0BxMuAB6Q3LZlrXUrGhZ4shczzVlNSxZGrPPEuM1oSXc77RUt Kx1prv+O3xP+j3lYNCDnLOXPOf/0NOSY5lCnv4HORW1oGWpFdWgFakALkAdlo8XAw2aUhZrQErQQ RYCn85CI4siGjMiC0pEbOZEdVaAWtBI5UBpyybOZQQZUFjz9t9v2nsGtm3vkH5vcjrh/mFrl5dVz 6Nz0ZQ14ZhieBdKB/p+B2YG2zADnRC0AJwG+DrAeoABgD8A6gF0AMYA68nt08u8BtwLV8gZ0NwX2 wX8MuJrPgQ/QzZ8HzAPowRQcvBTYl1AJp0cHZFChcvYEKqVAcU5AB8hGtI8C+6qMH1DcD+OgnT0H 41LA7EEHZFiKbDOgyECG5Hn6Gw+VCZM1cCzx6BNrDdV/Qe6kEB959R35t/lP71y/6pNNUocOKQ/A WBVKnlf0fwARhQFrCmVuZHN0cmVhbQplbmRvYmoKMTEgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3Jp cHRvci9Gb250TmFtZS9SQ0lTTkQrVGFob21hL0ZvbnRCQm94Wy00IC0yMDYgODg5IDc2NF0vRmxh Z3MgNAovQXNjZW50IDc2NAovQ2FwSGVpZ2h0IDc2NAovRGVzY2VudCAtMjA2Ci9JdGFsaWNBbmds ZSAwCi9TdGVtViAxMzMKL01pc3NpbmdXaWR0aCAxMDAwCi9Gb250RmlsZTIgMTE4IDAgUj4+CmVu ZG9iagoxMTggMCBvYmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2RlCi9MZW5ndGgxIDIyNzUyL0xlbmd0 aCAxMTk1OT4+c3RyZWFtCnic7Xx7fFTVueha+zV73jOZV2Ymycxk8t5JJpnMIy+YTZIJkIDhESAB IgkkCCgSClpFFPoSRFtRW6XVo7S1tPU5hIeBIuRYDre1pSparVZbpFStp6lcRWuVTM631t4TgrXn 9J57z+93/2B21t7fXnuttdf63t+3NiCMEDKirYhFczrmh8KI/hY+T04r1vYNKvcLChDC31xx/Ub/ 9nPfGoeK1xFiuZWDV62tZ3o/Bvg0QkLjVdfcuFJpb7EjFC1YNdDX/0LHzjKEun4ElbFVUGEc1b+D kC4H7gtWrd14g9J+UQmM33vNuhV9yn2yFiHzu2v7bhjUH9fAHHQyVPqv7Vs7oM5vGE7Zg+s2bFTu u7aT54NfGBh8853XZkH7XoT4vUKeYOfP8S9wm7ke9hSyIDT+9vib6RvS/elu9n5UDH3uRY+gQ+gE +hXK/I6gZ+j1ejSERtAv0OTfl9A30R70S/Qaem+ibhd6ED2KUgDdB9DNeCXejHbS2ofRj9ETaB86 jH6K/qvfizhXhX7K2LEygz8hA/MC3oC/ASPfh5rgODGpx3agWR0c/40fHmdmsglmMfNL5jZmHRNX aplNsLoR9hT7QzQLjhH0Mjr6OZ2/hP+G/4Y2oj8C3p7F32JOoMfQD9HXYD53wap/AHfr0DZ0J7of 7f5sV2EHb+Xev6RqGD2ObkVL0W8B08ehx61oPiKYvAvONyMd8iAf36u2fQR977+z2v+JH3clcwCw 9U3mJNvEHGFSbIjh2CP4LuC3T1gO9cLRDfOfBXhYidoBH3vQj4Czbqad7wDOGkLfAP4gv/VwfAd9 jL7CPALtr0PXsQ+w1fDsCJqCluObsAi969BB/CA6gxbDMYieRGfwTwH70JM7glYBtx3hXtNka/6M lqG5UB7BT3EH+V+jW9BadIs8pbOhvq42HotGasLVVaHKinKprLSkuKiwIJgf8PvycnO8Hne2y+mw 27KsFrPJaNDrtKJG4DmWwagcp7Kbu/a6NZI3EAh0V6j3nkvvU2yh5f1ACmVd0sj7mU45n7nP/cx9 3sT9FSlkT7UGm1vIwHtR61spZEthewqRt2DbbHiT2inZvyaYXJ1yN/f39kKPlqDFn2o9F1KnQsfe q9c1B5sHdBXlaK9OD6AeIGg7uBe3TsUUYFqT9XsZJBorylNZUoopTJKyJiXf3gtAsAVGgie2i0+G x0fumPwIQbcMZFMgnBKaUxr6Xv/qlNyXQrf795aP7Lhj2IKW90qG/mB/31LAXB/McS9iC5OrOgke k6T0rvKnOBicnrxQ40+u8u8IEnQkV/XCOdgCvT63Hqq1zV3bAiPeVBZckymrlJoOLaZvOutldySz V/vJ7Y4d2/yp3XO7Jj8NkHN3d3c2THhHMggDwmDJNU2wlOxQRbmyJhUB/b1ryDvX9JF5Jtf4d9w+ QOd6B50DbZpcBYTp+69a7diR7A8m+/v6m5TRm1NyJ72gzsVddIGAupZutUptAE84+qS3pTugILt9 XlczmViwr8WrkH2ipletgYpk5qGfzGAmDJDyr/Cn0LyuIDStJaeBWrRjRS1lnkA3hl5zLvZK8YWW oH/HhyiFe4Ojf760pk+tEQotHyICtgZbe3fsaA36W3f07ugbHt+6POi3BHfsbW/fMZjshbfO6YJe w+OHb/emWu/oTll6V+F6wD3hgNZ5XQlvwNqduZ2TuUXAUsBYerocwAL8zVQvgGXU2RXwA6IWdHV7 AU9dBO4EWLkSRgLGrQUaq2gjOBqonUBPswoGAoQ7bx+W0XK4SW2d26Xc+9Fy7xCSQxLQo5c8Gck8 cSwgT7Zmnkx07w3CW/Yj4mM4UmLRxJ/Z4rQlV9WnsPM/eTygPE/ZmrtYL9OtQIyXJZBOAklvTLkk gEukHUCE54Mpi5Tiu0a8jd1+ixU0AKHe/GD73MVd/uSOCS5QatSVEj4AVg/2rdqhihJh+s+vbZ+f QTjhWBDp2wHjW5evAaaBv747iPoJ7LCkWj8KeAM7rMEsf12ITJVp7uya/NaMYgKF07Q3iLfP3Svj 7fMXdx0C/8S/vbNriMFMc29T994CeNZ1yI+QTGsZUksqyY2f3KB2wuVDjEjbew/JCG2lTzlaQe9X DGNE68RMHUYrhhmlzpKpY6COU+pkWkd+FYQwIk53I6T3fxr5ZJPuACXV5F8XqdGcB5tmQf1IhIEs SEYLwCPsGB8Hn5LZ24mmZeGboZkFzjKUnVBYlMDXoWW0XA93Ml63r6QiJg/jdUMub2wYr9/H1gd2 TvPg9dCzCs5zoAxCeQjKMSi/hyIgM5wTUJZB2QKFGx/B84dycmOHAFgxlGWjwBVDNREVKCiCwa/Y 1+j0mZ/GS9B7UBh4++J9bg95++J9Dge9DlkstEf3Pq2OVAyq0xsk0yMPeoYcCrB8yO5QAfW98zLA VUOhmAqYiiiwckhrpEBfBhgYqompQEmZCuT6YZIDQx63T2naMVftMzWhAm7lBX37bHS6ffv0RnJd NlQSpg86hhYuVoB9dQ2xqmlO3AGr7AAsdgC2B+G8FQoDrmA/0KUfoOfhfJpAuH9osJ++uHXIZo8p gNOpAoANAjQNWQlqjwOgM9GaqUOubApMGdIDgKtwSNaHfW+/0+9751SVz38E1wEd62D8uiE22zdN hxtwGJjFh+NwNcI1isNDdl9omgHuMY7hGmSC2ghc7XCtxjVDFp98GNcCA9XKIcb8h9AfGPm1/ILY C68kfC+/4vFt/TX+NVx8r+DBV/CzPy/zPfvzutpnsf5nLT9jQO8dfF1rjXWcwgDKeUOl4ZhlyD8k D80ZGhzaOrR7KDX0/NDpId3I0Lkh0lpuOQAL8rVg80LfQqZjwbIFTO2xMt+6Y/ihY08eY+KHHL7Q T/CRoy7f00edvqNPO3yHD83zHTxU6nvqUNg3DOVQtM43jDfI9YmwrxHKlMQU39REwNecyPU1Jeb5 pkGRoSSiYV+4pt9XE434opFOXySa53s+cjpyLsIOj/9l3/7CGbHh8dP79luCcP2LbNqvNcf2e2b4 nr8Wn15PV6PdRZh0PSxvePxfZe1gFjDFOuAM8sxzrTYrNvhtLF8F3QZXbl25e2VqJffkwLEBusqy fui17p4t9zDrduLBb+Atdzx0B7N1N0bL5ywfWc7KfYN9jGWJf8nOJeww3ig/ZQ/7Vtln+PZBqbBb feX2Qp9kr/OV2W2+35e8V8I8V0IubInd4nvQ3+zz2fN8YJF8fnuj7yHPPJ/HO93n9TT6PDCOA/rZ 7NN8WXaPzwpl0I5l+7TmGBKwGcNfCCfwOrwFP4mP4efwe3gc68wIm1EIJSDE2AJu8DH0HARi40in 08Z9ZsbMMs8xz7HjzDjLGYx1PFfHMnUY1c3h8TD0TmW1o/bOppQNw3V+015tWGpP9c9r+trXv56b upeY06253cMitAG7nMLf6E6JROVTEEnw27AR/jZsTLHJlJBc1ZcSgi0byI2J3JjAizIlU2YCm4Mt OGVPrkrZgy3SBmnyD8ZQAfUnkb9Jj9B10uf9NtK30xlIeKOEoBetoSORk5Q5Tbxo4+ePpDylC5JA zyZXwQkWQluTFxCtzhA1rwH9CspCg+xPCQyHSAmdfOMkPVVXBawBayGcMLT6ZCuPPiVXBADoFPQv qJmPcr9GerRInso+hrlj4mM6swZrqoyykUGP6rZijMt4i9EoNPCPavxcFSdzcziOc5IaLttggLNJ r4dzCKbV03hWGoNTDwrBeazxbHUVDliD1kA0YK2xBvhoWrMnrcF/24P/xjQSYDf+W1oD82hLfwOf h8iaRVG5sAxLTBTVMUk0g1mAupl+CGJ1DMMu5EI8rFfHeMDEhnpqQj3Icj4cgnf0YBy04fPpd+5O 4dyx9cydZG0QE+PH6ZiFso5ZiEXSuwLk8IysIzMmLMvgUI802oMSo4CooLUGP/7eeyTAZ9D88Tc5 Pf8eYCaInpEdEdygT+I2/SYrX++IBtocyQCnHR4/J2ebzHHWAifHIS0TOMTqzAEL8DyDhsdf2m80 Mg0AnNtvMFDg5f16PQVO7yeYowBBJAAX5HIyKYS8gd3CiMAIFtJZsJCegpN0EwykqWAgPQVYxX7S HoCRfUZrXAipDNMzWhPKQLCsxCgA1VU92MIE8xmrJasmnIVjEGMWFRcVBfMFjSA47E6X01kTjnH6 P33w0VukjKPc7Oy8vNWd86/25Tlt/tyrF86/mvlTel36NnwL3o7vwdelb7lwsO3Md759pn1WR8cV s965+4FT82fP7wC8nwFmHOZfRgZ0k1zIHxQELasHnSSGEH4SHgMRtHqRLEvvx352K8sQ7UlRBUBa 1pNHrIGsGO7PU0QRQDaR5ZMHcGZNRmtWXWahNaNSXTgE/AA+xlhjoiZEqEl4LhANx+LAeOzwWBk2 pd//9l3a+7G4i31r+6IbP3kGJrMWIY7jz6EitEmu8eQXuiSfFGjkY6664Cy+1TUz2OlaHFiSP+Dq 9W50fdF7k39Lvs1uNx12M0zhYSwSL1326S3xoiIxkMjpyGFyPGT6Oc5CZw4bYvAIuIiEQjpjnAlJ PetdNaGQQiKYaTgBANAGphqLxS8liiYIdTVhCPbpHfwFOO7C6hWpzkc2F+cHl8aja8NlV2Trp76x 4vk/lxYUrqq/8u0k8/oLVz7W85M3b5h6pS8vz2u3Vllf8jW88fSibyambZ268nXiUvaNv8m+CyuW 0RF50Gkq0pY6SoMxbTirPhipiNYntS1ZbRCcttQv0C52Lg4uKF9aPb9+hbbXtMLc714dvE47aFpv vjGY67DHood6a3FtbUCv0aDDeqawsPRwQBdrEAmdGgLWmN3KFoQCCe9WL+N1ErR4CT0JYQH4WKbs 7BW9Ym8BLiBI0hvjBYCdGoIjwr5ZrrrQqARWBNBECqE41NbVEX6+BEvAvwRRDmcGEoRgflFxtIby 9UXUBqNwq8B4PHZNpGp6jmHa7wcG7pvS1Py99aGrKyvrk4lpw9cNvt5uSry0ZspNpSVlobKyDc0L mrb9uDy/aCnf7HHYy20vButKpartS2467DZpyyVpW9/Aj6e1tMaKXqzsLC4vXzN37qq8PNeerZtq 52Z77KAMSoDPJP4FpAMH6hY5F5YeFzR2WIBB0GiNhzDmOFbDsiLiNAaKG4Iugx8jv4jF4fHfUfEA 4H2qScSMAgHgracIGkXRKIRqFMnvqWkck+oaAW8JQFijZazRWle3ja+UuJstx0FZBqlCxjXWmoAV c9LekbFrme8M703fmdYxKA2TPcWMX3iOaR07TLToZuCXD2DmFegBOVwm1osxe527TWy2t7kXi532 xe414ibR4PfnHiopEQoOB1idznpY0AWDrkACuhMVqadq0KDqwPMZHXj+KarwCv3+jPz7ydKp/PuR v1eLtYQrtMa4VuEKSRoNZVScyhSwwDFiAXrwJUR3fYbuwCzWgANYUmUW9oPk1MRPNl793CyTa2Gk YfmUxi+UFhZLpdLNs+c+XM1Wj+0saM39woMz2zrwa9cMN7dcESp60SrZHC6pqvz6OR0rA0U+t54Z fzK9keOK4rU/AqQtAHvh5UdRIapHP5eT2hw+6LK4cxzBupJwJFw/s6Qp0lLfzSyyzAvOK4Cou2Bj JCtXKD/k9wtZTqfncBZTe0jQObIJNR2OIjAimBqMf2xCZGqVUW4IhQO7DSMGxkC0kdNgjRuo7TBQ 22GgtgMenZX1BN8GKnaGCRtREw5PIFUiBgPwSQQNUHsJWouYaCQrHisgCHQEFZxm0Kn5XGvinSU3 7+kf+EFi9qI58+di9KPwwoDWu7L+8B8d0+/tXvSV6fPm/KIqVrwi0vpVmWGmVEhLojd8C/9hwzPT ktNbmudi84lncN3G9Vt0+mNm96d/DceC0alHty/dXO63l5U4S333H60OFT1GeHQFSJcdeFRAs+QQ CzHJgwxrB4cBMexhnmVEFiOJ2QhOA8MRtCLFjenltnI8R/0IolhAr4DEjFlh2URYtt18HJwKDFaE s49t/jXzyIU0u5d7/1MTn/8k8bbaxn8H7/wAQp9cVI99Bx2AWIHgGSwWAPoMoMsAWmLDVhCozFol Vpmq3OGwLMom2d0U7saL+U5xmXVx1jJXp7szd37p/JqeeL9uwHVNoLdoRfmKqv7Y6rrNWdeXb6jy FTsMUW2WkMc+Vcl4h/N0yF9dXesokcyBiMECCllxKpgGAE5RZiE1BwjVawUyGepXEEtrpf5EQKqV sgO7C0YKmALKQCZrvIAyUAEV2QLKQAWE4SgDFVAGKrjIQGBuJYlq7Lq6UVA1Vqigngfob2Ah2gxH CHsovOGKxWyUYYoptwCrYMJfRdFILB6lF9XuOYguR6x06xfX3j59um9LZNHUnBlX5a+fPr/r+zfd siv9zrqDcmLal266dk36p7/48Lprv3xr+t+56/tvvWFl28pSa6O1+etj65deU2srz4t/96ptqfvS LzVNbfzB0ht/0SjIu77wo9O/3tN/PC5MeeK2Y2mi9prH/8BpweOzgwSfkGWuWlfrrPbUlhZOYaaI Uf1spl1M6jtdXYWLa5fUXV17Td0mZjDfFvaaD0WjxcIhLwNYOFysC2ehgCWAAxnhDWSEN5AR3kCG HoEygtVCApYFyrSBQcdWx27HiINzOElPBzWaDop/x4QAO6jYO0IX0S8pAjwWDhOnQtGKqvhmBHNC KkEnFkbImUpulsPOXGIrs+KqtBexcm11+eLYTXdXxYp64/I345gdY9unTd239KofTpm9YP7chf97 b8niYp17Tfz4afOcuxbM356cM49du+tYpKog9cMrN5X7HBWF5uoHNxxNNrUlp81Lf/SLQ+kDazdu 0hqOmTyYORcLF0Sm/IT42h+AEJ/hemgMUyAb8UKGFxbyogZVCDjj6OKQ1DjWSPmK2rAaK3HXz7wH P1bGuZ9+H9x2Zvwj0AQvgybQgKU9vVcgGb1DUH1e9hGkYcq6oo7XRcArRZjlRCSynBZpQDh/R82R VmvQU8/ypZOWl06CQgAbCtgcsYzAWyXJK7fxSMcWojLoptWJ/DYOc3ZwYbU6YRuETXZYCY91jAN7 mCJcCiFMG04ybex1aBNrECJVOohEdFodZll4MZE2h9YaZ1mD2eAzJAxbDHcaeLMBQ/TUY6XquDFR R3weEuJss4z1jIyMKBdxBPd0B3ENDrIBFkbT4Y/O449e2Db2v7Yxt731R/6FT0J4d7qXmckcHWsC vN4HeLkN8OJABagGF8p+3uAwFBvqqtvsbdULmIWO1cFNbl0JjeSyrOWRPDK3OWaz0JCXp8mNiGxF RCM6BYI+pyOrHJll8xwza3ZaLEKD2UnamamyMBsI45oF4pyYaXMzHdNs1hQ6EDXnzjhc391P+qiB EDVn72cs3dlMaPS7TGj0rJylhEZRc1SOPhdl88rtmuHxT/aTtwPwMR1MQ4MHMojGSDrC/fGDpJ+m P2L5iErLWJiiVfmNTsQPEuj+UUlRWVA3ShxMCWdsH0QRkx1MVaSA+agw2S695W7rnN45siu9AN/+ 0EMz57StW/61u9N/Liipun7V0Td7ukIVRa1VM0PrVr753S/fW1cbwT9f90i8Kc6/4CiWbr9y9Z6Q WHCMMcY6XF5DepYtL/fKse92ri1ym8Zeyy4uXgGmi9AxC+ioRetlKx9lGA2OiqxGRIQJFPxaCX5/ KVsUlOnNep+eYXiCsDRF8edi7hkVUzoFUxlEkRA7oegTGskTHwqcRy5rrJ3ZNbbqBHsTH0gvTY3V wJTU2T0PoB6HDhhlorYUERxioyJhKAt5myjyOg2LeRER/+48nYqWMAJ5CMAFSn8Axin9AXiXTg7k NdOcKgXSHJO1kOaY9KMiDh6xoicxNhpEls/04alvSTrxHM1mAHtQied5oyETS74xMhFVWk6qF5QY SYxQvqiu8soOWEpmAVrGjgwZZ1amyhqZKBcPGM0kfyKydnhN+iCp4/sNgFtALMXwWJjIdqOC2G4s BQCrRKHBuYZ7/sTY/BMnmMdPMK+OFfMvjA0zMwh2e0BVPkSwi76voFU2aLmwwOrYMBZJEP0+XSiN la1koayFxs45NG4eHn/pKSV0vrhcCRY3NgJ/ZGWxi4OJ+t06O8/s3snuZlMsBNs0GBdoYM7QQB0G ISucY2R71MF6RsNjo7CqUYhqw7AmCGpBRUcDDlgV89DY0aNHmaajR3dx392169NlCq+wH8FqeLTg IMNyUSxS9tVR9j2qZGgQ0nB2nGFcQn5ZT+mvV0n9M8oZuF9Q2HaUMi0RZBL/E2yyH1347gnm26AP f6/y5wiRHhyXr9BTBr1egw0ar6ZAE9EkNXM0q5k+zY3Meo3OjJHgw1ahCEeEFmG+cDXuFTbjQcAB 5gRmMV4gMFgwWolN0Sv5GEC6Hu5BIkWBxZwoYEajcDOVufOykVBDY0N+VfWdo+QC4CPZqvAO5SWn qgfTGT2YzujBt2QvxcoACLUMQs2RXuQMb7VxmQG5DL44wvGUETiG5umo9YPaExRrXEbYAW9AvgwM vClJVuILU/6so2ZP+sL6HtTTQ/gUEwWAgUtHfjd27SHsZhYd4rlPLvAvfDrA3Q+2HHDMZwOOLciH TstzkuZkLqPDblyO69EUPAu32Rfjbnt37tV4jf1G/EXLTXazYpYZvA86WTSeCCOTSYPSyo4ILOJF q8NsBGEm2DESRHrJuo3URTXSbJiRDmA0WvhJKvBnihpAKOBWxJAihZ9gootqgKKD7/dbziu6j3IR MfsTabRG1TIQpwpvs2wayx7BEmAkEFCi6QkD8RlzwGenx9MlZ07grVsfv+KKJXvuXFlZVTY4//gT C7ZXSaXMnLEU/0JOTfjB6x5+PYr3TBvw57jGfpUXKttI5H32+B+5Jv7PYK9nya0hY6ldkuqYOmMs J1rcxiR1bYZkzsyCluLFzEJdt3lx9oKcKwsGhDW2axwrswdyVpb0lq+quj4nZ5NpYwlTIllNHPJQ q+4gq/XlhfK25LF5efkRD7Oexzx5EtDq47ys6EQxgnS0V6UrL09P8at3VJJWOq09XkmJUZlJcQLw DtXHlSSSJxQB4C3KtgA8L5vJmJWVYL47ogzHFRIaVJGnhY7drpSLcVnIcC7qQbioB+EykeFclLou +nbX8Pjr1BF0ERJDkOvKWG+gEDFUkyy7RHJFrjqaI4DH5NIjkRqSCeUvJoaU7IDyF41MDm3VSCWT TGJi3/tDv2n5xxse/lFXb/ILC2dvClXWYM9vb/79MvP0323a8Uj/ssTBxu98Y7o844C3ufrjpQO3 DXYPeu0ep31quPpriw58GK4cndb3pdXLBj1WKSt09PZFjzRMayUfeI2DTnqceqyPqFpdL+Ao8Q95 DYMy1otaGGq9kF9VC3/KqAVFryOkFSf0+ok3TpBYlur1HHU4szahZfglGjuzxIL8aCfajTiad6YJ lwlD9hfZSBUQDLdOu0XLTOj3s2NniTMwRpU7yeiDL4A/SBu4J9IGPpBKUQ3rAZWdC6sxYP1B1qKz 0kD43H4CiCQV9CCBeDaLzWfj7BL2anYzOC+cRu9mnJzEFHBFulomppvBzNC26gxGrAduYXhONOg9 XAlbzJVqi3SNTISL62Zw03Uz9V3MKuYq8QZuB3Mr9xvuFf4V3dv82+Jf8V/1eXrRYI7rdXrGYIN5 iVp4i13ghVJUjEv4IqENteMWPimIIqtneaQVqEdC9+hAfexGKSWDr7AuQiafKWFaZmIF4qjQvHtI ohzXQ530xkYa61Innfjm6kXqWY9I/EsSCZh46+RPk5ve8fv0C+nfvJb+yi9ALZb9HFfgMuKxcy99 Wg56tIx7+dM87gzMek/6BuYJwQ68USS7+KfB4jyN9SwCy4SwBfvxHMzhEEncTMRFiosWYJ4Y+5gR 0z/E3ekbNA/c+bcvE32yHEZbQ0erkE3c0xrMktF8oK/Bkh5RLC4Zk+6JNGaCeDIozaQHmDVjH8OA P4SBb7hTuOVOErnVj7/J7uNuQAYUw/dk4i0DuPcqb76rZHkRNupsvil0DzSX8K8FY4ThZytKVHK6 abaYaNNFYz4Uo3xOWsQMhNvJhqqcT2YWi9XGNW4DEQY3feSmysFNN6LcoByoFLjdtfGL3o0KPT9C vLiERfHve3rAT8iqI3keBAHdwVqZpsmG6aSphXk3E4ooQDkw7j6nO15JrlpdXIJVHDBZ43iKj6wn x2CM+3y2yo4yXFZGloNMsBxYk44u52N5Jhk/5ol6zGamIUr3B6ICGTi6rtZtMVnibgsoXkkmJ0nj dTtJO7efyKObtnZnkdbuwbhioJQNHsWNlBop6a01NVTJ0QWDNYf4hbCd1A0ejJqUA3XnEiaSeTTZ EiuIX8yPTsqkW4PMx80nE+3Lr1nVvTPhml0Q7ulMbg5VxJavuRKjb5YUFKyKT0t16SPPLNvwYGJK 40+wDccEh821bEHv8tn91ilZnpxIqHJb+8bvV0kBsaBprtNlLi48Zi4oCFXevXqMI5yzffxNrhq4 0YBy8RRV82UJ2WyTl3Nih6ix6WSLDhkzXo0xY2IAeI2aGPqI2v3h8VOKrTcafXnZGhsotQOkhc0x oTUddFMC7p+lbOJw+PJU5nhDGhmZ7A+PAioT5FxdldK3K+x8vrbbK1f5ZEIYH3Ub63GNIWZqx02G pGlhzsqc6zTav5s7ob2N6lavkdLU6FRdGCWLD8DLsp/y3HofTJvuidk8DoHme6if7bg2j9CZkFml vXTJDMEjAxpHlAS3kt+xIEJgDYklCEGz2HWbts3+F3n6tU07H34m/dHPlnwpYUgdmb5n9dOvMeGf PTcjPrY1mPvLf0//JT1UURQR7GMvyZ1pGs01jL/NfoP7IihMg0qfWMiSsDAWsyth4PJz/YGqABPI TSCtOT+/tMQjZBFCCTQbIOTQXUoqnERnUqwLQmnJpcKpYjh//N3a7hFY2UmIxBOjdSd7iOEyNbir vbPdsrebWaAT8qnvYbIyDfkyyEyAqmq9MW6BmD9uJndukEmLxSyTNnSKgUC+MjvytEibG4dpLivF Hq9AySF46K4qFTHBQ7OigyUqmqlub6S4JltPkupbAMa7+YvyE8t4DBNJNkKBGgeVM6Zlw0gyOauj qenf1i99tFlvT1QUr6m+e++ju5bukfU5nflVs9zTZ8z47TfveXnmzI5I/ovWcpc9741nT7wxq/FF Y6HWZAYpaQD9ehakxI2KcIlKBbungBFdLns2ymuycxjkS9TRKMJOPQOXB1tokCSoEfL5TISsalKM S4oDJtrGZCdtTLSjiRLLlNGkJlNJ8d9pUpCVkzS+ojoHHGVrDaFUWYkiFOwUfyS/vqjD35J/Y47G w4heOstpmVnC1CaEAnsQVXFIpyaA/iIXULW7riTgNVECmWgDEyWQiRLINFisRnqXqD9FA1pViegO BKOf1XSUUtYa1jqJUOzZI+WyVLKwbsn9sXjjrOYpjy/r3Jw8cqR13bS7Hr7l9rZ7v1BYZbc5Zs1s e/Xr97wyZ+b8wmJ89pMLzFfzPa+e/LcXmhGlz1sc4jajPCThHpU+TqnRZEKFUwTOn42zs91W4EG3 z5hx5YyZ7JdqaShwOqPSXlbssNFYUS6ZCLLyKIVYSi6WyhabRQP6PHVj/HU1rK8onyAX6LSLpDuh cHFPJo3jlf0V1OQVmis8EXPS3J3/be4RTlOYDYbMXQVeEwjsxwfMljisg36YlGUDzCsrUpdzlQG7 3T4P2VWCNVHr+ZYcoZtO6ysSFVgyWRSisU7ymKXkZCkJWUpOlpKWHSzPZOakRhqBjtKMkyJ1qi2T FKLyfmS1INVCOQJ2NZmdkTZb0cUtKA2zNv1h+lWc9/aq3Y2N8oVPjj8+9YtVNa0ufWB5cbx7F+PP C1w1q321VFYueMD5cmArbm6U5UO3rvzpr3KcLsl20lisN1uYf5t1bVFZeYVUfvV00Ifks5CXhDyU jd5WKR3IdoD3nnAgvWmqVeStvFHUapFJvFePzMhs1XtMNLinklZA6Uh9FpOyCQoAJdHoCNnxtvyR kIwknMF3TIyGQ8RB8cqNor3Ozky8RbzkHWafOWRm6auUDyo8yGQx+U2siaLdRLJjVJAIQOVHSSsw 6pshcGokrBGynFVf3jjWmBhTPqkheSk1GHIoeb9gtEbZnHExL+ncVxZ+cQDH088d2bLlmQOR/lK+ V2u9+o6iBy4k2H99oPDZU3oNkY90N3sW5MMAUWxCxVqwjMelnFwEAaluWq6mpsYmQ3SLPJTFPQzB kwesvRwkKPJ4opGwxk+f+am28tP9Dz/VWX5wBij7+/3RyEWWPz7h+GW+HaihhSB0apTqqqlCRGw0 NHpnCUlxpuFmfHO1Vq7BIfI1z8xc/HkzNIcxTJKIpJFg0OMp9xAklxPNVUv9RJogK6ecXb4uGg5r vH5KBz9lfz9lfz9lfz9t5B+MKOaGsL2afACN1nPppHuU73eILzdJeeHJm9xRousY64Sii9dYyec+ EOeyJa1fbLjz4ZvvmHn/2AlbWyjSFVl0Y77fM+vua4+duaIp8djSRVtk/d6Px+c92oZDzEB+7qnj h5+pT88TvQajpbK09Jrk8qYEzsG6219pn3FFaVHVhfz02fRHHudxkIjtJIcH1smJ/SptjXqL2GTj TBiLRhJOfUwdMZK5PZ3J3H6cydNO2KWzis7DONtlMWT6GIwTzptRULWk4rwZjdmui85bhurELhG3 qC5MqGxjHU7H9Q7WYlSnYxSZCdIxHkTpQnNrhDQ0UFG+UhBUa/SubKXWaV22JSNbRiLMbtLRSJ0z I21rZKhTd61LzZxLjRma0sgwoWzEgU2yXvwUIeOcOR3sR0fMDte86a3fmn7kSOfDS35wmNk8+2sl ZaXtjReOgjN2sn3Oq78COdoCDtkC/rdkhwxLKq61fIvAMjwWORLFF9GcHuIZmtvSTUp0080YnqN5 HbrRouYfL9LmvOyixBGpx8ApW2UqcU49pdBmUnbhpCSdUJLjJyjSqVGZPBvQOhaaf/xELiI44h7i GVLD04wl34soRpGnA6fwCH4eoliatjPHaRqfYJgkfYnpA4jiGlNcY47gmsylQ/k4ZEhvjks9k74E G5XO03SmOi2C9po46C0848gR48svcz0/+Snw7R2AzRnAtyz6VwWX+xlM88//Tdzw3GTcwLsJQpx0 zM9b6UFYaQePL12s9x8tluf4zEon3tJDVkrfQ1dIVieQrUcikUIt6NtKrO5+ytl5AV2BU9NU7GwK FHMBLkdAoln0ihDNXjhIU3XIlAFNZk8G9HgR0cE0U4pEFSt0fw2gMjUFdUrNPIXMNP1NNwMphsz0 w1Coff4pZfcv5CWyRhp4J7YnvFSsvTQ3DbW/pE293qrQxDKtytV6cUtG+aOSTgJ6yyg4fVnUUEar qFPDB/kyR9BRVhQsKqvzaXQFxe48jbOpGBbOI7NXrKAEqQANoAr+hc98nvQu2WwE6D5dgcckKl6M mXBygJDKTLuZKZnIIuGc5xEVe+BVPDz6dVtaLicNvTTO99IGXhrXee9DZovZb95pTpl5s7kq5K/a UqUk2XrOq65Q2KLoD2td3UTQ19hIjfNkL/eiQqEx+6X6xaFYgosxPb/ZYLO3Jeq/Nh2zRyg45dbE kSNtdy1a8e2SBd9bNuP68opq5tbZXyksKZrebA35xwLq3ayGC0e5ns1tcxdftWx5Rbhm14axAMpo f+C1v9f+wj/W/p/8n2t/8f9W+/Og/fGE9sf/o9o//E9pf8c/of0B5VT5g/avG3+T8wGm9ciFvRlc OxKsaE5oOQPKEibvJv15/8T+kpqEeyezk3RK9isCmy1Qh0qgDpVA4wkhW/2uOBOru7M/K4cgeiSR Nqoo/Iib5kPc1J1qMEUsEXuDs93UYmmxtzvpzGCGOoMXiRTb+SqqT2eSa5/INRTbNPeP1rt9bpwF kTlpnInPaUyuxOfUYRIGs9V4YTSzXzWRpOwhmRCS/FDCBMRGLjpLnC997syf0h9i25tnsOWZB+++ 56GH7rnrIaYy/Vb6JJ6CLTgbx9K/SL/96osvvnrq1V/T/FS6n6sGnFsm5aeseoG1N5k4Le+VWa1o sE7G+zt/h/eJj7x/l9mK8uXpXZoMj2vECR4XKY+LGR4XxX+YnqLRLt2W88oVkzNSUdyQVZ3bjNuz 5NxF5pVm8bNznRAAq3dC+b2WIcZ5OXvSFuR6H0yT8rfGQ9P2lO9FyvcirRepMhOV9BTl+7AamEuT 56jkp5SU1ATfZ7GTE1ZcdfrDX87f2gxx96MDI688s+m2Od9qblvdcvf3mFnpP6UPFJWky/m/XZdY kH4+/e/HXpxeO7atwPOyqn+Y33A9KAs9KHuR0WL0G6uMnEFrRmgLdyfHcC06M69Vt5Wz4jS5r6bz 7QaNqO7LfkLNncZDP+a3knVq6Tq11PxqFRtNP0NIK7TSGtTvE55VPku41jaxdTomSY3qFjQo6x76 ISVBQvDv9DLzG50jFJh1Lyz7qm/PyM3NYu8R2KZpF97mevYsaWdZsr7m8T+yV3M3oBjepfJfTrXV U8LlokCgcGoux3H6qUjrt9Lv4q3VJJtAZlpNv4AgM62mT6pJUoHGUtXVtXG2xMPROIvm0D005+Oh K/JkRN/jmZxDP35RxR6f9CW2i3LgJiV5Xks5UJcthDzZjlCRpjQY09QF25ikr5vpzu70zQmtZgZ8 AxUrQjcy1/u+6vtq0Om2u12l9lJXg73BJdhdrv1SpV2SKq+Tbpdur2SlSpedQ7k7A3jyUlk/qWf9 gsfqrVa/JapWbAtDlnmeqvNqEpDRzeFquqcFqy7xemim3uSIe7JIGw/NqHvoJxseau89ynJHM7uI 9OPzi5+e99Ddw22mSsl0s+U4Wq+yNv/53xsXZ75i/Afbifjg4E9lXfa0WNWGqRUr3UHfzJ6CjdVb N559uueIrJuxd3HP1lmdZVfVbb65Lt54n7cx/0VbpduZ77C4IpHmFpc221R4/7X3Ha0M/ryu6YqO 1qRT7zD5dm6e8aXKcIRwjmP8XeYR/kEEPpxcmCtTH9Ov1cdBzXBTdRo+O9ueQNpELs5Geover2f1 GXusJ1lCao/1+lydUSA+IN2wEYxUYIwejVnwCX6WFdgimtrJWFE2s8NOPkRR+I81qF+epKmksLty VOMohXsaR6WQZFGkpYeEvOTDReLghMi2DJYAs1GScCAfcTgC1onPF0m6B7/2nce2bDmCF6f3CHbr rGmVC2366Frnk08zVz+Ap6WPPTA2umBpSTDo1f7YbCX/Ssr3nxwr0NfheAw9hmfih5hs5kW2ij3O fZk7wv9AWC5sm3xobJq/KofYCseH2qX0uFd7r26GeozqTxum0+MvymF0wJFQDtNSc4X5Pcsx64Gs DttU2wf275DDoXFOcb7veiz7ZjhGPTrP3ZePy8fl4/Jx+bh8XD4uH5ePy8fl4/Jx+bh8XD7+8UH/ nytG/Z+vyO4e+S9OPFAEANjQjJmLcu1mV+uc6Ky2dofNWTgvu366lOMpXbCwZW486TVVW6e65fnl sYKO/9f/C+X/Bz8ObaJnjuDnXAX57vwc/foc7jlE/kVzCM1AM9EilAu4MyMXakVzUBTNQm2oHTmQ DTlRIZqHslE9mo4klIM8qBQtQAtRC5qL4iiJvMiEqpEVTUVuJKP5qBzFUAHqoG/IArowAAnkv6rp 7Fu1bm0fmQfeifh/egXipbfn0LnxSypwphmeKMxW9E8X/hT6F+Ya1KaWo6RwV6L5UM5AWQulD0oJ lM1QFkBZAaUNSjPzEvrgHxXul+N/5Z5C911SypXCX4XuYy6gnkxhP0X3kcIvurRwf4VyHZrNPQYk VIsmjjyTC2tBe9SyfHLhalA9dw3azu5FDXBt4GKogbkD5VL4erQdv4S2TCp3CMNoO6nnulAd6UcK cwb63w3rfBw4gf0v6ETowBat3Jt68vAyc+OHyKsQ7omRw+T/EkZPb+w3fBpJd+kOiK1wq6V8Ab// AINl/y4KZW5kc3RyZWFtCmVuZG9iago3NSAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0Zv bnROYW1lL0VEV0xLUitWZXJkYW5hL0ZvbnRCQm94WzAgLTIwNiA4ODYgNzY0XS9GbGFncyA0Ci9B c2NlbnQgNzY0Ci9DYXBIZWlnaHQgNzY0Ci9EZXNjZW50IC0yMDYKL0l0YWxpY0FuZ2xlIDAKL1N0 ZW1WIDEzMgovTWlzc2luZ1dpZHRoIDEwMDAKL0ZvbnRGaWxlMiAxMTkgMCBSPj4KZW5kb2JqCjEx OSAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUKL0xlbmd0aDEgMTIzMjAvTGVuZ3RoIDY1NzQ+ PnN0cmVhbQp4nO1aeXxTVb4/59xzb+7NnjRJ06RtkqZ7WlrSprXSkkubbqTQjZYWjbRSFJGlsigg Y3FBKsNSl+cu43OcRZ0ZSoHaSh0ZdBAdHXGZ8bkOzmN0dEQZRXSQJu+ck6QUYRzf+3zeH+99vJd7 8rvnnvX3+/62QwEEAGjABsCBpsbWAi9g1xRatC9Y2t0bfc9bBQBctuDqVc6Gh2YgUvE2eb/7st7L l5Y2v5wDAKLfT16+ZO1l0faKOwBIObpoYXfPCx/e8wAABX8llSWLSEXCNOkwAHgJeU9ftHTVmth8 HXT8JcsXdEffM0i9cHpp95pe/ivuz6T9AKl0LuteujD6Pf8oKZJ6l69cFX0vOES/965Y2Lt24X9E SPtBsqb/FFIFE3+cfxmvxyHuHaAHIPJB5L3wmnBPuJO7AzhInzvBo2AUHAS/B/FrDBxgv1eDIbAf /A5Mvq4Hd4CfghfAm+DTibq7wQ7wGBg8q90Aq30YPAJ+BXaDJ8DTpK4f3EpqfwJ+MandcrAJbAf3 gQfBqzAlVvc0MsHoCj4EavQyXAm3ARvIAwFwMVgJrgM3k3Udgg2kroLUNZHaFWANuI3UjoJD4Nyr ArSDEFgMloFdpMVvWF0uqZ0DekgtrYteV4F14Bbw7+BnYB9Z1zqyslvBvecZ73rkQi6wCvyF9Hwe /hs6SHb0M7BRMAElAPzLlKs4xHgLIu8BEO6JfAEAdyk6gR5Ct4KdaDFokLVtc0pLMjMcCUaNmsco zznIZVS7q93dizY7qxc5N7sDXYH8vGBLR3XA7nJ15uc5SXXAOQi7nNWDNVcvsm6upg0GjZ5BlFFN n8WD8g+7COEOuFwu8iXhzJeRyP4tkz7tAmSuRXM66JT06VrkHMTkIyvspCa2AvptURcp3QGygPPW n7XEGndN1+bNNW5nzeauzd0jkQ2Xup169+ZdweDm3uou5yBo6hiEpP6JH9oHa7Z0Duq7FsELyc7o ImpaOvx2l4GMEmx1B5vndTirN3fFxo3VXBB924VA5S437G/eJcP+1nkdowTUzv45HUMIoqquys5d 6eRbx6gTAJnVIlpLK+mLk76AICSrHkIia28flQHYwL5iVsHeF4xAwOrEeB0EC0ZQtE4fr0OkDkfr ZFZHL8IqVDWnY/KqyUPXTgBBbI2oCrcAoM6L3Pv1a6rbac1Z1zxaw/0AXAoU4ErAkzn0oIAgGCA+ EiE2Co6COZH9cupQjrdEP+QckoeahnqHNgw9ODQ4dHjoyJBy/9DxIURELvfuTbSWOAJQ1+5oR41t 89vQ8jnwR3N2zkHNrYm4pdWCW1vMeGZ9C66pL8W19V5cR556Xxku93txhb8CT/e7cJU/BVf6W/AM 8sjk8fu82FvUg4t8xdhXPAcX+1Lx4eIjxceLuZHIJ7v3ZNSVjESO7N6jd5PfT2TNHklXssdWh6/e ffNusqzju3ezFqfkyG4pvWS3qQ7f0p+Ae5f0rkG6+/+0A8kPWJJK5Pst9hL5rkRC3ZloL7l5Y4JD d5Nuo26bbrtuwHGTY5tje8G2DRs39G+/dWDjwKaBfp18g6Qv0a1wrEDyVZK6RLcUOg9B57PQf/DT g8j5W/m3CFwKwaX6S5Hc/WA30l0E800GnGfKwB5TGc41JeAckxk7TKnY5azCTlM5fs5WjW32Wmy3 lWObyYvNpF0CWa7RZMMG8vSaoGyaUVWi0+Y6gAA1Twcd6gNBh3J/0CGRhx8LOvCTQQc3GnSgJ4IO OBx0gMeDjqcP5Dr2P5XreFJuH3M5nhh1OR4fdjkOPP2M5qn9v9GMPflr9egT+9TDj4+o9WMbxpA8 umEU6Yb9w43DfcNYN1xAyOWEfGr4peHIsKiUSrFag4gJ4RCCADXxcARGNm7dmjJ4JwH54IaUzhER BImyw0G4rXNQDLbGSOCh18pVK1d6znMNctWDQvWi7kHBHVhJX7T0RUuUX1s9qKO0zh3wwEFT9aJB E6HOGWRl/PKsjH2MTsQKsPp8c9K1rCIl+Q4QVQsFEIgqkB/T4wLCgD4FL77zIiumFroMLkMGKSBp dWoDD76mv4AQVMvuQVM5Cb1PejtlE6zUEeOg4xtBIz8fzOdJE1RQVBACBaFjUwuhy+fipPEB1Ium 7qV9x0nxMfFGpO8waociyIcjkb/KSp0OtRVAP0SwIOQ5Bvykr8ttKIIff/opaY3ALZH38Hb+U6AC brBJTiuBZapi9TTjNGtxajWsVwXUQWPQGkhVm+sl5KrnlLqRyIlhtRq16VyAKMYeOj4hTsh2lYpQ VvoJ7MjQZTgykF1N3+wugTSUE2hLQS9JpFTTtsLd6fqThIPHPKHYL1kdXV8I6pHLiQx6o8tphCUl vuLMrMxMd5qgEASzyZJosRR5S/D2r8NfhU98eQpKUP1l+B/upKR099r5l1ybnpZkSXet7blkPfow vDx8C1wPN8Ot8Npw3+m9zW/de/eR2bNmz26c+cm2+19pnd0ym7ANWojvK+f/CHSgX/bxNYKg5rRc HRR1BocB8cihgzqdWss2o9Wo1UKb1on83HKul+M4tV6P2ogROSKr6AY5C90gRxmSQjfJpdJenKDR kFKv0QikpCNwBXEAhYqOeTxl3oJQQVEI+Me9/qICKiMiX4PL5y0pLSkpLTK4cPnpN2FJ+Hn/QMYU H74PFt7Nvd9vNiXNmnHqAJHiIiLFFLwGZIIieIXcqVZid5LS7MYeI50sj5X5rOzUNqdenHeFtitl ef61ynWm3pRr85RIzK4oNMgGZDA4xcZkmJxs9Tvx1BmikjAhBaYYsnwy3RcxhSf2TBB0Z5SQLXRg ZAMpKiBQdgAjw8JI5H3ZwPBhpX2AjTKB1J5mPUGMZwJpTvszEJkliVA6yidwq0/nc/j8Pm7KSOSr PbTvFNpEQ7tMEWmXKXYVtcmldE4Vw5RKpO1UyXQ+lZrRAp1MZaEDU5qUSjq8amMxQ130OkYFoX// jFobyvTj9NdLBAP8FJdE9QzGMqJ8xjICUfIJhlxun0BB6U7L9BUTSaWXnoGq21dSUuSlYDVzBiEG XYrblH1JbdkF61ruemXpwstg6sP5udm9FTOHu5WlhxdevVP2V+5r/zDQ3LPqmgUPX2OoMCY6Dt3X 90B+vlNMkedYE/VZGU/p0rMKpty2JJwCS3lTQmJ3W1f3LIKBUYKBARLPJQAnNMo5xcinm2YudAZQ tS5olp1zjZcb+8Rrk9VaSUisNGA1TJUFpUo0RUUptJnimm2yT9bs43tiwjwhq5gAtTHpfbyHCSve nRCfyzlMcgNpjjR/GtLaJTUVhMQ0RxJpc0qT0qYeiby7h8qNEH+Oqo6aNSbvnzBhE+KkrKI91QLt qaZLoZ0J8ekwnUfd7zojwpi0QvoTZ0TKBOcnAqMSg6aYqLIUxP4ZqHSMXDGTlSFqUQYaq2ofvWz+ tmr14Fjj0PKDfzlw0+0tP69rWll//y5UuuVIQ2NjfmaxYBp/bUZr+HD4/UMv1V4wviE9+UVqf6+I fMB9jq8BLrBXbtC5G93IA9O0uZZ064XQp73Q4rPWw0ZlQNtomWHthG3aK+BC7Tq4Upug15v8auxy 2fycpHPLlCdumbFYHWP0u3FGvytPYfzd6k5kqE60SwzvksgYzDRAYgZIYiyTiOIwTkkb0+KcOuaJ UeWAYpo+lDmhjChvMjN9ekBxa3YzHEdBy4wQ9/klj8xf+3xdfRPM/7JrdJay/fG5D47ufbjs6oKc OrOyJt9bW1f39u3QCC8oyXq5qu71w8+/kWo1FxgINpcQbFbFsInkjHJbYfIFzkZbZXKds0NYJPTq JSNEBt46Q4uhmFrJKw2mf2JrNFFbkybH4HlSdjOTIzKU6lktAxLIZexTxozOJ3I+szU6htWohbkt itOYm2J22W4XrXQkcSQSlj10NJGNJjLHJbKWIqZjigzJokhHEjdOQuIxT8yhTUKm1wviUPQTdjPD 4U5DBmo1mJkwFHGGSQzHVWPNg5cf+ltzdWBvd0d/cGysYU3tjsH+O5seXl0zGxZDw7Z3Zzc0ZWTB o6ci6Po029vPP/tSLYkQwOLI+7gLrwdWkssdkrMysUdTiKdpylOrcFATTJ2nabIs1nQlrtGsS9XC codDl1xhxioaKiQx46hS+HVESV3M3rsYEJMolzWMsgFnDJQn5ADj4XaXzuVw+V2cAzLmQCUdBtqN jI1GxjYjw6eRsc3IvhsR7Wzc6IwzijApqrvUEhcVMGx6KL8KWEDgirv90iIz4ZwTGChKjeaYscVd p5+bXlK8vX3FB1OV8w8uDX8UPgQ9J/78xePw9jvv2q1G9svvmVpYeFHei9klMB+aCUYrw199nnvH Q0M3Ed0NkIDNKKQSnj0rX25jyLLJTMamMtNqniPhgd8MVNrpooHXiECSJSTpJC3BnDrqaJiLYSqn YqhQQeZibDoD0MoafanWQjGqddKRtayPdsK6aafQmbQUocwbao10HPL+tRyLNehY2luSJmPK6/WO R4kCwiLmoopI6DDuJcoMiXOCMe01u8wug9vg9pHEh+GMMyodPZlrl8LW8O6xvr6D+/wLc/lLpIQr t2TuOD2De2pHxrN/UItUY8OduIrgyA0KYYGcX5EwPdebd2FhQAomNORW5gULL4Ihfp5lMVzCL7as 53udhjTe6DJny6lYQfI4ZsIpIdvpphQKlcxppswwK3QCFFzpXsZkY1zFjXEVp4QcRYgNCFam383f Qb9t5+q21+H1e5GHQc/DpOKxW/V0FCvV7Qw6kpUZSyuTn5XFaFbWktKk3Dh1sjcJ6Y/+k/CARQce z4R6Z+iBi9hSX5ElZjx931T30m+qezgcPtH5SItyyqGeruvc7tS2+9YQ7a+Z8cTF3TfWE38UvF6+ b+ime1p+0hc+Gj6ZlLjf6JuSk7UscFmgCrqgYuDlhtrGrOzC039E3Wkphw+OHfATGe4kjulG/i2W jfxYToABRFx4KeIEnhf7JCjdRoMxOY/xsQszrmLGC8ywjBkvsI1kIYRXsKuPh3zcbfMTES/P+vFx t02Ik0yUPA306DCEiAzTkfh+cQLDoaNRj33U8z4Fr99DcxpIcMrR5OTG115Tj43x1qdPZeAQ9a77 SHEN8R8c+IGchSAU6VpuiwEh6idZeAHYkoGtD0IYXyqcWCpk7WF8qXBCByGmnSF1l4zox2cWypbJ FkmzLrq6a8bGyFLIqkZJtpdIdMQDD8lBLp3LSUhPyAk4A5mP5yqGM2CGIyVZTKzMTsMpPNQni3I+ dOQX5sv5Tfm9+fw/X3w+VZtEuuB8Zn+hlW2DaQBZ40csMoNUUwxsP4WsUXJsS5/toboAacrlYZth phZ26zNUyTo2p47NqWNz6ticOpue8YLOo2fzkPdXosG7PpO21jM909NInA7PCNqfEF+zqIwQEdlF p9I7bGwaG5vGxqaxsWlstuS4UJJpcsCEkswaJ8dhkxyXTvKERUxW0iGSo4lDlJC1dKbkbode1m/Q c/qC0IkJ3Ywqpv7sd0NZmf5Mk6ib8YSIVMvL/f7ycS8J7ctCzDMbJkJ4ErobJr0SusgcVV9WmhWJ YxpzYntz445GDkfJWffNGhvr2LlgxY+yVoxdObITra+7OduT11iRWJE67kPrZ27M9ngapp3+NQ6t r2/pautq+9OhGJLwfIIkC8yREzizxbzaTLJFsTIBa3moEc8bC0UFgKJRO8u/KDaYsaQcSmQGEzOD KTKopcVcd3hPLCY6QiVMEMf8DGBpEan9Ss5maLzV6rB2WZE+5t6irk6c5ORsmrg0CXGEoVITl55m Qrc0rCN5/ygqTQ0bgrz/nUmTEixG1fQnTvJwUSGeFUcxkRGBsTDqG6I6Ixsznj9mtCZdEpz1cyqK sQV7f43Wz9qUmZszwfY3X2Rx0nv4KsJxFUgEp2TbNG2xvtg0zRLUBvQBU9Ai6vwSNvs5pTrKaJaP RFlPiM+irlltT5JjPD0dz5KORLUodhAyEnmT6QsNQONR/Ml4unRKroimS0m6JEeSP2l5EjZi5g4Z x42My0a7YGGnJSyHFpg7E1gkJVA3lkRHp6cqpMS0Pf1Gyo3WswLSyRHpMcZGdtICQ1AP3GnRaApE s6GYR7oq/Ne/HQt/CBOP/Q1aDzx61z2PPHr3nY+hKeFPw8/Acmggd0X46fCnb7z66huvvPE6zT/D PXiAcJTG+GlyhheVmb3OKlRvrnS2k9zzOnF9sjKee/Ik95RUalOcp4Q4yVAcyz1jzDwch/PxqK2g JwXs/bM4hM/l6slvTULV3zUJPRmX9UQ2GrNG3ykbPTcd/ZZ8dAK838xHZ9dW7u6Zu7V+bCy4b/Hz 7x3YvL354SBJRx8YROX9782e2ZyZHc7j/7Ha3xZ+Kfzx84dqysY3pdteY9FbD4veqCwUsmcaV0Ey rgudDVzQVpM800nzLR4ZsFUm+Zaa5FuSwRTNqL6zpfmuedcpuTN6pvMv8y4Ty7sElmcZz8m2tHQU Ufy2nOsbLuCbSRd0G/5VFDY29xc9zx5rDVQOLZj3wzoSds1eU/PjR2+5veXhcA+yBethEdQOvBOs b8rOKjz9FFrjTn7nwDOv1sYsOLeCBCtGMCabgEavcWo4taQjdr1KqeMlkZ6GTRypyNmMO8Akm3pN SK1gjFOw7SoYvBQMoQqbFEeoNBHExOAcR6hEgWlgpwDpFJ6SMp75M3gS4h/RI4D+hHPNq4GGrYA5 wAIDM6qxxGGys+NWKHMbS+Y+RJLQ3sc6p+blcQNKaVbF6Q9w6CfzgryC7n5Z5C/c63gNKIKt8lwB SXYzSrJnSrnpXqk8vVJqSL+ED1laXe0Fc7zL+SWWLmdPwUKvaR3fZ1jlXJu9yrMZ9ms22jZl3wHv tauA1pqDU7kNacSMUEykpWVOj2YVMjviIMnEdE5yaSm4PJQZOYxzOYxnOXYfs8lWlnlalYxmLoeE /Sf3suheG8e2lp1qsSzLDlxWBfOgMdsz4UpJC4ZrU8z2TJicr+Im5ys5i+F6W+zEcr6vz8crmNlW sINHhY2J8+ZidsR45qCRRiUEugUTdnki8SVFyGBMZCKhpsJ9Jp/wFWdRt0ePaiaQPHFak0jzZFpw r4+/tf6lGmXnmz3rt2RmLsm+3nf7tWUXXvDLK3teDCjrfr/g8m2e3EuKr/fcWFsLK+95Zpr71arG pvbKtDSrZNVm3bWsel1hQelU93O++sbZ1W63RW1VptbPJLKeHvkIjfM7gB0MyZVq3sZ7eE6lV0zX qJS83Z7o56TGlL4UpAVbUkSNnqFVzwSkZ1G2nolJb1OKCpoaK+ixloGyWsHS45guxOGtmIC3Ipkl kmwMUvv3qAtWJFLOK/qTz86Oo/gu0J/0sjP1An9REcuNY8dcPpoRG4oMNDs+c7KAxn0/mPrYUF/f GLwpvF60WmY1TumxKJVa48jvUMsOOCP81I4w17HAk51hlyjqd5EYYi7ReQu0yyaVkKRYp+AQb5Z4 QyWvhOL5j7BOnseYfiKnRI3pOdEaipnRj+JhxEm5iMEvGrNpo/Y0GqmddRpxVqAmEv/G4CxOhN2x Y604n8W4TxUpa5mjE9kQYjxQI8QXzJKImxK/cXJ+1nlXlPXM1ZXH4jRfjOlFZ5htKMJzx+b/6orB Z8b0Nnt7S/0vg2Prg02vH0Z/GL+pba0nL7thGldJeFxBLGgf4bEAtsozMnGOUILLhBpcLwg5fBkv 8818F88LNtIS2zjEZYMs7gJQys0EtdxquA6JgEerOcjxSESQA9SGpEv6UjVIBovBOoDBVlEnQo5L 4BZyqznMJbP/tLlBQVQ0RDxKiKoo2UuI+WwY2qQfJ/8A1UnoJt4A4r5w+ZNh/wtwHiRI+PrHOHR6 E7eWrKacrHsDWbcKvCdvkVR2aOJMCruUxWUpysE0WMwV42KhWDFNqlA2gCAMcAEcEAKKoDRLOQ+2 cfP4NsU8qU21HHZxV/BdiuXSZSq3DgHRjwrFRiSLP0C9REA2pUqpsAm8AG1kJs6GeQwRT4Qv4HV4 tYAEHhMaCkgDCQdUGCsZC9IICwSyyK0anQbqNA6NrJmvwQLCEDOrhW9QE4mGvIQFJ0MeryGxLMTO mELMIsFN+mMT/ygvXG7KDcqOIog3HCNh4W/egnvCTcfgNFj+drge/jLcivJRYXge/On4m1RzKkh8 QqWqAFvkGVgoFgJCk9Al9AqCxCn4JC6Rr4H1XAeYC9dyElJQ8fI2zOF6UIMR4BDmkRotIkk+4jg8 sSUq1ZlMrjzYKukkyOEEXI0X4tWELzeI+qPR/bDtkN2cJdP9MASoUBOiUh1f9dzhcNULcC6ch0On FPAVnHX6Ga6c/q2D41/cFaCT3G+RIPl/9UbT0Ti3Bc/Ab/ELhVpy/4LdX4rJ4h+k65QB5bhqvXqF +kvNI1qe3HdoP/v+/v7+/v7+/v7+/v6f3ID+/2L0L//oSTz9kyUbeQRCcLVtgfq5+oa6lsbmjvaZ cxJMhouqm2paOy8+z5+i/j+8MJjDSkz5c9wWiZAS0pLGpYD+PVgtaAMBUA/mAj1oAHWgBTSCZtAB 2knEMgckEI4awEWgGjSBGtBK4oco4yAwEp7Tv9wWSKwE2heu6Ole1h39AuAA4L/zCsWzX4+D45Gz KmC8GZx40GHw3364h8A96EMwTh/eAm7hLdDyf/nBvweL8Gkwij3gCvK7BD8DFpN9BhhNHuQFOyc9 +xSHwCivJ+3fAotZP9KGW8z6L+OywHTybRceIzFiBckQKhgyvv2ickHLTLsGdz4xX1f+BbBHBfno dYEc+juiuV+M3BvuVN0u0pYSwwq5/gs6PNHuCmVuZHN0cmVhbQplbmRvYmoKMTI0IDAgb2JqCjw8 L0xlbmd0aCAxNTk0Pj5zdHJlYW0KPD94cGFja2V0IGJlZ2luPSfvu78nIGlkPSdXNU0wTXBDZWhp SHpyZVN6TlRjemtjOWQnPz4KPD9hZG9iZS14YXAtZmlsdGVycyBlc2M9IkNSTEYiPz4KPHg6eG1w bWV0YSB4bWxuczp4PSdhZG9iZTpuczptZXRhLycgeDp4bXB0az0nWE1QIHRvb2xraXQgMi45LjEt MTMsIGZyYW1ld29yayAxLjYnPgo8cmRmOlJERiB4bWxuczpyZGY9J2h0dHA6Ly93d3cudzMub3Jn LzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMnIHhtbG5zOmlYPSdodHRwOi8vbnMuYWRvYmUuY29t L2lYLzEuMC8nPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0nOTUwM2YzOTAtODMwNy0xMWRk LTAwMDAtNWU5ZjU3YjY1YjdmJyB4bWxuczpwZGY9J2h0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEu My8nIHBkZjpQcm9kdWNlcj0nR1BMIEdob3N0c2NyaXB0IDguNTQnLz4KPHJkZjpEZXNjcmlwdGlv biByZGY6YWJvdXQ9Jzk1MDNmMzkwLTgzMDctMTFkZC0wMDAwLTVlOWY1N2I2NWI3ZicgeG1sbnM6 eGFwPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJyB4YXA6TW9kaWZ5RGF0ZT0nMjAwOC0w OS0xMicgeGFwOkNyZWF0ZURhdGU9JzIwMDgtMDktMTInPjx4YXA6Q3JlYXRvclRvb2w+R1BMIEdo b3N0c2NyaXB0IDguNTQgUERGIFdyaXRlcjwveGFwOkNyZWF0b3JUb29sPjwvcmRmOkRlc2NyaXB0 aW9uPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0nOTUwM2YzOTAtODMwNy0xMWRkLTAwMDAt NWU5ZjU3YjY1YjdmJyB4bWxuczp4YXBNTT0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21t LycgeGFwTU06RG9jdW1lbnRJRD0nOTUwM2YzOTAtODMwNy0xMWRkLTAwMDAtNWU5ZjU3YjY1Yjdm Jy8+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSc5NTAzZjM5MC04MzA3LTExZGQtMDAwMC01 ZTlmNTdiNjViN2YnIHhtbG5zOmRjPSdodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLycg ZGM6Zm9ybWF0PSdhcHBsaWNhdGlvbi9wZGYnPjxkYzp0aXRsZT48cmRmOkFsdD48cmRmOmxpIHht bDpsYW5nPSd4LWRlZmF1bHQnPlwzNzZcMzc3XDAwMGRcMDAwclwwMDBhXDAwMGZcMDAwdFwwMDAt XDAwMGlcMDAwZVwwMDB0XDAwMGZcMDAwLVwwMDByXDAwMG9cMDAwbFwwMDBsXDAwMC1cMDAwaFww MDBvXDAwMG1cMDAwZVwwMDAtXDAwMHJcMDAwb1wwMDB1XDAwMHRcMDAwaVwwMDBuXDAwMGdcMDAw LVwwMDByXDAwMGVcMDAwcVwwMDBzXDAwMF9cMDAwZFwwMDBlXDAwMGxcMDAwdFwwMDBhXDAwMF9c MDAwMFwwMDAyXDAwMF9cMDAwdFwwMDBvXDAwMF9cMDAwMFwwMDAzPC9yZGY6bGk+PC9yZGY6QWx0 PjwvZGM6dGl0bGU+PGRjOmNyZWF0b3I+PHJkZjpTZXE+PHJkZjpsaT5cMzc2XDM3N1wwMDBhXDAw MGJcMDAwcjwvcmRmOmxpPjwvcmRmOlNlcT48L2RjOmNyZWF0b3I+PC9yZGY6RGVzY3JpcHRpb24+ CjwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK PD94cGFja2V0IGVuZD0ndyc/PgplbmRzdHJlYW0KZW5kb2JqCjIgMCBvYmoKPDwvUHJvZHVjZXIo R1BMIEdob3N0c2NyaXB0IDguNTQpCi9DcmVhdGlvbkRhdGUoRDoyMDA4MDkxMjExMjA0MyswMicw MCcpCi9Nb2REYXRlKEQ6MjAwODA5MTIxMTIwNDMpCi9UaXRsZShcMzc2XDM3N1wwMDBkXDAwMHJc MDAwYVwwMDBmXDAwMHRcMDAwLVwwMDBpXDAwMGVcMDAwdFwwMDBmXDAwMC1cMDAwclwwMDBvXDAw MGxcMDAwbFwwMDAtXDAwMGhcMDAwb1wwMDBtXDAwMGVcMDAwLVwwMDByXDAwMG9cMDAwdVwwMDB0 XDAwMGlcMDAwblwwMDBnXDAwMC1cMDAwclwwMDBlXDAwMHFcMDAwc1wwMDBfXDAwMGRcMDAwZVww MDBsXDAwMHRcMDAwYVwwMDBfXDAwMDBcMDAwMlwwMDBfXDAwMHRcMDAwb1wwMDBfXDAwMDBcMDAw MykKL0NyZWF0b3IoXDM3NlwzNzdcMDAwUFwwMDBEXDAwMEZcMDAwQ1wwMDByXDAwMGVcMDAwYVww MDB0XDAwMG9cMDAwclwwMDAgXDAwMFZcMDAwZVwwMDByXDAwMHNcMDAwaVwwMDBvXDAwMG5cMDAw IFwwMDAwXDAwMC5cMDAwOVwwMDAuXDAwMDMpCi9BdXRob3IoXDM3NlwzNzdcMDAwYVwwMDBiXDAw MHIpCi9LZXl3b3JkcygpCi9TdWJqZWN0KCk+PmVuZG9iagp4cmVmCjAgMTI1CjAwMDAwMDAwMDAg NjU1MzUgZiAKMDAwMDE1NDcyMSAwMDAwMCBuIAowMDAwMTg3MDU0IDAwMDAwIG4gCjAwMDAxNTQ0 NzMgMDAwMDAgbiAKMDAwMDE1MDU5MCAwMDAwMCBuIAowMDAwMDAwMDE1IDAwMDAwIG4gCjAwMDAw MDUzNjkgMDAwMDAgbiAKMDAwMDE1NjA0OCAwMDAwMCBuIAowMDAwMTU2MjcyIDAwMDAwIG4gCjAw MDAxNTc4MDkgMDAwMDAgbiAKMDAwMDE1Njc3MiAwMDAwMCBuIAowMDAwMTY2Mjk5IDAwMDAwIG4g CjAwMDAxNTQ3ODcgMDAwMDAgbiAKMDAwMDE1MDczMiAwMDAwMCBuIAowMDAwMDA1Mzg5IDAwMDAw IG4gCjAwMDAwMDg1NDggMDAwMDAgbiAKMDAwMDE1NDgzNyAwMDAwMCBuIAowMDAwMTUwODg0IDAw MDAwIG4gCjAwMDAwMDg1NjkgMDAwMDAgbiAKMDAwMDAyODcwNiAwMDAwMCBuIAowMDAwMTU2MjA1 IDAwMDAwIG4gCjAwMDAxNTQ4ODcgMDAwMDAgbiAKMDAwMDE1MTAyOCAwMDAwMCBuIAowMDAwMDI4 NzI4IDAwMDAwIG4gCjAwMDAwMzQ1MzUgMDAwMDAgbiAKMDAwMDE1NDk0OCAwMDAwMCBuIAowMDAw MTUxMTgwIDAwMDAwIG4gCjAwMDAwMzQ1NTYgMDAwMDAgbiAKMDAwMDA0MzcyNyAwMDAwMCBuIAow MDAwMTU0OTk4IDAwMDAwIG4gCjAwMDAxNTEzMzIgMDAwMDAgbiAKMDAwMDA0Mzc0OCAwMDAwMCBu IAowMDAwMDUzMDIwIDAwMDAwIG4gCjAwMDAxNTUwNDggMDAwMDAgbiAKMDAwMDE1MTQ4NCAwMDAw MCBuIAowMDAwMDUzMDQxIDAwMDAwIG4gCjAwMDAwNjE2NTIgMDAwMDAgbiAKMDAwMDE1NTA5OCAw MDAwMCBuIAowMDAwMTUxNjM2IDAwMDAwIG4gCjAwMDAwNjE2NzMgMDAwMDAgbiAKMDAwMDA3MDg2 OSAwMDAwMCBuIAowMDAwMTU1MTQ4IDAwMDAwIG4gCjAwMDAxNTE3ODggMDAwMDAgbiAKMDAwMDA3 MDg5MCAwMDAwMCBuIAowMDAwMDc4NjcyIDAwMDAwIG4gCjAwMDAxNTczNDEgMDAwMDAgbiAKMDAw MDE1NTE5OCAwMDAwMCBuIAowMDAwMTUxOTQwIDAwMDAwIG4gCjAwMDAwNzg2OTMgMDAwMDAgbiAK MDAwMDA4NTg3OSAwMDAwMCBuIAowMDAwMTU1MjU5IDAwMDAwIG4gCjAwMDAxNTIwOTIgMDAwMDAg biAKMDAwMDA4NTkwMCAwMDAwMCBuIAowMDAwMDk0MjM5IDAwMDAwIG4gCjAwMDAxNTUzMDkgMDAw MDAgbiAKMDAwMDE1MjI0NCAwMDAwMCBuIAowMDAwMDk0MjYwIDAwMDAwIG4gCjAwMDAxMDIwODMg MDAwMDAgbiAKMDAwMDE1NTM1OSAwMDAwMCBuIAowMDAwMTUyMzk2IDAwMDAwIG4gCjAwMDAxMDIx MDQgMDAwMDAgbiAKMDAwMDEwOTY3OSAwMDAwMCBuIAowMDAwMTU1NDA5IDAwMDAwIG4gCjAwMDAx NTI1NDggMDAwMDAgbiAKMDAwMDEwOTcwMCAwMDAwMCBuIAowMDAwMTE3MDcyIDAwMDAwIG4gCjAw MDAxNTU0NTkgMDAwMDAgbiAKMDAwMDE1MjcwMCAwMDAwMCBuIAowMDAwMTE3MDkzIDAwMDAwIG4g CjAwMDAxMjQ5MTkgMDAwMDAgbiAKMDAwMDE1NTUwOSAwMDAwMCBuIAowMDAwMTUyODUyIDAwMDAw IG4gCjAwMDAxMjQ5NDAgMDAwMDAgbiAKMDAwMDEyOTA5NyAwMDAwMCBuIAowMDAwMTU3NDA2IDAw MDAwIG4gCjAwMDAxNzg1NDcgMDAwMDAgbiAKMDAwMDE1NTU3MCAwMDAwMCBuIAowMDAwMTUzMDA0 IDAwMDAwIG4gCjAwMDAxMjkxMTggMDAwMDAgbiAKMDAwMDEzMzkyMyAwMDAwMCBuIAowMDAwMTU1 NjMxIDAwMDAwIG4gCjAwMDAxNTMxNTYgMDAwMDAgbiAKMDAwMDEzMzk0NCAwMDAwMCBuIAowMDAw MTM4MDM2IDAwMDAwIG4gCjAwMDAxNTU2ODEgMDAwMDAgbiAKMDAwMDE1MzMwOCAwMDAwMCBuIAow MDAwMTM4MDU3IDAwMDAwIG4gCjAwMDAxMzkzODMgMDAwMDAgbiAKMDAwMDE1NTczMSAwMDAwMCBu IAowMDAwMTUzNDUyIDAwMDAwIG4gCjAwMDAxMzk0MDQgMDAwMDAgbiAKMDAwMDE0MDg5OCAwMDAw MCBuIAowMDAwMTU1NzcwIDAwMDAwIG4gCjAwMDAxNTM1OTYgMDAwMDAgbiAKMDAwMDE0MDkxOSAw MDAwMCBuIAowMDAwMTQyMjgyIDAwMDAwIG4gCjAwMDAxNTU4MDkgMDAwMDAgbiAKMDAwMDE1Mzc0 MCAwMDAwMCBuIAowMDAwMTQyMzAzIDAwMDAwIG4gCjAwMDAxNDM2NzcgMDAwMDAgbiAKMDAwMDE1 NTg0OCAwMDAwMCBuIAowMDAwMTUzODg1IDAwMDAwIG4gCjAwMDAxNDM2OTggMDAwMDAgbiAKMDAw MDE0NTAxOCAwMDAwMCBuIAowMDAwMTU1ODg4IDAwMDAwIG4gCjAwMDAxNTQwMzIgMDAwMDAgbiAK MDAwMDE0NTA0MCAwMDAwMCBuIAowMDAwMTQ2NDgxIDAwMDAwIG4gCjAwMDAxNTU5MjggMDAwMDAg biAKMDAwMDE1NDE3OSAwMDAwMCBuIAowMDAwMTQ2NTAzIDAwMDAwIG4gCjAwMDAxNDg2NzIgMDAw MDAgbiAKMDAwMDE1NTk2OCAwMDAwMCBuIAowMDAwMTU0MzI2IDAwMDAwIG4gCjAwMDAxNDg2OTQg MDAwMDAgbiAKMDAwMDE1MDU2OCAwMDAwMCBuIAowMDAwMTU2MDA4IDAwMDAwIG4gCjAwMDAxNTgw MTAgMDAwMDAgbiAKMDAwMDE2NjUwMiAwMDAwMCBuIAowMDAwMTc4NzUwIDAwMDAwIG4gCjAwMDAx NTYxMjcgMDAwMDAgbiAKMDAwMDE1NjU1NSAwMDAwMCBuIAowMDAwMTU3MDk3IDAwMDAwIG4gCjAw MDAxNTc2NTYgMDAwMDAgbiAKMDAwMDE4NTQwOSAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDEy NSAvUm9vdCAxIDAgUiAvSW5mbyAyIDAgUgovSUQgWzwxM0UzN0Y4OUNFOEQ5NjU4Q0MzQUEwRjg0 NzhBMkQzMz48MTNFMzdGODlDRThEOTY1OENDM0FBMEY4NDc4QTJEMzM+XQo+PgpzdGFydHhyZWYK MTg3NjIyCiUlRU9GCg== ------_=_NextPart_001_01C914BB.415C7F08 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------_=_NextPart_001_01C914BB.415C7F08-- From roll-bounces@ietf.org Fri Sep 12 03:49:23 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 967613A6C1F; Fri, 12 Sep 2008 03:49:23 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CABF93A6C20 for ; Fri, 12 Sep 2008 03:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.348 X-Spam-Level: X-Spam-Status: No, score=-5.348 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUXI94pGindt for ; Fri, 12 Sep 2008 03:49:20 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0EE393A6BFC for ; Fri, 12 Sep 2008 03:49:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,389,1217808000"; d="scan'208,217";a="20630712" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 12 Sep 2008 10:49:17 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8CAnHHQ025993 for ; Fri, 12 Sep 2008 06:49:17 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8CAnHwJ029358 for ; Fri, 12 Sep 2008 10:49:17 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Sep 2008 06:49:17 -0400 Received: from 10.61.97.226 ([10.61.97.226]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Sep 2008 10:49:17 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Fri, 12 Sep 2008 12:49:16 +0200 From: JP Vasseur To: Message-ID: Thread-Topic: ROLL WG Minutes IETF 72 Dublin Thread-Index: AckUxTNii196rMigaUy5214S58YTXw== Mime-version: 1.0 X-OriginalArrivalTime: 12 Sep 2008 10:49:17.0205 (UTC) FILETIME=[341ABC50:01C914C5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1163; t=1221216557; x=1222080557; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20ROLL=20WG=20Minutes=20IETF=2072=20Dublin |Sender:=20 |To:=20; bh=cjSG9396TvjFJn+wOex6g170bR1ne+Hh8aEfq1ygmD4=; b=Qrw23VK57rHSnOQJBVdadQ2mp1kVLtP9OnIQXYTs1/t2acIRzOBHTgxdjm JLuBpyG4P/rV54l16NbNIC1VPtHVekTQAJWJMXg7JSKDo3dEH/LDh83Sr9su D2Di1h0+rO; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Roll] ROLL WG Minutes IETF 72 Dublin X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1590218215==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1590218215== Content-type: multipart/alternative; boundary="B_3304068556_39445993" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3304068556_39445993 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear WG, The minutes of the ROLL Working Group meeting IETF-72 have been posted. Please let me know by September 19 if you have any comment: http://www.ietf.org/proceedings/08jul/minutes/roll.txt Thanks to Jakob and Pascal for the minutes. JP. --B_3304068556_39445993 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable ROLL WG Minutes IETF 72 Dublin Dear WG,

The minutes of the ROLL Working Group meeting IETF-72 have been posted. Ple= ase let me know by September 19 if you have any comment: http://www.ietf.org/proceeding= s/08jul/minutes/roll.txt

Thanks to Jakob and Pascal for the minutes.

JP. --B_3304068556_39445993-- --===============1590218215== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1590218215==-- From roll-bounces@ietf.org Fri Sep 12 04:02:13 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E31B3A6BFF; Fri, 12 Sep 2008 04:02:13 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22BD83A6BFF for ; Fri, 12 Sep 2008 04:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVvNSRpJRt-1 for ; Fri, 12 Sep 2008 04:02:06 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 8865F3A6ABC for ; Fri, 12 Sep 2008 04:02:06 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Sep 2008 13:02:13 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3EB68DF7@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3EB68DF5@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-03.txt (2) Thread-Index: AckUMiDrdXqJlL/LC0yvf3BrmcP73AAhY8gAAANrTyA= References: <20080911124501.4AA473A67C0@core3.amsl.com> <6D9687E95918C04A8B30A7D6DA805A3EB68DF5@zensys17.zensys.local> From: "Anders Brandt" To: "JP Vasseur" , Cc: Porcu Giorgio Subject: Re: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-03.txt (2) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi JP - again Oops Just realized you asked for a summary; not all changes! Primary changes from v.02 to 03: * Update to common terminology of sensors and actuators * Energy conservation section simplified (mainly editorial) * New table: Mapping use cases to requirements * Groupcast section, emphasis: Requirement for L2 interface * New requirement sections: - Sleeping nodes - Healthcare routing * Security considerations section significantly reduced to reflect only requirements really relating to routing. * Added references to other application requirements drafts (to be updated when drafts become RFC's or time out) As mentioned earlier, V.03 has no additional input from TelecomItalia. All blame should be put on Jakob and me. Cheers, Anders _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Sep 12 05:05:00 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AE6228C0DD; Fri, 12 Sep 2008 05:05:00 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F5BB3A688A for ; Fri, 12 Sep 2008 05:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.929 X-Spam-Level: X-Spam-Status: No, score=-5.929 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDWxSGt7ukgZ for ; Fri, 12 Sep 2008 05:04:54 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5402F3A6835 for ; Fri, 12 Sep 2008 05:04:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,389,1217808000"; d="scan'208";a="20602996" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 12 Sep 2008 12:04:57 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8CC4vgF013093; Fri, 12 Sep 2008 08:04:57 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8CC4vjc015105; Fri, 12 Sep 2008 12:04:57 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Sep 2008 08:04:57 -0400 Received: from 10.61.97.226 ([10.61.97.226]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Sep 2008 12:04:57 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Fri, 12 Sep 2008 14:04:56 +0200 From: JP Vasseur To: Anders Brandt , Message-ID: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-03.txt Thread-Index: AckUMiDrdXqJlL/LC0yvf3BrmcP73AAhY8gAAAYFWT4= In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3EB68DF5@zensys17.zensys.local> Mime-version: 1.0 X-OriginalArrivalTime: 12 Sep 2008 12:04:57.0493 (UTC) FILETIME=[C653B450:01C914CF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4651; t=1221221097; x=1222085097; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20I-D=20Action=3Adraft-ietf-roll -home-routing-reqs-03.txt |Sender:=20 |To:=20Anders=20Brandt=20,=20; bh=pUPEOKbMSJ+rpDUChSJ1NdjlOJv+EZlgKJk43DGc+4o=; b=XjuT2SqYisnRghxyio8SAJcdbG7JVWjvwyV4+DFjQXuKfQ2mvoFoYbZ04s gEhk1yNkx8w+ZRasTyxV2MmI9J9Dtf1SdEaXqZJY/9x85aABc9uGiQPM0dVB ITYa3zKrWL; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Porcu Giorgio Subject: Re: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, Thanks for the new revision. Two main comments 1) with regards to your question: " Author's note: | | The support of groupcast only has implication on the | | addressing scheme and as such, it is outside the scope | | of this document that focuses on routing requirements. | | Nevertheless, it is an important parameter for the | | definition of the ROLL layer interface towards various | | layer two technologies for home control. | | | | Should a dedicated application-specific document be | | created for such details? | +----------------------------------------------------------+ " Start with a email thread on the ML. 2) Open issues Other items to be addressed in further revisions of this document include: o Load Balancing (Symmetrical and Asymmetrical) o Groupcast definition in a separate document? (TBD) o Use case: Home Control Installer Scenario o Security Question/suggestion: Dou you think that you could quckly address the first 3 bullets ? With regards to security, I would suggest you to start a separate thread on the ML. In the next revision you should be able to point to the terminology draft, at which point we should be able for LC. Thanks. JP. On 9/12/08 11:38 AM, "Anders Brandt" wrote: > Hi JP > >> Thanks ! Could send an email summarizing the changes, and tell us if > you addressed the comments that I sent you ? > Sure. Delta spec is attached showing all changes from v.02 to v.03 > > We have tried to incorporate most of your comments and suggestions as > well. > The same goes for the comments posted to the list by Zach Shelby and > some few others we received directly. > > To all of you: Thanks for taking the time to review this doc. It is > beginning to look right. > > V.03 has no additional input from TelecomItalia. All blame should be put > on Jakob and me. > > Cheers, > Anders > > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: 11. september 2008 19:16 > To: Anders Brandt; Porcu Giorgio > Subject: FW: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-03.txt > > Thanks ! Could send an email summarizing the changes, and tell us if you > addressed the comments that I sent you ? > > Thanks. > > JP. > > ------ Forwarded Message > From: > Date: Thu, 11 Sep 2008 05:45:01 -0700 (PDT) > To: > Cc: > Subject: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-03.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > > Title : Home Automation Routing Requirement in Low Power and > Lossy Networks > Author(s) : A. Brandt, et al. > Filename : draft-ietf-roll-home-routing-reqs-03.txt > Pages : 18 > Date : 2008-09-11 > > This document presents home control and automation application specific > requirements for Routing Over Low power and Lossy networks (ROLL). In a > modern home, a high number of wireless devices are used for a wide set > of purposes. Examples include actuators (relay, light dimmer, heating > valve), sensors (wall switch, water leak, blood pressure) and advanced > controllers. > Because such devices only cover a limited radio range, routing is > > > often required. The aim of this document is to specify the routing > requirements for networks comprising such constrained devices in a home > control and automation environment. > > > > Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" > in this document are to be interpreted as described in RFC-2119 > [RFC2119]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-03 > .txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > ------ End of Forwarded Message > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Sat Sep 13 00:42:31 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48CEB3A697D; Sat, 13 Sep 2008 00:42:31 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1FB3A697D for ; Sat, 13 Sep 2008 00:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.973 X-Spam-Level: X-Spam-Status: No, score=-5.973 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqDEknT3G5yh for ; Sat, 13 Sep 2008 00:42:29 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 007703A6969 for ; Sat, 13 Sep 2008 00:42:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,393,1217808000"; d="txt'208?scan'208,208";a="20729766" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Sep 2008 07:42:33 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8D7gVVj024499 for ; Sat, 13 Sep 2008 03:42:31 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8D7gVo1006726 for ; Sat, 13 Sep 2008 07:42:31 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Sep 2008 03:42:31 -0400 Received: from 10.61.97.226 ([10.61.97.226]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Sat, 13 Sep 2008 07:40:17 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Sat, 13 Sep 2008 09:40:12 +0200 From: JP Vasseur To: Message-ID: Thread-Topic: I-D Action:draft-vasseur-roll-terminology-01.txt Thread-Index: AckVc/Q/8FG37RERcEiXv8xFElKVsg== In-Reply-To: <20080913073001.4BEE63A697D@core3.amsl.com> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3304143616_43900558" X-OriginalArrivalTime: 13 Sep 2008 07:42:31.0837 (UTC) FILETIME=[479904D0:01C91574] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3035; t=1221291751; x=1222155751; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20FW=3A=20I-D=20Action=3Adraft-vasseur-roll-termi nology-01.txt=20 |Sender:=20 |To:=20; bh=iIz8Q9gK+VOH60FtGDPavywx8UMe96BuVN7+23p5WiI=; b=Y+JDbmkxFUZ3l0vlpjFM03udt3G49HtGOAoH6aLpw02zf+CEEww3ww3uUf 3qEG3FPjqZx8sI/XHTtf7A6QRc1g9PBubUx97hZhCZjiflhmsvcyLCf3UueF kfOaA6l8FO; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Roll] FW: I-D Action:draft-vasseur-roll-terminology-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3304143616_43900558 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, Here is a terminology ID, the idea being to use this document for the terminology in ROLL IDs, and thus avoid terminology inconsistencies. Thanks to review and provide your comments. Then, thanks to the authors of ROLL IDs to make the appropriate changes in their documents referring to this one and only specify the terminology specific to their document. Thanks. JP. ------ Forwarded Message From: Reply-To: Date: Sat, 13 Sep 2008 00:30:01 -0700 (PDT) To: Subject: I-D Action:draft-vasseur-roll-terminology-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Terminology in Low power And Lossy Networks Author(s) : J. Vasseur Filename : draft-vasseur-roll-terminology-01.txt Pages : 8 Date : 2008-09-13 The documents defines a terminology for discussing routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN). A LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (Heating, Ventilating, and Air Conditioning also referred to as HVAC, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking, refrigeration.Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vasseur-roll-terminology-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------ End of Forwarded Message --B_3304143616_43900558 Content-type: application/octet-stream; name="draft-vasseur-roll-terminology-01.txt" Content-disposition: attachment; filename="draft-vasseur-roll-terminology-01.txt" Content-transfer-encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDA4LTA5LTEzMDAxOTA1 LkktREBpZXRmLm9yZz4NDQ== --B_3304143616_43900558 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --B_3304143616_43900558-- From roll-bounces@ietf.org Mon Sep 15 00:09:45 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEEDC3A67E9; Mon, 15 Sep 2008 00:09:45 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92F4A3A68DB for ; Mon, 15 Sep 2008 00:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.853 X-Spam-Level: X-Spam-Status: No, score=-3.853 tagged_above=-999 required=5 tests=[AWL=-1.478, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUVuqXf-X+Tw for ; Mon, 15 Sep 2008 00:09:22 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BBDEE3A685C for ; Mon, 15 Sep 2008 00:09:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,399,1217808000"; d="scan'208,217";a="20851233" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 15 Sep 2008 07:09:32 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8F79Vnv013505; Mon, 15 Sep 2008 03:09:31 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8F79VVm025853; Mon, 15 Sep 2008 07:09:31 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Sep 2008 03:09:31 -0400 Received: from 10.61.81.152 ([10.61.81.152]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 15 Sep 2008 07:09:31 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Mon, 15 Sep 2008 09:09:29 +0200 From: JP Vasseur To: Tom Phinney , , Kris Pister , "Pascal Thubert (pthubert)" , Message-ID: Thread-Topic: Detailed Review of draft-ietf-roll-indus-routing-reqs Thread-Index: AckXAf6PcifHqoXRk0OTvo/2G3Ex8g== In-Reply-To: <48C7EE2F.60204@cox.net> Mime-version: 1.0 X-OriginalArrivalTime: 15 Sep 2008 07:09:31.0723 (UTC) FILETIME=[002F19B0:01C91702] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=43322; t=1221462571; x=1222326571; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20Detailed=20Review=20of=20draft-ietf-rol l-indus-routing-reqs |Sender:=20 |To:=20Tom=20Phinney=20,=20,=0A=20=20=20=20=20=20=20=20Kris=20Pister=20,=0A=20=20=20=20=20=20=20=20=22Pascal=20Thuber t=20(pthubert)=22=20,=0A=20=20=20=20=20= 20=20=20; bh=C+YpEqArnTUsNVbz7I+46V9auAwHI+ftBmMhlALNH7g=; b=aPigZTZpE60Y/IbPGIr95CMjgaXVtuiHN5Ptoug2U61r2gnWNA7rt+rxov +VCMeFUTAxg6r4vJOKSES1p1N9YWfE8aUhwNDjI1SeHC/2V98s6iIeJatBu5 aQR6hnav4A; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Roll] Detailed Review of draft-ietf-roll-indus-routing-reqs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1373361548==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1373361548== Content-type: multipart/alternative; boundary="B_3304314569_54167105" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3304314569_54167105 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Tom, On 9/10/08 5:56 PM, "Tom Phinney" wrote: > Re item 8) below, closing loops in the field > =A0 i) does not prevent the same loop from being closed through a remote > multi-variable controller during some modes of operation, while being clo= sed > directly in the field during other modes of operation (e.g., fallback, or= when > timing is more critical) > =A0 ii) does not imply that the loop will be closed with a wired connection= , or > that the wired connection is more energy efficient even when it exists as= an > alternate to the wireless connection. >=20 > A realistic future scenario is for a field device with a battery or > ultra-capacitor power storage to have both wireless and unpowered wired > communications capability (e.g., galvanically isolated RS-485), where the > wireless communication is more flexible and, for local loop operation, mo= re > energy efficient, and the wired communication capability serves as a back= up > interconnect among the loop elements, but without a wired connection back= to > the operations center blockhouse.=A0 In other words, the loop elements are > interconnected through wiring to a nearby junction box, but the 2 km home= -run > link from the junction box to the control center does not exist. >=20 > When wireless communication conditions are good, devices use wireless for= loop > interconnect, and either one wireless device reports alarms and other sta= tus > to the control center for all elements of the loop or each element report= s > independently.=A0 When wireless communications are sporadic, the loop > interconnect uses the self-powered galvanically-isolated RS-485 link and = one > of the devices with good wireless communications to the control center se= rves > as a router for those devices which are unable to contact the control cen= ter > directly. >=20 > The above approach is particularly attractive for large storage tanks in = tank > farms, where devices may not all have good wireless visibility of the con= trol > center, and where a home run cable from the tank to the control center is > undesirable due to the electro-potential differences between the tank loc= ation > and the distant control center that arise during lightning storms.. >=20 > JP> Really interesting scenario. Feel free to add it to the document, it = is > definitely worth it. >=20 > Cheers, >=20 > JP. >=20 > -Tom > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > JP Vasseur wrote: >> Detailed Review of draft-ietf-roll-indus-routing-reqs Hi, >> =20 >> After the review of draft-ietf-roll-urban-routing-reqs and >> draft-ietf-roll-home-routing-reqs (new revision coming soon according to >> their authors), here is my review of draft-ietf-roll-indus-routing-reqs = (lots >> of excellent content). >> =20 >> 1) Abstract and Section 2 >> =A0=A0=A0=A0=A0=A0For wireless devices to have a significant >> =A0=A0=A0advantage over wired devices in an industrial environment the >> =A0=A0=A0wireless network needs to have three qualities: low power, high >> =A0=A0=A0reliability, and easy installation and maintenance. >> =20 >> JP> I would propose not to =B3oppose=B2 wireless and wired devices. Indeed, >> sensor networks will more than likely be interconnected by a variety of >> links. Still those networks will be LLN and will require these three >> qualities. I would then suggest to keep the list of qualities but genera= lize >> it to devices in LLN. >> =20 >> =20 >> 2) s/L2N/LLN in the entire document (to match the ROLL charter). >> I still owe the WG a terminology ID (will be done early next week). >> =20 >> 3) I skip the terminology section since it will addressed in the termino= logy >> ID.=20 >> =20 >> 4) Introduction >> =20 >> Referring to: >> =B3Wireless field devices enable expansion of networked points by >> =A0=A0=A0appreciably reducing cost of installing a device. =A0The cost >> =A0=A0=A0reductions come from eliminating cabling costs and simplified >> =A0=A0=A0planning. =A0Cabling also carries an overhead cost associated with >> =A0=A0=A0planning the installation, determining where the cable has to run, >> =A0=A0=A0and interfacing with the various organizations required to coordinate >> =A0=A0=A0its deployment. =A0Doing away with the network and power cables reduces >> =A0=A0=A0the planning and administrative overhead of installing a device.=B2 >> =20 >> JP> This is a bit arguable ... (look at PLC) and not really a technical >> consideration. I would suggest to simply remove this paragraph. >> =20 >> 5) Section 2 >> =20 >> * =B3wired HART=B2 please add a informative reference. >> =20 >> 6) s/=B2In the near future, most low power and lossy network systems will= be >> =A0=A0=A0for low frequency data collection.=B2/=B2In the near future, most low pow= er >> and lossy network systems in industrial automation environments will be >> =A0=A0=A0for low frequency data collection.=B2 >> =20 >> 7) In several places, you make the assumption that the collected data is= sent >> to a Sink/... Residing outside of the LLN. Don=B9t you see cases where the= re >> will be intra-LLN flows in Industrial automation ? >> And I just read: =B3 =A0In the future, it is envisioned that some open loop >> processes will be >> =A0=A0=A0automated (closed loop) and packets will flow over local loops and >> =A0=A0=A0not involve the L2N access point. =B3 - Thanks. >> =20 >> 8) you wrote: =B3More likely though is that loops will be closed in the fi= eld >> =A0=A0=A0entirely, which in most cases eliminates the need for having wireless >> =A0=A0=A0links within the control loop.=B2 >> Why does this eliminate the need for wireless links ? >> =20 >> 9) =B3L2N-ish=B2 ... You may want to slighlty reword here ;-) >> =20 >> 10) s/=B2maximum number of hops from two to twenty.=B2/=B2maximum number of ho= ps of >> twenty=B2 >> =20 >> 11) Section 2.2 >> =20 >> You wrote: =B3 The backbone is a high-speed infrastructure network that ma= y >> =A0=A0=A0interconnect multiple WSNs through backbone routers. =A0Infrastructure >> =A0=A0=A0devices can be connected to the backbone. =A0A gateway / manager that >> =A0=A0=A0interconnects the backbone to the plant network of the corporate >> =A0=A0=A0network can be viewed as collapsing the backbone and the >> =A0=A0=A0infrastructure devices into a single device that operates all the >> =A0=A0=A0required logical roles. =A0The backbone is likely to become an >> =A0=A0=A0important function of the industrial network.=B2 >> =20 >> Although I do agree that this is a common architecture, you may want to >> indicate that this is only one possible architecture. >> =20 >> 12) Could you please use a coherent terminology throughout the document = ? L2N >> sensor, field devices, ... I=B9ll try to write the terminology ID this wee= k, >> then thanks to align the terminology. >> =20 >> 13) I found this section is bit out of the scope: >> =20 >> =B3This multiple domain multiple applications connectivity creates a >> =A0=A0=A0significant challenge. =A0Many different applications will all share >> =A0=A0=A0the same medium, the ether, within the fence, preferably sharing the >> =A0=A0=A0same frequency bands, and preferably sharing the same protocols, >> =A0=A0=A0preferably synchronized to optimize co-existence challenges, yet >> =A0=A0=A0logically segregated to avoid creation of intolerable short cuts >> =A0=A0=A0between existing wired domains. >> =20 >> =A0=A0=A0Given this challenge, L2N networks are best to be treated as all >> =A0=A0=A0sitting on yet another segregated domain, segregated from all other >> =A0=A0=A0wired domains where conventional security is organized by perimeter. >> =A0=A0=A0Moving away from the traditional perimeter security mindset means >> =A0=A0=A0moving towards stronger end-device identity authentication, so that >> =A0=A0=A0L2N access points can split the various wireless data streams and >> =A0=A0=A0interconnect back to the appropriate domain pending identity and >> =A0=A0=A0trust established by the gateways in the authenticity of message >> =A0=A0=A0originators.=B2 >> =20 >> 14) Question about Figure 1: it looks like we still do have to compute r= outes >> within the LLN ? >> Furthermore, thanks to mention that this is one of many potential >> architectures. For example, in section 2.2.2 you wrote =B32.2.2. =A0Logical >> Topologies >> =20 >> =A0=A0=A0Most of the traffic over the LLN is publish/subscribe of sensor data >> =A0=A0=A0from the field device towards the backbone router or gateway that >> =A0=A0=A0acts as the sink for the WSN.=B2 >> =20 >> You may want to replace the backbone router/gateway by a sink to make th= e >> statement more general and applicable to other topologies (without a gat= eway, >> ...). The use of gateway is a bit dangerous here unless carefully define= d but >> we=B9ll discuss terminology in a separate email. >> =20 >> 15) Section 2.2.2: =B3Since publishing the data is the raison d'etre for m= ost >> of the >> =A0=A0=A0sensors, it makes sense to build proactively a set of default routes >> =A0=A0=A0between the sensors and one or more backbone router and maintain >> =A0=A0=A0those routes at all times. =A0Also, because of the lossy nature of the >> =A0=A0=A0network, the routing in place should attempt to propose multiple >> =A0=A0=A0forwarding solutions, building forwarding topologies in the form of >> =A0=A0=A0Directed Acyclic Graphs oriented towards the sinks.=B2 >> =20 >> Is it a requirement to be able to configure =B3default routes?=B2 >> By =B3multiple forwarding solutions=B2 do you actually means =B3multiple paths= =B2 ? >> =20 >> 16) Comment on =B3For these reasons, the ROLL routing infrastructure MUST = be >> able to >> =A0=A0=A0compute and update constrained routes on demand (that is reactively), >> =A0=A0=A0and it can be expected that this model will become more prevalent for >> =A0=A0=A0field device to field device connectivity as well as for some field >> =A0=A0=A0device to Infrastructure devices over time.=B2 >> =20 >> =20 >> * you may want to move the MUST in the routing requirement sections, to = have >> them all in one place. >> * Are you requiring a reactive mechanism >> * =20 >> =20 >> 17) Section 3. >> * =B3Service Requirement=B2 - You may want to change the title for =B3Traffic >> Characteristics=B2 just to avoid confusion with upper layer requirements. >> excellent paragraph >> * I=B9m not sure to see the rationale of the various bullets =B3data bandwi= dth=B2, >> =B3Latency=B2, ... In this context of routing requirements. >> * You wrote =B3The routing protocol >> =A0=A0=A0MUST be able to set up unidirectional or asymmetrical cost routes >> =A0=A0=A0that are composed of one or more non congruent paths.=B2 >> You may want to reword this sentence, which may be misleading (in partic= ular, >> there is no =B3or=B2 routes can be unidirectional and asymmetrical=B2). Did yo= u >> mean =B3The routing protocol MUST be able to compute a set of unidirection= al >> routes with potentially different costs=B2. >> =20 >> 18) Section 3.1 >> =20 >> * S/ Time-varying user requirements for latency and bandwidth will requi= re >> =A0=A0=A0changes in the provisioning of the underlying L2 protocols/ Time-vary= ing >> user requirements for latency and bandwidth may require >> =A0=A0=A0changes in the provisioning of the underlying L2 protocols. >> =20 >> * =A0=B3The routing protocol MUST route on paths that are changed to >> =A0=A0=A0appropriately provision the application requirements.=B2 =A0 >> =20 >> JP> This should translate into =B3The routing protocol MUST dynamically >> recompute path if the underlying topology changes. >> =20 >> =A0=A0=A0=B3The routing >> =A0=A0=A0protocol MUST support the ability to recompute paths based on >> =A0=A0=A0underlying link characteristics that may change dynamically.=B2 >> =20 >> JP> Could you be more accurate ? =B3What if the BER crosses some threshold= ?=B2. >> Should it trigger a path computation ? If so, you would need to list all >> parameters that can trigger a path computation. Alternatively, (IMO the >> prefered option) each of the link characteristic should be reflected in = a >> metric or attribute change that will trigger a path computation (use fil= ters >> of course).=20 >> =20 >> 19) Section 3.2. >> S/=B2The routing algorithm MUST be able to >> =A0=A0=A0generate different routes for different flows.=B2/=B2The routing algorith= m >> MUST be able to >> =A0=A0=A0generate different routes with different characteritics (e.g. Optimiz= ed >> according to different cost, ...).=B2 >> =20 >> 20) Replace globally =B3low power lossy network=B2 by =B3LLN=B2. >> =20 >> 21) Replace globally =B3#=B2 by =B3number=B2. >> =20 >> 22) s/=B2 3) =A0Probability of failure on demand,=B2/=B2 3) =A0Probability of fail= ure >> to compute an on demand route=B2 >> =20 >> 23) In the list of =B3Reliability Requirements=B2 you may want to add a =B3...= =B2 >> since there are many other ones (ability to reroute upon a network failu= re, >> ...). >> =20 >> 24) =B3Hop-by-hop path diversity is used to improve latency-bounded >> =A0=A0=A0reliability.=B2 >> =20 >> JP> Path diversity does not help with latency-bounded reliability ... It= does >> help to increase packet delivery if you use a 1+1 technique, or to find = an >> alternate path or limit the proportion of flows impacted by a single fai= lure >> but not for latency. What did you mean ? >> =20 >> 25) =B3The routing protocol MUST support multiple L2N access >> =A0=A0=A0points and load distribution among L2N access points. =A0 >> JP> In order to make this requirement not =B3topology dependent=B2 could you >> reword it =B3The routing protocol MUST be able to compute paths towards >> different destination so as to perform load balancing across a variety o= f >> paths.=B2 >> =20 >> 26) =B3The routing >> =A0=A0=A0protocol MUST support multiple L2N access points when L2N access >> =A0=A0=A0point redundancy is required.=B2 >> =20 >> This is not a routing protocol requirement. >> =20 >> 27) =B3Because L2Ns are lossy in nature, >> =A0=A0=A0multiple paths in a L2N route MUST be supported. =B3 --> already stated= . >> =20 >> 28) Section 6: >> =20 >> =B32) =A0Delivery of common packets to multiple routers over a backbone, >> =A0=A0=A0=A0=A0=A0=A0where the packets results in each receiving router initiating >> =A0=A0=A0=A0=A0=A0=A0multicast (sometimes as a full broadcast) within the LLN. =A0This >> =A0=A0=A0=A0=A0=A0=A0is byproduct of having potentially physically separated backbone >> =A0=A0=A0=A0=A0=A0=A0routers that can inject messages into different portions of the >> =A0=A0=A0=A0=A0=A0=A0same larger LLN.=B2 >> =20 >> JP> IMO a too solution-specific statement. >> =20 >> 29) Section 7 >> * =B3The routing algorithm SHOULD always be in the process of >> =A0=A0=A0optimizing the system in response to changing link statistics.=B2 >> JP> The term =B3optimizing=B2 is worth a few words of explanation. Optimizin= g >> with regards to which objective ? >> =20 >> * =B3The >> =A0=A0=A0routing algorithm MUST re-optimize the paths when field devices >> =A0=A0=A0change due to insertion, removal or failure, and this re-optimization >> =A0=A0=A0MUST not cause latencies greater than the specified constraints >> =A0=A0=A0(typically seconds to minutes).=B2 >> Few comments here: (1) The first =B3MUST=B2 is not different than the basic >> requirement of being able to compute new path upon topology changes. (2)= I >> would propose to carefully use the term =B3re-optimization=B2. Indeed, I gue= ss >> that you refer to the event where a =B3shorter=B2 path is found according to= some >> metrics. Then you are requiring the ability to switch to a shorter path = while >> bounding the latency, which requires to only switch if the delta between= the >> old and new cost is also bounded and also implies other constraints. Ind= eed, >> in distributed systems, you cannot guarantee that systems are fully >> synchronized. Thus a router may start using a route that is not yet read= y if >> some of the next hops have not converged yet, which may lead to micro-lo= ops. >> Could you elaborate on this requirement ? >> =20 >> 30)=20 >> * =B3The routing protocol SHOULD support the wireless worker with fast >> =A0=A0=A0network connection times of a few of seconds, and low command and >> =A0=A0=A0response latencies to the plant behind the L2N access points, to >> =A0=A0=A0applications, and to field devices. =A0=B3 >> =20 >> Is it a different requirement than the one expressed in Section 7: >> =20 >> =B3The routing algorithm MUST find the appropriate >> =A0=A0=A0route(s) and report success or failure within several minutes, and >> =A0=A0=A0SHOULD report success or failure within tens of seconds.=B2 >> =20 >> =20 >> * =B3The routing protocol SHOULD also >> =A0=A0=A0support the bandwidth allocation for bulk transfers between the field >> =A0=A0=A0device and the handheld device of the wireless worker. =A0=A0=B3 >> =20 >> JP> of course, I see what you mean but this should either be removed or >> reworded. This may simply refer to topology changes, for which you alrea= dy >> have a routing requirement or some cross-layer function (hope not). >> =20 >> =B3The routing >> =A0=A0=A0protocol SHOULD support walking speeds for maintaining network >> =A0=A0=A0connectivity as the handheld device changes position in the wireless >> =A0=A0=A0network. >> =20 >> =A0=A0=A0Some field devices will be mobile. =A0These devices may be located on >> =A0=A0=A0moving parts such as rotating components or they may be located on >> =A0=A0=A0vehicles such as cranes or fork lifts. =A0The routing protocol SHOULD >> =A0=A0=A0support vehicular speeds of up to 35 kmph. >> =B3 >> =20 >> JP> You may just want to say that such requirement has also consequences= on >> non-routing functions. >> =20 >> 31) Section 9 >> =20 >> * =B3Therefore, >> =A0=A0=A0the routing protocol MUST support auto-provisioning of field devices.= =B2 >> =20 >> JP> To which extent ? Does that mean a true 0-configuration routing prot= ocol >> ? >> =20 >> *=B2The protocol also MUST support the distribution of configuration from >> =A0=A0=A0a centralized management controller if operator-initiated >> =A0=A0=A0configuration change is allowed.=B2 >> =20 >> JP> Not a routing requirement. Or do you refer to the dynamic set up of = a >> =B3default DAG/Tree=B2 used to retrieve a more sophisticated =B3routing featur= e=B2 >> from a centralized tool ? >> =20 >> 32) Section 10 >> =20 >> * s/=B21) attacks on the actual application served be the wireless >> =A0=A0=A0devices and =B3/=B21) attacks on the actual application served by the wir= eless >> =A0=A0=A0devices and =B3 >> =20 >> * =B32) attacks that exploit the presence of a wireless access >> =A0=A0=A0point that MAY provide connectivity onto legacy wired plant networks, >> =A0=A0=A0so attacks that have little to do with the wireless devices in the >> =A0=A0=A0L2Ns. =B3/=B22) attacks that exploit the presence of a wireless access >> =A0=A0=A0point that may provide connectivity onto legacy wired plant networks, >> =A0=A0=A0so attacks that have little to do with the wireless devices in the >> =A0=A0=A0LLNs. =B3 >> =20 >> * =B3The routing protocol SHOULD place limited trust in the field devices >> =A0=A0=A0deployed in the plant network. >> =B3 >> =20 >> JP> Could you elaborate a little bit ? It sounds a bit too vague for a >> protocol designer to figure out what action to take according to this >> requirement.=20 >> =20 >> =B3Standards exist that address those >> =A0=A0=A0vulnerabilities.=B2 >> =20 >> JP> ?? >> =20 >> 33) replace =B3isn=B9t by is not=B2, =B3doesn=B9t by does not=B2 , ... >> =20 >> Thanks. >> =20 >> Cheers, >> =20 >> JP.=20 >=20 --B_3304314569_54167105 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: Detailed Review of draft-ietf-roll-indus-routing-reqs Hi Tom,


On 9/10/08 5:56 PM, "Tom Phinney" <tom.phinney@cox.net> wrote:

R= e item 8) below, closing loops in the field
=A0 i) does not prevent the same loop from being closed through a remote mult= i-variable controller during some modes of operation, while being closed dir= ectly in the field during other modes of operation (e.g., fallback, or when = timing is more critical)
=A0 ii) does not imply that the loop will be closed with a wired connection, = or that the wired connection is more energy efficient even when it exists as= an alternate to the wireless connection.

A realistic future scenario is for a field device with a battery or ultra-c= apacitor power storage to have both wireless and unpowered wired communicati= ons capability (e.g., galvanically isolated RS-485), where the wireless comm= unication is more flexible and, for local loop operation, more energy effici= ent, and the wired communication capability serves as a backup interconnect = among the loop elements, but without a wired connection back to the operatio= ns center blockhouse.=A0 In other words, the loop elements are interconnected = through wiring to a nearby junction box, but the 2 km home-run link from the= junction box to the control center does not exist.

When wireless communication conditions are good, devices use wireless for l= oop interconnect, and either one wireless device reports alarms and other st= atus to the control center for all elements of the loop or each element repo= rts independently.=A0 When wireless communications are sporadic, the loop inte= rconnect uses the self-powered galvanically-isolated RS-485 link and one of = the devices with good wireless communications to the control center serves a= s a router for those devices which are unable to contact the control center = directly.

The above approach is particularly attractive for large storage tanks in ta= nk farms, where devices may not all have good wireless visibility of the con= trol center, and where a home run cable from the tank to the control center = is undesirable due to the electro-potential differences between the tank loc= ation and the distant control center that arise during lightning storms..
JP> Really interesting scenario. Feel free to add = it to the document, it is definitely worth it.

Cheers,

JP.

-Tom
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
JP Vasseur wrote:
Detailed Review of draft-ietf-roll-indus-routin= g-reqs Hi,
 
After the review of draft-ietf-roll-urban-routing-reqs and draft-ietf-roll-= home-routing-reqs (new revision coming soon according to their authors), her= e is my review of draft-ietf-roll-indus-routing-reqs (lots of excellent cont= ent).
 
1) Abstract and Section 2
=A0=A0=A0=A0=A0=A0For wireless devices to have a significant
=A0=A0=A0advantage over wired devices in an industrial environment the
=A0=A0=A0wireless network needs to have three qualities: low power, high
=A0=A0=A0reliability, and easy installation and maintenance.
 
JP> I would propose not to “oppose” wireless and wired devic= es. Indeed, sensor networks will more than likely be interconnected by a var= iety of links. Still those networks will be LLN and will require these three= qualities. I would then suggest to keep the list of qualities but generaliz= e it to devices in LLN.
 
 
2) s/L2N/LLN in the entire document (to match the ROLL charter).
I still owe the WG a terminology ID (will be done early next week).
 
3) I skip the terminology section since it will addressed in the terminolog= y ID.
 
4) Introduction
 
Referring to:
“Wireless field devices enable expansion of networked points by
=A0=A0=A0appreciably reducing cost of installing a device. =A0The cost
=A0=A0=A0reductions come from eliminating cabling costs and simplified
=A0=A0=A0planning. =A0Cabling also carries an overhead cost associated with
=A0=A0=A0planning the installation, determining where the cable has to run,
=A0=A0=A0and interfacing with the various organizations required to coordinate =A0=A0=A0its deployment. =A0Doing away with the network and power cables reduces =A0=A0=A0the planning and administrative overhead of installing a device.”<= BR>  
JP> This is a bit arguable ... (look at PLC) and not really a technical = consideration. I would suggest to simply remove this paragraph.
 
5) Section 2
 
* “wired HART” please add a informative reference.
 
 6) s/”In the near future, most low power and lossy network systems will be
=A0=A0=A0for low frequency data collection.”/”In the near future, mos= t low power and lossy network systems in industrial automation environments = will be
=A0=A0=A0for low frequency data collection.”
 
7) In several places, you make the assumption that the collected data is se= nt to a Sink/... Residing outside of the LLN. Don’t you see cases wher= e there will be intra-LLN flows in Industrial automation ?
And I just read: “ =A0In the future, it is envisioned that some open lo= op processes will be
=A0=A0=A0automated (closed loop) and packets will flow over local loops and
=A0=A0=A0not involve the L2N access point. “ - Thanks.
 
8) you wrote: “More likely though is that loops will be closed in the= field
=A0=A0=A0entirely, which in most cases eliminates the need for having wireless =A0=A0=A0links within the control loop.”
Why does this eliminate the need for wireless links ?
 
9) “L2N-ish” ... You may want to slighlty reword here ;-)
 
10) s/”maximum number of hops from two to twenty.”/”maxim= um number of hops of twenty”
 
11) Section 2.2
 
You wrote: “ The backbone is a high-speed infrastructure network that= may
=A0=A0=A0interconnect multiple WSNs through backbone routers. =A0Infrastructure
=A0=A0=A0devices can be connected to the backbone. =A0A gateway / manager that
=A0=A0=A0interconnects the backbone to the plant network of the corporate
=A0=A0=A0network can be viewed as collapsing the backbone and the
=A0=A0=A0infrastructure devices into a single device that operates all the
=A0=A0=A0required logical roles. =A0The backbone is likely to become an
=A0=A0=A0important function of the industrial network.”
 
Although I do agree that this is a common architecture, you may want to ind= icate that this is only one possible architecture.
 
12) Could you please use a coherent terminology throughout the document ? L= 2N sensor, field devices, ... I’ll try to write the terminology ID thi= s week, then thanks to align the terminology.
 
13) I found this section is bit out of the scope:
 
“This multiple domain multiple applications connectivity creates a =A0=A0=A0significant challenge. =A0Many different applications will all share
=A0=A0=A0the same medium, the ether, within the fence, preferably sharing the
=A0=A0=A0same frequency bands, and preferably sharing the same protocols,
=A0=A0=A0preferably synchronized to optimize co-existence challenges, yet
=A0=A0=A0logically segregated to avoid creation of intolerable short cuts
=A0=A0=A0between existing wired domains.
 
=A0=A0=A0Given this challenge, L2N networks are best to be treated as all
=A0=A0=A0sitting on yet another segregated domain, segregated from all other
=A0=A0=A0wired domains where conventional security is organized by perimeter.
=A0=A0=A0Moving away from the traditional perimeter security mindset means
=A0=A0=A0moving towards stronger end-device identity authentication, so that
=A0=A0=A0L2N access points can split the various wireless data streams and
=A0=A0=A0interconnect back to the appropriate domain pending identity and
=A0=A0=A0trust established by the gateways in the authenticity of message
=A0=A0=A0originators.”
 
14) Question about Figure 1: it looks like we still do have to compute rout= es within the LLN ?
Furthermore, thanks to mention that this is one of many potential architect= ures. For example, in section 2.2.2 you wrote “2.2.2. =A0Logical Topolog= ies
 
=A0=A0=A0Most of the traffic over the LLN is publish/subscribe of sensor data
=A0=A0=A0from the field device towards the backbone router or gateway that
=A0=A0=A0acts as the sink for the WSN.”
 
You may want to replace the backbone router/gateway by a sink to make the s= tatement more general and applicable to other topologies (without a gateway,= ...). The use of gateway is a bit dangerous here unless carefully defined b= ut we’ll discuss terminology in a separate email.
 
15) Section 2.2.2: “Since publishing the data is the raison d'etre fo= r most of the
=A0=A0=A0sensors, it makes sense to build proactively a set of default routes
=A0=A0=A0between the sensors and one or more backbone router and maintain
=A0=A0=A0those routes at all times. =A0Also, because of the lossy nature of the
=A0=A0=A0network, the routing in place should attempt to propose multiple
=A0=A0=A0forwarding solutions, building forwarding topologies in the form of
=A0=A0=A0Directed Acyclic Graphs oriented towards the sinks.”
 
Is it a requirement to be able to configure “default routes?” By “multiple forwarding solutions” do you actually means “= ;multiple paths” ?
 
16) Comment on “For these reasons, the ROLL routing infrastructure MU= ST be able to
=A0=A0=A0compute and update constrained routes on demand (that is reactively), =A0=A0=A0and it can be expected that this model will become more prevalent for =A0=A0=A0field device to field device connectivity as well as for some field
=A0=A0=A0device to Infrastructure devices over time.”
 
 =
  • you may want to move the MUST in the routing requir= ement sections, to have them all in one place.=20
  • <= SPAN STYLE=3D'font-size:10pt'>Are you requiring a reactive mechanism=20
  • <= SPAN STYLE=3D'font-size:10pt'>
<= SPAN STYLE=3D'font-size:13pt'>
17) Section 3.
* “Service Requirement” - You may want to change the title for = “Traffic Characteristics” just to avoid confusion with upper lay= er requirements. excellent paragraph
 * I’m not sure to see the rationale of the various bullets = “data bandwidth”, “Latency”, ... In this context of = routing requirements.
* You wrote “The routing protocol
=A0=A0=A0MUST be able to set up unidirectional or asymmetrical cost routes
=A0=A0=A0that are composed of one or more non congruent paths.”
You may want to reword this sentence, which may be misleading (in particula= r, there is no “or” routes can be unidirectional and asymmetrica= l”). Did you mean “The routing protocol MUST be able to compute = a set of unidirectional routes with potentially different costs”.
 
18) Section 3.1
 
* S/ Time-varying user requirements for latency and bandwidth will require<= BR> =A0=A0=A0changes in the provisioning of the underlying L2 protocols/ Time-varying= user requirements for latency and bandwidth may require
=A0=A0=A0changes in the provisioning of the underlying L2 protocols.
 
* =A0“The routing protocol MUST route on paths that are changed to
=A0=A0=A0appropriately provision the application requirements.” =A0
 
JP> This should translate into “The routing protocol MUST dynamica= lly recompute path if the underlying topology changes.
 
=A0=A0=A0“The routing
=A0=A0=A0protocol MUST support the ability to recompute paths based on
=A0=A0=A0underlying link characteristics that may change dynamically.”
 
JP> Could you be more accurate ? “What if the BER crosses some thr= eshold?”. Should it trigger a path computation ? If so, you would need= to list all parameters that can trigger a path computation. Alternatively, = (IMO the prefered option) each of the link characteristic should be reflecte= d in a metric or attribute change that will trigger a path computation (use = filters of course).
 
19) Section 3.2.
S/”The routing algorithm MUST be able to
=A0=A0=A0generate different routes for different flows.”/”The routing= algorithm MUST be able to
=A0=A0=A0generate different routes with different characteritics (e.g. Optimized = according to different cost, ...).”
 
20) Replace globally “low power lossy network” by “LLN= 221;.
 
21) Replace globally “#” by “number”.
 
22) s/” 3) =A0Probability of failure on demand,”/” 3) =A0Prob= ability of failure to compute an on demand route”
 
23) In the list of “Reliability Requirements” you may want to a= dd a “...” since there are many other ones (ability to reroute u= pon a network failure, ...).
 
24) “Hop-by-hop path diversity is used to improve latency-bounded
=A0=A0=A0reliability.”
 
JP> Path diversity does not help with latency-bounded reliability ... It= does help to increase packet delivery if you use a 1+1 technique, or to fin= d an alternate path or limit the proportion of flows impacted by a single fa= ilure but not for latency. What did you mean ?
 
25) “The routing protocol MUST support multiple L2N access
=A0=A0=A0points and load distribution among L2N access points. =A0
JP> In order to make this requirement not “topology dependent̶= 1; could you reword it “The routing protocol MUST be able to compute p= aths towards different destination so as to perform load balancing across a = variety of paths.”
 
26) “The routing
=A0=A0=A0protocol MUST support multiple L2N access points when L2N access
=A0=A0=A0point redundancy is required.”
 
This is not a routing protocol requirement.
 
27) “Because L2Ns are lossy in nature,
=A0=A0=A0multiple paths in a L2N route MUST be supported. “ --> already = stated.
 
28) Section 6:
 
“2) =A0Delivery of common packets to multiple routers over a backbone,<= BR> =A0=A0=A0=A0=A0=A0=A0where the packets results in each receiving router initiating
=A0=A0=A0=A0=A0=A0=A0multicast (sometimes as a full broadcast) within the LLN. =A0This
=A0=A0=A0=A0=A0=A0=A0is byproduct of having potentially physically separated backbone
=A0=A0=A0=A0=A0=A0=A0routers that can inject messages into different portions of the
=A0=A0=A0=A0=A0=A0=A0same larger LLN.”
 
JP> IMO a too solution-specific statement.
 
29) Section 7
* “The routing algorithm SHOULD always be in the process of
=A0=A0=A0optimizing the system in response to changing link statistics.” JP> The term “optimizing” is worth a few words of explanatio= n. Optimizing with regards to which objective ?
 
* “The
=A0=A0=A0routing algorithm MUST re-optimize the paths when field devices
=A0=A0=A0change due to insertion, removal or failure, and this re-optimization =A0=A0=A0MUST not cause latencies greater than the specified constraints
=A0=A0=A0(typically seconds to minutes).”
Few comments here: (1) The first “MUST” is not different than t= he basic requirement of being able to compute new path upon topology changes= . (2) I would propose to carefully use the term “re-optimization”= ;. Indeed, I guess that you refer to the event where a “shorter”= path is found according to some metrics. Then you are requiring the ability= to switch to a shorter path while bounding the latency, which requires to o= nly switch if the delta between the old and new cost is also bounded and als= o implies other constraints. Indeed, in distributed systems, you cannot guar= antee that systems are fully synchronized. Thus a router may start using a r= oute that is not yet ready if some of the next hops have not converged yet, = which may lead to micro-loops. Could you elaborate on this requirement ?
 
30)
* “The routing protocol SHOULD support the wireless worker with fast<= BR> =A0=A0=A0network connection times of a few of seconds, and low command and
=A0=A0=A0response latencies to the plant behind the L2N access points, to
=A0=A0=A0applications, and to field devices. =A0“
 
Is it a different requirement than the one expressed in Section 7:
 
“The routing algorithm MUST find the appropriate
=A0=A0=A0route(s) and report success or failure within several minutes, and
=A0=A0=A0SHOULD report success or failure within tens of seconds.”
 
 
* “The routing protocol SHOULD also
=A0=A0=A0support the bandwidth allocation for bulk transfers between the field =A0=A0=A0device and the handheld device of the wireless worker. =A0=A0“
 
JP> of course, I see what you mean but this should either be removed or = reworded. This may simply refer to topology changes, for which you already h= ave a routing requirement or some cross-layer function (hope not).
 
“The routing
=A0=A0=A0protocol SHOULD support walking speeds for maintaining network
=A0=A0=A0connectivity as the handheld device changes position in the wireless
=A0=A0=A0network.
 
=A0=A0=A0Some field devices will be mobile. =A0These devices may be located on
=A0=A0=A0moving parts such as rotating components or they may be located on
=A0=A0=A0vehicles such as cranes or fork lifts. =A0The routing protocol SHOULD
=A0=A0=A0support vehicular speeds of up to 35 kmph.
“
 
JP> You may just want to say that such requirement has also consequences= on non-routing functions.
 
31) Section 9
 
* “Therefore,
=A0=A0=A0the routing protocol MUST support auto-provisioning of field devices.= 221;
 
JP> To which extent ? Does that mean a true 0-configuration routing prot= ocol ?
 
*”The protocol also MUST support the distribution of configuration fr= om
=A0=A0=A0a centralized management controller if operator-initiated
=A0=A0=A0configuration change is allowed.”
 
JP> Not a routing requirement. Or do you refer to the dynamic set up of = a “default DAG/Tree” used to retrieve a more sophisticated ̶= 0;routing feature” from a centralized tool ?
 
32) Section 10
 
* s/”1) attacks on the actual application served be the wireless
=A0=A0=A0devices and “/”1) attacks on the actual application served b= y the wireless
=A0=A0=A0devices and “
 
* “2) attacks that exploit the presence of a wireless access
=A0=A0=A0point that MAY provide connectivity onto legacy wired plant networks, =A0=A0=A0so attacks that have little to do with the wireless devices in the
=A0=A0=A0L2Ns. “/”2) attacks that exploit the presence of a wireless = access
=A0=A0=A0point that may provide connectivity onto legacy wired plant networks, =A0=A0=A0so attacks that have little to do with the wireless devices in the
=A0=A0=A0LLNs. “
 
* “The routing protocol SHOULD place limited trust in the field devic= es
=A0=A0=A0deployed in the plant network.
“
 
JP> Could you elaborate a little bit ? It sounds a bit too vague for a p= rotocol designer to figure out what action to take according to this require= ment.
 
“Standards exist that address those
=A0=A0=A0vulnerabilities.”
 
JP> ??
 
33) replace “isn’t by is not”, “doesn’t by do= es not” , ...
 
Thanks.
 
Cheers,
 
JP.
=
--B_3304314569_54167105-- --===============1373361548== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1373361548==-- From roll-bounces@ietf.org Mon Sep 15 10:00:13 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A743228C11D; Mon, 15 Sep 2008 10:00:13 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F51A3A6BAF for ; Mon, 15 Sep 2008 10:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.534 X-Spam-Level: X-Spam-Status: No, score=-0.534 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Pscb0sAJ8uV for ; Mon, 15 Sep 2008 10:00:11 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 24C7C3A6B01 for ; Mon, 15 Sep 2008 10:00:11 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id m8FH0Gvv007978; Mon, 15 Sep 2008 10:00:16 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id m8FH0GN7007977; Mon, 15 Sep 2008 10:00:16 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 15 Sep 2008 10:00:16 -0700 From: David Meyer To: JP Vasseur Message-ID: <20080915170016.GA7919@1-4-5.net> References: <20080913073001.4BEE63A697D@core3.amsl.com> MIME-Version: 1.0 In-Reply-To: X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: roll@ietf.org Subject: Re: [Roll] FW: I-D Action:draft-vasseur-roll-terminology-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0359415376==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0359415376== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable JP, Nice document. Bunch of editorial (and some substantive) comments in-line (search for dmm>). Thnx, Dave Networking Working Group JP. Vasseur Internet-Draft Cisco Systems, Inc Intended status: Informational September 15, 2008 Expires: March 19, 2009 Terminology in Low power And Lossy Networks draft-vasseur-roll-terminology-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 19, 2009. Abstract The documents defines a terminology for discussing routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN). A LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (Heating, Ventilating, and Air Conditioning also referred dmm> s/(Heating,/(e.g, Heating,/ to as HVAC, lighting, access control, fire), connected home, dmm> s/also referred to as HVAC// dmm> (no need to give the acronym in the abstract) healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking, refrigeration. Vasseur Expires March 19, 2009 [Page 1] =0C Internet-Draft draft-vasseur-roll-terminology-01.txt September 2008 Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. dmm> The use of 2119 language in non-protocol specs is at least dmm> controversial, and since you don't really use 2119 language dmm> in the document, you could probably remove the above text dmm> (Requirements Language) and the normative reference. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Vasseur Expires March 19, 2009 [Page 2] =0C Internet-Draft draft-vasseur-roll-terminology-01.txt September 2008 1. Introduction This document defines a terminology for discussing routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN). Low power and Lossy networks (LLNs) are typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links, such as IEEE 802.15.4, Low dmm> s/802.15.4, Low/802.15.4 or Low/ Power WiFi. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking and refrigeration. Since these applications are usually highly specific (Industrial Automation, Building Automation, ...), it is not uncommon to see a dmm> maybe =20 dmm>=20 dmm> "Since these applications are usually highly specific dmm> (for example, Industrial or Building Automation), it is dmm> not..." number of disparate terms to describe the same device or functionality. =20 Thus it was needed to specify common terms for all LLNs to avoid confusion and discrepancies. =20 dmm> Maybe: "Thus in order to avoid confusion or discrepancies, dmm> this document specifies the common terminology to be used dmm> in all ROLL Working Group documents."=20 Terminology specific to a particular application are out of the scope of this document.=20 It is expected that all routing requirements documents defining requirements or specifying routing solutions for LLN will use the common terminology specified in this document. 2. Terminology Actuator: a field device that controls a set of equipments. =20 dmm> s/equipments/equipment/ An actuator can control and/or modulates the flow of a gas or liquid, control electricity distribution, perform a mechanical operation, ...=20 dmm> Maybe: dmm>=20 dmm> For example, an actuator might control and/or modulate the dmm> flow of a gas or liquid, control electricity distribution, dmm> or perform a mechanical operation. AMI: Advanced Metering Infrastructure that makes use of Smart Grid technologies. Encompasses smart-metering applications. dmm> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ dmm> Maybe dmm> A canonical Smart Grid application is smart-metering. dmm>=20 dmm> BTW, need a cite for Smart Grid here? Channel: Radio frequency sub-band used to transmit a modulated signal carrying packets. Channel Hopping: A procedure by which field devices synchronously change channels during operation. Commissioning Tool: Any physical or logical device temporarily added to the network for the expressed purpose of setting up the network and device operational parameters. The commision tool can also be dmm> s/commision/commissioning=20 temporarily added for scheduled or unscheduled maintenance. dmm> s/added/added to the LLN network/ Closed Loop Control: A process whereby a device controller controls Vasseur Expires March 19, 2009 [Page 3] =0C Internet-Draft draft-vasseur-roll-terminology-01.txt September 2008 an actuator based on information sensed by one or more field devices. Controller: A field device that can receive sensor input and automatically change the environment in the facility by manipulating digital or analog actuators. DA: Distribution Automation, part of Smart Grid. Encompasses technologies for maintenance and management of electrical distribution systems. dmm> Maybe dmm> Technologies for maintenance and management of electrical dmm> distribution systems are examples DA. Downstream: Data direction traveling from outside of the LLN (e.g. traffic coming from a LAN, WAN or the Internet) via a LBR. Field Device: physical devices placed in the network's operating dmm> s/physical devices/A Field Device is a physical device/ environment (plant, urban, home, ...). Field devices include dmm> s/(plant, urban, home, ...)/(e.g., plant, urban, or home) sensors, actuators as well as routers and Low power and lossy network dmm> s/lossy network/Lossy Network/ Border Router (including LBR). A field device is most of the time dmm> s/most of the time/usually/ (but not always) a constrained device with limited CPU, memory dmm> s/constrained// dmm> (limited --> constrained) footprint, storage capacity, bandwidth and sometimes power constrained (battery operated). At the time of writing, for the sake dmm> s/constrained// of illustration, a typicaly sensor or actuator would have a few dmm> s/typicaly/typically/ KBytes of RAM, a few dozens of KBytes of ROM/Flash memory, a 8/16/32 bit microcontroller and communication capabilities ranging from a few Kbits/s to a few hundreds of KBits/s. Altough it is expected to see dmm> s/Altough/Although/ comtinuous improvements of hardware and software technologies, such dmm> s/comtinous/continous/ devices will likely continue to be seen as constrained devices dmm> s/constrained/resource constrained/ compared to computers and routers used in the Internet. Flash memory: non-volatile memory that can be re-programmed. FMS: Facility Management System. A global term applied across all the vertical designations within a building including, Heating, dmm> vertial designations not really defined... Ventilating, and Air Conditioning also referred to as HVAC, Fire, dmm> s/also referred to as HVAC/(HVAC)/ Security, Lighting and Elevator control. HART: "Highway Addressable Remote Transducer", a group of specifications for industrial process and control devices administered by the HART Foundation (see [HART]). The latest version for the specifications is HART7 which includes the additions for WirelessHART. HVAC: Heating, Ventilation and Air Conditioning. A term applied to the comfort level of an internal space. ISA: "International Society of Automation". ISA is an ANSI accredited standards-making society. ISA100 is an ISA committee whose charter includes defining a family of standards for industrial automation. [ISA100.11a] is a working group within ISA100 that is Vasseur Expires March 19, 2009 [Page 4] =0C Internet-Draft draft-vasseur-roll-terminology-01.txt September 2008 working on a standard for monitoring and non-critical process control applications. LAN: Local Area Network. LBR: Low power and lossy network Border Router. The LBR is a device that connects the low power and lossy network to another routing dmm> capitalization of Low power and Lossy Network dmm> consistent capitalization, etc... domain such as a Local Area Network (LAN), Wide Area Network (WAN) or the Internet where a possibly different routing protocol is in operation. The LBR acts as a routing device and may possibly host other functions such as data collector or aggregator. LLN: Low power and Lossy networks (LLNs) are typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links, such as IEEE 802.15.4, Low Power WiFi. There is a wide scope of application areas dmm> s/802.15.4,/802.15.4 or / for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire), connected home, healthcare, dmm> s/(HVAC, lighting, access control, fire)// environmental monitoring, urban sensor networks, energy management, assets tracking and refrigeration.. dmm> s/assets tracking and refrigeration../asset tracking and refrigeration= =2E/ Open Loop Control: A process whereby a plant operator manually manipulates an actuator over the network where the decision is influenced by information sensed by field devices. RAM: Random Access Memory. The RAM is a volatile memory. ROM: Read Only Memory. ROLL: Routing Over Low power and Lossy networks. Schedule: An agreed execution, wake-up, transmission, reception, etc., time-table between two or more field devices. Sensor: device that measures a physical quantity and converts it to a dmm> s/device/A Sensor is a device/ analog or digital signal that can be read by a program or a user. Sensed data can be of many types: electromagnetic (current, voltage, power, resistance) , mechanical (pressure, flow, liquid density, humidity, ...), chemical (oxygen, carbon monoxide, ...), acoustic (noise, ultrasound), ... dmm> s/acoustic (noise, ultrasound), .../or acoustic (e.g., noise or ultras= ound)./ Smart Grid: a broad class of applications to network and automate dmm> s/a/A Smart Grid is a/ utility infrastructure. Timeslot: A fixed time interval that may be used for the transmission or reception of a packet between two field devices. A timeslot used for communications is associated with a slotted-link dmm> to be consistent, you might say "Timeslot: A Timeslot is a fixed..." Vasseur Expires March 19, 2009 [Page 5] =0C Internet-Draft draft-vasseur-roll-terminology-01.txt September 2008 Upstream: Data direction traveling from the LLN via the LBR to outside of the LLN (LAN, WAN, Internet). WAN: Wide Area Network. 3. IANA Considerations This document includes no request for IANA action. 4. Security Considerations Since this document specifies terminology and does not specify new procedure or protocols, there are no security issues associated with it. dmm> Maybe dmm> s/there are no security issues associated with it/it raises dmm> no new security issues/ 5. Acknowledgements The authors would like to thank Christian Jacquenet, Tim Winter and Pieter De Mil for their valuable feed-back. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. dmm> again, I'm not sure this reference is needed.. 6.2. Informative References dmm> None of these are referenced anywhere... [I-D.ietf-roll-home-routing-reqs] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirement in Low Power and Lossy Networks", draft-ietf-roll-home-routing-reqs-03 (work in progress), September 2008. [I-D.ietf-roll-indus-routing-reqs] Networks, D., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low Power and Lossy Networks", draft-ietf-roll-indus-routing-reqs-01 (work in progress), July 2008. [I-D.ietf-roll-urban-routing-reqs] Dohler, M., Watteyne, T., Winter, T., Jacquenet, C., Madhusudan, G., Chegaray, G., and D. Barthel, "Urban WSNs Vasseur Expires March 19, 2009 [Page 6] =0C Internet-Draft draft-vasseur-roll-terminology-01.txt September 2008 Routing Requirements in Low Power and Lossy Networks", draft-ietf-roll-urban-routing-reqs-01 (work in progress), July 2008. [I-D.martocci-roll-building-routing-reqs] Martocci, J., Riou, N., Mil, P., and W. Vermeylen, "Commercial Routing Requirements in Low Power and Lossy Networks", draft-martocci-roll-building-routing-reqs-00 (work in progress), September 2008. Author's Address JP Vasseur Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA Email: jpv@cisco.com Vasseur Expires March 19, 2009 [Page 7] =0C Internet-Draft draft-vasseur-roll-terminology-01.txt September 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Vasseur Expires March 19, 2009 [Page 8] =0C --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjOlKAACgkQORgD1qCZ2KfBAQCfZDiYO6LNxwrtZ9Jfcn11LLga W/sAoIw6dJlFirLrSrrtnZiHwazTxcQZ =4HTa -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- --===============0359415376== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0359415376==-- From roll-bounces@ietf.org Mon Sep 15 10:13:09 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC403A6BB9; Mon, 15 Sep 2008 10:13:09 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534F23A6BAF for ; Mon, 15 Sep 2008 10:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.727 X-Spam-Level: X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=0.872, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYTg8BCVlN+B for ; Mon, 15 Sep 2008 10:13:04 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 9ABC53A6877 for ; Mon, 15 Sep 2008 10:13:04 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id m8FHDERY008657; Mon, 15 Sep 2008 10:13:14 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id m8FHDE03008656; Mon, 15 Sep 2008 10:13:14 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 15 Sep 2008 10:13:14 -0700 From: David Meyer To: JP Vasseur Message-ID: <20080915171314.GA8530@1-4-5.net> References: <20080913073001.4BEE63A697D@core3.amsl.com> <20080915170016.GA7919@1-4-5.net> MIME-Version: 1.0 In-Reply-To: <20080915170016.GA7919@1-4-5.net> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: roll@ietf.org Subject: Re: [Roll] FW: I-D Action:draft-vasseur-roll-terminology-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0497095086==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0497095086== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable A couple of other points. A definition of "Access Point" and "Repeater" may be useful to prevent every use-case document from having to (re)define them. Perhaps: Access Point: An access point is an infrastructure device that connects the LLN to a backbone network. Repeater: A repeater is an infrastructure device that acts a relay for the purpose of improving LLN coverage,=20 lifetime, and routing efficiency.=20 Dave --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjOl6oACgkQORgD1qCZ2KcYmQCfWERBIDksnOAL2PoWHxgQU1EP 4WUAoI/juFZDYOPaXDHg3tR3VpzszmRV =B/di -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- --===============0497095086== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0497095086==-- From roll-bounces@ietf.org Mon Sep 15 13:52:22 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 909333A6B01; Mon, 15 Sep 2008 13:52:22 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E902A3A6B01 for ; Mon, 15 Sep 2008 13:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.927 X-Spam-Level: X-Spam-Status: No, score=-5.927 tagged_above=-999 required=5 tests=[AWL=0.672, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLKOMHKtyGQb for ; Mon, 15 Sep 2008 13:52:21 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 09B0D3A6A62 for ; Mon, 15 Sep 2008 13:52:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,404,1217808000"; d="scan'208";a="20993651" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 15 Sep 2008 20:52:31 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8FKqVoo020551; Mon, 15 Sep 2008 16:52:31 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8FKqV8c018216; Mon, 15 Sep 2008 20:52:31 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Sep 2008 16:52:31 -0400 Received: from 10.61.65.34 ([10.61.65.34]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 15 Sep 2008 20:52:30 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Mon, 15 Sep 2008 22:52:14 +0200 From: JP Vasseur To: David Meyer Message-ID: Thread-Topic: [Roll] FW: I-D Action:draft-vasseur-roll-terminology-01.txt Thread-Index: AckXdO5kobBaPGbGb0+DjaQAIZNUuA== In-Reply-To: <20080915171314.GA8530@1-4-5.net> Mime-version: 1.0 X-OriginalArrivalTime: 15 Sep 2008 20:52:31.0158 (UTC) FILETIME=[F89EED60:01C91774] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=581; t=1221511951; x=1222375951; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20FW=3A=20I-D=20Action=3Adraft-v asseur-roll-terminology-01.txt |Sender:=20 |To:=20David=20Meyer=20; bh=rBalVbgKKRJVKuOYqsOo1v7CJoB/FZ7yIF2ap8CUtF8=; b=fUFLEeAU//+FSvw8tD+Noq2Mus4JJbQwbVUn5la3slsGJZU25664w6d4vF vWAWGbO3zAdnncghesCJ92AdwqWitRufhZpF6IFzGNFSoLlzWyXtYjtak1Jt /VbvOzL5yk; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] FW: I-D Action:draft-vasseur-roll-terminology-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Well I asked *not* to use the term access point and repeater. On 9/15/08 7:13 PM, "David Meyer" wrote: > A couple of other points. A definition of "Access Point" > and "Repeater" may be useful to prevent every use-case > document from having to (re)define them. Perhaps: > > Access Point: An access point is an infrastructure > device that connects the LLN to a backbone network. > > Repeater: A repeater is an infrastructure device that > acts a relay for the purpose of improving LLN coverage, > lifetime, and routing efficiency. > > Dave _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Sep 15 13:57:59 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B37A3A68C9; Mon, 15 Sep 2008 13:57:59 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E40C3A6846 for ; Mon, 15 Sep 2008 13:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=0.727, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpJjj5pTWiOf for ; Mon, 15 Sep 2008 13:57:57 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 870863A68C9 for ; Mon, 15 Sep 2008 13:57:56 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id m8FKw1L1014890; Mon, 15 Sep 2008 13:58:01 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id m8FKw1cZ014889; Mon, 15 Sep 2008 13:58:01 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 15 Sep 2008 13:58:01 -0700 From: David Meyer To: JP Vasseur Message-ID: <20080915205801.GA14848@1-4-5.net> References: <20080915171314.GA8530@1-4-5.net> MIME-Version: 1.0 In-Reply-To: X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: roll@ietf.org Subject: Re: [Roll] FW: I-D Action:draft-vasseur-roll-terminology-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1657824554==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1657824554== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 15, 2008 at 10:52:14PM +0200, JP Vasseur wrote: > Well I asked *not* to use the term access point and repeater. Ok, must have missed that. I just noticed the use of one or both in the U-LLN and home-routing-reqs drafts. Thnx, Dave =09 =09 =09 --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjOzFkACgkQORgD1qCZ2KfLwgCeJ0azw/nnqD12wFEt/nCWkGX0 UGoAn0iVPGmxv1WK9dommpwCCZ+1/gQa =LIcZ -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb-- --===============1657824554== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1657824554==-- From roll-bounces@ietf.org Mon Sep 15 18:47:33 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DB313A6AA2; Mon, 15 Sep 2008 18:47:33 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36F23A6AA2 for ; Mon, 15 Sep 2008 18:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_ASCII0=1.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKgmYDZcQVlK for ; Mon, 15 Sep 2008 18:47:31 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 84B5B3A69B2 for ; Mon, 15 Sep 2008 18:47:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,404,1217808000"; d="xml'?scan'208,217";a="20983726" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 Sep 2008 01:47:42 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8G1lgnG005808 for ; Mon, 15 Sep 2008 21:47:42 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8G1lgaa007385 for ; Tue, 16 Sep 2008 01:47:42 GMT Received: from xmb-rtp-216.amer.cisco.com ([64.102.31.80]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Sep 2008 21:47:42 -0400 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9179E.35193C19" Date: Mon, 15 Sep 2008 21:47:22 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New MailFiler Definition Thread-Index: AckXnjUZsxpWgUF6T66810cy1CE26w== From: "Alvaro Retana (aretana)" To: X-OriginalArrivalTime: 16 Sep 2008 01:47:42.0322 (UTC) FILETIME=[354C1520:01C9179E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3341; t=1221529662; x=1222393662; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aretana@cisco.com; z=From:=20=22Alvaro=20Retana=20(aretana)=22=20 |Subject:=20New=20MailFiler=20Definition |Sender:=20 |To:=20; bh=s60+Pmz/ilbONz1KfN9R/wKPYFT1IRhVywAB3MmmBTU=; b=S0p2dE0DhjpIRzXj1gGq3L4zNFU+rkOmczzVPKPC5kcfhaY24HlUJdckVE 6dsxSM0R6DZRHUqCVxnqwcZroFwAcjUKFCrzxqORggclOU7oJ/Wmqs0SS3dA sCVQfqTUSj; Authentication-Results: rtp-dkim-2; header.From=aretana@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [Roll] New MailFiler Definition X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C9179E.35193C19 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9179E.35193C19" ------_=_NextPart_002_01C9179E.35193C19 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This message contains the definition for the Project roll If you are running MailFiler then this Project will be automatically = added to your list of Projects. If you are not running MailFiler Pro then you can get a copy from = http://www.MailFiler.com or you can just delete this message. ------_=_NextPart_002_01C9179E.35193C19 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New MailFiler Definition

This message contains the definition for the Project = roll

If you are running MailFiler then this Project will be automatically = added to your list of Projects.

If you are not running MailFiler Pro then you can get a copy from http://www.MailFiler.com or you = can just delete this message.

------_=_NextPart_002_01C9179E.35193C19-- ------_=_NextPart_001_01C9179E.35193C19 Content-Type: text/xml; name="roll.xml" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="roll.xml" PD94bWwgdmVyc2lvbj0iMS4wIj8+DQo8IS0tIE91dGxvb2sgUEEgUHJvamVjdCBEYXRhIC0gd3d3 Lm1haWxmaWxlci5jb20gLS0+DQo8bWY6bWFpbGZpbGVycHJvamVjdCB4bWxuczptZj0iaHR0cDov L3d3dy5tYWlsZmlsZXIuY29tL21mcHJvIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIw MDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4c2k6c2NoZW1hTG9jYXRpb249Imh0dHA6Ly93d3cubWFp bGZpbGVyLmNvbS9tZnByby54c2QiPg0KCTxuYW1lPnJvbGw8L25hbWU+DQoJPGlkPjwvaWQ+DQoJ PG1haWxmaWxlcnJlZmVyZW5jZT48IVtDREFUQVtBUkEtNEZESUNLMl1dPjwvbWFpbGZpbGVycmVm ZXJlbmNlPg0KCTxkZXNjcmlwdGlvbj5yb2xsIFdHPC9kZXNjcmlwdGlvbj4NCgk8b3V0bG9va2Zv bGRlcj4NCgkJPGVudHJ5aWQ+MDAwMDAwMDAyNEE5RDcxQjQwRjYwMTQwODc1MkEwNzhDNEQ0REEz QjAxMDBBMTFCQTVGOUE2REFGNjQ2QTdDRTdBRDY5NzE4MkM4RTAwMDg2MjUzMDA0MDAwMDA8L2Vu dHJ5aWQ+DQoJCTxzdG9yZWlkPjAwMDAwMDAwMzhBMUJCMTAwNUU1MTAxQUExQkIwODAwMkIyQTU2 QzIwMDAwNDU0RDUzNEQ0NDQyMkU0NDRDNEMwMDAwMDAwMDAwMDAwMDAwMUI1NUZBMjBBQTY2MTFD RDlCQzgwMEFBMDAyRkM0NUEwQzAwMDAwMDU4NEQ0MjJENTI1NDUwMkQzMjMxMzYwMDJGNkYzRDQz Njk3MzYzNkYyMDUzNzk3Mzc0NjU2RDczMkY2Rjc1M0Q0NjY5NzI3Mzc0MjA0MTY0NkQ2OTZFNjk3 Mzc0NzI2MTc0Njk3NjY1MjA0NzcyNkY3NTcwMkY2MzZFM0Q1MjY1NjM2OTcwNjk2NTZFNzQ3MzJG NjM2RTNENjE3MjY1NzQ2MTZFNjEwMEQ4MzUyMUYzQTYwMDAwMDAwMTAwMDAwMDE0MDAwMDAwNkUw MDAwMDAyRjZGM0Q0MzY5NzM2MzZGMjA1Mzc5NzM3NDY1NkQ3MzJGNkY3NTNENDY2OTcyNzM3NDIw NDE2NDZENjk2RTY5NzM3NDcyNjE3NDY5NzY2NTIwNDc3MjZGNzU3MDJGNjM2RTNENDM2RjZFNjY2 OTY3NzU3MjYxNzQ2OTZGNkUyRjYzNkUzRDUzNjU3Mjc2NjU3MjczMkY2MzZFM0Q1ODRENDIyRDUy NTQ1MDJEMzIzMTM2MDA3ODAwNkQwMDYyMDAyRDAwNzIwMDc0MDA3MDAwMkQwMDMyMDAzMTAwMzYw MDJFMDA2MTAwNkQwMDY1MDA3MjAwMkUwMDYzMDA2OTAwNzMwMDYzMDA2RjAwMkUwMDYzMDA2RjAw NkQwMDAwMDAwMDAwPC9zdG9yZWlkPg0KCQk8cG9pbnR0b2ZvbGRlcj4wPC9wb2ludHRvZm9sZGVy Pg0KCTwvb3V0bG9va2ZvbGRlcj4NCgk8ZmlsZXN5c3RlbT4NCgk8L2ZpbGVzeXN0ZW0+DQoJPHRv dGFsdGltZT4wPC90b3RhbHRpbWU+DQo8L21mOm1haWxmaWxlcnByb2plY3Q+DQoA ------_=_NextPart_001_01C9179E.35193C19 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------_=_NextPart_001_01C9179E.35193C19-- From roll-bounces@ietf.org Wed Sep 17 07:39:58 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9C603A6907; Wed, 17 Sep 2008 07:39:58 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4BF3A6907 for ; Wed, 17 Sep 2008 07:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.734, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2I4t9zM3D-E for ; Wed, 17 Sep 2008 07:39:56 -0700 (PDT) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 860AA3A6922 for ; Wed, 17 Sep 2008 07:39:56 -0700 (PDT) Received: from aste-genev-bois-153-1-58-73.w81-249.abo.wanadoo.fr ([81.249.208.73] helo=[192.168.147.109]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KfyCO-0003Mm-OM for roll@ietf.org; Wed, 17 Sep 2008 14:40:09 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 81.249.208.73 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19rW6ZHiyKPzng8AHY89GM7 Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <097F8B3A-74F6-4156-87CA-068F80311D9B@ThomasClausen.org> To: roll@ietf.org From: Thomas Heide Clausen Date: Wed, 17 Sep 2008 16:40:29 +0200 X-Mailer: Apple Mail (2.753.1) Subject: [Roll] A couple of thoughts on draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Dear all, I may be late to the party, but I have read draft-ietf-roll-protocols- survey-00, and want to share my thoughts on that document (which, credit to the authors, is a well written and easy to read document). First, I am not quite sure that it is clearly justified from where the different "suitability metrics", over which protocols are evaluated, are presented. I am aware of the various requirements documents, however the simplified and simplistic view of "suitability metrics" as presented seem somewhat of a leap from those. This may be due to the survey and the requirements documents being in an early phase of development, and so I shall retain detailed comments on this matter until a later point in time. Second, with respect to the "Control Cost" suitability metric, I would respectfully question their validity since they are observing events at one given point in time, rather than over time - i.e. does not take any requirements for recurring transmissions into account. A "protocol operation" on the network with a complexity of O(N^2) might, on the face value, appear less preferential than one which has a complexity of O(N). However (taking an extreme example) in the event where the former O(N^2) operation occurs once every week and the latter O(N) once every microsecond, the O(N^2) operation could be largely preferential. On a similar token and considering that the ROLL working group is interested in complexity with respect to the number of destinations, a protocol might (taking a sought example again) exhibit a complexity of O(k*D) whereas another a complexity of O(i*N). On the face value, the O(k*D) option might appear preferential, however as D approaches N the relative value of k and i of course become important. This has long been a favorite subject of study in the MANET community, where this presents one of the differences between e.g. AODV and OLSR. Note that, however, there's also a difference between considering "number of destinations" and "number of communicating pairs", which is interesting to observe. Third, the suitability metrics disregard, at least in part, both temporary storage requirements necessary for the algorithms to operate, as well as the penalty incurring from suboptimal routes (e.g. the energy consumption penalty of transiting data over a longer- than-shortest-path). Evaluating table-size alone is insufficient. (I may get back to this specific point in a subsequent email later.) I want to share a single observation regarding the evaluation of OLSR, which is the protocol among those surveyed with which I am most familiar. I will, for brevity, in this email address the observation that OLSR is recorded as "fail" with respect to the survey metric "Control"; I may in following emails address the remaining suitability metrics, which I believe are similarly inappropriately applied. I note that the evaluation in the I-D is considering only the ROLL suitability metrics, and that the evaluation is considering only the "stock" deployment, and specifically not a deployment with additional "design consideration necessary". Let me thus address the temporal aspect, i.e. that which has to do with the "Control Cost" suitability metric when considering not only the cost of one protocol operation, but the cost of protocol operations over the lifetime of a network. In OLSR (RFC3626, OLSRv2 both), TC messages are diffused globally and periodically, using MPR flooding. In both, however, there are provisioning for modulating the period time - i.e. to increase or decrease the periodicity as appropriate for the network in operation. A "design consideration necessary" that would need to be specified for a given deployment would thus when observing "local stability" (in OLSRv2-terms: when the MPR selector set of a router is stable) increase the interval between TC message emissions. In case of "local instability (in OLSRv2 terms: when the MPR selector set of a router experiences changes), a TC message MAY be generated and/or the interval between TC messages modulated. While the exact heuristics by which this modulation is performed is not specified, performing this modulation requires no changes to the protocol, since the mechanism for modulating these intervals exists. Since I have started using extreme examples let me continue: in a stable network, a reasonable heuristic would after an initialization phase set a 45-day interval between successive TC message emissions. Hence, my reflection on the simple O(...) notation as evaluation metric for the "Control Cost" as being insufficient or inappropriate. I am not convinced that the conclusion drawn by the protocol survey I-D -- which seems to be that all routing protocols in existence are severely broken -- is justified. Sincerely, Thomas _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Sep 17 18:30:24 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2AC13A67F1; Wed, 17 Sep 2008 18:30:23 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24F33A67F1 for ; Wed, 17 Sep 2008 18:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfY+xhomS-n5 for ; Wed, 17 Sep 2008 18:30:21 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.228]) by core3.amsl.com (Postfix) with ESMTP id 2B5D93A67B2 for ; Wed, 17 Sep 2008 18:30:21 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id s16so1967307wxc.31 for ; Wed, 17 Sep 2008 18:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=3RDVh4m2CMLCDKIHb6ieqhmSzW/VbO/wmHkfRIJQNRI=; b=IhFuKIC0RWo6nepGxZGH4Qt26L34F0EhpLMacSDRJQ7itDH3Om3WDRKZgmVRFWHRzw giSnhWpIvYHBJrMuCB4PzUYi4AWjgTyWa4jOhKl4VWhde2Crb2pDqDboLld6K7JwGXR+ u2uNh/9R1wfeP66jVNhFNcKxIfhkoyUMb+A9E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=ED5Ew7emD884ChkvHlLTM1g8l1VLYvshTunPUWDXdDk6UhfgtmgfYfTZtinbrZk3oH YlTG4MbTxMCQ+/W/nd7lhkgQUy9RjfmbETdpYSit1OAqYzNNCdCoIDqLr3XiXsF+7VPR sbRTTb+LhW8MPLhErTovWhKgs3i+ii41HGUTw= Received: by 10.70.38.12 with SMTP id l12mr3409341wxl.9.1221701432363; Wed, 17 Sep 2008 18:30:32 -0700 (PDT) Received: by 10.70.9.14 with HTTP; Wed, 17 Sep 2008 18:30:32 -0700 (PDT) Message-ID: <44680fe70809171830k4a7e95c1ldfcb44a7f8e2d046@mail.gmail.com> Date: Wed, 17 Sep 2008 18:30:32 -0700 From: "Stephen Dawson-Haggerty" To: "Thomas Heide Clausen" In-Reply-To: <097F8B3A-74F6-4156-87CA-068F80311D9B@ThomasClausen.org> MIME-Version: 1.0 References: <097F8B3A-74F6-4156-87CA-068F80311D9B@ThomasClausen.org> X-Google-Sender-Auth: 49505cfa306eff9a Cc: roll@ietf.org Subject: Re: [Roll] A couple of thoughts on draft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1258673482==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1258673482== Content-Type: multipart/alternative; boundary="----=_Part_181_9652371.1221701432516" ------=_Part_181_9652371.1221701432516 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline It seems in the current version, "control cost" is the setup cost and assumed to be recurring. There is also "loss response"; all of the triggered temporal components of traffic would fit into that bin, provided that you can, as you suggest, turn down the global flood frequency so as to be basically negligible. However, we don't have a way to pass something that sends large updates extremely infrequently; I believe that that were a protocol to emerge which had a setup phase followed only by triggered updates, it __would__ have to pass the control traffic criteria (loss response might be another story). It's also true, we never say that protocols need to converge to optimal routes; this seems unnecessary to me since people seem unlikely to develop protocols that do not converge to good routes under some metric; as long as that metric is clear it would be fine with me. Also, I would disagree that we conclude that all protocols are "severely broken"; I actually think that a number of them could be made to work without all that much trouble... apparently that doesn't come out in the draft, though. I think having a discussion about whether or not OLSR (or any other protocol) will work in this space will be very interesting and seems to be the point you are driving at; after all that is the question we are trying to answer. This draft is mostly a guide for this debate. As always, we appreciate the comments. Steve On Wed, Sep 17, 2008 at 7:40 AM, Thomas Heide Clausen < IETF@thomasclausen.org> wrote: > Dear all, > > I may be late to the party, but I have read draft-ietf-roll-protocols- > survey-00, and want to share my thoughts on that document (which, > credit to the authors, is a well written and easy to read document). > > First, I am not quite sure that it is clearly justified from where > the different "suitability metrics", over which protocols are > evaluated, are presented. I am aware of the various requirements > documents, however the simplified and simplistic view of "suitability > metrics" as presented seem somewhat of a leap from those. This may be > due to the survey and the requirements documents being in an early > phase of development, and so I shall retain detailed comments on this > matter until a later point in time. > > Second, with respect to the "Control Cost" suitability metric, I > would respectfully question their validity since they are observing > events at one given point in time, rather than over time - i.e. does > not take any requirements for recurring transmissions into account. A > "protocol operation" on the network with a complexity of O(N^2) > might, on the face value, appear less preferential than one which has > a complexity of O(N). However (taking an extreme example) in the > event where the former O(N^2) operation occurs once every week and > the latter O(N) once every microsecond, the O(N^2) operation could be > largely preferential. > > On a similar token and considering that the ROLL working group is > interested in complexity with respect to the number of destinations, > a protocol might (taking a sought example again) exhibit a > complexity of O(k*D) whereas another a complexity of O(i*N). On the > face value, the O(k*D) option might appear preferential, however as D > approaches N the relative value of k and i of course become > important. This has long been a favorite subject of study in the > MANET community, where this presents one of the differences between > e.g. AODV and OLSR. Note that, however, there's also a difference > between considering "number of destinations" and "number of > communicating pairs", which is interesting to observe. > > Third, the suitability metrics disregard, at least in part, both > temporary storage requirements necessary for the algorithms to > operate, as well as the penalty incurring from suboptimal routes > (e.g. the energy consumption penalty of transiting data over a longer- > than-shortest-path). Evaluating table-size alone is insufficient. (I > may get > back to this specific point in a subsequent email later.) > > I want to share a single observation regarding the evaluation > of OLSR, which is the protocol among those surveyed with which I am > most familiar. I will, for brevity, in this email address the > observation that OLSR is recorded as "fail" with respect to the > survey metric "Control"; I may in following emails address the remaining > suitability metrics, which I believe are similarly inappropriately > applied. I note > that the evaluation in the I-D is considering only the ROLL > suitability metrics, > and that the evaluation is considering only the "stock" deployment, and > specifically not a deployment with additional "design consideration > necessary". > > Let me thus address the temporal aspect, i.e. that which has to do > with the "Control Cost" suitability metric when considering not only > the cost of one protocol operation, but the cost of protocol > operations over the lifetime of a network. In OLSR (RFC3626, OLSRv2 > both), TC messages are diffused globally and periodically, using MPR > flooding. In both, however, there are provisioning for modulating the > period time - i.e. to increase or decrease the periodicity as > appropriate for the network in operation. A "design consideration > necessary" that would need to be specified for a given deployment > would thus when observing "local stability" (in OLSRv2-terms: when > the MPR selector set of a router is stable) increase the interval > between TC message emissions. In case of "local instability (in > OLSRv2 terms: when the MPR selector set of a router experiences > changes), a TC message MAY be generated and/or the interval between > TC messages modulated. While the exact heuristics by which this > modulation is performed is not specified, performing this modulation > requires no changes to the protocol, since the mechanism for > modulating these intervals exists. > > Since I have started using extreme examples let me continue: in a > stable network, a reasonable heuristic would after an initialization > phase set a 45-day interval between successive TC message emissions. > > Hence, my reflection on the simple O(...) notation as evaluation > metric for the "Control Cost" as being insufficient or inappropriate. > > I am not convinced that the conclusion drawn by the protocol survey > I-D -- which seems to be that all routing protocols in existence are > severely broken -- is justified. > > Sincerely, > > Thomas > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > ------=_Part_181_9652371.1221701432516 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
It seems in the current version, "control cost" is the setup cost and assumed to be recurring.  There is also "loss response"; all of the triggered temporal components of traffic would fit into that bin, provided that you can, as you suggest, turn down the global flood frequency so as to be basically negligible.  However, we don't have a way to pass something that sends large updates extremely infrequently; I believe that that were a protocol to emerge which had a setup phase followed only by triggered updates, it __would__ have to pass the control traffic criteria (loss response might be another story).

It's also true, we never say that protocols need to converge to optimal routes; this seems unnecessary to me since people seem unlikely to develop protocols that do not converge to good routes under some metric; as long as that metric is clear it would be fine with me.

Also, I would disagree that we conclude that all protocols are "severely broken"; I actually think that a number of them could be made to work without all that much trouble...  apparently that doesn't come out in the draft, though.  I think having a discussion about whether or not OLSR (or any other protocol) will work in this space will be very interesting and seems to be the point you are driving at; after all that is the question we are trying to answer.  This draft is mostly a guide for this debate.

As always, we appreciate the comments.
Steve



On Wed, Sep 17, 2008 at 7:40 AM, Thomas Heide Clausen <IETF@thomasclausen.org> wrote:
Dear all,

I may be late to the party, but I have read draft-ietf-roll-protocols-
survey-00, and want to share my thoughts on that document (which,
credit to the authors, is a well written and easy to read document).

First, I am not quite sure that it is clearly justified from where
the different "suitability metrics", over which protocols are
evaluated, are presented. I am aware of the various requirements
documents, however the simplified and simplistic view of "suitability
metrics" as presented seem somewhat of a leap from those. This may be
due to the survey and the requirements documents being in an early
phase of development, and so I shall retain detailed comments on this
matter until a later point in time.

Second, with respect to the "Control Cost" suitability metric, I
would respectfully question their validity since they are observing
events at one given point in time, rather than over time - i.e. does
not take any requirements for recurring transmissions into account. A
"protocol operation"  on the network with a complexity of O(N^2)
might, on the face value, appear less preferential than one which has
a complexity of O(N). However (taking an extreme example) in the
event where the former O(N^2) operation occurs once every week and
the latter O(N) once every microsecond, the O(N^2) operation could be
largely preferential.

On a similar token and considering that the ROLL working group is
interested in complexity with respect to the number of destinations,
a protocol might (taking a sought example again) exhibit a
complexity of O(k*D) whereas another a complexity of O(i*N).  On the
face value, the O(k*D) option might appear preferential, however as D
approaches N the relative value of k and i of course become
important. This has long been a favorite subject of study in the
MANET community, where this presents one of the differences between
e.g. AODV and OLSR. Note that, however, there's also a difference
between considering "number of destinations" and "number of
communicating pairs", which is interesting to observe.

Third, the suitability metrics disregard, at least in part, both
temporary storage requirements necessary for the algorithms to
operate, as well as the penalty incurring from suboptimal routes
(e.g. the energy consumption penalty of transiting data over a longer-
than-shortest-path). Evaluating table-size alone is insufficient. (I
may get
back to this specific point in a subsequent email later.)

I want to share a single observation regarding the evaluation
of OLSR, which is the protocol among those surveyed with which I am
most familiar. I will, for brevity, in this email address the
observation that OLSR is recorded as "fail" with respect to the
survey metric "Control"; I may in following emails address the remaining
suitability metrics, which I believe are similarly inappropriately
applied.  I note
that the evaluation in the I-D is considering only the ROLL
suitability metrics,
and that the evaluation is considering only the "stock" deployment, and
specifically not a deployment with additional "design consideration
necessary".

Let me thus address the temporal aspect, i.e. that which has to do
with the "Control Cost" suitability metric when considering not only
the cost of one protocol operation, but the cost of protocol
operations over the lifetime of a network. In OLSR (RFC3626, OLSRv2
both), TC messages are diffused globally and periodically, using MPR
flooding. In both, however, there are provisioning for modulating the
period time - i.e. to increase or decrease the periodicity as
appropriate for the network in operation. A "design consideration
necessary" that would need to be specified for a given deployment
would thus when observing "local stability" (in OLSRv2-terms: when
the MPR selector set of a router is stable) increase the interval
between TC message emissions. In case of "local instability (in
OLSRv2 terms: when the MPR selector set of a router experiences
changes), a TC message MAY be generated and/or the interval between
TC messages modulated. While the exact heuristics by which this
modulation is performed is not specified, performing this modulation
requires no changes to the protocol, since the mechanism for
modulating these intervals exists.

Since I have started using extreme examples let me continue: in a
stable network, a reasonable heuristic would after an initialization
phase set a 45-day interval between successive TC message emissions.

Hence, my reflection on the simple O(...) notation as evaluation
metric for the "Control Cost"  as being insufficient or inappropriate.

I am not convinced that the conclusion drawn by the protocol survey
I-D -- which seems to be that all routing protocols in existence are
severely broken -- is justified.

Sincerely,

Thomas

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

------=_Part_181_9652371.1221701432516-- --===============1258673482== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1258673482==-- From roll-bounces@ietf.org Wed Sep 17 22:21:11 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6DDD3A6ADA; Wed, 17 Sep 2008 22:21:11 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CD1E3A6AD9 for ; Wed, 17 Sep 2008 22:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.245 X-Spam-Level: X-Spam-Status: No, score=-5.245 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16DDtYAY7ntn for ; Wed, 17 Sep 2008 22:21:05 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D9E783A6AA4 for ; Wed, 17 Sep 2008 22:21:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,419,1217808000"; d="scan'208,217";a="21249592" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Sep 2008 05:21:18 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8I5LIgV006970 for ; Thu, 18 Sep 2008 01:21:18 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8I5LIgk021986 for ; Thu, 18 Sep 2008 05:21:18 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Sep 2008 01:21:18 -0400 Received: from 10.61.85.187 ([10.61.85.187]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 18 Sep 2008 05:21:17 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Thu, 18 Sep 2008 07:21:16 +0200 From: JP Vasseur To: Message-ID: Thread-Topic: Metric document: draft-mjkim-roll-routing-metrics-00 Thread-Index: AckZTl+r/LkhDzSP3EiQYpRkgnrbVw== Mime-version: 1.0 X-OriginalArrivalTime: 18 Sep 2008 05:21:18.0158 (UTC) FILETIME=[60F4F6E0:01C9194E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1918; t=1221715278; x=1222579278; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Metric=20document=3A=20draft-mjkim-roll-routing -metrics-00 |Sender:=20 |To:=20; bh=y9Qj7FEGl8P4SbfZcfUywSxe3jMQKsPUbJS4c8dltYQ=; b=bOLMH3zVarXdzNPE3kcrYv9FCgxajG9pwxqXrbuvqm+EpYLKH7HShU7cnj XP4SeKy0o34AqlWxDz1DT5+AFmArlmNKmYuhjOhE+OU+AejI69ROAt2yxYVU G9rI6Z+g5J; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [Roll] Metric document: draft-mjkim-roll-routing-metrics-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1540743749==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1540743749== Content-type: multipart/alternative; boundary="B_3304567276_7406457" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3304567276_7406457 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Dear all, It might be a good time to start the discussion on draft-mjkim-roll-routing-metrics-00. As pointed out during the meeting in Dublin, this is a very first draft and the idea was to start with a large set of possible metrics. We all know that many of the proposed metrics may not be realistic especially in large scale networks (we learnt from the pas= t with ARPANET !) but again the idea was to start listing all potential candidates and go from there. Comments are very welcome. If OK with you, let=B9s concentrate on the technical aspects (editorial issues to be worked out at a larger stage). Thanks. JP and Kim. --B_3304567276_7406457 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Metric document: draft-mjkim-roll-routing-metrics-00 Dear all,
It might be a good time to start the discussion on draft-mjkim-roll-routing= -metrics-00. As pointed out during the meeting in Dublin, this is a very fir= st draft and the idea was to start with a large set of possible metrics. We = all know that many of the proposed metrics may not be realistic especially i= n large scale networks (we learnt from the past with ARPANET !) but again th= e idea was to start listing all potential candidates and go from there.

Comments are very welcome. If OK with you, let’s concentrate on the t= echnical aspects (editorial issues to be worked out at a larger stage).

Thanks.

JP and Kim. --B_3304567276_7406457-- --===============1540743749== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1540743749==-- From roll-bounces@ietf.org Thu Sep 18 14:04:47 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CBC83A681A; Thu, 18 Sep 2008 14:04:47 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 553463A699A for ; Thu, 18 Sep 2008 14:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWUbHxb5GO7K for ; Thu, 18 Sep 2008 14:04:45 -0700 (PDT) Received: from usstuh502.johnsondiversey.com (mail3.johnsondiversey.com [208.251.229.30]) by core3.amsl.com (Postfix) with ESMTP id 8E0913A6AD1 for ; Thu, 18 Sep 2008 14:04:45 -0700 (PDT) From: david.bruemmer@johnsondiversey.com To: roll@ietf.org Message-ID: Date: Thu, 18 Sep 2008 16:02:18 -0500 X-MIMETrack: Serialize by Router on USSTUH502/SVR/CMI(Release 7.0.3FP1|February 24, 2008) at 09/18/2008 16:05:00 MIME-Version: 1.0 Subject: [Roll] David Bruemmer is out of the office. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I will be out of the office starting 09/18/2008 and will not return until 09/23/2008. I will respond to your message when I return. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Sep 18 15:15:48 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AA753A688C; Thu, 18 Sep 2008 15:15:48 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 680B03A67A5 for ; Thu, 18 Sep 2008 15:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PH71+gogBnmB for ; Thu, 18 Sep 2008 15:15:46 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 0BC7D3A6403 for ; Thu, 18 Sep 2008 15:15:40 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id m8I8ZAkD018829 for ; Thu, 18 Sep 2008 09:35:10 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id m8I8ZAkh013400 for ; Thu, 18 Sep 2008 09:35:10 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 18 Sep 2008 09:35:10 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 18 Sep 2008 09:35:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Sep 2008 09:35:03 +0100 Message-ID: In-Reply-To: <44680fe70809171830k4a7e95c1ldfcb44a7f8e2d046@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] A couple of thoughts ondraft-ietf-roll-protocols-survey-00 thread-index: AckZL3CqdZwt5kqeR3GrjFF0xS0yQAAOSdoQ References: <097F8B3A-74F6-4156-87CA-068F80311D9B@ThomasClausen.org> <44680fe70809171830k4a7e95c1ldfcb44a7f8e2d046@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Stephen Dawson-Haggerty" , "Thomas Heide Clausen" X-OriginalArrivalTime: 18 Sep 2008 08:35:10.0259 (UTC) FILETIME=[763AB830:01C91969] Cc: roll@ietf.org Subject: Re: [Roll] A couple of thoughts ondraft-ietf-roll-protocols-survey-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Stephen Dawson-Haggerty > It's also true, we never say that protocols need to converge to optimal routes; > this seems unnecessary to me since people seem unlikely to develop protocols > that do not converge to good routes under some metric; as long as that metric > is clear it would be fine with me. That doesn't have to be the case. A protocol could set up a route, even according to some good criterion, but then, in order to minimise signalling, maintain that route in the face of mobility by patching it locally. That won't optimise any particular metric of the route. Over time, the route could become quite sub-optimal. (Separate route establishment and route maintenance is done by more than one protocol. How good routes they maintain, I don't know for certain.) ******************************************************************** 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. ******************************************************************** _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Sep 19 14:21:16 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED5363A6882; Fri, 19 Sep 2008 14:21:16 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC8613A6803 for ; Fri, 19 Sep 2008 14:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glovlczVgE8J for ; Fri, 19 Sep 2008 14:21:12 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 51CA53A6997 for ; Fri, 19 Sep 2008 14:21:12 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id m8JLLP2F014439 for ; Fri, 19 Sep 2008 14:21:25 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id m8JLLOkn014438 for roll@ietf.org; Fri, 19 Sep 2008 14:21:24 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 19 Sep 2008 14:21:24 -0700 From: David Meyer To: roll@ietf.org Message-ID: <20080919212124.GA14414@1-4-5.net> References: MIME-Version: 1.0 In-Reply-To: X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Roll] Metric document: draft-mjkim-roll-routing-metrics-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0839899203==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0839899203== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 18, 2008 at 07:21:16AM +0200, JP Vasseur wrote: > Dear all, >=20 > It might be a good time to start the discussion on > draft-mjkim-roll-routing-metrics-00. As pointed out during the meeting in > Dublin, this is a very first draft and the idea was to start with a large > set of possible metrics. We all know that many of the proposed metrics may > not be realistic especially in large scale networks (we learnt from the p= ast > with ARPANET !) but again the idea was to start listing all potential > candidates and go from there. All, Nice start. I've made several comments (both types, avoiding editorial where possible) in-line below. Search for dmm>=20 Thnx, Dave Networking Working Group M. Kim, Ed. Internet-Draft KT Intended status: Standards Track JP. Vasseur, Ed. Expires: January 5, 2009 Cisco Systems H. Chong KT July 4, 2008 Routing Metrics used for Path Calculation in Low Power and Lossy Networks draft-mjkim-roll-routing-metrics-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 5, 2009. Abstract This document specifies routing metrics used in path calculation for Routing Over Low power and Lossy networks (ROLL). Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired networks or even with similar ones such as mobile ad-hoc networks as indicated in several application-specific requirements documents. Since typical IGP routing metrics such as hop counts or link metrics are not sufficient for LLNs,=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ dmm>=20 dmm> might give a sentence or two about why traditional IGP dmm> metrics aren't sufficient in the LLN context this document specifies a new set of required link and node metrics suitable to Kim, et al. Expires January 5, 2009 [Page 1] =0C Internet-Draft Routing Metrics for LLNs July 2008 LLNs. Table of Contents 1. Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Node attributes . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Computational resources . . . . . . . . . . . . . . . . . 6 4.2. Residual Energy . . . . . . . . . . . . . . . . . . . . . 6 4.3. Current workload . . . . . . . . . . . . . . . . . . . . . 7 4.4. Node latency . . . . . . . . . . . . . . . . . . . . . . . 7 4.5. Data Aggregation attribute . . . . . . . . . . . . . . . . 7 4.6. Node degree . . . . . . . . . . . . . . . . . . . . . . . 8 4.7. Dynamicity . . . . . . . . . . . . . . . . . . . . . . . . 9 4.8. Node reliability . . . . . . . . . . . . . . . . . . . . . 9 5. Link attributes . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Reliability (Quality) . . . . . . . . . . . . . . . . . . 10 5.3. Propagation delay . . . . . . . . . . . . . . . . . . . . 10 6. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Kim, et al. Expires January 5, 2009 [Page 2] =0C Internet-Draft Routing Metrics for LLNs July 2008 1. Note Some of the routing metrics defined in this document may be subject to change or may even be removed in light of the routing requirements currently being specified by the Routing Over Low power and Lossy networks (ROLL) Working Group. For the sake of illustration, some metrics are only meaningful in routing protocols that fall into the category of Distance Vector. Since the Working Group has not yet determined which routing protocol will be chosen for Low power and Lossy Networks (LLNs), it is not yet possible to determine whether such metrics will be required. Conversely, other metrics may be further required depending on which routing protocol is selected by the Working Group. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 'RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. o Access point: An infrastructure device that connects the low power and lossy networks to the backbone network like the Internet, mostly via access networks. o Data sink: A device which collects data from nodes in a LLN. o Dynamic LLN: Low power and Lossy Network where some nodes are mobile. o ROLL: Routing Over Low-power and Lossy networks. o Static LLN: Low power and Lossy Network where all nodes are static, not mobile. dmm> looks likek most of this can be replaces with a citation to=20 dmm> draft-vasseur-roll-terminology-01.txt=09 3. Introduction This document specifies routing metrics used in path calculation for dmm> s/used/to be used/ (or maybe "for use") Routing Over Low power and Lossy networks (ROLL). Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired networks or even with similar ones such as mobile ad-hoc networks as indicated in several application-specific requirements documents. Since typical IGP routing metrics such as hop counts or link metrics are not sufficient for LLNs, this document specifies a new set of required link and node metrics suitable to LLNs. dmm> do you really want to say the the metrics are "required"? dmm> How about s/required// Kim, et al. Expires January 5, 2009 [Page 3] =0C Internet-Draft Routing Metrics for LLNs July 2008 Routing metrics can be classified according to the following set of characteristics: - Link versus Node metrics - Qualitative versus quantitative - Dynamic or static Historically, IGP such as OSPF and IS-IS have been using quantitative dmm> citations for OSPF and IS-IS static link metrics. Other mechanisms such as Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) make use of other link dmm> again, citation for MPLS/MPLS-TE attributes such as the available reserved bandwidth, affinities and so on to compute constrained shortest path for Traffic Engineering s/path/paths/ Label Switched Paths (TE LSPs). It must be noted that the use of dynamic metrics is not new and has been experimented in ARPANET 2, with a moderate success. Indeed, a dmm> citation for ARPANET 2 very careful care must be given to the use of dynamic metrics that may lead to potential routing instabilities. In LLNs, it is required to take into account various node constraints when calculating the desirable path. Node metrics include the node's resources like memory, energy and CPU (computational power). Other node attributes such as the ability to act as an aggregator (node capable of performing data aggregation) may be of interest. Additionally, work load, transmission range and dynamicity (mobility, duty cycle, etc) may need to be taken into account. Link attributes include propagation delay, reliability (quality) and available bandwidth. By contrast with the current Internet, LLNs are characterized by their dynamic nature, which not only applies to the link but also to the nodes in the networks. Thus, it is required to specify various dynamic metrics. For instance, even though a wireless sensor network topology is static in absence of failure, nodes' workload and resource such as residual energy and available memory are changing continuously and may have to be taken into account during the path computation. Similarly, link attributes including latency and reliability are not static because moving obstacles can appear at any time. Thus, they are real-time parameters. That being said, very careful attention must be given to highly dynamic parameters that affect routing decision in order to preserve the routing stability. Furthermore, it is quite time- and energy-consuming process to update these dynamic metrics in a regular basis. Therefore, we may regard them as static metrics in static LLNs to cut off overhead by compromising accuracy. dmm> This last sentence is hard to understand. Maybe: dmm> "Therefore we might treat such dynamic metrics as static dmm> metrics in order to reduce computational overhead and dmm> bandwidth utilization. Of course, this comes with a cost, dmm> namely, reduced metric accuracy. Kim, et al. Expires January 5, 2009 [Page 4] =0C Internet-Draft Routing Metrics for LLNs July 2008 Reliability is an example of quality parameter. However, to be routing metrics for path calculation, quality parameters MUST be transformed to quantity values. Some criteria SHOULD be set to make the quality parameters appear in quantity forms. Quantity form can be numbers or levels. This document specifies a set of link and nodes metrics that can be used to compute the optimal path within a LLN. Furthermore, some link or node attributes (e.g. level of link reliability, energy remaining on the node) can be used to perform constraint-based routing. It is not required to use all the metrics and attributes specified in this document. A particular implementation MAY use a subset or all of the metrics defined in this document. Note: finding the shortest path is not always best in LLNs since a reliable path is more preferable. !oThe optimal path!+/- here means the best path having regard to constraints. The term !oconstrained shortest path!+/- may be used instead. The specification of the objective function used to compute the path is out of the scope of this document. Note: in the first revision of this document, link and node metrics are defined with no packet format or suggestions to encode the data. This will be determined in a further revision of this document. 4. Node attributes Most node attributes may be taken as static attributes in LLNs since it might require quite amount of resources to get exact values of the attributes and update them periodically. Furthermore, the use of dynamic metrics is subject to routing instabilities and must be used dmm> s/is subject/can cause/ with extreme care. However, critical parameters like residual power dmm> you might want to consider the total power of a given path dmm> as well (especially when optimizing network lifetime). dmm> See, e.g., "Wireless sensor networks: a survey", dmm> I.F. Akyildiz, et. al., Computer Networks (38), 2002,, 393-422. might need to be considered dynamic and monitored continuously in some scenarios. Implementation MUST make use of multi-threshold dmm> s/Implmentation/An implementation/ scheme rather than fine granular metric update so as to avoid dmm> The term "multi-threshold scheme" hasn't been described constant routing changes. In LLNs, it is not uncommon to have highly heterogeneous nodes in term of capabilities (e.g node being battery operated or not, amount of memory, !|) and functionalities. More capable and stable nodes can assist the most constrained ones for routing packets, which results in extension of network lifetime and efficient network operations. Therefore, node metrics SHOULD be carefully maintained and utilized for routing. This has the following strong implication referred to as constrained-based routing whereby the computed path may not be the shortest path according to some specified metrics. dmm> maybe: "This implies that constraint-based routing will be dmm> used in some cases." Kim, et al. Expires January 5, 2009 [Page 5] =0C Internet-Draft Routing Metrics for LLNs July 2008 Mechanisms must be designed to ensure lack of routing loops in the presence of constrained based routing with a non connection oriented environment. dmm> "Routing should be loop-free" (?). In addition, what kind of dmm> micro-loops (if any) are to be tollerated? I would imagine dmm> that this is application specific. However, there is a dmm> convergence time v. energy utilization question here dmm> (possibly also application specifc). 4.1. Computational resources Memory and CPU resources can be considered as computational ones and are potentially important routing metrics in LLNs because in some environments nodes are resource constraint. Resource-awareness SHOULD be employed to routing protocols strictly or loosely considering trade-off between cost and benefit. 4.2. Residual Energy Low power is one of the most distinguished features of LLNs, so residual energy MUST be considered as a pivotal metric in environments where nodes are battery powered. Residual energy should be taken as a relative value considering statistical node lifetime and other conditions like the role of the node in the network. For example, if the node's expected lifetime is 5 years and the remaining energy is only one fifth, then the energy is quite precious resources to the node. In such cases, the routing protocol decision should be dmm> so "relative" above means relative to other resources that dmm> are considered "more important"? How would we quantify that? such that potentially a suboptimal path would be used for some traffic so as to increase the network life duration. Furthermore, in dmm> this implies that the routing protocol needs (must?) have a dmm> global view of the residual energy of the network (likely dmm> the rate at which certain devices are being dischared as dmm> well, and which ones are battery powered and which ones are dmm> mains powered). Is that what is intended? case absence of the node affects the network connectivity critically, the node SHOULD be avoided to save its power. Hence, whenever possible, the node should not be selected as a router (an intermediate node to deliver data), thus the support for constrained- based routing is needed. If the battery can be simply charged or the node can be easily replaced with another same kind of node, then it is not really a matter to use up the battery. Such information should be defined as a node attribute to be used in combination with the energy level. Algorithms defining how such metrics and attributes should be combined are outside of the scope of this document. Generally, the residual energy should be taken as a dynamic metric. Most battery operated devices have ability to estimate the remaining energy [I-D.ietf-roll-indus-routing-reqs]. However, initial energy status can be considered as a static metric in some situations where monitoring current energy status demands quite resources. Simply categorizing devices into two classes, main-powered and battery- powered, can be good enough to select a routing path for highly constrained scenarios, which contributes to prolonging network lifetime. To maximize network lifetime, it is essential to maintain energy balance among nodes in LLNs. dmm> ^^^^^^^^^^^^ dmm> how is "energy balance" defined? Kim, et al. Expires January 5, 2009 [Page 6] =0C Internet-Draft Routing Metrics for LLNs July 2008 4.3. Current workload Workload of a node is somewhat difficult to be measured and compared. It is also difficult to express the workload in a quantitative form. However, it could be an important metric to select a path in LLNs, especially when data processing along the data path is required or queuing delays must be minimized for highly sensitive traffic. Putting the workload as a "heavy" or "light" one bit metric can give a good advice to select a path for routing, thus providing a sufficient level of granularity, similarly to the "overload" bit used in protocols such as IS-IS. An implementation may then decide to dmm> might be useful to cite documents that define the IS-IS dmm> overload bit.=20 exclude from its routes any node with a "heavy" value for workload unless there is no alternative. 4.4. Node latency Node latency is the time span from the arrival time to the departure time of a given packet at a node. It is primarily made up of packet processing time and packet transmission time. Node latency is highly correlated with other metrics. For instance, heavy workload increases node latency while enough computational resources can reduce it. Therefore, in some LLNs where available resources and current workload can be measured, they can facilitate to estimate node latency or may substitute it. 4.5. Data Aggregation attribute Some nodes may sense (get) similar or same data if the nodes are dmm> s/(get) similar or same /or receive the same (or similar) located in a close area due to data correlation. dmm> BTW, this is frequently called "overlap" in the dmm> literature. See e.e., "Adaptive Protocols for Information dmm> Dissemination in Wireless Sensor Networks", Joanna Kulik, dmm> Wendi Rabiner, Hari Balakrishnan,1999 dmm> http://www.cs.washington.edu/education/courses/590es/01au/papers/2.pdf Thus, data aggregation/fusion can be performed. Data fusion involves more dmm> s/can be performed/may be possible/ complicated processing to improve accuracy of the output data while data aggregation mostly aims to reduce the amount of data. Especially in urban applications where sensor nodes collect dmm> s/Especially/Sensing overlap is common/ environmental information and send it to a data sink, quite a number of sensor nodes sense same kind or same value of data. In the Figure 1, let us assume that three nodes A, B and C need to send sensed data to the data sink. Node A sensed "xyz" and sent this data to node C. Since C also sensed same data, it has no additional information from node A. However, because the data node B sent is "xqz", node C aggregates this data with its own data "xyz" resulting in "xyqz". Therefore, node C sends "xyqz" to the data sink. In this example, each node's data requires 3 bytes. If no aggregation is performed, node C needs to send 9 byte data to the sink, but C only sends 4 bytes thanks to data aggregation. Kim, et al. Expires January 5, 2009 [Page 7] =0C Internet-Draft Routing Metrics for LLNs July 2008 A B |------| |------| | xyz | | xqz | |______| |______| \ / \ / \ C / sink |------| xyqz |------| | xyz |-----------| | |______| |______| Figure 1: Data aggregation Some applications MAY make use of the aggregation node attribute in their routing decision so as to minimize the amount of traffic on the network, thus potentially increasing its life time in battery operated environments. dmm> So this is a form of data-aware routing. How far to we think dmm> we need to go in this direction? I did notice that=20 dmm> I-D.ietf-roll-indus-routing-reqs also suggests the need for=20 dmm> data-aware routing.=20 dmm>=20 dmm> For a good discussion of (some of the) issuess, see, e.g., dmm>=20 dmm> "Directed Diffusion: A scalable and robust communication dmm> paradigm for sensor networks", Ramesh Govindan, Deborah dmm> Estrin, 2000 http://netweb.usc.edu/estrin/papers/diffusion.ps dmm>=20 dmm> (its just one such approach) To make data aggregation possible, the routing protocol needs to capture the time and location dependent correlation among sensed data from nodes on the possible routes, which is quite challenging. Obtaining correlation structure also demands high resource (energy) consumption and in-network processing itself may have high complexity. Consequently, in most applications, data aggregation may not be adopted for routing. However, simply choosing nodes that have the same kind of sensors with the source node can increase the chance to aggregate data, so it can be helpful for path formation regardless of having data-aware routing capability. =20 dmm> nice heuristic. Do we have a citation that examines the=20 dmm> use of this heuristic? Applications where high directional data flow is expected in a regular basis may take advantage of data aggregation supported routing. 4.6. Node degree Node degree is the number of neighbors that can send a message to the node directly. In other words, neighbors are nodes located within the transmission range of the node. Generally, a high node degree can be helpful for quick route recovery when the next hop node on the route cannot be accessible. Therefore, it may be beneficial to choose a node with a high degree to construct a route. On the contrary, a node with a high degree has a high possibility to have heavy workload in a busy network. Therefore, node degree has to be carefully utilized in routing decision. dmm> basically this is an "amplication effect" [RFC 3439] Kim, et al. Expires January 5, 2009 [Page 8] =0C Internet-Draft Routing Metrics for LLNs July 2008 4.7. Dynamicity Node dynamicity can be measured by many different factors such as mobility, transmission range, duty cycle, and the rate at which node joins and leaves the network. Node dynamicity directly affects the network topology and connectivity, which in turn may trigger route reestablishment process. For that reason, node dynamicity needs to be monitored and presented in a quantity form utilizing a well dmm> ^^^^^^^^ dmm> Do you mean quantative (v. qualatative)? defined objective function. Thus, less dynamic nodes should be preferred for path selection. =20 dmm> is that true, even if a more "dynamic" path has better (optimizes) dmm> residual energy or some other metric of interest? i.e., is dmm> the statement too general? In the most constrained LLN environments, classifying nodes into only static and dynamic can be very helpful in routing decision. =20 dmm> Maybe something like this: dmm> "In the most constrained LLN environments, the simple heuristic dmm> of classifying nodes into static or dynamic can be very dmm> helpful in routing decision." dmm> I think that is what you mean...if not, then ? Note that this node metric may either be static or dynamic. In the later case, the network administrator will have to use consistent metric values. 4.8. Node reliability Node reliability is deeply related to node dynamicity such that node reliability deteriorates as node dynamicity increases. However, node reliability is a wider concept than node dynamicity since node dmm> s/wider/more general/ reliability is influenced by more factors. For example, node's unexpected failure cuts off node reliability, but it is not really dmm> s/cuts of node/reduces a node's/ (I think that's what you mean) related to node dynamicity. Therefore, node dynamicity metric can be covered by node reliability metric. However, it is very challenging to estimate or monitor node reliability. A specific function needs to be defined to get values of the reliability metric from a variety of features affecting node reliability. Node reliability is a crucial metric in LLNs compared with in other conventional or even wireless networks considering that nodes in LLNs may stay in a sleep mode most of the time. =20 dmm> maybe : dmm> "Node reliability can be a crucial metric in LLNs, since dmm> nodes in LLNs may stay in a sleep mode most of the time." dmm> Again, I think that's what you mean. A sleeping node should dmm> question here about 2119 language. SHOULD NOT v. should not not be an intermediate node to deliver a packet, thus status of a node must be monitored or can be anticipated. Additionally, residual dmm> s/can be anticipated/should be predictable/ energy of a node should be predictable not to make the node suddenly die during routing process due to battery out. Nodes on the chosen path for routing should be reliable. 5. Link attributes There are several dynamic link attributes especially in wireless LLNs. Even in case of static LLNs where nodes are stationary, there are always variables like appearance of obstacles and signal interference. Similar to node attributes, link attributes can be considered as static ones in static LLNs not only because it is very challenging to update them in a real-time manner, but also it is quite time- and energy-consuming work. However, in dynamic LLNs, we may need to take these attributes as dynamic metrics and make use of Kim, et al. Expires January 5, 2009 [Page 9] =0C Internet-Draft Routing Metrics for LLNs July 2008 current real-time values whenever necessary. Values of dynamic metrics cannot be obtained easily. One way to get values of dynamic metrics is to use historical data and average them within a specified time window. 5.1. Bandwidth Bandwidth can be taken as a link capacity metric. It can be evaluated as nodes' communicational capability, too. =20 dmm> perhaps: dmm> Bandwidth can be also be used to represent a node's dmm> communication capability. dmm> Is that what you mean? It must be remembered that in case of wireless link, the link capacity is shared among nodes in a single wireless link. 5.2. Reliability (Quality) Link reliability can be measured by the Bit Error Rate (BER), Mean Time Between Failures (MTBF) or link churn defined as the rate at which links change between good and bad [I-D.levis-roll-protocols-survey]. Link reliability is closely related to node reliability especially in wireless LLNs. Two nodes which form a link affect directly to the link reliability as follows: if one node falls in a sleep mode or moves away beyond of the transmission range from the other node, the link vanishes away. dmm> s/vanishes away/vanishes/ dmm>=20 dmm> But more generally, I think what you are trying to say that dmm> if there if one (or both) end of a link either dies or dmm> moves, the link should be removed from routing. Correct? If dmm> so, that is sensible. If not, what did you have in mind? However, link reliability is also influenced by other factors like unexpected obstacles or temporary interference. Just like node reliability is critical, link reliability is also essential for routing given that most nodes have very short duty cycles. Change of link quality directly gives rise to that of network connectivity. =20 dmm> couldn't parse the last sentence. I'm guessing you mean to dmm> say something to the effect that "A change in link quality can dmm> effect network topology." Therefore, link quality may be taken into account as a critical routing metric. Increasing link and node reliability together enhances route robustness. Therefore, choosing reliable links and nodes during route establishment process improves robustness of the selected routes. 5.3. Propagation delay Propagation delay is the time taken for the packet to traverse the link from the source node to the target node. Path (route) latency is made up of nodes' latency and links!_ propagation delay on the path. =20 dmm> I think you mean: dmm> Path (route) latency is usually computed as the sum of the=20 dmm> latencies of the indivudal nodes along a the path. dmm>=20 dmm> also, note the !_=20 As mentioned earlier, it can be obtained by making average from historical data. dmm> I think you mean: dmm> As mentioned earlier, propogation delay can be obtained dmm> averagin historical data. dmm>=20 dmm> So where does this historical data reside? 6. Open issues Other items to be addressed in further revisions of this document include: Kim, et al. Expires January 5, 2009 [Page 10] =0C Internet-Draft Routing Metrics for LLNs July 2008 o Traffic flow requirement: selection of applicable routing metrics needs to be performed depending on application and traffic flow requirements. For example, when latency is not a matter at all, it is possible to remove latency related metrics in the objective function to calculate the routing path. As such, different applications or Service Level Agreement (SLA) might demand different routing metric combination for path calculation, which forms a different route. Moreover, some routing algorithm may support Multi-topology routing with the ability to compute routes based on the traffic flow requirements using different set of metrics. o Metric weights exploitation: weights for the listed metrics should be decided according to applications and data flows. =20 dmm> are you suggesting data-aware routing here? For example, latency critical applications in military scenarios SHOULD put a dmm> s/in military scenarios// dmm> (since this would be true in any latency critical application) high weight to latency metrics rather than resource metrics. On top of that, applicable metrics or optimized weights may need to be changed on demand. o Metrics related to security: Metrics that security is associated with need to be further considered. If a route is comprised of authenticated and authorized nodes for the data, then the route should be preferable. o Consideration of routing efficiency and stability: LLNs are highly constrained networks, thus it is hard to maintain many metrics for efficient routing due to resource demand and overhead. =20 dmm> maybe: dmm> Since LLNs are highly constrained networks, maintaining many dmm> different routing metrics is challenging. Routing should be lightweight. =20 dmm> again, 2119 language. should be v. SHOULD BE In addition, careful condition should be given to the dynamic nature of some metrics and their implication on routing stability. dmm> you mention this several times (rightfully so). It might be dmm> nice to have a citation for this. o Influence of network topology and density: Network topology and network density need to affect route construction in such a way that they need to give some input to metric decision. For example, star topology and mesh topology should employ different routing protocols. =20 dmm> why? should be made explict Obviously they need to adopt different routing metrics. =20 dmm> Again, why? should be made explict Similarly, network density in terms of average node degree needs to be considered when setting routing metrics and weights. Network size in terms of physical and total number of nodes needs to be taken into account, too. In addition, influence of network deployment on routing metrics should be further studied. dmm> I couldn't parse this last sentence (In addition, influence dmm> of network deployment on routing metrics should be further dmm> studied). 7. Security Considerations Routing metrics should be handled in a secure and trustful manner. For instance, a malicious node can not advertise falsely that it has Kim, et al. Expires January 5, 2009 [Page 11] =0C Internet-Draft Routing Metrics for LLNs July 2008 good metrics for routing and belong to the established path to have a chance to intercept packets. dmm> This section needs to be expanded. Let me know if you'd like dmm> me to contribute some text. 8. IANA Considerations This document requests no action by IANA. 9. Acknowledgements The authors would like to acknowledge the contributions of Dr. YoungJae Kim for his review and comments. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [I-D.ietf-roll-indus-routing-reqs] Networks, D. and P. Thubert, "Industrial Routing Requirements in Low Power and Lossy Networks", draft-ietf-roll-indus-routing-reqs-00 (work in progress), April 2008. [I-D.levis-roll-protocols-survey] Levis, P., Vasseur, J., and D. Culler, "Overview of Existing Routing Protocols for Low Power and Lossy Networks", draft-levis-roll-protocols-survey-00 (work in progress), May 2008. Kim, et al. Expires January 5, 2009 [Page 12] =0C Internet-Draft Routing Metrics for LLNs July 2008 Authors' Addresses Mijeom Kim (editor) Future Tech Lab., KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-6063 Fax: +82-2-526-5071 Email: mjkim@kt.com JP Vasseur (editor) Cisco Distinguished Engineer 11, Rue Camille Desmoulins L'Atlantis 92782 Issy Les Moulineaux France Email: jpv@cisco.com Hakjin Chong Future Tech Lab., KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-5070 Fax: +82-2-526-5071 Email: hjchong@kt.com Kim, et al. Expires January 5, 2009 [Page 13] =0C Internet-Draft Routing Metrics for LLNs July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Kim, et al. Expires January 5, 2009 [Page 14] =0C --wac7ysb48OaltWcw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjUF9QACgkQORgD1qCZ2Kd02ACaAyKCh0LUGAWn515BdYXdWFVl z04An2lCXjgOjISHZqLXkvK7j/bBEWmv =slpE -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- --===============0839899203== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0839899203==-- From roll-bounces@ietf.org Wed Sep 24 04:53:14 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7F028C170; Wed, 24 Sep 2008 04:53:14 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABEB13A68F8 for ; Wed, 24 Sep 2008 04:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TszRvsMWhOsQ for ; Wed, 24 Sep 2008 04:53:01 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by core3.amsl.com (Postfix) with ESMTP id A30CC3A69FD for ; Wed, 24 Sep 2008 04:53:00 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so1268739tib.25 for ; Wed, 24 Sep 2008 04:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=CK91cDNN6f+8O3MtN+RRaHNwbxnru9OfdtMtYDoSVhI=; b=J7CslnQ9JODfKgteKGvR5Xd6zJut7cXFrC5zRTdNNvGygji7l1pwb28xMYbuK6X34w sTalG/g0AmAgPsbmdC3zuOJ3iaJ4G3USTgChSrKi13KMRULM7A2+tyTNosTtnkcjMvX/ M8vE4LItEjg/ehkwuLOKtVFRV+yYjxV19abm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=FfYLn/aXHV5tKSr2JnBe47gpeNVgti4ldWY/8Lp6fxZ8jAbGwZPFxz15SwlDqZtBwn 7E59Ef/EdBMDViXMZ2MRMlQRJ4JSZJ02v31b9j0lcrGWkRPG9EKQJlyPufAhpcZYUuD+ s7rahzW7/Si1r6jbSvTkEOn0OaYy8V5ApTLPQ= Received: by 10.110.49.2 with SMTP id w2mr9232940tiw.43.1222257184693; Wed, 24 Sep 2008 04:53:04 -0700 (PDT) Received: by 10.110.46.5 with HTTP; Wed, 24 Sep 2008 04:53:04 -0700 (PDT) Message-ID: Date: Wed, 24 Sep 2008 20:53:04 +0900 From: "MiJeom Kim" To: "David Meyer" , roll@ietf.org In-Reply-To: <20080919212124.GA14414@1-4-5.net> MIME-Version: 1.0 References: <20080919212124.GA14414@1-4-5.net> Subject: Re: [Roll] Metric document: draft-mjkim-roll-routing-metrics-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0644883593==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0644883593== Content-Type: multipart/alternative; boundary="----=_Part_140688_21887504.1222257184528" ------=_Part_140688_21887504.1222257184528 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Dave, I really appreciate your kind and detail comments. Mostly I agree with you in your opinion. However, there are still things I'd like to discuss. See the red arrows. (So if there is no red arrow, your comments will be reflected in the next revision.) Thank you. Mijeom. On Sat, Sep 20, 2008 at 6:21 AM, David Meyer wrote: > On Thu, Sep 18, 2008 at 07:21:16AM +0200, JP Vasseur wrote: > > Dear all, > > > > It might be a good time to start the discussion on > > draft-mjkim-roll-routing-metrics-00. As pointed out during the meeting in > > Dublin, this is a very first draft and the idea was to start with a large > > set of possible metrics. We all know that many of the proposed metrics > may > > not be realistic especially in large scale networks (we learnt from the > past > > with ARPANET !) but again the idea was to start listing all potential > > candidates and go from there. > > > > All, > > Nice start. I've made several comments (both types, > avoiding editorial where possible) in-line below. Search > for dmm> > > Thnx, > > Dave > > > > Networking Working Group M. Kim, Ed. > Internet-Draft KT > Intended status: Standards Track JP. Vasseur, Ed. > Expires: January 5, 2009 Cisco Systems > H. Chong > KT > July 4, 2008 > > > Routing Metrics used for Path Calculation in Low Power and Lossy > Networks > draft-mjkim-roll-routing-metrics-00 > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on January 5, 2009. > > Abstract > > This document specifies routing metrics used in path calculation for > Routing Over Low power and Lossy networks (ROLL). Low power and > Lossy Networks (LLNs) have unique characteristics compared with > traditional wired networks or even with similar ones such as mobile > ad-hoc networks as indicated in several application-specific > requirements documents. Since typical IGP routing metrics such as > hop counts or link metrics are not sufficient for LLNs, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > dmm> > dmm> might give a sentence or two about why traditional IGP > dmm> metrics aren't sufficient in the LLN context > ===> I think the sentence "LLNs have unique characteristics" is the > reason. And this is the abstract, so I omitted all the details. However, > it's not difficult to add some specific reasons such as resource > constraints, so if you still think it's better to add, let me know. > this document > specifies a new set of required link and node metrics suitable to > > > > Kim, et al. Expires January 5, 2009 [Page 1] > > Internet-Draft Routing Metrics for LLNs July 2008 > > > LLNs. > > > Table of Contents > > 1. Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 4. Node attributes . . . . . . . . . . . . . . . . . . . . . . . 5 > 4.1. Computational resources . . . . . . . . . . . . . . . . . 6 > 4.2. Residual Energy . . . . . . . . . . . . . . . . . . . . . 6 > 4.3. Current workload . . . . . . . . . . . . . . . . . . . . . 7 > 4.4. Node latency . . . . . . . . . . . . . . . . . . . . . . . 7 > 4.5. Data Aggregation attribute . . . . . . . . . . . . . . . . 7 > 4.6. Node degree . . . . . . . . . . . . . . . . . . . . . . . 8 > 4.7. Dynamicity . . . . . . . . . . . . . . . . . . . . . . . . 9 > 4.8. Node reliability . . . . . . . . . . . . . . . . . . . . . 9 > > 5. Link attributes . . . . . . . . . . . . . . . . . . . . . . . 9 > 5.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 10 > 5.2. Reliability (Quality) . . . . . . . . . . . . . . . . . . 10 > 5.3. Propagation delay . . . . . . . . . . . . . . . . . . . . 10 > > 6. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 > > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 > > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 > > 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 > > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 > 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 > 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 > Intellectual Property and Copyright Statements . . . . . . . . . . 14 > > > > > > > > > > > > Kim, et al. Expires January 5, 2009 [Page 2] > > Internet-Draft Routing Metrics for LLNs July 2008 > > > 1. Note > > Some of the routing metrics defined in this document may be subject > to change or may even be removed in light of the routing requirements > currently being specified by the Routing Over Low power and Lossy > networks (ROLL) Working Group. For the sake of illustration, some > metrics are only meaningful in routing protocols that fall into the > category of Distance Vector. Since the Working Group has not yet > determined which routing protocol will be chosen for Low power and > Lossy Networks (LLNs), it is not yet possible to determine whether > such metrics will be required. Conversely, other metrics may be > further required depending on which routing protocol is selected by > the Working Group. > > > 2. Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", 'RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > o Access point: An infrastructure device that connects the low power > and lossy networks to the backbone network like the Internet, > mostly via access networks. > > o Data sink: A device which collects data from nodes in a LLN. > > o Dynamic LLN: Low power and Lossy Network where some nodes are > mobile. > > o ROLL: Routing Over Low-power and Lossy networks. > > o Static LLN: Low power and Lossy Network where all nodes are > static, not mobile. > > dmm> looks likek most of this can be replaces with a citation to > dmm> draft-vasseur-roll-terminology-01.txt > ===> Only ROLL is in the draft, so I think it's better to leave them for > now. > > 3. Introduction > > This document specifies routing metrics used in path calculation for > dmm> s/used/to be used/ (or maybe "for use") > Routing Over Low power and Lossy networks (ROLL). Low power and > Lossy Networks (LLNs) have unique characteristics compared with > traditional wired networks or even with similar ones such as mobile > ad-hoc networks as indicated in several application-specific > requirements documents. Since typical IGP routing metrics such as > hop counts or link metrics are not sufficient for LLNs, this document > specifies a new set of required link and node metrics suitable to > LLNs. > dmm> do you really want to say the the metrics are "required"? > dmm> How about s/required// > > > Kim, et al. Expires January 5, 2009 [Page 3] > > Internet-Draft Routing Metrics for LLNs July 2008 > > > Routing metrics can be classified according to the following set of > characteristics: > > - Link versus Node metrics > > - Qualitative versus quantitative > > - Dynamic or static > > Historically, IGP such as OSPF and IS-IS have been using quantitative > dmm> citations for OSPF and IS-IS > static link metrics. Other mechanisms such as Multiprotocol Label > Switching (MPLS) Traffic Engineering (TE) make use of other link > dmm> again, citation for MPLS/MPLS-TE > attributes such as the available reserved bandwidth, affinities and > so on to compute constrained shortest path for Traffic Engineering > s/path/paths/ > Label Switched Paths (TE LSPs). > > It must be noted that the use of dynamic metrics is not new and has > been experimented in ARPANET 2, with a moderate success. Indeed, a > dmm> citation for ARPANET 2 > very careful care must be given to the use of dynamic metrics that > may lead to potential routing instabilities. > > In LLNs, it is required to take into account various node constraints > when calculating the desirable path. Node metrics include the node's > resources like memory, energy and CPU (computational power). Other > node attributes such as the ability to act as an aggregator (node > capable of performing data aggregation) may be of interest. > Additionally, work load, transmission range and dynamicity (mobility, > duty cycle, etc) may need to be taken into account. Link attributes > include propagation delay, reliability (quality) and available > bandwidth. > > By contrast with the current Internet, LLNs are characterized by > their dynamic nature, which not only applies to the link but also to > the nodes in the networks. Thus, it is required to specify various > dynamic metrics. For instance, even though a wireless sensor network > topology is static in absence of failure, nodes' workload and > resource such as residual energy and available memory are changing > continuously and may have to be taken into account during the path > computation. Similarly, link attributes including latency and > reliability are not static because moving obstacles can appear at any > time. Thus, they are real-time parameters. That being said, very > careful attention must be given to highly dynamic parameters that > affect routing decision in order to preserve the routing stability. > Furthermore, it is quite time- and energy-consuming process to update > these dynamic metrics in a regular basis. Therefore, we may regard > them as static metrics in static LLNs to cut off overhead by > compromising accuracy. > > dmm> This last sentence is hard to understand. Maybe: > dmm> "Therefore we might treat such dynamic metrics as static > dmm> metrics in order to reduce computational overhead and > dmm> bandwidth utilization. Of course, this comes with a cost, > dmm> namely, reduced metric accuracy. > > > > > Kim, et al. Expires January 5, 2009 [Page 4] > > Internet-Draft Routing Metrics for LLNs July 2008 > > > Reliability is an example of quality parameter. However, to be > routing metrics for path calculation, quality parameters MUST be > transformed to quantity values. Some criteria SHOULD be set to make > the quality parameters appear in quantity forms. Quantity form can > be numbers or levels. > > This document specifies a set of link and nodes metrics that can be > used to compute the optimal path within a LLN. Furthermore, some > link or node attributes (e.g. level of link reliability, energy > remaining on the node) can be used to perform constraint-based > routing. It is not required to use all the metrics and attributes > specified in this document. A particular implementation MAY use a > subset or all of the metrics defined in this document. > > Note: finding the shortest path is not always best in LLNs since a > reliable path is more preferable. !oThe optimal path!+/- here means > the best path having regard to constraints. The term !oconstrained > shortest path!+/- may be used instead. > > The specification of the objective function used to compute the path > is out of the scope of this document. > > Note: in the first revision of this document, link and node metrics > are defined with no packet format or suggestions to encode the data. > This will be determined in a further revision of this document. > > > 4. Node attributes > > Most node attributes may be taken as static attributes in LLNs since > it might require quite amount of resources to get exact values of the > attributes and update them periodically. Furthermore, the use of > dynamic metrics is subject to routing instabilities and must be used > dmm> s/is subject/can cause/ > with extreme care. However, critical parameters like residual power > dmm> you might want to consider the total power of a given path > dmm> as well (especially when optimizing network lifetime). > dmm> See, e.g., "Wireless sensor networks: a survey", > dmm> I.F. Akyildiz, et. al., Computer Networks (38), 2002,, 393-422. > ===> Of course, considering a given path will make better route selection > possible than considering only individual nodes and links. It applies to not > only power but also most other metrics, I believe. However, it's very > challenging to consider paths in LLNs due to resource constraints and there > are implementation issues. We may need to delay this issue until path > calculation using the metrics is discussed. > might need to be considered dynamic and monitored continuously in > some scenarios. Implementation MUST make use of multi-threshold > > dmm> s/Implmentation/An implementation/ > > scheme rather than fine granular metric update so as to avoid > > dmm> The term "multi-threshold scheme" hasn't been described > > constant routing changes. > > In LLNs, it is not uncommon to have highly heterogeneous nodes in > term of capabilities (e.g node being battery operated or not, amount > of memory, !|) and functionalities. More capable and stable nodes > can assist the most constrained ones for routing packets, which > results in extension of network lifetime and efficient network > operations. Therefore, node metrics SHOULD be carefully maintained > and utilized for routing. This has the following strong implication > referred to as constrained-based routing whereby the computed path > may not be the shortest path according to some specified metrics. > > dmm> maybe: "This implies that constraint-based routing will be > dmm> used in some cases." > > Kim, et al. Expires January 5, 2009 [Page 5] > > Internet-Draft Routing Metrics for LLNs July 2008 > > > Mechanisms must be designed to ensure lack of routing loops in the > presence of constrained based routing with a non connection oriented > environment. > dmm> "Routing should be loop-free" (?). In addition, what kind of > dmm> micro-loops (if any) are to be tollerated? I would imagine > dmm> that this is application specific. However, there is a > dmm> convergence time v. energy utilization question here > dmm> (possibly also application specifc). > > 4.1. Computational resources > > Memory and CPU resources can be considered as computational ones and > are potentially important routing metrics in LLNs because in some > environments nodes are resource constraint. Resource-awareness > SHOULD be employed to routing protocols strictly or loosely > considering trade-off between cost and benefit. > > 4.2. Residual Energy > > Low power is one of the most distinguished features of LLNs, so > residual energy MUST be considered as a pivotal metric in > environments where nodes are battery powered. Residual energy should > be taken as a relative value considering statistical node lifetime > and other conditions like the role of the node in the network. For > example, if the node's expected lifetime is 5 years and the remaining > energy is only one fifth, then the energy is quite precious resources > to the node. In such cases, the routing protocol decision should be > > dmm> so "relative" above means relative to other resources that > dmm> are considered "more important"? How would we quantify that? > ===> Initially, I meant with "relative" that the residual energy should > not be evaluated with absolute values. For example, both devices A and B > have the same amount of residual energy to last 1 year. A is essential in > the network such that the absence of the node causes network partition and A > is neither rechargeable nor replaceable. However, B is easily replaceable. > Then, 1 year of the power lifetime is a relative value to both devices. There > may be several ways to quantify that even though these are challenging. When > a device is produced or deployed, some parameters indicating the device is > rechargeable or replaceable easily or not can be set manually. Or some > parameters indicating the role of the device in the network can be set by > the device itself using context aware capability such that it can recognize > itself as a pivotal device to maintain network connectivity. > such that potentially a suboptimal path would be used for some > traffic so as to increase the network life duration. Furthermore, in > > dmm> this implies that the routing protocol needs (must?) have a > dmm> global view of the residual energy of the network (likely > dmm> the rate at which certain devices are being dischared as > dmm> well, and which ones are battery powered and which ones are > dmm> mains powered). Is that what is intended? > ===> The routing protocol does not need to have a global view, but it just > needs to choose the best next hop among possible candidates. case absence of the node affects the network connectivity critically, the node SHOULD be avoided to save its power. Hence, whenever possible, the node should not be selected as a router (an intermediate node to deliver data), thus the support for constrained- based routing is needed. If the battery can be simply charged or the node can be easily replaced with another same kind of node, then it is not really a matter to use up the battery. Such information should be defined as a node attribute to be used in combination with the energy level. Algorithms defining how such metrics and attributes should be combined are outside of the scope of this document. Generally, the residual energy should be taken as a dynamic metric. Most battery operated devices have ability to estimate the remaining energy [I-D.ietf-roll-indus-routing-reqs]. However, initial energy status can be considered as a static metric in some situations where monitoring current energy status demands quite resources. Simply categorizing devices into two classes, main-powered and battery- powered, can be good enough to select a routing path for highly constrained scenarios, which contributes to prolonging network lifetime. To maximize network lifetime, it is essential to maintain energy balance among nodes in LLNs. dmm> ^^^^^^^^^^^^ dmm> how is "energy balance" defined? ===> I may say the amounts of residual energy of all nodes in the network are fairly even. Kim, et al. Expires January 5, 2009 [Page 6] Internet-Draft Routing Metrics for LLNs July 2008 4.3. Current workload Workload of a node is somewhat difficult to be measured and compared. It is also difficult to express the workload in a quantitative form. However, it could be an important metric to select a path in LLNs, especially when data processing along the data path is required or queuing delays must be minimized for highly sensitive traffic. Putting the workload as a "heavy" or "light" one bit metric can give a good advice to select a path for routing, thus providing a sufficient level of granularity, similarly to the "overload" bit used in protocols such as IS-IS. An implementation may then decide to dmm> might be useful to cite documents that define the IS-IS dmm> overload bit. exclude from its routes any node with a "heavy" value for workload unless there is no alternative. 4.4. Node latency Node latency is the time span from the arrival time to the departure time of a given packet at a node. It is primarily made up of packet processing time and packet transmission time. Node latency is highly correlated with other metrics. For instance, heavy workload increases node latency while enough computational resources can reduce it. Therefore, in some LLNs where available resources and current workload can be measured, they can facilitate to estimate node latency or may substitute it. 4.5. Data Aggregation attribute Some nodes may sense (get) similar or same data if the nodes are dmm> s/(get) similar or same /or receive the same (or similar) located in a close area due to data correlation. dmm> BTW, this is frequently called "overlap" in the dmm> literature. See e.e., "Adaptive Protocols for Information dmm> Dissemination in Wireless Sensor Networks", Joanna Kulik, dmm> Wendi Rabiner, Hari Balakrishnan,1999 dmm> http://www.cs.washington.edu/education/courses/590es/01au/papers/2.pdf Thus, data aggregation/fusion can be performed. Data fusion involves more dmm> s/can be performed/may be possible/ complicated processing to improve accuracy of the output data while data aggregation mostly aims to reduce the amount of data. Especially in urban applications where sensor nodes collect dmm> s/Especially/Sensing overlap is common/ ===> Even though "overlap" is frequently used in the literature, we might need a definition for the term if we want to use it here. I cannot see any reason to use the term "overlap" here, though. And the suggested substitution results in connection of two sentences using comma, which is incorrect. environmental information and send it to a data sink, quite a number of sensor nodes sense same kind or same value of data. In the Figure 1, let us assume that three nodes A, B and C need to send sensed data to the data sink. Node A sensed "xyz" and sent this data to node C. Since C also sensed same data, it has no additional information from node A. However, because the data node B sent is "xqz", node C aggregates this data with its own data "xyz" resulting in "xyqz". Therefore, node C sends "xyqz" to the data sink. In this example, each node's data requires 3 bytes. If no aggregation is performed, node C needs to send 9 byte data to the sink, but C only sends 4 bytes thanks to data aggregation. Kim, et al. Expires January 5, 2009 [Page 7] Internet-Draft Routing Metrics for LLNs July 2008 A B |------| |------| | xyz | | xqz | |______| |______| \ / \ / \ C / sink |------| xyqz |------| | xyz |-----------| | |______| |______| Figure 1: Data aggregation Some applications MAY make use of the aggregation node attribute in their routing decision so as to minimize the amount of traffic on the network, thus potentially increasing its life time in battery operated environments. dmm> So this is a form of data-aware routing. How far to we think dmm> we need to go in this direction? I did notice that dmm> I-D.ietf-roll-indus-routing-reqs also suggests the need for dmm> data-aware routing. ===> I do agree that data-aware routing is very challenging especially with resource constraints. As I mentioned below, we need to make the data aggregation mechanism as simple as possible to reduce overhead. Further discussion is needed. dmm> dmm> For a good discussion of (some of the) issuess, see, e.g., dmm> dmm> "Directed Diffusion: A scalable and robust communication dmm> paradigm for sensor networks", Ramesh Govindan, Deborah dmm> Estrin, 2000 http://netweb.usc.edu/estrin/papers/diffusion.ps dmm> dmm> (its just one such approach) To make data aggregation possible, the routing protocol needs to capture the time and location dependent correlation among sensed data from nodes on the possible routes, which is quite challenging. Obtaining correlation structure also demands high resource (energy) consumption and in-network processing itself may have high complexity. Consequently, in most applications, data aggregation may not be adopted for routing. However, simply choosing nodes that have the same kind of sensors with the source node can increase the chance to aggregate data, so it can be helpful for path formation regardless of having data-aware routing capability. dmm> nice heuristic. Do we have a citation that examines the dmm> use of this heuristic? ===> No, unfortunately we do not have a citation. This is just an idea. Applications where high directional data flow is expected in a regular basis may take advantage of data aggregation supported routing. 4.6. Node degree Node degree is the number of neighbors that can send a message to the node directly. In other words, neighbors are nodes located within the transmission range of the node. Generally, a high node degree can be helpful for quick route recovery when the next hop node on the route cannot be accessible. Therefore, it may be beneficial to choose a node with a high degree to construct a route. On the contrary, a node with a high degree has a high possibility to have heavy workload in a busy network. Therefore, node degree has to be carefully utilized in routing decision. dmm> basically this is an "amplication effect" [RFC 3439] ===> you mean amplification? Actually I have not seen the reference. Do you think it's better to include the citation? Kim, et al. Expires January 5, 2009 [Page 8] Internet-Draft Routing Metrics for LLNs July 2008 4.7. Dynamicity Node dynamicity can be measured by many different factors such as mobility, transmission range, duty cycle, and the rate at which node joins and leaves the network. Node dynamicity directly affects the network topology and connectivity, which in turn may trigger route reestablishment process. For that reason, node dynamicity needs to be monitored and presented in a quantity form utilizing a well dmm> ^^^^^^^^ dmm> Do you mean quantative (v. qualatative)? defined objective function. Thus, less dynamic nodes should be preferred for path selection. dmm> is that true, even if a more "dynamic" path has better (optimizes) dmm> residual energy or some other metric of interest? i.e., is dmm> the statement too general? ===> Dynamicity is just one metric. And we have more metrics to be used in path calculation. Thus, we need a weight for each metric. The sentence does not say that dynamicity is the most important metric over other metrics. In the most constrained LLN environments, classifying nodes into only static and dynamic can be very helpful in routing decision. dmm> Maybe something like this: dmm> "In the most constrained LLN environments, the simple heuristic dmm> of classifying nodes into static or dynamic can be very dmm> helpful in routing decision." dmm> I think that is what you mean...if not, then ? Note that this node metric may either be static or dynamic. In the later case, the network administrator will have to use consistent metric values. 4.8. Node reliability Node reliability is deeply related to node dynamicity such that node reliability deteriorates as node dynamicity increases. However, node reliability is a wider concept than node dynamicity since node dmm> s/wider/more general/ reliability is influenced by more factors. For example, node's unexpected failure cuts off node reliability, but it is not really dmm> s/cuts of node/reduces a node's/ (I think that's what you mean) related to node dynamicity. Therefore, node dynamicity metric can be covered by node reliability metric. However, it is very challenging to estimate or monitor node reliability. A specific function needs to be defined to get values of the reliability metric from a variety of features affecting node reliability. Node reliability is a crucial metric in LLNs compared with in other conventional or even wireless networks considering that nodes in LLNs may stay in a sleep mode most of the time. dmm> maybe : dmm> "Node reliability can be a crucial metric in LLNs, since dmm> nodes in LLNs may stay in a sleep mode most of the time." dmm> Again, I think that's what you mean. A sleeping node should dmm> question here about 2119 language. SHOULD NOT v. should not ===> I think "should not" is okay for now. Need further discussion. not be an intermediate node to deliver a packet, thus status of a node must be monitored or can be anticipated. Additionally, residual dmm> s/can be anticipated/should be predictable/ energy of a node should be predictable not to make the node suddenly die during routing process due to battery out. Nodes on the chosen path for routing should be reliable. 5. Link attributes There are several dynamic link attributes especially in wireless LLNs. Even in case of static LLNs where nodes are stationary, there are always variables like appearance of obstacles and signal interference. Similar to node attributes, link attributes can be considered as static ones in static LLNs not only because it is very challenging to update them in a real-time manner, but also it is quite time- and energy-consuming work. However, in dynamic LLNs, we may need to take these attributes as dynamic metrics and make use of Kim, et al. Expires January 5, 2009 [Page 9] Internet-Draft Routing Metrics for LLNs July 2008 current real-time values whenever necessary. Values of dynamic metrics cannot be obtained easily. One way to get values of dynamic metrics is to use historical data and average them within a specified time window. 5.1. Bandwidth Bandwidth can be taken as a link capacity metric. It can be evaluated as nodes' communicational capability, too. dmm> perhaps: dmm> Bandwidth can be also be used to represent a node's dmm> communication capability. dmm> Is that what you mean? It must be remembered that in case of wireless link, the link capacity is shared among nodes in a single wireless link. 5.2. Reliability (Quality) Link reliability can be measured by the Bit Error Rate (BER), Mean Time Between Failures (MTBF) or link churn defined as the rate at which links change between good and bad [I-D.levis-roll-protocols-survey]. Link reliability is closely related to node reliability especially in wireless LLNs. Two nodes which form a link affect directly to the link reliability as follows: if one node falls in a sleep mode or moves away beyond of the transmission range from the other node, the link vanishes away. dmm> s/vanishes away/vanishes/ dmm> dmm> But more generally, I think what you are trying to say that dmm> if there if one (or both) end of a link either dies or dmm> moves, the link should be removed from routing. Correct? If dmm> so, that is sensible. If not, what did you have in mind? However, link reliability is also influenced by other factors like unexpected obstacles or temporary interference. Just like node reliability is critical, link reliability is also essential for routing given that most nodes have very short duty cycles. Change of link quality directly gives rise to that of network connectivity. dmm> couldn't parse the last sentence. I'm guessing you mean to dmm> say something to the effect that "A change in link quality can dmm> effect network topology." Therefore, link quality may be taken into account as a critical routing metric. Increasing link and node reliability together enhances route robustness. Therefore, choosing reliable links and nodes during route establishment process improves robustness of the selected routes. 5.3. Propagation delay Propagation delay is the time taken for the packet to traverse the link from the source node to the target node. Path (route) latency is made up of nodes' latency and links!_ propagation delay on the path. dmm> I think you mean: dmm> Path (route) latency is usually computed as the sum of the dmm> latencies of the indivudal nodes along a the path. ===> No, I mean path latency is the sum of all node latencies (section 4.4) and all link propagation delays (senction 5.3) along the path. If the original sentence is hard to read, I may change it. dmm> dmm> also, note the !_ As mentioned earlier, it can be obtained by making average from historical data. dmm> I think you mean: dmm> As mentioned earlier, propogation delay can be obtained dmm> averagin historical data. dmm> dmm> So where does this historical data reside? ===> each node should maintain the data. It does not need to keep all the historical data but just maintain an average. However, I also think that it costs high and has not much benefit since propagation delay is mostly negligible. Need further discussion. 6. Open issues Other items to be addressed in further revisions of this document include: Kim, et al. Expires January 5, 2009 [Page 10] Internet-Draft Routing Metrics for LLNs July 2008 o Traffic flow requirement: selection of applicable routing metrics needs to be performed depending on application and traffic flow requirements. For example, when latency is not a matter at all, it is possible to remove latency related metrics in the objective function to calculate the routing path. As such, different applications or Service Level Agreement (SLA) might demand different routing metric combination for path calculation, which forms a different route. Moreover, some routing algorithm may support Multi-topology routing with the ability to compute routes based on the traffic flow requirements using different set of metrics. o Metric weights exploitation: weights for the listed metrics should be decided according to applications and data flows. dmm> are you suggesting data-aware routing here? ===> Yes, but trade-off should be further discussed. For example, latency critical applications in military scenarios SHOULD put a dmm> s/in military scenarios// dmm> (since this would be true in any latency critical application) ===> I know what you mean, but this is an example. Thus I think it's better to have "in military scenarios" since it helps to understand the example. high weight to latency metrics rather than resource metrics. On top of that, applicable metrics or optimized weights may need to be changed on demand. o Metrics related to security: Metrics that security is associated with need to be further considered. If a route is comprised of authenticated and authorized nodes for the data, then the route should be preferable. o Consideration of routing efficiency and stability: LLNs are highly constrained networks, thus it is hard to maintain many metrics for efficient routing due to resource demand and overhead. dmm> maybe: dmm> Since LLNs are highly constrained networks, maintaining many dmm> different routing metrics is challenging. Routing should be lightweight. dmm> again, 2119 language. should be v. SHOULD BE ===> I prefer should be for now. In addition, careful condition should be given to the dynamic nature of some metrics and their implication on routing stability. dmm> you mention this several times (rightfully so). It might be dmm> nice to have a citation for this. ===> I do not have any reference here. To me it is quite obvious. But if you think a citation is still needed, I will try to find. o Influence of network topology and density: Network topology and network density need to affect route construction in such a way that they need to give some input to metric decision. For example, star topology and mesh topology should employ different routing protocols. dmm> why? should be made explict ===> Actually, I intended to remove this final bullet, but accidentally I didn't delete in the first draft. I will remove it for the next submission. Obviously they need to adopt different routing metrics. dmm> Again, why? should be made explict Similarly, network density in terms of average node degree needs to be considered when setting routing metrics and weights. Network size in terms of physical and total number of nodes needs to be taken into account, too. In addition, influence of network deployment on routing metrics should be further studied. dmm> I couldn't parse this last sentence (In addition, influence dmm> of network deployment on routing metrics should be further dmm> studied). 7. Security Considerations Routing metrics should be handled in a secure and trustful manner. For instance, a malicious node can not advertise falsely that it has Kim, et al. Expires January 5, 2009 [Page 11] Internet-Draft Routing Metrics for LLNs July 2008 good metrics for routing and belong to the established path to have a chance to intercept packets. dmm> This section needs to be expanded. Let me know if you'd like dmm> me to contribute some text. ===> I would very appreciate if you contribute. 8. IANA Considerations This document requests no action by IANA. 9. Acknowledgements The authors would like to acknowledge the contributions of Dr. YoungJae Kim for his review and comments. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [I-D.ietf-roll-indus-routing-reqs] Networks, D. and P. Thubert, "Industrial Routing Requirements in Low Power and Lossy Networks", draft-ietf-roll-indus-routing-reqs-00 (work in progress), April 2008. [I-D.levis-roll-protocols-survey] Levis, P., Vasseur, J., and D. Culler, "Overview of Existing Routing Protocols for Low Power and Lossy Networks", draft-levis-roll-protocols-survey-00 (work in progress), May 2008. Kim, et al. Expires January 5, 2009 [Page 12] Internet-Draft Routing Metrics for LLNs July 2008 Authors' Addresses Mijeom Kim (editor) Future Tech Lab., KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-6063 Fax: +82-2-526-5071 Email: mjkim@kt.com JP Vasseur (editor) Cisco Distinguished Engineer 11, Rue Camille Desmoulins L'Atlantis 92782 Issy Les Moulineaux France Email: jpv@cisco.com Hakjin Chong Future Tech Lab., KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-5070 Fax: +82-2-526-5071 Email: hjchong@kt.com Kim, et al. Expires January 5, 2009 [Page 13] Internet-Draft Routing Metrics for LLNs July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Kim, et al. Expires January 5, 2009 [Page 14] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjUF9QACgkQORgD1qCZ2Kd02ACaAyKCh0LUGAWn515BdYXdWFVl z04An2lCXjgOjISHZqLXkvK7j/bBEWmv =slpE -----END PGP SIGNATURE----- _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_Part_140688_21887504.1222257184528 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdiBkaXI9Imx0ciI+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Ik1BUkdJTjogMGNtIDBj bSAwcHQ7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBURVhULUFVVE9TUEFDRTogaWRlb2dyYXBoLW51 bWVyaWM7IFRFWFQtQUxJR046IGxlZnQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4iIGFs aWduPSJsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9O VC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiCxvLiyOyBtc28tZm9udC1rZXJu aW5nOiAwcHQiPjxmb250IHNpemU9IjIiPkhpJm5ic3A7RGF2ZSwgPC9mb250Pjwvc3Bhbj48L3A+ Cgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgV09SRC1C UkVBSzoga2VlcC1hbGw7IFRFWFQtQVVUT1NQQUNFOiBpZGVvZ3JhcGgtbnVtZXJpYzsgVEVYVC1B TElHTjogbGVmdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgYWxpZ249ImxlZnQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogsby4 sjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ILG8uLI7IG1zby1mb250LWtlcm5pbmc6IDBwdCI+PGZv bnQgc2l6ZT0iMiI+Jm5ic3A7PC9mb250Pjwvc3Bhbj48L3A+Cgo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgV09SRC1CUkVBSzoga2VlcC1hbGw7IFRFWFQt QVVUT1NQQUNFOiBpZGVvZ3JhcGgtbnVtZXJpYzsgVEVYVC1BTElHTjogbGVmdDsgbXNvLXBhZ2lu YXRpb246IHdpZG93LW9ycGhhbiIgYWxpZ249ImxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogsby4sjsgbXNvLWJpZGktZm9udC1mYW1p bHk6ILG8uLI7IG1zby1mb250LWtlcm5pbmc6IDBwdCI+PGZvbnQgc2l6ZT0iMiI+SSByZWFsbHkg YXBwcmVjaWF0ZSB5b3VyIGtpbmQgYW5kIGRldGFpbCZuYnNwO2NvbW1lbnRzLiBNb3N0bHkgSSBh Z3JlZSB3aXRoIHlvdSZuYnNwO2luIHlvdXIgb3Bpbmlvbi4mbmJzcDtIb3dldmVyLCB0aGVyZSBh cmUgc3RpbGwgdGhpbmdzJm5ic3A7SSYjMzk7ZCBsaWtlIHRvJm5ic3A7ZGlzY3Vzcy4gU2VlIHRo ZSByZWQgYXJyb3dzLjwvZm9udD48L3NwYW4+PC9wPgoKPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBURVhULUFVVE9T UEFDRTogaWRlb2dyYXBoLW51bWVyaWM7IFRFWFQtQUxJR046IGxlZnQ7IG1zby1wYWdpbmF0aW9u OiB3aWRvdy1vcnBoYW4iIGFsaWduPSJsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZP TlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiCx vLiyOyBtc28tZm9udC1rZXJuaW5nOiAwcHQiPjxmb250IHNpemU9IjIiPihTbyBpZiB0aGVyZSBp cyBubyByZWQgYXJyb3csIHlvdXIgY29tbWVudHMgd2lsbCBiZSByZWZsZWN0ZWQgaW4gdGhlIG5l eHQgcmV2aXNpb24uKTwvZm9udD48L3NwYW4+PC9wPgoKPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBURVhULUFVVE9T UEFDRTogaWRlb2dyYXBoLW51bWVyaWM7IFRFWFQtQUxJR046IGxlZnQ7IG1zby1wYWdpbmF0aW9u OiB3aWRvdy1vcnBoYW4iIGFsaWduPSJsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZP TlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiCx vLiyOyBtc28tZm9udC1rZXJuaW5nOiAwcHQiPjxmb250IHNpemU9IjIiPiZuYnNwOzwvZm9udD48 L3NwYW4+PC9wPgoKPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iTUFSR0lOOiAwY20gMGNt IDBwdDsgV09SRC1CUkVBSzoga2VlcC1hbGw7IFRFWFQtQVVUT1NQQUNFOiBpZGVvZ3JhcGgtbnVt ZXJpYzsgVEVYVC1BTElHTjogbGVmdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgYWxp Z249ImxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05U LUZBTUlMWTogsby4sjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ILG8uLI7IG1zby1mb250LWtlcm5p bmc6IDBwdCI+PGZvbnQgc2l6ZT0iMiI+VGhhbmsgeW91LjwvZm9udD48L3NwYW4+PC9kaXY+Cgo8 ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBXT1JELUJS RUFLOiBrZWVwLWFsbDsgVEVYVC1BVVRPU1BBQ0U6IGlkZW9ncmFwaC1udW1lcmljOyBURVhULUFM SUdOOiBsZWZ0OyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuIiBhbGlnbj0ibGVmdCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiCxvLiy OyBtc28tYmlkaS1mb250LWZhbWlseTogsby4sjsgbXNvLWZvbnQta2VybmluZzogMHB0Ij48Zm9u dCBzaXplPSIyIj5NaWplb20uPC9mb250Pjwvc3Bhbj48Zm9udCBzaXplPSIyIj48YnI+Cjxicj48 L2ZvbnQ+PC9kaXY+CjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBTYXQsIFNlcCAyMCwgMjAw OCBhdCA2OjIxIEFNLCBEYXZpZCBNZXllciA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1h aWx0bzpkbW1AMS00LTUubmV0Ij5kbW1AMS00LTUubmV0PC9hPiZndDs8L3NwYW4+IHdyb3RlOjxi cj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iUEFERElORy1MRUZUOiAx ZXg7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IEJPUkRFUi1MRUZUOiAjY2NjIDFweCBzb2xp ZCI+CjxkaXYgY2xhc3M9IkloMkUzZCI+T24gVGh1LCBTZXAgMTgsIDIwMDggYXQgMDc6MjE6MTZB TSArMDIwMCwgSlAgVmFzc2V1ciB3cm90ZTo8YnI+Jmd0OyBEZWFyIGFsbCw8YnI+Jmd0Ozxicj4m Z3Q7IEl0IG1pZ2h0IGJlIGEgZ29vZCB0aW1lIHRvIHN0YXJ0IHRoZSBkaXNjdXNzaW9uIG9uPGJy PiZndDsgZHJhZnQtbWpraW0tcm9sbC1yb3V0aW5nLW1ldHJpY3MtMDAuIEFzIHBvaW50ZWQgb3V0 IGR1cmluZyB0aGUgbWVldGluZyBpbjxicj4KJmd0OyBEdWJsaW4sIHRoaXMgaXMgYSB2ZXJ5IGZp cnN0IGRyYWZ0IGFuZCB0aGUgaWRlYSB3YXMgdG8gc3RhcnQgd2l0aCBhIGxhcmdlPGJyPiZndDsg c2V0IG9mIHBvc3NpYmxlIG1ldHJpY3MuIFdlIGFsbCBrbm93IHRoYXQgbWFueSBvZiB0aGUgcHJv cG9zZWQgbWV0cmljcyBtYXk8YnI+Jmd0OyBub3QgYmUgcmVhbGlzdGljIGVzcGVjaWFsbHkgaW4g bGFyZ2Ugc2NhbGUgbmV0d29ya3MgKHdlIGxlYXJudCBmcm9tIHRoZSBwYXN0PGJyPgomZ3Q7IHdp dGggQVJQQU5FVCAhKSBidXQgYWdhaW4gdGhlIGlkZWEgd2FzIHRvIHN0YXJ0IGxpc3RpbmcgYWxs IHBvdGVudGlhbDxicj4mZ3Q7IGNhbmRpZGF0ZXMgYW5kIGdvIGZyb20gdGhlcmUuPGJyPjxicj48 YnI+PGJyPjwvZGl2PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0FsbCw8YnI+PGJyPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO05pY2Ugc3RhcnQuIEkmIzM5O3ZlIG1hZGUgc2V2ZXJhbCBj b21tZW50cyAoYm90aCB0eXBlcyw8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YXZvaWRp bmcgZWRpdG9yaWFsIHdoZXJlIHBvc3NpYmxlKSBpbi1saW5lIGJlbG93LiBTZWFyY2g8YnI+CiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2ZvciBkbW0mZ3Q7PGJyPjxicj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtUaG54LDxicj48YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RGF2 ZTxicj48YnI+PGJyPjxicj5OZXR3b3JraW5nIFdvcmtpbmcgR3JvdXAgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTS4g S2ltLCBFZC48YnI+SW50ZXJuZXQtRHJhZnQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7S1Q8YnI+ CkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7SlAuIFZhc3NldXIsIEVkLjxicj5FeHBpcmVzOiBKYW51YXJ5IDUsIDIwMDkgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBDaXNj byBTeXN0ZW1zPGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtILiBDaG9uZzxicj4KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0tUPGJyPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SnVseSA0LCAyMDA4PGJyPjxicj48YnI+Jm5ic3A7ICZu YnNwO1JvdXRpbmcgTWV0cmljcyB1c2VkIGZvciBQYXRoIENhbGN1bGF0aW9uIGluIExvdyBQb3dl ciBhbmQgTG9zc3k8YnI+CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO05ldHdvcmtzPGJyPgo8ZGl2IGNsYXNzPSJJaDJFM2QiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQt bWpraW0tcm9sbC1yb3V0aW5nLW1ldHJpY3MtMDA8YnI+PGJyPjwvZGl2PlN0YXR1cyBvZiB0aGlz IE1lbW88YnI+PGJyPiZuYnNwOyBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVh Y2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnk8YnI+Jm5ic3A7IGFwcGxpY2FibGUgcGF0ZW50 IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hpY2ggaGUgb3Igc2hlIGlzIGF3YXJlPGJyPgombmJz cDsgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9y IHNoZSBiZWNvbWVzPGJyPiZuYnNwOyBhd2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3Jk YW5jZSB3aXRoIFNlY3Rpb24gNiBvZiBCQ1AgNzkuPGJyPjxicj4mbmJzcDsgSW50ZXJuZXQtRHJh ZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8YnI+ Jm5ic3A7IFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91 cHMuICZuYnNwO05vdGUgdGhhdDxicj4KJm5ic3A7IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0 cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LTxicj4mbmJzcDsgRHJhZnRzLjxi cj48YnI+Jm5ic3A7IEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZv ciBhIG1heGltdW0gb2Ygc2l4IG1vbnRoczxicj4mbmJzcDsgYW5kIG1heSBiZSB1cGRhdGVkLCBy ZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnk8YnI+CiZuYnNw OyB0aW1lLiAmbmJzcDtJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMg YXMgcmVmZXJlbmNlPGJyPiZuYnNwOyBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhh biBhcyAmcXVvdDt3b3JrIGluIHByb2dyZXNzLiZxdW90Ozxicj48YnI+Jm5ic3A7IFRoZSBsaXN0 IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdDxicj4mbmJzcDsg PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0IiB0YXJn ZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0PC9h Pi48YnI+Cjxicj4mbmJzcDsgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVj dG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdDxicj4mbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5p ZXRmLm9yZy9zaGFkb3cuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcv c2hhZG93Lmh0bWw8L2E+Ljxicj48YnI+Jm5ic3A7IFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBl eHBpcmUgb24gSmFudWFyeSA1LCAyMDA5Ljxicj4KPGJyPkFic3RyYWN0PGJyPjxicj4mbmJzcDsg VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgcm91dGluZyBtZXRyaWNzIHVzZWQgaW4gcGF0aCBjYWxj dWxhdGlvbiBmb3I8YnI+Jm5ic3A7IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5l dHdvcmtzIChST0xMKS4gJm5ic3A7TG93IHBvd2VyIGFuZDxicj4mbmJzcDsgTG9zc3kgTmV0d29y a3MgKExMTnMpIGhhdmUgdW5pcXVlIGNoYXJhY3RlcmlzdGljcyBjb21wYXJlZCB3aXRoPGJyPgom bmJzcDsgdHJhZGl0aW9uYWwgd2lyZWQgbmV0d29ya3Mgb3IgZXZlbiB3aXRoIHNpbWlsYXIgb25l cyBzdWNoIGFzIG1vYmlsZTxicj4mbmJzcDsgYWQtaG9jIG5ldHdvcmtzIGFzIGluZGljYXRlZCBp biBzZXZlcmFsIGFwcGxpY2F0aW9uLXNwZWNpZmljPGJyPiZuYnNwOyByZXF1aXJlbWVudHMgZG9j dW1lbnRzLiAmbmJzcDtTaW5jZSB0eXBpY2FsIElHUCByb3V0aW5nIG1ldHJpY3Mgc3VjaCBhczxi cj4mbmJzcDsgaG9wIGNvdW50cyBvciBsaW5rIG1ldHJpY3MgYXJlIG5vdCBzdWZmaWNpZW50IGZv ciBMTE5zLDxicj4KJm5ic3A7IF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl48YnI+ZG1tJmd0Ozxicj5kbW0mZ3Q7IG1pZ2h0IGdpdmUgYSBzZW50 ZW5jZSBvciB0d28gYWJvdXQgd2h5IHRyYWRpdGlvbmFsIElHUDxicj5kbW0mZ3Q7IG1ldHJpY3Mg YXJlbiYjMzk7dCBzdWZmaWNpZW50IGluIHRoZSBMTE4gY29udGV4dDxicj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IHJlZDsgRk9OVC1GQU1JTFk6ILG8 uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiCxvLiyOyBtc28tYmlkaS1mb250LXNpemU6IDEyLjBw dDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1z by1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PT09Jmd0OyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTog sby4sjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ILG8uLI7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIu MHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsg bXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5JIHRoaW5rIHRoZSBzZW50ZW5jZSAmcXVvdDtMTE5z IGhhdmUgdW5pcXVlIGNoYXJhY3RlcmlzdGljcyZxdW90OyBpcyB0aGUgcmVhc29uLiBBbmQgdGhp cyBpcyB0aGUgYWJzdHJhY3QsIHNvIEkgb21pdHRlZCBhbGwgdGhlIGRldGFpbHMuIEhvd2V2ZXIs IGl0JiMzOTtzIG5vdCBkaWZmaWN1bHQgdG8gYWRkIHNvbWUgc3BlY2lmaWMgcmVhc29ucyBzdWNo IGFzIHJlc291cmNlIGNvbnN0cmFpbnRzLCBzbyBpZiB5b3Ugc3RpbGwgdGhpbmsgaXQmIzM5O3Mg YmV0dGVyIHRvIGFkZCwgbGV0IG1lIGtub3cuJm5ic3A7PC9zcGFuPjwvYmxvY2txdW90ZT4KCjxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9IlBBRERJTkctTEVGVDogMWV4OyBN QVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JERVItTEVGVDogI2NjYyAxcHggc29saWQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmxhY2s7IEZP TlQtRkFNSUxZOiCxvLiyOyBtc28tYmlkaS1mb250LWZhbWlseTogsby4sjsgbXNvLWJpZGktZm9u dC1zaXplOiAxMi4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjxzcGFuIGlkPSIiPjwvc3Bhbj48 L3NwYW4+PGJyPgombmJzcDsgdGhpcyBkb2N1bWVudDxicj4mbmJzcDsgc3BlY2lmaWVzIGEgbmV3 IHNldCBvZiByZXF1aXJlZCBsaW5rIGFuZCBub2RlIG1ldHJpY3Mgc3VpdGFibGUgdG88YnI+PGJy Pjxicj48YnI+S2ltLCBldCBhbC4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7RXhwaXJlcyBKYW51YXJ5IDUsIDIwMDkgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tQYWdlIDFdPGJyPjxicj5JbnRlcm5l dC1EcmFmdCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Um91dGluZyBNZXRyaWNz IGZvciBMTE5zICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBKdWx5IDIwMDg8YnI+Cjxicj48YnI+Jm5ic3A7IExMTnMuPGJyPjxicj48YnI+VGFibGUgb2Yg Q29udGVudHM8YnI+PGJyPiZuYnNwOyAxLiAmbmJzcDtOb3RlIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAmbmJzcDszPGJyPjxicj4mbmJz cDsgMi4gJm5ic3A7VGVybWlub2xvZ3kgJm5ic3A7LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAmbmJzcDszPGJyPjxicj4mbmJzcDsgMy4gJm5ic3A7SW50 cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gJm5ic3A7Mzxicj4KPGJyPiZuYnNwOyA0LiAmbmJzcDtOb2RlIGF0dHJpYnV0ZXMgJm5ic3A7 LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICZuYnNwOzU8YnI+ Jm5ic3A7ICZuYnNwOyA0LjEuICZuYnNwO0NvbXB1dGF0aW9uYWwgcmVzb3VyY2VzICZuYnNwOy4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAmbmJzcDs2PGJyPiZuYnNwOyAmbmJzcDsg NC4yLiAmbmJzcDtSZXNpZHVhbCBFbmVyZ3kgJm5ic3A7LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gJm5ic3A7Njxicj4KJm5ic3A7ICZuYnNwOyA0LjMuICZuYnNwO0N1 cnJlbnQgd29ya2xvYWQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g Jm5ic3A7Nzxicj4mbmJzcDsgJm5ic3A7IDQuNC4gJm5ic3A7Tm9kZSBsYXRlbmN5IC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAmbmJzcDs3PGJyPiZuYnNwOyAm bmJzcDsgNC41LiAmbmJzcDtEYXRhIEFnZ3JlZ2F0aW9uIGF0dHJpYnV0ZSAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICZuYnNwOzc8YnI+CiZuYnNwOyAmbmJzcDsgNC42LiAmbmJzcDtO b2RlIGRlZ3JlZSAmbmJzcDsuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gJm5ic3A7ODxicj4mbmJzcDsgJm5ic3A7IDQuNy4gJm5ic3A7RHluYW1pY2l0eSAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAmbmJzcDs5PGJyPiZu YnNwOyAmbmJzcDsgNC44LiAmbmJzcDtOb2RlIHJlbGlhYmlsaXR5IC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICZuYnNwOzk8YnI+Cjxicj4mbmJzcDsgNS4gJm5ic3A7 TGluayBhdHRyaWJ1dGVzICZuYnNwOy4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAmbmJzcDs5PGJyPiZuYnNwOyAmbmJzcDsgNS4xLiAmbmJzcDtCYW5kd2lkdGgg Jm5ic3A7LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTA8 YnI+Jm5ic3A7ICZuYnNwOyA1LjIuICZuYnNwO1JlbGlhYmlsaXR5IChRdWFsaXR5KSAmbmJzcDsu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMDxicj4KJm5ic3A7ICZuYnNwOyA1 LjMuICZuYnNwO1Byb3BhZ2F0aW9uIGRlbGF5ICZuYnNwOy4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxMDxicj48YnI+Jm5ic3A7IDYuICZuYnNwO09wZW4gaXNzdWVzICZu YnNwOy4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTA8 YnI+PGJyPiZuYnNwOyA3LiAmbmJzcDtTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAmbmJzcDsuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExPGJyPgo8YnI+Jm5ic3A7IDguICZu YnNwO0lBTkEgQ29uc2lkZXJhdGlvbnMgJm5ic3A7LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTI8YnI+PGJyPiZuYnNwOyA5LiAmbmJzcDtBY2tub3dsZWRnZW1lbnRz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMjxicj48YnI+ Jm5ic3A7IDEwLiBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxMjxicj4KJm5ic3A7ICZuYnNwOyAxMC4xLiBOb3JtYXRpdmUgUmVm ZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyPGJyPiZuYnNw OyAmbmJzcDsgMTAuMi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxMjxicj48YnI+Jm5ic3A7IEF1dGhvcnMmIzM5OyBBZGRyZXNzZXMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTI8YnI+CiZu YnNwOyBJbnRlbGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTQ8YnI+PGJyPjxicj48YnI+PGJyPjxicj48YnI+PGJyPjxicj48YnI+ PGJyPjxicj5LaW0sIGV0IGFsLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtFeHBpcmVzIEphbnVhcnkgNSwgMjAwOSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W1BhZ2UgMl08YnI+PGJyPkludGVybmV0 LURyYWZ0ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSb3V0aW5nIE1ldHJpY3Mg Zm9yIExMTnMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IEp1bHkgMjAwODxicj4KPGJyPjxicj4xLiAmbmJzcDtOb3RlPGJyPjxicj4mbmJzcDsgU29tZSBv ZiB0aGUgcm91dGluZyBtZXRyaWNzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBtYXkgYmUgc3Vi amVjdDxicj4mbmJzcDsgdG8gY2hhbmdlIG9yIG1heSBldmVuIGJlIHJlbW92ZWQgaW4gbGlnaHQg b2YgdGhlIHJvdXRpbmcgcmVxdWlyZW1lbnRzPGJyPiZuYnNwOyBjdXJyZW50bHkgYmVpbmcgc3Bl Y2lmaWVkIGJ5IHRoZSBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeTxicj4KJm5ic3A7 IG5ldHdvcmtzIChST0xMKSBXb3JraW5nIEdyb3VwLiAmbmJzcDtGb3IgdGhlIHNha2Ugb2YgaWxs dXN0cmF0aW9uLCBzb21lPGJyPiZuYnNwOyBtZXRyaWNzIGFyZSBvbmx5IG1lYW5pbmdmdWwgaW4g cm91dGluZyBwcm90b2NvbHMgdGhhdCBmYWxsIGludG8gdGhlPGJyPiZuYnNwOyBjYXRlZ29yeSBv ZiBEaXN0YW5jZSBWZWN0b3IuICZuYnNwO1NpbmNlIHRoZSBXb3JraW5nIEdyb3VwIGhhcyBub3Qg eWV0PGJyPiZuYnNwOyBkZXRlcm1pbmVkIHdoaWNoIHJvdXRpbmcgcHJvdG9jb2wgd2lsbCBiZSBj aG9zZW4gZm9yIExvdyBwb3dlciBhbmQ8YnI+CiZuYnNwOyBMb3NzeSBOZXR3b3JrcyAoTExOcyks IGl0IGlzIG5vdCB5ZXQgcG9zc2libGUgdG8gZGV0ZXJtaW5lIHdoZXRoZXI8YnI+Jm5ic3A7IHN1 Y2ggbWV0cmljcyB3aWxsIGJlIHJlcXVpcmVkLiAmbmJzcDtDb252ZXJzZWx5LCBvdGhlciBtZXRy aWNzIG1heSBiZTxicj4mbmJzcDsgZnVydGhlciByZXF1aXJlZCBkZXBlbmRpbmcgb24gd2hpY2gg cm91dGluZyBwcm90b2NvbCBpcyBzZWxlY3RlZCBieTxicj4mbmJzcDsgdGhlIFdvcmtpbmcgR3Jv dXAuPGJyPgo8YnI+PGJyPjIuICZuYnNwO1Rlcm1pbm9sb2d5PGJyPjxicj4mbmJzcDsgVGhlIGtl eSB3b3JkcyAmcXVvdDtNVVNUJnF1b3Q7LCAmcXVvdDtNVVNUIE5PVCZxdW90OywgJnF1b3Q7UkVR VUlSRUQmcXVvdDssICZxdW90O1NIQUxMJnF1b3Q7LCAmcXVvdDtTSEFMTCBOT1QmcXVvdDssPGJy PiZuYnNwOyAmcXVvdDtTSE9VTEQmcXVvdDssICZxdW90O1NIT1VMRCBOT1QmcXVvdDssICYjMzk7 UkVDT01NRU5ERUQmcXVvdDssICZxdW90O01BWSZxdW90OywgYW5kICZxdW90O09QVElPTkFMJnF1 b3Q7IGluIHRoaXM8YnI+CiZuYnNwOyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMg ZGVzY3JpYmVkIGluIFtSRkMyMTE5XS48YnI+PGJyPiZuYnNwOyBvICZuYnNwO0FjY2VzcyBwb2lu dDogQW4gaW5mcmFzdHJ1Y3R1cmUgZGV2aWNlIHRoYXQgY29ubmVjdHMgdGhlIGxvdyBwb3dlcjxi cj4mbmJzcDsgJm5ic3A7ICZuYnNwO2FuZCBsb3NzeSBuZXR3b3JrcyB0byB0aGUgYmFja2JvbmUg bmV0d29yayBsaWtlIHRoZSBJbnRlcm5ldCw8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDttb3N0bHkg dmlhIGFjY2VzcyBuZXR3b3Jrcy48YnI+Cjxicj4mbmJzcDsgbyAmbmJzcDtEYXRhIHNpbms6IEEg ZGV2aWNlIHdoaWNoIGNvbGxlY3RzIGRhdGEgZnJvbSBub2RlcyBpbiBhIExMTi48YnI+PGJyPiZu YnNwOyBvICZuYnNwO0R5bmFtaWMgTExOOiBMb3cgcG93ZXIgYW5kIExvc3N5IE5ldHdvcmsgd2hl cmUgc29tZSBub2RlcyBhcmU8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDttb2JpbGUuPGJyPjxicj4m bmJzcDsgbyAmbmJzcDtST0xMOiBSb3V0aW5nIE92ZXIgTG93LXBvd2VyIGFuZCBMb3NzeSBuZXR3 b3Jrcy48YnI+Cjxicj4mbmJzcDsgbyAmbmJzcDtTdGF0aWMgTExOOiBMb3cgcG93ZXIgYW5kIExv c3N5IE5ldHdvcmsgd2hlcmUgYWxsIG5vZGVzIGFyZTxicj4mbmJzcDsgJm5ic3A7ICZuYnNwO3N0 YXRpYywgbm90IG1vYmlsZS48YnI+PGJyPmRtbSZndDsgbG9va3MgbGlrZWsgbW9zdCBvZiB0aGlz IGNhbiBiZSByZXBsYWNlcyB3aXRoIGEgY2l0YXRpb24gdG88YnI+ZG1tJmd0OyBkcmFmdC12YXNz ZXVyLXJvbGwtdGVybWlub2xvZ3ktMDEudHh0PGJyPgo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IHJlZDsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRp LWZvbnQtZmFtaWx5OiCxvLiyOyBtc28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWFuc2kt bGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1 YWdlOiBBUi1TQSI+PT09Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiCxvLiy OyBtc28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBt c28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+Jm5ic3A7 T25seSBST0xMIGlzIGluIHRoZSBkcmFmdCwgc28gSSB0aGluayBpdCYjMzk7cyBiZXR0ZXIgdG8g bGVhdmUgdGhlbSBmb3Igbm93Ljwvc3Bhbj48YnI+Cjxicj4zLiAmbmJzcDtJbnRyb2R1Y3Rpb248 YnI+PGJyPiZuYnNwOyBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyByb3V0aW5nIG1ldHJpY3MgdXNl ZCBpbiBwYXRoIGNhbGN1bGF0aW9uIGZvcjxicj5kbW0mZ3Q7IHMvdXNlZC90byBiZSB1c2VkLyAm bmJzcDsob3IgbWF5YmUgJnF1b3Q7Zm9yIHVzZSZxdW90Oyk8YnI+Jm5ic3A7IFJvdXRpbmcgT3Zl ciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzIChST0xMKS4gJm5ic3A7TG93IHBvd2VyIGFu ZDxicj4KJm5ic3A7IExvc3N5IE5ldHdvcmtzIChMTE5zKSBoYXZlIHVuaXF1ZSBjaGFyYWN0ZXJp c3RpY3MgY29tcGFyZWQgd2l0aDxicj4mbmJzcDsgdHJhZGl0aW9uYWwgd2lyZWQgbmV0d29ya3Mg b3IgZXZlbiB3aXRoIHNpbWlsYXIgb25lcyBzdWNoIGFzIG1vYmlsZTxicj4mbmJzcDsgYWQtaG9j IG5ldHdvcmtzIGFzIGluZGljYXRlZCBpbiBzZXZlcmFsIGFwcGxpY2F0aW9uLXNwZWNpZmljPGJy PiZuYnNwOyByZXF1aXJlbWVudHMgZG9jdW1lbnRzLiAmbmJzcDtTaW5jZSB0eXBpY2FsIElHUCBy b3V0aW5nIG1ldHJpY3Mgc3VjaCBhczxicj4KJm5ic3A7IGhvcCBjb3VudHMgb3IgbGluayBtZXRy aWNzIGFyZSBub3Qgc3VmZmljaWVudCBmb3IgTExOcywgdGhpcyBkb2N1bWVudDxicj4mbmJzcDsg c3BlY2lmaWVzIGEgbmV3IHNldCBvZiByZXF1aXJlZCBsaW5rIGFuZCBub2RlIG1ldHJpY3Mgc3Vp dGFibGUgdG88YnI+Jm5ic3A7IExMTnMuPGJyPmRtbSZndDsgZG8geW91IHJlYWxseSB3YW50IHRv IHNheSB0aGUgdGhlIG1ldHJpY3MgYXJlICZxdW90O3JlcXVpcmVkJnF1b3Q7Pzxicj4KZG1tJmd0 OyBIb3cgYWJvdXQgcy9yZXF1aXJlZC8vPGJyPjxicj48YnI+S2ltLCBldCBhbC4gJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RXhwaXJlcyBKYW51YXJ5IDUs IDIwMDkgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO1tQYWdlIDNdPGJyPjxicj5JbnRlcm5ldC1EcmFmdCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Um91dGluZyBNZXRyaWNzIGZvciBMTE5zICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBKdWx5IDIwMDg8YnI+PGJyPjxicj4mbmJzcDsg Um91dGluZyBtZXRyaWNzIGNhbiBiZSBjbGFzc2lmaWVkIGFjY29yZGluZyB0byB0aGUgZm9sbG93 aW5nIHNldCBvZjxicj4KJm5ic3A7IGNoYXJhY3RlcmlzdGljczo8YnI+PGJyPiZuYnNwOyAtIExp bmsgdmVyc3VzIE5vZGUgbWV0cmljczxicj48YnI+Jm5ic3A7IC0gUXVhbGl0YXRpdmUgdmVyc3Vz IHF1YW50aXRhdGl2ZTxicj48YnI+Jm5ic3A7IC0gRHluYW1pYyBvciBzdGF0aWM8YnI+PGJyPiZu YnNwOyBIaXN0b3JpY2FsbHksIElHUCBzdWNoIGFzIE9TUEYgYW5kIElTLUlTIGhhdmUgYmVlbiB1 c2luZyBxdWFudGl0YXRpdmU8YnI+ZG1tJmd0OyBjaXRhdGlvbnMgZm9yIE9TUEYgYW5kIElTLUlT PGJyPgombmJzcDsgc3RhdGljIGxpbmsgbWV0cmljcy4gJm5ic3A7T3RoZXIgbWVjaGFuaXNtcyBz dWNoIGFzIE11bHRpcHJvdG9jb2wgTGFiZWw8YnI+Jm5ic3A7IFN3aXRjaGluZyAoTVBMUykgVHJh ZmZpYyBFbmdpbmVlcmluZyAoVEUpIG1ha2UgdXNlIG9mIG90aGVyIGxpbms8YnI+ZG1tJmd0OyBh Z2FpbiwgY2l0YXRpb24gZm9yIE1QTFMvTVBMUy1URTxicj4mbmJzcDsgYXR0cmlidXRlcyBzdWNo IGFzIHRoZSBhdmFpbGFibGUgcmVzZXJ2ZWQgYmFuZHdpZHRoLCBhZmZpbml0aWVzIGFuZDxicj4K Jm5ic3A7IHNvIG9uIHRvIGNvbXB1dGUgY29uc3RyYWluZWQgc2hvcnRlc3QgcGF0aCBmb3IgVHJh ZmZpYyBFbmdpbmVlcmluZzxicj5zL3BhdGgvcGF0aHMvPGJyPiZuYnNwOyBMYWJlbCBTd2l0Y2hl ZCBQYXRocyAoVEUgTFNQcykuPGJyPjxicj4mbmJzcDsgSXQgbXVzdCBiZSBub3RlZCB0aGF0IHRo ZSB1c2Ugb2YgZHluYW1pYyBtZXRyaWNzIGlzIG5vdCBuZXcgYW5kIGhhczxicj4mbmJzcDsgYmVl biBleHBlcmltZW50ZWQgaW4gQVJQQU5FVCAyLCB3aXRoIGEgbW9kZXJhdGUgc3VjY2Vzcy4gJm5i c3A7SW5kZWVkLCBhPGJyPgpkbW0mZ3Q7IGNpdGF0aW9uIGZvciBBUlBBTkVUIDI8YnI+Jm5ic3A7 IHZlcnkgY2FyZWZ1bCBjYXJlIG11c3QgYmUgZ2l2ZW4gdG8gdGhlIHVzZSBvZiBkeW5hbWljIG1l dHJpY3MgdGhhdDxicj4mbmJzcDsgbWF5IGxlYWQgdG8gcG90ZW50aWFsIHJvdXRpbmcgaW5zdGFi aWxpdGllcy48YnI+PGJyPiZuYnNwOyBJbiBMTE5zLCBpdCBpcyByZXF1aXJlZCB0byB0YWtlIGlu dG8gYWNjb3VudCB2YXJpb3VzIG5vZGUgY29uc3RyYWludHM8YnI+CiZuYnNwOyB3aGVuIGNhbGN1 bGF0aW5nIHRoZSBkZXNpcmFibGUgcGF0aC4gJm5ic3A7Tm9kZSBtZXRyaWNzIGluY2x1ZGUgdGhl IG5vZGUmIzM5O3M8YnI+Jm5ic3A7IHJlc291cmNlcyBsaWtlIG1lbW9yeSwgZW5lcmd5IGFuZCBD UFUgKGNvbXB1dGF0aW9uYWwgcG93ZXIpLiAmbmJzcDtPdGhlcjxicj4mbmJzcDsgbm9kZSBhdHRy aWJ1dGVzIHN1Y2ggYXMgdGhlIGFiaWxpdHkgdG8gYWN0IGFzIGFuIGFnZ3JlZ2F0b3IgKG5vZGU8 YnI+CiZuYnNwOyBjYXBhYmxlIG9mIHBlcmZvcm1pbmcgZGF0YSBhZ2dyZWdhdGlvbikgbWF5IGJl IG9mIGludGVyZXN0Ljxicj4mbmJzcDsgQWRkaXRpb25hbGx5LCB3b3JrIGxvYWQsIHRyYW5zbWlz c2lvbiByYW5nZSBhbmQgZHluYW1pY2l0eSAobW9iaWxpdHksPGJyPiZuYnNwOyBkdXR5IGN5Y2xl LCBldGMpIG1heSBuZWVkIHRvIGJlIHRha2VuIGludG8gYWNjb3VudC4gJm5ic3A7TGluayBhdHRy aWJ1dGVzPGJyPiZuYnNwOyBpbmNsdWRlIHByb3BhZ2F0aW9uIGRlbGF5LCByZWxpYWJpbGl0eSAo cXVhbGl0eSkgYW5kIGF2YWlsYWJsZTxicj4KJm5ic3A7IGJhbmR3aWR0aC48YnI+PGJyPiZuYnNw OyBCeSBjb250cmFzdCB3aXRoIHRoZSBjdXJyZW50IEludGVybmV0LCBMTE5zIGFyZSBjaGFyYWN0 ZXJpemVkIGJ5PGJyPiZuYnNwOyB0aGVpciBkeW5hbWljIG5hdHVyZSwgd2hpY2ggbm90IG9ubHkg YXBwbGllcyB0byB0aGUgbGluayBidXQgYWxzbyB0bzxicj4mbmJzcDsgdGhlIG5vZGVzIGluIHRo ZSBuZXR3b3Jrcy4gJm5ic3A7VGh1cywgaXQgaXMgcmVxdWlyZWQgdG8gc3BlY2lmeSB2YXJpb3Vz PGJyPgombmJzcDsgZHluYW1pYyBtZXRyaWNzLiAmbmJzcDtGb3IgaW5zdGFuY2UsIGV2ZW4gdGhv dWdoIGEgd2lyZWxlc3Mgc2Vuc29yIG5ldHdvcms8YnI+Jm5ic3A7IHRvcG9sb2d5IGlzIHN0YXRp YyBpbiBhYnNlbmNlIG9mIGZhaWx1cmUsIG5vZGVzJiMzOTsgd29ya2xvYWQgYW5kPGJyPiZuYnNw OyByZXNvdXJjZSBzdWNoIGFzIHJlc2lkdWFsIGVuZXJneSBhbmQgYXZhaWxhYmxlIG1lbW9yeSBh cmUgY2hhbmdpbmc8YnI+Jm5ic3A7IGNvbnRpbnVvdXNseSBhbmQgbWF5IGhhdmUgdG8gYmUgdGFr ZW4gaW50byBhY2NvdW50IGR1cmluZyB0aGUgcGF0aDxicj4KJm5ic3A7IGNvbXB1dGF0aW9uLiAm bmJzcDtTaW1pbGFybHksIGxpbmsgYXR0cmlidXRlcyBpbmNsdWRpbmcgbGF0ZW5jeSBhbmQ8YnI+ Jm5ic3A7IHJlbGlhYmlsaXR5IGFyZSBub3Qgc3RhdGljIGJlY2F1c2UgbW92aW5nIG9ic3RhY2xl cyBjYW4gYXBwZWFyIGF0IGFueTxicj4mbmJzcDsgdGltZS4gJm5ic3A7VGh1cywgdGhleSBhcmUg cmVhbC10aW1lIHBhcmFtZXRlcnMuICZuYnNwO1RoYXQgYmVpbmcgc2FpZCwgdmVyeTxicj4mbmJz cDsgY2FyZWZ1bCBhdHRlbnRpb24gbXVzdCBiZSBnaXZlbiB0byBoaWdobHkgZHluYW1pYyBwYXJh bWV0ZXJzIHRoYXQ8YnI+CiZuYnNwOyBhZmZlY3Qgcm91dGluZyBkZWNpc2lvbiBpbiBvcmRlciB0 byBwcmVzZXJ2ZSB0aGUgcm91dGluZyBzdGFiaWxpdHkuPGJyPiZuYnNwOyBGdXJ0aGVybW9yZSwg aXQgaXMgcXVpdGUgdGltZS0gYW5kIGVuZXJneS1jb25zdW1pbmcgcHJvY2VzcyB0byB1cGRhdGU8 YnI+Jm5ic3A7IHRoZXNlIGR5bmFtaWMgbWV0cmljcyBpbiBhIHJlZ3VsYXIgYmFzaXMuICZuYnNw O1RoZXJlZm9yZSwgd2UgbWF5IHJlZ2FyZDxicj4KJm5ic3A7IHRoZW0gYXMgc3RhdGljIG1ldHJp Y3MgaW4gc3RhdGljIExMTnMgdG8gY3V0IG9mZiBvdmVyaGVhZCBieTxicj4mbmJzcDsgY29tcHJv bWlzaW5nIGFjY3VyYWN5Ljxicj48YnI+ZG1tJmd0OyBUaGlzIGxhc3Qgc2VudGVuY2UgaXMgaGFy ZCB0byB1bmRlcnN0YW5kLiBNYXliZTo8YnI+ZG1tJmd0OyAmcXVvdDtUaGVyZWZvcmUgd2UgbWln aHQgdHJlYXQgc3VjaCBkeW5hbWljIG1ldHJpY3MgYXMgc3RhdGljPGJyPgpkbW0mZ3Q7IG1ldHJp Y3MgaW4gb3JkZXIgdG8gcmVkdWNlIGNvbXB1dGF0aW9uYWwgb3ZlcmhlYWQgYW5kPGJyPmRtbSZn dDsgYmFuZHdpZHRoIHV0aWxpemF0aW9uLiBPZiBjb3Vyc2UsIHRoaXMgY29tZXMgd2l0aCBhIGNv c3QsPGJyPmRtbSZndDsgbmFtZWx5LCByZWR1Y2VkIG1ldHJpYyBhY2N1cmFjeS48YnI+PGJyPjxi cj48YnI+PGJyPktpbSwgZXQgYWwuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO0V4cGlyZXMgSmFudWFyeSA1LCAyMDA5ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbUGFnZSA0XTxicj4KPGJyPkludGVy bmV0LURyYWZ0ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSb3V0aW5nIE1ldHJp Y3MgZm9yIExMTnMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IEp1bHkgMjAwODxicj48YnI+PGJyPiZuYnNwOyBSZWxpYWJpbGl0eSBpcyBhbiBleGFtcGxl IG9mIHF1YWxpdHkgcGFyYW1ldGVyLiAmbmJzcDtIb3dldmVyLCB0byBiZTxicj4mbmJzcDsgcm91 dGluZyBtZXRyaWNzIGZvciBwYXRoIGNhbGN1bGF0aW9uLCBxdWFsaXR5IHBhcmFtZXRlcnMgTVVT VCBiZTxicj4KJm5ic3A7IHRyYW5zZm9ybWVkIHRvIHF1YW50aXR5IHZhbHVlcy4gJm5ic3A7U29t ZSBjcml0ZXJpYSBTSE9VTEQgYmUgc2V0IHRvIG1ha2U8YnI+Jm5ic3A7IHRoZSBxdWFsaXR5IHBh cmFtZXRlcnMgYXBwZWFyIGluIHF1YW50aXR5IGZvcm1zLiAmbmJzcDtRdWFudGl0eSBmb3JtIGNh bjxicj4mbmJzcDsgYmUgbnVtYmVycyBvciBsZXZlbHMuPGJyPjxicj4mbmJzcDsgVGhpcyBkb2N1 bWVudCBzcGVjaWZpZXMgYSBzZXQgb2YgbGluayBhbmQgbm9kZXMgbWV0cmljcyB0aGF0IGNhbiBi ZTxicj4KJm5ic3A7IHVzZWQgdG8gY29tcHV0ZSB0aGUgb3B0aW1hbCBwYXRoIHdpdGhpbiBhIExM Ti4gJm5ic3A7RnVydGhlcm1vcmUsIHNvbWU8YnI+Jm5ic3A7IGxpbmsgb3Igbm9kZSBhdHRyaWJ1 dGVzIChlLmcuIGxldmVsIG9mIGxpbmsgcmVsaWFiaWxpdHksIGVuZXJneTxicj4mbmJzcDsgcmVt YWluaW5nIG9uIHRoZSBub2RlKSBjYW4gYmUgdXNlZCB0byBwZXJmb3JtIGNvbnN0cmFpbnQtYmFz ZWQ8YnI+Jm5ic3A7IHJvdXRpbmcuICZuYnNwO0l0IGlzIG5vdCByZXF1aXJlZCB0byB1c2UgYWxs IHRoZSBtZXRyaWNzIGFuZCBhdHRyaWJ1dGVzPGJyPgombmJzcDsgc3BlY2lmaWVkIGluIHRoaXMg ZG9jdW1lbnQuICZuYnNwO0EgcGFydGljdWxhciBpbXBsZW1lbnRhdGlvbiBNQVkgdXNlIGE8YnI+ Jm5ic3A7IHN1YnNldCBvciBhbGwgb2YgdGhlIG1ldHJpY3MgZGVmaW5lZCBpbiB0aGlzIGRvY3Vt ZW50Ljxicj48YnI+Jm5ic3A7IE5vdGU6IGZpbmRpbmcgdGhlIHNob3J0ZXN0IHBhdGggaXMgbm90 IGFsd2F5cyBiZXN0IGluIExMTnMgc2luY2UgYTxicj4mbmJzcDsgcmVsaWFibGUgcGF0aCBpcyBt b3JlIHByZWZlcmFibGUuICFvVGhlIG9wdGltYWwgcGF0aCErLy0gaGVyZSBtZWFuczxicj4KJm5i c3A7IHRoZSBiZXN0IHBhdGggaGF2aW5nIHJlZ2FyZCB0byBjb25zdHJhaW50cy4gJm5ic3A7VGhl IHRlcm0gIW9jb25zdHJhaW5lZDxicj4mbmJzcDsgc2hvcnRlc3QgcGF0aCErLy0gbWF5IGJlIHVz ZWQgaW5zdGVhZC48YnI+PGJyPiZuYnNwOyBUaGUgc3BlY2lmaWNhdGlvbiBvZiB0aGUgb2JqZWN0 aXZlIGZ1bmN0aW9uIHVzZWQgdG8gY29tcHV0ZSB0aGUgcGF0aDxicj4mbmJzcDsgaXMgb3V0IG9m IHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Ljxicj4KPGJyPiZuYnNwOyBOb3RlOiBpbiB0aGUg Zmlyc3QgcmV2aXNpb24gb2YgdGhpcyBkb2N1bWVudCwgbGluayBhbmQgbm9kZSBtZXRyaWNzPGJy PiZuYnNwOyBhcmUgZGVmaW5lZCB3aXRoIG5vIHBhY2tldCBmb3JtYXQgb3Igc3VnZ2VzdGlvbnMg dG8gZW5jb2RlIHRoZSBkYXRhLjxicj4mbmJzcDsgVGhpcyB3aWxsIGJlIGRldGVybWluZWQgaW4g YSBmdXJ0aGVyIHJldmlzaW9uIG9mIHRoaXMgZG9jdW1lbnQuPGJyPjxicj4KPGJyPjQuICZuYnNw O05vZGUgYXR0cmlidXRlczxicj48YnI+Jm5ic3A7IE1vc3Qgbm9kZSBhdHRyaWJ1dGVzIG1heSBi ZSB0YWtlbiBhcyBzdGF0aWMgYXR0cmlidXRlcyBpbiBMTE5zIHNpbmNlPGJyPiZuYnNwOyBpdCBt aWdodCByZXF1aXJlIHF1aXRlIGFtb3VudCBvZiByZXNvdXJjZXMgdG8gZ2V0IGV4YWN0IHZhbHVl cyBvZiB0aGU8YnI+Jm5ic3A7IGF0dHJpYnV0ZXMgYW5kIHVwZGF0ZSB0aGVtIHBlcmlvZGljYWxs eS4gJm5ic3A7RnVydGhlcm1vcmUsIHRoZSB1c2Ugb2Y8YnI+CiZuYnNwOyBkeW5hbWljIG1ldHJp Y3MgaXMgc3ViamVjdCB0byByb3V0aW5nIGluc3RhYmlsaXRpZXMgYW5kIG11c3QgYmUgdXNlZDxi cj5kbW0mZ3Q7IHMvaXMgc3ViamVjdC9jYW4gY2F1c2UvPGJyPiZuYnNwOyB3aXRoIGV4dHJlbWUg Y2FyZS4gJm5ic3A7SG93ZXZlciwgY3JpdGljYWwgcGFyYW1ldGVycyBsaWtlIHJlc2lkdWFsIHBv d2VyPGJyPmRtbSZndDsgeW91IG1pZ2h0IHdhbnQgdG8gY29uc2lkZXIgdGhlIHRvdGFsIHBvd2Vy IG9mIGEgZ2l2ZW4gcGF0aDxicj4KZG1tJmd0OyBhcyB3ZWxsIChlc3BlY2lhbGx5IHdoZW4gb3B0 aW1pemluZyBuZXR3b3JrIGxpZmV0aW1lKS48YnI+ZG1tJmd0OyBTZWUsIGUuZy4sICZxdW90O1dp cmVsZXNzIHNlbnNvciBuZXR3b3JrczogYSBzdXJ2ZXkmcXVvdDssPGJyPmRtbSZndDsgSS5GLiBB a3lpbGRpeiwgZXQuIGFsLiwgQ29tcHV0ZXIgTmV0d29ya3MgKDM4KSwgMjAwMiwsIDM5My00MjIu PGJyPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogcmVk OyBGT05ULUZBTUlMWTogsby4sjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ILG8uLI7IG1zby1iaWRp LWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0 LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj49PT0mZ3Q7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogsby4 sjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ILG8uLI7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0 OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNv LWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj4gPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzExMTExMTsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1i aWRpLWZvbnQtZmFtaWx5OiAmIzM5O1RpbWVzIE5ldyBSb21hbiYjMzk7OyBtc28tZm9udC1rZXJu aW5nOiAxLjBwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMi4wcHQ7IG1zby1hbnNpLWxhbmd1YWdl OiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5ndWFnZTogQVIt U0EiPk9mIGNvdXJzZSwgY29uc2lkZXJpbmcgYSBnaXZlbiBwYXRoIHdpbGwgbWFrZSBiZXR0ZXIg cm91dGUgc2VsZWN0aW9uIHBvc3NpYmxlIHRoYW4gY29uc2lkZXJpbmcgb25seSBpbmRpdmlkdWFs IG5vZGVzIGFuZCBsaW5rcy4gSXQgYXBwbGllcyB0byBub3Qgb25seSBwb3dlciBidXQgYWxzbyBt b3N0IG90aGVyIG1ldHJpY3MsIEkgYmVsaWV2ZS4gSG93ZXZlciwgaXQncyB2ZXJ5IGNoYWxsZW5n aW5nIHRvIGNvbnNpZGVyIHBhdGhzIGluIExMTnMgZHVlIHRvIHJlc291cmNlIGNvbnN0cmFpbnRz IGFuZCB0aGVyZSBhcmUgaW1wbGVtZW50YXRpb24gaXNzdWVzLiBXZSBtYXkgbmVlZCB0byBkZWxh eSB0aGlzIGlzc3VlIHVudGlsIHBhdGggY2FsY3VsYXRpb24gdXNpbmcgdGhlIG1ldHJpY3MgaXMg ZGlzY3Vzc2VkLjwvc3Bhbj48L2Jsb2NrcXVvdGU+Cgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhl eDsgQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxMTExMTE7IEZPTlQtRkFNSUxZOiCxvLiyOyBtc28t YmlkaS1mb250LWZhbWlseTogJiMzOTtUaW1lcyBOZXcgUm9tYW4mIzM5OzsgbXNvLWZvbnQta2Vy bmluZzogMS4wcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tYW5zaS1sYW5ndWFn ZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFS LVNBIj48c3BhbiBpZD0iIj48L3NwYW4+PC9zcGFuPjxicj4KJm5ic3A7IG1pZ2h0IG5lZWQgdG8g YmUgY29uc2lkZXJlZCBkeW5hbWljIGFuZCBtb25pdG9yZWQgY29udGludW91c2x5IGluPGJyPiZu YnNwOyBzb21lIHNjZW5hcmlvcy4gJm5ic3A7SW1wbGVtZW50YXRpb24gTVVTVCBtYWtlIHVzZSBv ZiBtdWx0aS10aHJlc2hvbGQ8YnI+PGJyPmRtbSZndDsgcy9JbXBsbWVudGF0aW9uL0FuIGltcGxl bWVudGF0aW9uLzxicj48YnI+Jm5ic3A7IHNjaGVtZSByYXRoZXIgdGhhbiBmaW5lIGdyYW51bGFy IG1ldHJpYyB1cGRhdGUgc28gYXMgdG8gYXZvaWQ8YnI+Cjxicj5kbW0mZ3Q7IFRoZSB0ZXJtICZx dW90O211bHRpLXRocmVzaG9sZCBzY2hlbWUmcXVvdDsgaGFzbiYjMzk7dCBiZWVuIGRlc2NyaWJl ZDxicj48YnI+Jm5ic3A7IGNvbnN0YW50IHJvdXRpbmcgY2hhbmdlcy48YnI+PGJyPiZuYnNwOyBJ biBMTE5zLCBpdCBpcyBub3QgdW5jb21tb24gdG8gaGF2ZSBoaWdobHkgaGV0ZXJvZ2VuZW91cyBu b2RlcyBpbjxicj4mbmJzcDsgdGVybSBvZiBjYXBhYmlsaXRpZXMgKGUuZyBub2RlIGJlaW5nIGJh dHRlcnkgb3BlcmF0ZWQgb3Igbm90LCBhbW91bnQ8YnI+CiZuYnNwOyBvZiBtZW1vcnksICF8KSBh bmQgZnVuY3Rpb25hbGl0aWVzLiAmbmJzcDtNb3JlIGNhcGFibGUgYW5kIHN0YWJsZSBub2Rlczxi cj4mbmJzcDsgY2FuIGFzc2lzdCB0aGUgbW9zdCBjb25zdHJhaW5lZCBvbmVzIGZvciByb3V0aW5n IHBhY2tldHMsIHdoaWNoPGJyPiZuYnNwOyByZXN1bHRzIGluIGV4dGVuc2lvbiBvZiBuZXR3b3Jr IGxpZmV0aW1lIGFuZCBlZmZpY2llbnQgbmV0d29yazxicj4mbmJzcDsgb3BlcmF0aW9ucy4gJm5i c3A7VGhlcmVmb3JlLCBub2RlIG1ldHJpY3MgU0hPVUxEIGJlIGNhcmVmdWxseSBtYWludGFpbmVk PGJyPgombmJzcDsgYW5kIHV0aWxpemVkIGZvciByb3V0aW5nLiAmbmJzcDtUaGlzIGhhcyB0aGUg Zm9sbG93aW5nIHN0cm9uZyBpbXBsaWNhdGlvbjxicj4mbmJzcDsgcmVmZXJyZWQgdG8gYXMgY29u c3RyYWluZWQtYmFzZWQgcm91dGluZyB3aGVyZWJ5IHRoZSBjb21wdXRlZCBwYXRoPGJyPiZuYnNw OyBtYXkgbm90IGJlIHRoZSBzaG9ydGVzdCBwYXRoIGFjY29yZGluZyB0byBzb21lIHNwZWNpZmll ZCBtZXRyaWNzLjxicj48YnI+CmRtbSZndDsgbWF5YmU6ICZxdW90O1RoaXMgaW1wbGllcyB0aGF0 IGNvbnN0cmFpbnQtYmFzZWQgcm91dGluZyB3aWxsIGJlPGJyPmRtbSZndDsgdXNlZCBpbiBzb21l IGNhc2VzLiZxdW90Ozxicj48YnI+S2ltLCBldCBhbC4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RXhwaXJlcyBKYW51YXJ5IDUsIDIwMDkgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tQYWdlIDVdPGJy Pjxicj5JbnRlcm5ldC1EcmFmdCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Um91 dGluZyBNZXRyaWNzIGZvciBMTE5zICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBKdWx5IDIwMDg8YnI+Cjxicj48YnI+Jm5ic3A7IE1lY2hhbmlzbXMgbXVz dCBiZSBkZXNpZ25lZCB0byBlbnN1cmUgbGFjayBvZiByb3V0aW5nIGxvb3BzIGluIHRoZTxicj4m bmJzcDsgcHJlc2VuY2Ugb2YgY29uc3RyYWluZWQgYmFzZWQgcm91dGluZyB3aXRoIGEgbm9uIGNv bm5lY3Rpb24gb3JpZW50ZWQ8YnI+Jm5ic3A7IGVudmlyb25tZW50Ljxicj5kbW0mZ3Q7ICZxdW90 O1JvdXRpbmcgc2hvdWxkIGJlIGxvb3AtZnJlZSZxdW90OyAoPykuIEluIGFkZGl0aW9uLCB3aGF0 IGtpbmQgb2Y8YnI+CmRtbSZndDsgbWljcm8tbG9vcHMgKGlmIGFueSkgYXJlIHRvIGJlIHRvbGxl cmF0ZWQ/IEkgd291bGQgaW1hZ2luZTxicj5kbW0mZ3Q7IHRoYXQgdGhpcyBpcyBhcHBsaWNhdGlv biBzcGVjaWZpYy4gSG93ZXZlciwgdGhlcmUgaXMgYTxicj5kbW0mZ3Q7IGNvbnZlcmdlbmNlIHRp bWUgdi4gZW5lcmd5IHV0aWxpemF0aW9uIHF1ZXN0aW9uIGhlcmU8YnI+ZG1tJmd0OyAocG9zc2li bHkgYWxzbyBhcHBsaWNhdGlvbiBzcGVjaWZjKS48YnI+Cjxicj40LjEuICZuYnNwO0NvbXB1dGF0 aW9uYWwgcmVzb3VyY2VzPGJyPjxicj4mbmJzcDsgTWVtb3J5IGFuZCBDUFUgcmVzb3VyY2VzIGNh biBiZSBjb25zaWRlcmVkIGFzIGNvbXB1dGF0aW9uYWwgb25lcyBhbmQ8YnI+Jm5ic3A7IGFyZSBw b3RlbnRpYWxseSBpbXBvcnRhbnQgcm91dGluZyBtZXRyaWNzIGluIExMTnMgYmVjYXVzZSBpbiBz b21lPGJyPiZuYnNwOyBlbnZpcm9ubWVudHMgbm9kZXMgYXJlIHJlc291cmNlIGNvbnN0cmFpbnQu ICZuYnNwO1Jlc291cmNlLWF3YXJlbmVzczxicj4KJm5ic3A7IFNIT1VMRCBiZSBlbXBsb3llZCB0 byByb3V0aW5nIHByb3RvY29scyBzdHJpY3RseSBvciBsb29zZWx5PGJyPiZuYnNwOyBjb25zaWRl cmluZyB0cmFkZS1vZmYgYmV0d2VlbiBjb3N0IGFuZCBiZW5lZml0Ljxicj48YnI+NC4yLiAmbmJz cDtSZXNpZHVhbCBFbmVyZ3k8YnI+PGJyPiZuYnNwOyBMb3cgcG93ZXIgaXMgb25lIG9mIHRoZSBt b3N0IGRpc3Rpbmd1aXNoZWQgZmVhdHVyZXMgb2YgTExOcywgc288YnI+Jm5ic3A7IHJlc2lkdWFs IGVuZXJneSBNVVNUIGJlIGNvbnNpZGVyZWQgYXMgYSBwaXZvdGFsIG1ldHJpYyBpbjxicj4KJm5i c3A7IGVudmlyb25tZW50cyB3aGVyZSBub2RlcyBhcmUgYmF0dGVyeSBwb3dlcmVkLiAmbmJzcDtS ZXNpZHVhbCBlbmVyZ3kgc2hvdWxkPGJyPiZuYnNwOyBiZSB0YWtlbiBhcyBhIHJlbGF0aXZlIHZh bHVlIGNvbnNpZGVyaW5nIHN0YXRpc3RpY2FsIG5vZGUgbGlmZXRpbWU8YnI+Jm5ic3A7IGFuZCBv dGhlciBjb25kaXRpb25zIGxpa2UgdGhlIHJvbGUgb2YgdGhlIG5vZGUgaW4gdGhlIG5ldHdvcmsu ICZuYnNwO0Zvcjxicj4mbmJzcDsgZXhhbXBsZSwgaWYgdGhlIG5vZGUmIzM5O3MgZXhwZWN0ZWQg bGlmZXRpbWUgaXMgNSB5ZWFycyBhbmQgdGhlIHJlbWFpbmluZzxicj4KJm5ic3A7IGVuZXJneSBp cyBvbmx5IG9uZSBmaWZ0aCwgdGhlbiB0aGUgZW5lcmd5IGlzIHF1aXRlIHByZWNpb3VzIHJlc291 cmNlczxicj4mbmJzcDsgdG8gdGhlIG5vZGUuICZuYnNwO0luIHN1Y2ggY2FzZXMsIHRoZSByb3V0 aW5nIHByb3RvY29sIGRlY2lzaW9uIHNob3VsZCBiZTxicj48YnI+ZG1tJmd0OyBzbyAmcXVvdDty ZWxhdGl2ZSZxdW90OyBhYm92ZSBtZWFucyByZWxhdGl2ZSB0byBvdGhlciByZXNvdXJjZXMgdGhh dDxicj4KZG1tJmd0OyBhcmUgY29uc2lkZXJlZCAmcXVvdDttb3JlIGltcG9ydGFudCZxdW90Oz8g SG93IHdvdWxkIHdlIHF1YW50aWZ5IHRoYXQ/PGJyPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogcmVkOyBGT05ULUZBTUlMWTogsby4sjsgbXNvLWJpZGkt Zm9udC1mYW1pbHk6ILG8uLI7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tYW5zaS1s YW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3Vh Z2U6IEFSLVNBIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6IHJlZDsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiCxvLiyOyBt c28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28t ZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PT09Jmd0Ozwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J TFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiCxvLiyOyBtc28tYmlkaS1mb250LXNpemU6 IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTog S087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPiBJbmk8 L2ZvbnQ+PHNwYW4gc3R5bGU9IkNPTE9SOiAjMTExMTExIj50aWFsbHksIEkgbWVhbnQgd2l0aCA8 L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBD T0xPUjogIzExMTExMTsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAm IzM5O1RpbWVzIE5ldyBSb21hbiYjMzk7OyBtc28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNv LWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRp LWxhbmd1YWdlOiBBUi1TQSI+Ijwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6ICMxMTExMTE7IEZPTlQtRkFNSUxZOiCxvLiyOyBtc28tYmlkaS1m b250LWZhbWlseTogsby4sjsgbXNvLWJpZGktZm9udC1zaXplOiAxMi4wcHQ7IG1zby1hbnNpLWxh bmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5ndWFn ZTogQVItU0EiPnJlbGF0aXZlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBDT0xPUjogIzExMTExMTsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZv bnQtZmFtaWx5OiAmIzM5O1RpbWVzIE5ldyBSb21hbiYjMzk7OyBtc28tYmlkaS1mb250LXNpemU6 IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTog S087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+Ijwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxMTExMTE7IEZPTlQtRkFNSUxZOiCxvLiy OyBtc28tYmlkaS1mb250LWZhbWlseTogsby4sjsgbXNvLWJpZGktZm9udC1zaXplOiAxMi4wcHQ7 IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28t YmlkaS1sYW5ndWFnZTogQVItU0EiPiB0aGF0IHRoZSByZXNpZHVhbCBlbmVyZ3kgc2hvdWxkIG5v dCBiZSBldmFsdWF0ZWQgd2l0aCBhYnNvbHV0ZSB2YWx1ZXMuIEZvciBleGFtcGxlLCBib3RoIGRl dmljZXMgQSBhbmQgQiBoYXZlIHRoZSBzYW1lIGFtb3VudCBvZiByZXNpZHVhbCBlbmVyZ3kgdG8g bGFzdCAxIHllYXIuJm5ic3A7QSBpcyBlc3NlbnRpYWwgaW4gdGhlIG5ldHdvcmsgc3VjaCB0aGF0 IHRoZSBhYnNlbmNlIG9mIHRoZSBub2RlIGNhdXNlcyBuZXR3b3JrIHBhcnRpdGlvbiBhbmQgQSBp cyBuZWl0aGVyIHJlY2hhcmdlYWJsZSBub3IgcmVwbGFjZWFibGUuIEhvd2V2ZXIsIEIgaXMgZWFz aWx5IHJlcGxhY2VhYmxlLiBUaGVuLCAxIHllYXIgb2YgdGhlIHBvd2VyIGxpZmV0aW1lIGlzIGEg cmVsYXRpdmUgdmFsdWUgdG8gYm90aCBkZXZpY2VzLiA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMTExMTExOyBGT05ULUZBTUlMWTogsby4 sjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICYjMzk7VGltZXMgTmV3IFJvbWFuJiMzOTs7IG1zby1m b250LWtlcm5pbmc6IDEuMHB0OyBtc28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWFuc2kt bGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1 YWdlOiBBUi1TQSI+VGhlcmUgbWF5IGJlIHNldmVyYWwgd2F5cyB0byBxdWFudGlmeSB0aGF0IGV2 ZW4gdGhvdWdoIHRoZXNlIGFyZSBjaGFsbGVuZ2luZy4gV2hlbiBhIGRldmljZSBpcyBwcm9kdWNl ZCBvciBkZXBsb3llZCwgc29tZSBwYXJhbWV0ZXJzIGluZGljYXRpbmcgdGhlIGRldmljZSBpcyBy ZWNoYXJnZWFibGUgb3IgcmVwbGFjZWFibGUgZWFzaWx5IG9yIG5vdCBjYW4gYmUgc2V0IG1hbnVh bGx5LiBPciBzb21lIHBhcmFtZXRlcnMgaW5kaWNhdGluZyB0aGUgcm9sZSBvZiB0aGUgZGV2aWNl IGluIHRoZSBuZXR3b3JrIGNhbiBiZSBzZXQgYnkgdGhlIGRldmljZSBpdHNlbGYgdXNpbmcgY29u dGV4dCBhd2FyZSBjYXBhYmlsaXR5IHN1Y2ggdGhhdCBpdCBjYW4gcmVjb2duaXplIGl0c2VsZiBh cyBhIHBpdm90YWwgZGV2aWNlIHRvIG1haW50YWluIG5ldHdvcmsgY29ubmVjdGl2aXR5Ljwvc3Bh bj48L3NwYW4+PC9ibG9ja3F1b3RlPgoKPGRpdj4mbmJzcDs8L2Rpdj4KPGJsb2NrcXVvdGUgY2xh c3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iUEFERElORy1MRUZUOiAxZXg7IE1BUkdJTjogMHB4IDBw eCAwcHggMC44ZXg7IEJPUkRFUi1MRUZUOiAjY2NjIDFweCBzb2xpZCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiByZWQ7IEZPTlQtRkFNSUxZOiCxvLiy OyBtc28tYmlkaS1mb250LWZhbWlseTogsby4sjsgbXNvLWJpZGktZm9udC1zaXplOiAxMi4wcHQ7 IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28t YmlkaS1sYW5ndWFnZTogQVItU0EiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogIzExMTExMTsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZvbnQt ZmFtaWx5OiAmIzM5O1RpbWVzIE5ldyBSb21hbiYjMzk7OyBtc28tZm9udC1rZXJuaW5nOiAxLjBw dDsgbXNvLWJpZGktZm9udC1zaXplOiAxMi4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsg bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjxzcGFu IGlkPSIiPjwvc3Bhbj48L3NwYW4+PC9zcGFuPiZuYnNwOyBzdWNoIHRoYXQgcG90ZW50aWFsbHkg YSBzdWJvcHRpbWFsIHBhdGggd291bGQgYmUgdXNlZCBmb3Igc29tZTxicj4KJm5ic3A7IHRyYWZm aWMgc28gYXMgdG8gaW5jcmVhc2UgdGhlIG5ldHdvcmsgbGlmZSBkdXJhdGlvbi4gJm5ic3A7RnVy dGhlcm1vcmUsIGluPGJyPjxicj5kbW0mZ3Q7IHRoaXMgaW1wbGllcyB0aGF0IHRoZSByb3V0aW5n IHByb3RvY29sIG5lZWRzIChtdXN0PykgaGF2ZSBhPGJyPmRtbSZndDsgZ2xvYmFsIHZpZXcgb2Yg dGhlIHJlc2lkdWFsIGVuZXJneSBvZiB0aGUgbmV0d29yayAobGlrZWx5PGJyPmRtbSZndDsgdGhl IHJhdGUgYXQgd2hpY2ggY2VydGFpbiBkZXZpY2VzIGFyZSBiZWluZyBkaXNjaGFyZWQgYXM8YnI+ CmRtbSZndDsgd2VsbCwgYW5kIHdoaWNoIG9uZXMgYXJlIGJhdHRlcnkgcG93ZXJlZCBhbmQgd2hp Y2ggb25lcyBhcmU8YnI+ZG1tJmd0OyBtYWlucyBwb3dlcmVkKS4gSXMgdGhhdCB3aGF0IGlzIGlu dGVuZGVkPzxicj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6IHJlZDsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiCxvLiyOyBt c28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28t ZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PT09Jmd0Ozwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J TFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiCxvLiyOyBtc28tYmlkaS1mb250LXNpemU6 IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTog S087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxMTExMTE7IEZPTlQtRkFNSUxZOiCxvLiy OyBtc28tYmlkaS1mb250LWZhbWlseTogJiMzOTtUaW1lcyBOZXcgUm9tYW4mIzM5OzsgbXNvLWZv bnQta2VybmluZzogMS4wcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tYW5zaS1s YW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3Vh Z2U6IEFSLVNBIj5UaGUgcm91dGluZyBwcm90b2NvbCBkb2VzIG5vdCBuZWVkIHRvIGhhdmUgYSBn bG9iYWwgdmlldywgYnV0IGl0IGp1c3QgbmVlZHMgdG8gY2hvb3NlIHRoZSBiZXN0IG5leHQgaG9w IGFtb25nIHBvc3NpYmxlIGNhbmRpZGF0ZXMuPC9zcGFuPjwvYmxvY2txdW90ZT4KCjxkaXY+PGJy PiZuYnNwOyBjYXNlIGFic2VuY2Ugb2YgdGhlIG5vZGUgYWZmZWN0cyB0aGUgbmV0d29yayBjb25u ZWN0aXZpdHkgY3JpdGljYWxseSw8YnI+Jm5ic3A7IHRoZSBub2RlIFNIT1VMRCBiZSBhdm9pZGVk IHRvIHNhdmUgaXRzIHBvd2VyLiAmbmJzcDtIZW5jZSwgd2hlbmV2ZXI8YnI+Jm5ic3A7IHBvc3Np YmxlLCB0aGUgbm9kZSBzaG91bGQgbm90IGJlIHNlbGVjdGVkIGFzIGEgcm91dGVyIChhbjxicj4m bmJzcDsgaW50ZXJtZWRpYXRlIG5vZGUgdG8gZGVsaXZlciBkYXRhKSwgdGh1cyB0aGUgc3VwcG9y dCBmb3IgY29uc3RyYWluZWQtPGJyPgombmJzcDsgYmFzZWQgcm91dGluZyBpcyBuZWVkZWQuICZu YnNwO0lmIHRoZSBiYXR0ZXJ5IGNhbiBiZSBzaW1wbHkgY2hhcmdlZCBvciB0aGU8YnI+Jm5ic3A7 IG5vZGUgY2FuIGJlIGVhc2lseSByZXBsYWNlZCB3aXRoIGFub3RoZXIgc2FtZSBraW5kIG9mIG5v ZGUsIHRoZW4gaXQ8YnI+Jm5ic3A7IGlzIG5vdCByZWFsbHkgYSBtYXR0ZXIgdG8gdXNlIHVwIHRo ZSBiYXR0ZXJ5LiAmbmJzcDtTdWNoIGluZm9ybWF0aW9uPGJyPiZuYnNwOyBzaG91bGQgYmUgZGVm aW5lZCBhcyBhIG5vZGUgYXR0cmlidXRlIHRvIGJlIHVzZWQgaW4gY29tYmluYXRpb24gd2l0aDxi cj4KJm5ic3A7IHRoZSBlbmVyZ3kgbGV2ZWwuICZuYnNwO0FsZ29yaXRobXMgZGVmaW5pbmcgaG93 IHN1Y2ggbWV0cmljcyBhbmQ8YnI+Jm5ic3A7IGF0dHJpYnV0ZXMgc2hvdWxkIGJlIGNvbWJpbmVk IGFyZSBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiB0aGlzPGJyPiZuYnNwOyBkb2N1bWVudC48YnI+ PGJyPiZuYnNwOyBHZW5lcmFsbHksIHRoZSByZXNpZHVhbCBlbmVyZ3kgc2hvdWxkIGJlIHRha2Vu IGFzIGEgZHluYW1pYyBtZXRyaWMuPGJyPgombmJzcDsgTW9zdCBiYXR0ZXJ5IG9wZXJhdGVkIGRl dmljZXMgaGF2ZSBhYmlsaXR5IHRvIGVzdGltYXRlIHRoZSByZW1haW5pbmc8YnI+Jm5ic3A7IGVu ZXJneSBbSS1ELmlldGYtcm9sbC1pbmR1cy1yb3V0aW5nLXJlcXNdLiAmbmJzcDtIb3dldmVyLCBp bml0aWFsIGVuZXJneTxicj4mbmJzcDsgc3RhdHVzIGNhbiBiZSBjb25zaWRlcmVkIGFzIGEgc3Rh dGljIG1ldHJpYyBpbiBzb21lIHNpdHVhdGlvbnMgd2hlcmU8YnI+CiZuYnNwOyBtb25pdG9yaW5n IGN1cnJlbnQgZW5lcmd5IHN0YXR1cyBkZW1hbmRzIHF1aXRlIHJlc291cmNlcy4gJm5ic3A7U2lt cGx5PGJyPiZuYnNwOyBjYXRlZ29yaXppbmcgZGV2aWNlcyBpbnRvIHR3byBjbGFzc2VzLCBtYWlu LXBvd2VyZWQgYW5kIGJhdHRlcnktPGJyPiZuYnNwOyBwb3dlcmVkLCBjYW4gYmUgZ29vZCBlbm91 Z2ggdG8gc2VsZWN0IGEgcm91dGluZyBwYXRoIGZvciBoaWdobHk8YnI+Jm5ic3A7IGNvbnN0cmFp bmVkIHNjZW5hcmlvcywgd2hpY2ggY29udHJpYnV0ZXMgdG8gcHJvbG9uZ2luZyBuZXR3b3JrPGJy PgombmJzcDsgbGlmZXRpbWUuICZuYnNwO1RvIG1heGltaXplIG5ldHdvcmsgbGlmZXRpbWUsIGl0 IGlzIGVzc2VudGlhbCB0byBtYWludGFpbjxicj4mbmJzcDsgZW5lcmd5IGJhbGFuY2UgYW1vbmcg bm9kZXMgaW4gTExOcy48YnI+ZG1tJmd0OyBeXl5eXl5eXl5eXl48YnI+ZG1tJmd0OyBob3cgaXMg JnF1b3Q7ZW5lcmd5IGJhbGFuY2UmcXVvdDsgZGVmaW5lZD88YnI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiByZWQ7IEZPTlQtRkFNSUxZOiCxvLiyOyBt c28tYmlkaS1mb250LWZhbWlseTogsby4sjsgbXNvLWJpZGktZm9udC1zaXplOiAxMi4wcHQ7IG1z by1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlk aS1sYW5ndWFnZTogQVItU0EiPj09PSZndDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiyOyBtc28tYmlkaS1mb250LWZhbWls eTogsby4sjsgbXNvLWJpZGktZm9udC1zaXplOiAxMi4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBF Ti1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0Ei PiA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9S OiAjMTExMTExOyBGT05ULUZBTUlMWTogsby4sjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICYjMzk7 VGltZXMgTmV3IFJvbWFuJiMzOTs7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYmlkaS1m b250LXNpemU6IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1s YW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+SSBtYXkgc2F5IHRoZSBhbW91 bnRzIG9mIHJlc2lkdWFsIGVuZXJneSBvZiBhbGwgbm9kZXMgaW4gdGhlIG5ldHdvcmsgYXJlIGZh aXJseSBldmVuLjwvc3Bhbj48YnI+Cjxicj48YnI+S2ltLCBldCBhbC4gJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RXhwaXJlcyBKYW51YXJ5IDUsIDIwMDkg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tQ YWdlIDZdPGJyPjxicj5JbnRlcm5ldC1EcmFmdCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Um91dGluZyBNZXRyaWNzIGZvciBMTE5zICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBKdWx5IDIwMDg8YnI+PGJyPjxicj40LjMuICZuYnNwO0N1 cnJlbnQgd29ya2xvYWQ8YnI+PGJyPiZuYnNwOyBXb3JrbG9hZCBvZiBhIG5vZGUgaXMgc29tZXdo YXQgZGlmZmljdWx0IHRvIGJlIG1lYXN1cmVkIGFuZCBjb21wYXJlZC48YnI+CiZuYnNwOyBJdCBp cyBhbHNvIGRpZmZpY3VsdCB0byBleHByZXNzIHRoZSB3b3JrbG9hZCBpbiBhIHF1YW50aXRhdGl2 ZSBmb3JtLjxicj4mbmJzcDsgSG93ZXZlciwgaXQgY291bGQgYmUgYW4gaW1wb3J0YW50IG1ldHJp YyB0byBzZWxlY3QgYSBwYXRoIGluIExMTnMsPGJyPiZuYnNwOyBlc3BlY2lhbGx5IHdoZW4gZGF0 YSBwcm9jZXNzaW5nIGFsb25nIHRoZSBkYXRhIHBhdGggaXMgcmVxdWlyZWQgb3I8YnI+Jm5ic3A7 IHF1ZXVpbmcgZGVsYXlzIG11c3QgYmUgbWluaW1pemVkIGZvciBoaWdobHkgc2Vuc2l0aXZlIHRy YWZmaWMuPGJyPgombmJzcDsgUHV0dGluZyB0aGUgd29ya2xvYWQgYXMgYSAmcXVvdDtoZWF2eSZx dW90OyBvciAmcXVvdDtsaWdodCZxdW90OyBvbmUgYml0IG1ldHJpYyBjYW4gZ2l2ZTxicj4mbmJz cDsgYSBnb29kIGFkdmljZSB0byBzZWxlY3QgYSBwYXRoIGZvciByb3V0aW5nLCB0aHVzIHByb3Zp ZGluZyBhPGJyPiZuYnNwOyBzdWZmaWNpZW50IGxldmVsIG9mIGdyYW51bGFyaXR5LCBzaW1pbGFy bHkgdG8gdGhlICZxdW90O292ZXJsb2FkJnF1b3Q7IGJpdCB1c2VkPGJyPgombmJzcDsgaW4gcHJv dG9jb2xzIHN1Y2ggYXMgSVMtSVMuICZuYnNwO0FuIGltcGxlbWVudGF0aW9uIG1heSB0aGVuIGRl Y2lkZSB0bzxicj5kbW0mZ3Q7IG1pZ2h0IGJlIHVzZWZ1bCB0byBjaXRlIGRvY3VtZW50cyB0aGF0 IGRlZmluZSB0aGUgSVMtSVM8YnI+ZG1tJmd0OyBvdmVybG9hZCBiaXQuPGJyPiZuYnNwOyBleGNs dWRlIGZyb20gaXRzIHJvdXRlcyBhbnkgbm9kZSB3aXRoIGEgJnF1b3Q7aGVhdnkmcXVvdDsgdmFs dWUgZm9yIHdvcmtsb2FkPGJyPgombmJzcDsgdW5sZXNzIHRoZXJlIGlzIG5vIGFsdGVybmF0aXZl Ljxicj48YnI+NC40LiAmbmJzcDtOb2RlIGxhdGVuY3k8YnI+PGJyPiZuYnNwOyBOb2RlIGxhdGVu Y3kgaXMgdGhlIHRpbWUgc3BhbiBmcm9tIHRoZSBhcnJpdmFsIHRpbWUgdG8gdGhlIGRlcGFydHVy ZTxicj4mbmJzcDsgdGltZSBvZiBhIGdpdmVuIHBhY2tldCBhdCBhIG5vZGUuICZuYnNwO0l0IGlz IHByaW1hcmlseSBtYWRlIHVwIG9mIHBhY2tldDxicj4mbmJzcDsgcHJvY2Vzc2luZyB0aW1lIGFu ZCBwYWNrZXQgdHJhbnNtaXNzaW9uIHRpbWUuICZuYnNwO05vZGUgbGF0ZW5jeSBpcyBoaWdobHk8 YnI+CiZuYnNwOyBjb3JyZWxhdGVkIHdpdGggb3RoZXIgbWV0cmljcy4gJm5ic3A7Rm9yIGluc3Rh bmNlLCBoZWF2eSB3b3JrbG9hZDxicj4mbmJzcDsgaW5jcmVhc2VzIG5vZGUgbGF0ZW5jeSB3aGls ZSBlbm91Z2ggY29tcHV0YXRpb25hbCByZXNvdXJjZXMgY2FuPGJyPiZuYnNwOyByZWR1Y2UgaXQu ICZuYnNwO1RoZXJlZm9yZSwgaW4gc29tZSBMTE5zIHdoZXJlIGF2YWlsYWJsZSByZXNvdXJjZXMg YW5kPGJyPiZuYnNwOyBjdXJyZW50IHdvcmtsb2FkIGNhbiBiZSBtZWFzdXJlZCwgdGhleSBjYW4g ZmFjaWxpdGF0ZSB0byBlc3RpbWF0ZTxicj4KJm5ic3A7IG5vZGUgbGF0ZW5jeSBvciBtYXkgc3Vi c3RpdHV0ZSBpdC48YnI+PGJyPjQuNS4gJm5ic3A7RGF0YSBBZ2dyZWdhdGlvbiBhdHRyaWJ1dGU8 YnI+PGJyPiZuYnNwOyBTb21lIG5vZGVzIG1heSBzZW5zZSAoZ2V0KSBzaW1pbGFyIG9yIHNhbWUg ZGF0YSBpZiB0aGUgbm9kZXMgYXJlPGJyPmRtbSZndDsgcy8oZ2V0KSBzaW1pbGFyIG9yIHNhbWUg L29yIHJlY2VpdmUgdGhlIHNhbWUgKG9yIHNpbWlsYXIpPGJyPgombmJzcDsgbG9jYXRlZCBpbiBh IGNsb3NlIGFyZWEgZHVlIHRvIGRhdGEgY29ycmVsYXRpb24uPGJyPmRtbSZndDsgQlRXLCB0aGlz IGlzIGZyZXF1ZW50bHkgY2FsbGVkICZxdW90O292ZXJsYXAmcXVvdDsgaW4gdGhlPGJyPmRtbSZn dDsgbGl0ZXJhdHVyZS4gU2VlIGUuZS4sICZxdW90O0FkYXB0aXZlIFByb3RvY29scyBmb3IgSW5m b3JtYXRpb248YnI+ZG1tJmd0OyBEaXNzZW1pbmF0aW9uIGluIFdpcmVsZXNzIFNlbnNvciBOZXR3 b3JrcyZxdW90OywgSm9hbm5hIEt1bGlrLDxicj4KZG1tJmd0OyBXZW5kaSBSYWJpbmVyLCBIYXJp IEJhbGFrcmlzaG5hbiwxOTk5PGJyPmRtbSZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5jcy53YXNo aW5ndG9uLmVkdS9lZHVjYXRpb24vY291cnNlcy81OTBlcy8wMWF1L3BhcGVycy8yLnBkZiIgdGFy Z2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuY3Mud2FzaGluZ3Rvbi5lZHUvZWR1Y2F0aW9uL2NvdXJz ZXMvNTkwZXMvMDFhdS9wYXBlcnMvMi5wZGY8L2E+PGJyPgo8YnI+PGJyPiZuYnNwOyBUaHVzLCBk YXRhPGJyPiZuYnNwOyBhZ2dyZWdhdGlvbi9mdXNpb24gY2FuIGJlIHBlcmZvcm1lZC4gJm5ic3A7 RGF0YSBmdXNpb24gaW52b2x2ZXMgbW9yZTxicj5kbW0mZ3Q7IHMvY2FuIGJlIHBlcmZvcm1lZC9t YXkgYmUgcG9zc2libGUvPGJyPiZuYnNwOyBjb21wbGljYXRlZCBwcm9jZXNzaW5nIHRvIGltcHJv dmUgYWNjdXJhY3kgb2YgdGhlIG91dHB1dCBkYXRhIHdoaWxlPGJyPiZuYnNwOyBkYXRhIGFnZ3Jl Z2F0aW9uIG1vc3RseSBhaW1zIHRvIHJlZHVjZSB0aGUgYW1vdW50IG9mIGRhdGEuPGJyPgombmJz cDsgRXNwZWNpYWxseSBpbiB1cmJhbiBhcHBsaWNhdGlvbnMgd2hlcmUgc2Vuc29yIG5vZGVzIGNv bGxlY3Q8YnI+ZG1tJmd0OyBzL0VzcGVjaWFsbHkvU2Vuc2luZyBvdmVybGFwIGlzIGNvbW1vbi88 L2Rpdj4KPGRpdj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6IHJlZDsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiCxvLiyOyBt c28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28t ZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PT09Jmd0OyA8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAj MTExMTExOyBGT05ULUZBTUlMWTogsby4sjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICYjMzk7VGlt ZXMgTmV3IFJvbWFuJiMzOTs7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYmlkaS1mb250 LXNpemU6IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5n dWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+RXZlbiB0aG91Z2ggIm92ZXJsYXAi IGlzIGZyZXF1ZW50bHkgdXNlZCBpbiB0aGUgbGl0ZXJhdHVyZSwgd2UgbWlnaHQgbmVlZCBhIGRl ZmluaXRpb24gZm9yIHRoZSB0ZXJtIGlmIHdlIHdhbnQgdG8gdXNlIGl0IGhlcmUuJm5ic3A7SSBj YW5ub3Qgc2VlIGFueSByZWFzb24gdG8gdXNlIHRoZSB0ZXJtICJvdmVybGFwIiBoZXJlLCB0aG91 Z2guIEFuZCB0aGUgc3VnZ2VzdGVkIHN1YnN0aXR1dGlvbiByZXN1bHRzIGluIGNvbm5lY3Rpb24g b2YgdHdvIHNlbnRlbmNlcyB1c2luZyBjb21tYSwgd2hpY2ggaXMgaW5jb3JyZWN0Ljwvc3Bhbj48 L2Rpdj4KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAj MTExMTExOyBGT05ULUZBTUlMWTogsby4sjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICYjMzk7VGlt ZXMgTmV3IFJvbWFuJiMzOTs7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYmlkaS1mb250 LXNpemU6IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5n dWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PC9zcGFuPgo8ZGl2Pjxicj4mbmJz cDsgZW52aXJvbm1lbnRhbCBpbmZvcm1hdGlvbiBhbmQgc2VuZCBpdCB0byBhIGRhdGEgc2luaywg cXVpdGUgYSBudW1iZXI8YnI+Jm5ic3A7IG9mIHNlbnNvciBub2RlcyBzZW5zZSBzYW1lIGtpbmQg b3Igc2FtZSB2YWx1ZSBvZiBkYXRhLiAmbmJzcDtJbiB0aGUgRmlndXJlPGJyPiZuYnNwOyAxLCBs ZXQgdXMgYXNzdW1lIHRoYXQgdGhyZWUgbm9kZXMgQSwgQiBhbmQgQyBuZWVkIHRvIHNlbmQgc2Vu c2VkIGRhdGE8YnI+CiZuYnNwOyB0byB0aGUgZGF0YSBzaW5rLiAmbmJzcDtOb2RlIEEgc2Vuc2Vk ICZxdW90O3h5eiZxdW90OyBhbmQgc2VudCB0aGlzIGRhdGEgdG8gbm9kZSBDLjxicj4mbmJzcDsg U2luY2UgQyBhbHNvIHNlbnNlZCBzYW1lIGRhdGEsIGl0IGhhcyBubyBhZGRpdGlvbmFsIGluZm9y bWF0aW9uIGZyb208YnI+Jm5ic3A7IG5vZGUgQS4gSG93ZXZlciwgYmVjYXVzZSB0aGUgZGF0YSBu b2RlIEIgc2VudCBpcyAmcXVvdDt4cXomcXVvdDssIG5vZGUgQzxicj4KJm5ic3A7IGFnZ3JlZ2F0 ZXMgdGhpcyBkYXRhIHdpdGggaXRzIG93biBkYXRhICZxdW90O3h5eiZxdW90OyByZXN1bHRpbmcg aW4gJnF1b3Q7eHlxeiZxdW90Oy48YnI+Jm5ic3A7IFRoZXJlZm9yZSwgbm9kZSBDIHNlbmRzICZx dW90O3h5cXomcXVvdDsgdG8gdGhlIGRhdGEgc2luay4gJm5ic3A7SW4gdGhpcyBleGFtcGxlLDxi cj4mbmJzcDsgZWFjaCBub2RlJiMzOTtzIGRhdGEgcmVxdWlyZXMgMyBieXRlcy4gJm5ic3A7SWYg bm8gYWdncmVnYXRpb24gaXMgcGVyZm9ybWVkLDxicj4KJm5ic3A7IG5vZGUgQyBuZWVkcyB0byBz ZW5kIDkgYnl0ZSBkYXRhIHRvIHRoZSBzaW5rLCBidXQgQyBvbmx5IHNlbmRzIDQ8YnI+Jm5ic3A7 IGJ5dGVzIHRoYW5rcyB0byBkYXRhIGFnZ3JlZ2F0aW9uLjxicj48YnI+PGJyPjxicj48YnI+PGJy Pjxicj48YnI+S2ltLCBldCBhbC4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7RXhwaXJlcyBKYW51YXJ5IDUsIDIwMDkgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tQYWdlIDddPGJyPjxicj5JbnRlcm5l dC1EcmFmdCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Um91dGluZyBNZXRyaWNz IGZvciBMTE5zICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBKdWx5IDIwMDg8YnI+Cjxicj48YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO0EgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IEI8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfC0tLS0tLXwgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7fC0tLS0tLXw8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCB4eXog Jm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8IHhxeiAmbmJzcDt8PGJyPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHxfX19fX198ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3xfX19fX198PGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IFwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy88YnI+CiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1wgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Lzxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgXCAmbmJzcDtDICZuYnNwOyAvICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHNpbms8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwtLS0tLS18ICZuYnNwOyAmbmJzcDt4eXF6ICZu YnNwOyB8LS0tLS0tfDxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfCB4eXogJm5ic3A7fC0tLS0tLS0tLS0tfCAmbmJzcDsgJm5ic3A7ICZu YnNwO3w8YnI+CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8X19fX19ffCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHxfX19f X198PGJyPjxicj48YnI+PGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RmlndXJlIDE6IERh dGEgYWdncmVnYXRpb248YnI+PGJyPiZuYnNwOyBTb21lIGFwcGxpY2F0aW9ucyBNQVkgbWFrZSB1 c2Ugb2YgdGhlIGFnZ3JlZ2F0aW9uIG5vZGUgYXR0cmlidXRlIGluPGJyPiZuYnNwOyB0aGVpciBy b3V0aW5nIGRlY2lzaW9uIHNvIGFzIHRvIG1pbmltaXplIHRoZSBhbW91bnQgb2YgdHJhZmZpYyBv biB0aGU8YnI+CiZuYnNwOyBuZXR3b3JrLCB0aHVzIHBvdGVudGlhbGx5IGluY3JlYXNpbmcgaXRz IGxpZmUgdGltZSBpbiBiYXR0ZXJ5PGJyPiZuYnNwOyBvcGVyYXRlZCBlbnZpcm9ubWVudHMuPGJy Pjxicj5kbW0mZ3Q7IFNvIHRoaXMgaXMgYSBmb3JtIG9mIGRhdGEtYXdhcmUgcm91dGluZy4gSG93 IGZhciB0byB3ZSB0aGluazxicj5kbW0mZ3Q7IHdlIG5lZWQgdG8gZ28gaW4gdGhpcyBkaXJlY3Rp b24/IEkgZGlkIG5vdGljZSB0aGF0PGJyPgpkbW0mZ3Q7IEktRC5pZXRmLXJvbGwtaW5kdXMtcm91 dGluZy1yZXFzIGFsc28gc3VnZ2VzdHMgdGhlIG5lZWQgZm9yPGJyPmRtbSZndDsgZGF0YS1hd2Fy ZSByb3V0aW5nLjwvZGl2Pgo8ZGl2PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogcmVkOyBGT05ULUZBTUlMWTogsby4sjsgbXNvLWJpZGktZm9udC1mYW1p bHk6ILG8uLI7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTog RU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNB Ij49PT0mZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogsby4sjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ILG8uLI7IG1zby1iaWRp LWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0 LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj4gPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzExMTExMTsgRk9OVC1G QU1JTFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAmIzM5O1RpbWVzIE5ldyBSb21hbiYj Mzk7OyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMi4wcHQ7 IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28t YmlkaS1sYW5ndWFnZTogQVItU0EiPkkgZG8gYWdyZWUgdGhhdCBkYXRhLWF3YXJlIHJvdXRpbmcg aXMgdmVyeSBjaGFsbGVuZ2luZyBlc3BlY2lhbGx5IHdpdGggcmVzb3VyY2UgY29uc3RyYWludHMu IEFzIEkgbWVudGlvbmVkIGJlbG93LCB3ZSBuZWVkIHRvIG1ha2UgdGhlIGRhdGEgYWdncmVnYXRp b24gbWVjaGFuaXNtIGFzIHNpbXBsZSBhcyBwb3NzaWJsZSB0byByZWR1Y2Ugb3ZlcmhlYWQuIEZ1 cnRoZXIgZGlzY3Vzc2lvbiBpcyBuZWVkZWQuIDwvc3Bhbj48L2Rpdj4KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMTExMTExOyBGT05ULUZBTUlMWTog sby4sjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICYjMzk7VGltZXMgTmV3IFJvbWFuJiMzOTs7IG1z by1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWFu c2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxh bmd1YWdlOiBBUi1TQSI+PC9zcGFuPgo8ZGl2Pjxicj5kbW0mZ3Q7PGJyPmRtbSZndDsgRm9yIGEg Z29vZCBkaXNjdXNzaW9uIG9mIChzb21lIG9mIHRoZSkgaXNzdWVzcywgc2VlLCBlLmcuLDxicj5k bW0mZ3Q7PGJyPmRtbSZndDsgJnF1b3Q7RGlyZWN0ZWQgRGlmZnVzaW9uOiBBIHNjYWxhYmxlIGFu ZCByb2J1c3QgY29tbXVuaWNhdGlvbjxicj5kbW0mZ3Q7IHBhcmFkaWdtIGZvciBzZW5zb3IgbmV0 d29ya3MmcXVvdDssIFJhbWVzaCBHb3ZpbmRhbiwgRGVib3JhaDxicj4KZG1tJmd0OyBFc3RyaW4s IDIwMDAgPGEgaHJlZj0iaHR0cDovL25ldHdlYi51c2MuZWR1L2VzdHJpbi9wYXBlcnMvZGlmZnVz aW9uLnBzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL25ldHdlYi51c2MuZWR1L2VzdHJpbi9wYXBl cnMvZGlmZnVzaW9uLnBzPC9hPjxicj5kbW0mZ3Q7PGJyPmRtbSZndDsgKGl0cyBqdXN0IG9uZSBz dWNoIGFwcHJvYWNoKTxicj48YnI+Jm5ic3A7IFRvIG1ha2UgZGF0YSBhZ2dyZWdhdGlvbiBwb3Nz aWJsZSwgdGhlIHJvdXRpbmcgcHJvdG9jb2wgbmVlZHMgdG88YnI+CiZuYnNwOyBjYXB0dXJlIHRo ZSB0aW1lIGFuZCBsb2NhdGlvbiBkZXBlbmRlbnQgY29ycmVsYXRpb24gYW1vbmcgc2Vuc2VkIGRh dGE8YnI+Jm5ic3A7IGZyb20gbm9kZXMgb24gdGhlIHBvc3NpYmxlIHJvdXRlcywgd2hpY2ggaXMg cXVpdGUgY2hhbGxlbmdpbmcuPGJyPiZuYnNwOyBPYnRhaW5pbmcgY29ycmVsYXRpb24gc3RydWN0 dXJlIGFsc28gZGVtYW5kcyBoaWdoIHJlc291cmNlIChlbmVyZ3kpPGJyPiZuYnNwOyBjb25zdW1w dGlvbiBhbmQgaW4tbmV0d29yayBwcm9jZXNzaW5nIGl0c2VsZiBtYXkgaGF2ZSBoaWdoPGJyPgom bmJzcDsgY29tcGxleGl0eS4gJm5ic3A7Q29uc2VxdWVudGx5LCBpbiBtb3N0IGFwcGxpY2F0aW9u cywgZGF0YSBhZ2dyZWdhdGlvbiBtYXk8YnI+Jm5ic3A7IG5vdCBiZSBhZG9wdGVkIGZvciByb3V0 aW5nLiAmbmJzcDtIb3dldmVyLCBzaW1wbHkgY2hvb3Npbmcgbm9kZXMgdGhhdCBoYXZlPGJyPiZu YnNwOyB0aGUgc2FtZSBraW5kIG9mIHNlbnNvcnMgd2l0aCB0aGUgc291cmNlIG5vZGUgY2FuIGlu Y3JlYXNlIHRoZSBjaGFuY2U8YnI+CiZuYnNwOyB0byBhZ2dyZWdhdGUgZGF0YSwgc28gaXQgY2Fu IGJlIGhlbHBmdWwgZm9yIHBhdGggZm9ybWF0aW9uIHJlZ2FyZGxlc3M8YnI+Jm5ic3A7IG9mIGhh dmluZyBkYXRhLWF3YXJlIHJvdXRpbmcgY2FwYWJpbGl0eS48YnI+PGJyPmRtbSZndDsgbmljZSBo ZXVyaXN0aWMuIERvIHdlIGhhdmUgYSBjaXRhdGlvbiB0aGF0IGV4YW1pbmVzIHRoZTxicj5kbW0m Z3Q7IHVzZSBvZiB0aGlzIGhldXJpc3RpYz88YnI+CjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogcmVkOyBGT05ULUZBTUlMWTogsby4sjsgbXNvLWJpZGkt Zm9udC1mYW1pbHk6ILG8uLI7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tYW5zaS1s YW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3Vh Z2U6IEFSLVNBIj49PT0mZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogsby4sjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ILG8uLI7 IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1z by1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj4gPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzExMTEx MTsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAmIzM5O1RpbWVzIE5l dyBSb21hbiYjMzk7OyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWJpZGktZm9udC1zaXpl OiAxMi4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 IEtPOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPk5vLCB1bmZvcnR1bmF0ZWx5IHdlIGRvIG5v dCBoYXZlIGEgY2l0YXRpb24uIFRoaXMgaXMganVzdCBhbiBpZGVhLjwvc3Bhbj48L2Rpdj4KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMTExMTExOyBG T05ULUZBTUlMWTogsby4sjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICYjMzk7VGltZXMgTmV3IFJv bWFuJiMzOTs7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYmlkaS1mb250LXNpemU6IDEy LjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087 IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PC9zcGFuPgo8ZGl2Pjxicj4mbmJzcDsgQXBwbGlj YXRpb25zIHdoZXJlIGhpZ2ggZGlyZWN0aW9uYWwgZGF0YSBmbG93IGlzIGV4cGVjdGVkIGluIGE8 YnI+Jm5ic3A7IHJlZ3VsYXIgYmFzaXMgbWF5IHRha2UgYWR2YW50YWdlIG9mIGRhdGEgYWdncmVn YXRpb24gc3VwcG9ydGVkPGJyPiZuYnNwOyByb3V0aW5nLjxicj48YnI+NC42LiAmbmJzcDtOb2Rl IGRlZ3JlZTxicj48YnI+Jm5ic3A7IE5vZGUgZGVncmVlIGlzIHRoZSBudW1iZXIgb2YgbmVpZ2hi b3JzIHRoYXQgY2FuIHNlbmQgYSBtZXNzYWdlIHRvIHRoZTxicj4KJm5ic3A7IG5vZGUgZGlyZWN0 bHkuICZuYnNwO0luIG90aGVyIHdvcmRzLCBuZWlnaGJvcnMgYXJlIG5vZGVzIGxvY2F0ZWQgd2l0 aGluPGJyPiZuYnNwOyB0aGUgdHJhbnNtaXNzaW9uIHJhbmdlIG9mIHRoZSBub2RlLiAmbmJzcDtH ZW5lcmFsbHksIGEgaGlnaCBub2RlIGRlZ3JlZTxicj4mbmJzcDsgY2FuIGJlIGhlbHBmdWwgZm9y IHF1aWNrIHJvdXRlIHJlY292ZXJ5IHdoZW4gdGhlIG5leHQgaG9wIG5vZGUgb24gdGhlPGJyPiZu YnNwOyByb3V0ZSBjYW5ub3QgYmUgYWNjZXNzaWJsZS4gJm5ic3A7VGhlcmVmb3JlLCBpdCBtYXkg YmUgYmVuZWZpY2lhbCB0bzxicj4KJm5ic3A7IGNob29zZSBhIG5vZGUgd2l0aCBhIGhpZ2ggZGVn cmVlIHRvIGNvbnN0cnVjdCBhIHJvdXRlLiAmbmJzcDtPbiB0aGU8YnI+Jm5ic3A7IGNvbnRyYXJ5 LCBhIG5vZGUgd2l0aCBhIGhpZ2ggZGVncmVlIGhhcyBhIGhpZ2ggcG9zc2liaWxpdHkgdG8gaGF2 ZTxicj4mbmJzcDsgaGVhdnkgd29ya2xvYWQgaW4gYSBidXN5IG5ldHdvcmsuICZuYnNwO1RoZXJl Zm9yZSwgbm9kZSBkZWdyZWUgaGFzIHRvIGJlPGJyPiZuYnNwOyBjYXJlZnVsbHkgdXRpbGl6ZWQg aW4gcm91dGluZyBkZWNpc2lvbi48YnI+Cjxicj5kbW0mZ3Q7IGJhc2ljYWxseSB0aGlzIGlzIGFu ICZxdW90O2FtcGxpY2F0aW9uIGVmZmVjdCZxdW90OyBbUkZDIDM0MzldPGJyPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogcmVkOyBGT05ULUZBTUlMWTog sby4sjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ILG8uLI7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIu MHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsg bXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj49PT0mZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogsby4sjsgbXNvLWJpZGktZm9u dC1mYW1pbHk6ILG8uLI7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tYW5zaS1sYW5n dWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6 IEFSLVNBIj4gPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBDT0xPUjogIzExMTExMTsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5 OiAmIzM5O1RpbWVzIE5ldyBSb21hbiYjMzk7OyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNv LWJpZGktZm9udC1zaXplOiAxMi4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPnlvdSBtZWFuIGFt cGxpZmljYXRpb24/IEFjdHVhbGx5IEkgaGF2ZSBub3Qgc2VlbiB0aGUgcmVmZXJlbmNlLiBEbyB5 b3UgdGhpbmsgaXQncyBiZXR0ZXIgdG8gaW5jbHVkZSB0aGUgY2l0YXRpb24/IDwvc3Bhbj48L2Rp dj4KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMTEx MTExOyBGT05ULUZBTUlMWTogsby4sjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICYjMzk7VGltZXMg TmV3IFJvbWFuJiMzOTs7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYmlkaS1mb250LXNp emU6IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFn ZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PC9zcGFuPgo8ZGl2Pjxicj48YnI+S2lt LCBldCBhbC4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 RXhwaXJlcyBKYW51YXJ5IDUsIDIwMDkgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tQYWdlIDhdPGJyPjxicj5JbnRlcm5ldC1EcmFmdCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Um91dGluZyBNZXRyaWNzIGZvciBMTE5zICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBKdWx5IDIwMDg8 YnI+PGJyPjxicj40LjcuICZuYnNwO0R5bmFtaWNpdHk8YnI+PGJyPiZuYnNwOyBOb2RlIGR5bmFt aWNpdHkgY2FuIGJlIG1lYXN1cmVkIGJ5IG1hbnkgZGlmZmVyZW50IGZhY3RvcnMgc3VjaCBhczxi cj4KJm5ic3A7IG1vYmlsaXR5LCB0cmFuc21pc3Npb24gcmFuZ2UsIGR1dHkgY3ljbGUsIGFuZCB0 aGUgcmF0ZSBhdCB3aGljaCBub2RlPGJyPiZuYnNwOyBqb2lucyBhbmQgbGVhdmVzIHRoZSBuZXR3 b3JrLiAmbmJzcDtOb2RlIGR5bmFtaWNpdHkgZGlyZWN0bHkgYWZmZWN0cyB0aGU8YnI+Jm5ic3A7 IG5ldHdvcmsgdG9wb2xvZ3kgYW5kIGNvbm5lY3Rpdml0eSwgd2hpY2ggaW4gdHVybiBtYXkgdHJp Z2dlciByb3V0ZTxicj4mbmJzcDsgcmVlc3RhYmxpc2htZW50IHByb2Nlc3MuICZuYnNwO0ZvciB0 aGF0IHJlYXNvbiwgbm9kZSBkeW5hbWljaXR5IG5lZWRzIHRvPGJyPgombmJzcDsgYmUgbW9uaXRv cmVkIGFuZCBwcmVzZW50ZWQgaW4gYSBxdWFudGl0eSBmb3JtIHV0aWxpemluZyBhIHdlbGw8YnI+ ZG1tJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBe Xl5eXl5eXjxicj5kbW0mZ3Q7IERvIHlvdSBtZWFuIHF1YW50YXRpdmUgKHYuIHF1YWxhdGF0aXZl KT88YnI+PGJyPiZuYnNwOyBkZWZpbmVkIG9iamVjdGl2ZSBmdW5jdGlvbi4gJm5ic3A7VGh1cywg bGVzcyBkeW5hbWljIG5vZGVzIHNob3VsZCBiZTxicj4KJm5ic3A7IHByZWZlcnJlZCBmb3IgcGF0 aCBzZWxlY3Rpb24uPGJyPmRtbSZndDsgaXMgdGhhdCB0cnVlLCBldmVuIGlmIGEgbW9yZSAmcXVv dDtkeW5hbWljJnF1b3Q7IHBhdGggaGFzIGJldHRlciAob3B0aW1pemVzKTxicj5kbW0mZ3Q7IHJl c2lkdWFsIGVuZXJneSBvciBzb21lIG90aGVyIG1ldHJpYyBvZiBpbnRlcmVzdD8gaS5lLiwgaXM8 YnI+ZG1tJmd0OyB0aGUgc3RhdGVtZW50IHRvbyBnZW5lcmFsPzwvZGl2PgoKPGRpdj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IHJlZDsgRk9OVC1GQU1J TFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiCxvLiyOyBtc28tYmlkaS1mb250LXNpemU6 IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTog S087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PT09Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRp LWZvbnQtZmFtaWx5OiCxvLiyOyBtc28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWFuc2kt bGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1 YWdlOiBBUi1TQSI+IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6ICMxMTExMTE7IEZPTlQtRkFNSUxZOiCxvLiyOyBtc28tYmlkaS1mb250LWZh bWlseTogJiMzOTtUaW1lcyBOZXcgUm9tYW4mIzM5OzsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7 IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1z by1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5EeW5hbWlj aXR5IGlzIGp1c3Qgb25lIG1ldHJpYy4gQW5kIHdlIGhhdmUgbW9yZSBtZXRyaWNzIHRvIGJlIHVz ZWQgaW4gcGF0aCBjYWxjdWxhdGlvbi4gVGh1cywgd2UgbmVlZCBhIHdlaWdodCBmb3IgZWFjaCBt ZXRyaWMuIFRoZSBzZW50ZW5jZSBkb2VzIG5vdCBzYXkgdGhhdCBkeW5hbWljaXR5IGlzIHRoZSBt b3N0IGltcG9ydGFudCBtZXRyaWMgb3ZlciBvdGhlciBtZXRyaWNzLjwvc3Bhbj48YnI+Cjxicj4m bmJzcDsgSW4gdGhlIG1vc3QgY29uc3RyYWluZWQgTExOIGVudmlyb25tZW50cywgY2xhc3NpZnlp bmcgbm9kZXM8YnI+Jm5ic3A7IGludG8gb25seSBzdGF0aWMgYW5kIGR5bmFtaWMgY2FuIGJlIHZl cnkgaGVscGZ1bCBpbiByb3V0aW5nPGJyPiZuYnNwOyBkZWNpc2lvbi48YnI+PGJyPmRtbSZndDsg TWF5YmUgc29tZXRoaW5nIGxpa2UgdGhpczo8YnI+ZG1tJmd0OyAmcXVvdDtJbiB0aGUgbW9zdCBj b25zdHJhaW5lZCBMTE4gZW52aXJvbm1lbnRzLCB0aGUgc2ltcGxlIGhldXJpc3RpYzxicj4KZG1t Jmd0OyBvZiBjbGFzc2lmeWluZyBub2RlcyBpbnRvIHN0YXRpYyBvciBkeW5hbWljIGNhbiBiZSB2 ZXJ5PGJyPmRtbSZndDsgaGVscGZ1bCBpbiByb3V0aW5nIGRlY2lzaW9uLiZxdW90Ozxicj5kbW0m Z3Q7IEkgdGhpbmsgdGhhdCBpcyB3aGF0IHlvdSBtZWFuLi4uaWYgbm90LCB0aGVuID88YnI+PGJy PiZuYnNwOyBOb3RlIHRoYXQgdGhpcyBub2RlIG1ldHJpYyBtYXkgZWl0aGVyIGJlIHN0YXRpYyBv cjxicj4KJm5ic3A7IGR5bmFtaWMuICZuYnNwO0luIHRoZSBsYXRlciBjYXNlLCB0aGUgbmV0d29y ayBhZG1pbmlzdHJhdG9yIHdpbGw8YnI+Jm5ic3A7IGhhdmUgdG8gdXNlIGNvbnNpc3RlbnQgbWV0 cmljIHZhbHVlcy48YnI+PGJyPjQuOC4gJm5ic3A7Tm9kZSByZWxpYWJpbGl0eTxicj48YnI+Jm5i c3A7IE5vZGUgcmVsaWFiaWxpdHkgaXMgZGVlcGx5IHJlbGF0ZWQgdG8gbm9kZSBkeW5hbWljaXR5 IHN1Y2ggdGhhdCBub2RlPGJyPiZuYnNwOyByZWxpYWJpbGl0eSBkZXRlcmlvcmF0ZXMgYXMgbm9k ZSBkeW5hbWljaXR5IGluY3JlYXNlcy4gJm5ic3A7SG93ZXZlciwgbm9kZTxicj4KJm5ic3A7IHJl bGlhYmlsaXR5IGlzIGEgd2lkZXIgY29uY2VwdCB0aGFuIG5vZGUgZHluYW1pY2l0eSBzaW5jZSBu b2RlPGJyPmRtbSZndDsgcy93aWRlci9tb3JlIGdlbmVyYWwvPGJyPiZuYnNwOyByZWxpYWJpbGl0 eSBpcyBpbmZsdWVuY2VkIGJ5IG1vcmUgZmFjdG9ycy4gJm5ic3A7Rm9yIGV4YW1wbGUsIG5vZGUm IzM5O3M8YnI+Jm5ic3A7IHVuZXhwZWN0ZWQgZmFpbHVyZSBjdXRzIG9mZiBub2RlIHJlbGlhYmls aXR5LCBidXQgaXQgaXMgbm90IHJlYWxseTxicj4KZG1tJmd0OyBzL2N1dHMgb2Ygbm9kZS9yZWR1 Y2VzIGEgbm9kZSYjMzk7cy8gJm5ic3A7KEkgdGhpbmsgdGhhdCYjMzk7cyB3aGF0IHlvdSBtZWFu KTxicj4mbmJzcDsgcmVsYXRlZCB0byBub2RlIGR5bmFtaWNpdHkuICZuYnNwO1RoZXJlZm9yZSwg bm9kZSBkeW5hbWljaXR5IG1ldHJpYyBjYW4gYmU8YnI+Jm5ic3A7IGNvdmVyZWQgYnkgbm9kZSBy ZWxpYWJpbGl0eSBtZXRyaWMuICZuYnNwO0hvd2V2ZXIsIGl0IGlzIHZlcnkgY2hhbGxlbmdpbmc8 YnI+CiZuYnNwOyB0byBlc3RpbWF0ZSBvciBtb25pdG9yIG5vZGUgcmVsaWFiaWxpdHkuICZuYnNw O0Egc3BlY2lmaWMgZnVuY3Rpb24gbmVlZHM8YnI+Jm5ic3A7IHRvIGJlIGRlZmluZWQgdG8gZ2V0 IHZhbHVlcyBvZiB0aGUgcmVsaWFiaWxpdHkgbWV0cmljIGZyb20gYSB2YXJpZXR5PGJyPiZuYnNw OyBvZiBmZWF0dXJlcyBhZmZlY3Rpbmcgbm9kZSByZWxpYWJpbGl0eS48YnI+PGJyPjxicj4mbmJz cDsgTm9kZSByZWxpYWJpbGl0eSBpcyBhIGNydWNpYWwgbWV0cmljIGluIExMTnMgY29tcGFyZWQg d2l0aCBpbiBvdGhlcjxicj4KJm5ic3A7IGNvbnZlbnRpb25hbCBvciBldmVuIHdpcmVsZXNzIG5l dHdvcmtzIGNvbnNpZGVyaW5nIHRoYXQgbm9kZXMgaW4gTExOczxicj4mbmJzcDsgbWF5IHN0YXkg aW4gYSBzbGVlcCBtb2RlIG1vc3Qgb2YgdGhlIHRpbWUuPGJyPjxicj5kbW0mZ3Q7IG1heWJlIDo8 YnI+ZG1tJmd0OyAmcXVvdDtOb2RlIHJlbGlhYmlsaXR5IGNhbiBiZSBhIGNydWNpYWwgbWV0cmlj IGluIExMTnMsIHNpbmNlPGJyPmRtbSZndDsgbm9kZXMgaW4gTExOcyBtYXkgc3RheSBpbiBhIHNs ZWVwIG1vZGUgbW9zdCBvZiB0aGUgdGltZS4mcXVvdDs8YnI+CmRtbSZndDsgQWdhaW4sIEkgdGhp bmsgdGhhdCYjMzk7cyB3aGF0IHlvdSBtZWFuLjxicj48YnI+Jm5ic3A7IEEgc2xlZXBpbmcgbm9k ZSBzaG91bGQ8YnI+ZG1tJmd0OyBxdWVzdGlvbiBoZXJlIGFib3V0IDIxMTkgbGFuZ3VhZ2UuIFNI T1VMRCBOT1Qgdi4gc2hvdWxkIG5vdDwvZGl2Pgo8ZGl2PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogcmVkOyBGT05ULUZBTUlMWTogsby4sjsgbXNvLWJp ZGktZm9udC1mYW1pbHk6ILG8uLI7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tYW5z aS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFu Z3VhZ2U6IEFSLVNBIj49PT0mZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogsby4sjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ILG8 uLI7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7 IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj4gPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogIzEx MTExMTsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAmIzM5O1RpbWVz IE5ldyBSb21hbiYjMzk7OyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWJpZGktZm9udC1z aXplOiAxMi4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6IEtPOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPkkgdGhpbmsgInNob3VsZCBub3QiIGlz IG9rYXkgZm9yIG5vdy4gTmVlZCBmdXJ0aGVyIGRpc2N1c3Npb24uPC9zcGFuPjwvZGl2Pgo8c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxMTExMTE7IEZP TlQtRkFNSUxZOiCxvLiyOyBtc28tYmlkaS1mb250LWZhbWlseTogJiMzOTtUaW1lcyBOZXcgUm9t YW4mIzM5OzsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIu MHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsg bXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48L3NwYW4+CjxkaXY+PGJyPiZuYnNwOyBub3QgYmUg YW4gaW50ZXJtZWRpYXRlIG5vZGUgdG8gZGVsaXZlciBhIHBhY2tldCwgdGh1cyBzdGF0dXMgb2Yg YTxicj4mbmJzcDsgbm9kZSBtdXN0IGJlIG1vbml0b3JlZCBvciBjYW4gYmUgYW50aWNpcGF0ZWQu ICZuYnNwO0FkZGl0aW9uYWxseSwgcmVzaWR1YWw8YnI+ZG1tJmd0OyBzL2NhbiBiZSBhbnRpY2lw YXRlZC9zaG91bGQgYmUgcHJlZGljdGFibGUvPGJyPiZuYnNwOyBlbmVyZ3kgb2YgYSBub2RlIHNo b3VsZCBiZSBwcmVkaWN0YWJsZSBub3QgdG8gbWFrZSB0aGUgbm9kZSBzdWRkZW5seTxicj4KJm5i c3A7IGRpZSBkdXJpbmcgcm91dGluZyBwcm9jZXNzIGR1ZSB0byBiYXR0ZXJ5IG91dC4gJm5ic3A7 Tm9kZXMgb24gdGhlIGNob3Nlbjxicj4mbmJzcDsgcGF0aCBmb3Igcm91dGluZyBzaG91bGQgYmUg cmVsaWFibGUuPGJyPjxicj48YnI+NS4gJm5ic3A7TGluayBhdHRyaWJ1dGVzPGJyPjxicj4mbmJz cDsgVGhlcmUgYXJlIHNldmVyYWwgZHluYW1pYyBsaW5rIGF0dHJpYnV0ZXMgZXNwZWNpYWxseSBp biB3aXJlbGVzczxicj4mbmJzcDsgTExOcy4gJm5ic3A7RXZlbiBpbiBjYXNlIG9mIHN0YXRpYyBM TE5zIHdoZXJlIG5vZGVzIGFyZSBzdGF0aW9uYXJ5LCB0aGVyZTxicj4KJm5ic3A7IGFyZSBhbHdh eXMgdmFyaWFibGVzIGxpa2UgYXBwZWFyYW5jZSBvZiBvYnN0YWNsZXMgYW5kIHNpZ25hbDxicj4m bmJzcDsgaW50ZXJmZXJlbmNlLiAmbmJzcDtTaW1pbGFyIHRvIG5vZGUgYXR0cmlidXRlcywgbGlu ayBhdHRyaWJ1dGVzIGNhbiBiZTxicj4mbmJzcDsgY29uc2lkZXJlZCBhcyBzdGF0aWMgb25lcyBp biBzdGF0aWMgTExOcyBub3Qgb25seSBiZWNhdXNlIGl0IGlzIHZlcnk8YnI+Jm5ic3A7IGNoYWxs ZW5naW5nIHRvIHVwZGF0ZSB0aGVtIGluIGEgcmVhbC10aW1lIG1hbm5lciwgYnV0IGFsc28gaXQg aXM8YnI+CiZuYnNwOyBxdWl0ZSB0aW1lLSBhbmQgZW5lcmd5LWNvbnN1bWluZyB3b3JrLiAmbmJz cDtIb3dldmVyLCBpbiBkeW5hbWljIExMTnMsIHdlPGJyPiZuYnNwOyBtYXkgbmVlZCB0byB0YWtl IHRoZXNlIGF0dHJpYnV0ZXMgYXMgZHluYW1pYyBtZXRyaWNzIGFuZCBtYWtlIHVzZSBvZjxicj48 YnI+PGJyPjxicj5LaW0sIGV0IGFsLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtFeHBpcmVzIEphbnVhcnkgNSwgMjAwOSAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W1BhZ2UgOV08YnI+Cjxicj5JbnRl cm5ldC1EcmFmdCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Um91dGluZyBNZXRy aWNzIGZvciBMTE5zICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBKdWx5IDIwMDg8YnI+PGJyPjxicj4mbmJzcDsgY3VycmVudCByZWFsLXRpbWUgdmFsdWVz IHdoZW5ldmVyIG5lY2Vzc2FyeS4gJm5ic3A7VmFsdWVzIG9mIGR5bmFtaWM8YnI+Jm5ic3A7IG1l dHJpY3MgY2Fubm90IGJlIG9idGFpbmVkIGVhc2lseS4gJm5ic3A7T25lIHdheSB0byBnZXQgdmFs dWVzIG9mIGR5bmFtaWM8YnI+CiZuYnNwOyBtZXRyaWNzIGlzIHRvIHVzZSBoaXN0b3JpY2FsIGRh dGEgYW5kIGF2ZXJhZ2UgdGhlbSB3aXRoaW4gYSBzcGVjaWZpZWQ8YnI+Jm5ic3A7IHRpbWUgd2lu ZG93Ljxicj48YnI+NS4xLiAmbmJzcDtCYW5kd2lkdGg8YnI+PGJyPiZuYnNwOyBCYW5kd2lkdGgg Y2FuIGJlIHRha2VuIGFzIGEgbGluayBjYXBhY2l0eSBtZXRyaWMuICZuYnNwO0l0IGNhbiBiZTxi cj4mbmJzcDsgZXZhbHVhdGVkIGFzIG5vZGVzJiMzOTsgY29tbXVuaWNhdGlvbmFsIGNhcGFiaWxp dHksIHRvby48YnI+CmRtbSZndDsgcGVyaGFwczo8YnI+ZG1tJmd0OyBCYW5kd2lkdGggY2FuIGJl IGFsc28gYmUgdXNlZCB0byByZXByZXNlbnQgYSBub2RlJiMzOTtzPGJyPmRtbSZndDsgY29tbXVu aWNhdGlvbiBjYXBhYmlsaXR5Ljxicj5kbW0mZ3Q7IElzIHRoYXQgd2hhdCB5b3UgbWVhbj88YnI+ PGJyPiZuYnNwOyBJdCBtdXN0IGJlPGJyPiZuYnNwOyByZW1lbWJlcmVkIHRoYXQgaW4gY2FzZSBv ZiB3aXJlbGVzcyBsaW5rLCB0aGUgbGluayBjYXBhY2l0eSBpcyBzaGFyZWQ8YnI+CiZuYnNwOyBh bW9uZyBub2RlcyBpbiBhIHNpbmdsZSB3aXJlbGVzcyBsaW5rLjxicj48YnI+NS4yLiAmbmJzcDtS ZWxpYWJpbGl0eSAoUXVhbGl0eSk8YnI+PGJyPiZuYnNwOyBMaW5rIHJlbGlhYmlsaXR5IGNhbiBi ZSBtZWFzdXJlZCBieSB0aGUgQml0IEVycm9yIFJhdGUgKEJFUiksIE1lYW48YnI+Jm5ic3A7IFRp bWUgQmV0d2VlbiBGYWlsdXJlcyAoTVRCRikgb3IgbGluayBjaHVybiBkZWZpbmVkIGFzIHRoZSBy YXRlIGF0PGJyPgombmJzcDsgd2hpY2ggbGlua3MgY2hhbmdlIGJldHdlZW4gZ29vZCBhbmQgYmFk PGJyPiZuYnNwOyBbSS1ELmxldmlzLXJvbGwtcHJvdG9jb2xzLXN1cnZleV0uICZuYnNwO0xpbmsg cmVsaWFiaWxpdHkgaXMgY2xvc2VseTxicj4mbmJzcDsgcmVsYXRlZCB0byBub2RlIHJlbGlhYmls aXR5IGVzcGVjaWFsbHkgaW4gd2lyZWxlc3MgTExOcy4gJm5ic3A7VHdvIG5vZGVzPGJyPiZuYnNw OyB3aGljaCBmb3JtIGEgbGluayBhZmZlY3QgZGlyZWN0bHkgdG8gdGhlIGxpbmsgcmVsaWFiaWxp dHkgYXMgZm9sbG93czo8YnI+CiZuYnNwOyBpZiBvbmUgbm9kZSBmYWxscyBpbiBhIHNsZWVwIG1v ZGUgb3IgbW92ZXMgYXdheSBiZXlvbmQgb2YgdGhlPGJyPiZuYnNwOyB0cmFuc21pc3Npb24gcmFu Z2UgZnJvbSB0aGUgb3RoZXIgbm9kZSwgdGhlIGxpbmsgdmFuaXNoZXMgYXdheS48YnI+ZG1tJmd0 OyBzL3ZhbmlzaGVzIGF3YXkvdmFuaXNoZXMvPGJyPmRtbSZndDs8YnI+ZG1tJmd0OyBCdXQgbW9y ZSBnZW5lcmFsbHksIEkgdGhpbmsgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBzYXkgdGhhdDxicj4K ZG1tJmd0OyBpZiB0aGVyZSBpZiBvbmUgKG9yIGJvdGgpIGVuZCBvZiBhIGxpbmsgZWl0aGVyIGRp ZXMgb3I8YnI+ZG1tJmd0OyBtb3ZlcywgdGhlIGxpbmsgc2hvdWxkIGJlIHJlbW92ZWQgZnJvbSBy b3V0aW5nLiBDb3JyZWN0PyBJZjxicj5kbW0mZ3Q7IHNvLCB0aGF0IGlzIHNlbnNpYmxlLiBJZiBu b3QsIHdoYXQgZGlkIHlvdSBoYXZlIGluIG1pbmQ/PGJyPjxicj4mbmJzcDsgSG93ZXZlciwgbGlu ayByZWxpYWJpbGl0eSBpcyBhbHNvIGluZmx1ZW5jZWQgYnkgb3RoZXIgZmFjdG9ycyBsaWtlPGJy PgombmJzcDsgdW5leHBlY3RlZCBvYnN0YWNsZXMgb3IgdGVtcG9yYXJ5IGludGVyZmVyZW5jZS48 YnI+PGJyPiZuYnNwOyBKdXN0IGxpa2Ugbm9kZSByZWxpYWJpbGl0eSBpcyBjcml0aWNhbCwgbGlu ayByZWxpYWJpbGl0eSBpcyBhbHNvPGJyPiZuYnNwOyBlc3NlbnRpYWwgZm9yIHJvdXRpbmcgZ2l2 ZW4gdGhhdCBtb3N0IG5vZGVzIGhhdmUgdmVyeSBzaG9ydCBkdXR5PGJyPiZuYnNwOyBjeWNsZXMu ICZuYnNwO0NoYW5nZSBvZiBsaW5rIHF1YWxpdHkgZGlyZWN0bHkgZ2l2ZXMgcmlzZSB0byB0aGF0 IG9mPGJyPgombmJzcDsgbmV0d29yayBjb25uZWN0aXZpdHkuPGJyPjxicj5kbW0mZ3Q7IGNvdWxk biYjMzk7dCBwYXJzZSB0aGUgbGFzdCBzZW50ZW5jZS4gSSYjMzk7bSBndWVzc2luZyB5b3UgbWVh biB0bzxicj5kbW0mZ3Q7IHNheSBzb21ldGhpbmcgdG8gdGhlIGVmZmVjdCB0aGF0ICZxdW90O0Eg Y2hhbmdlIGluIGxpbmsgcXVhbGl0eSBjYW48YnI+ZG1tJmd0OyBlZmZlY3QgbmV0d29yayB0b3Bv bG9neS4mcXVvdDs8YnI+Cjxicj4mbmJzcDsgVGhlcmVmb3JlLCBsaW5rIHF1YWxpdHkgbWF5IGJl IHRha2VuIGludG88YnI+Jm5ic3A7IGFjY291bnQgYXMgYSBjcml0aWNhbCByb3V0aW5nIG1ldHJp Yy4gJm5ic3A7SW5jcmVhc2luZyBsaW5rIGFuZCBub2RlPGJyPiZuYnNwOyByZWxpYWJpbGl0eSB0 b2dldGhlciBlbmhhbmNlcyByb3V0ZSByb2J1c3RuZXNzLiAmbmJzcDtUaGVyZWZvcmUsIGNob29z aW5nPGJyPiZuYnNwOyByZWxpYWJsZSBsaW5rcyBhbmQgbm9kZXMgZHVyaW5nIHJvdXRlIGVzdGFi bGlzaG1lbnQgcHJvY2VzcyBpbXByb3Zlczxicj4KJm5ic3A7IHJvYnVzdG5lc3Mgb2YgdGhlIHNl bGVjdGVkIHJvdXRlcy48YnI+PGJyPjUuMy4gJm5ic3A7UHJvcGFnYXRpb24gZGVsYXk8YnI+PGJy PiZuYnNwOyBQcm9wYWdhdGlvbiBkZWxheSBpcyB0aGUgdGltZSB0YWtlbiBmb3IgdGhlIHBhY2tl dCB0byB0cmF2ZXJzZSB0aGU8YnI+Jm5ic3A7IGxpbmsgZnJvbSB0aGUgc291cmNlIG5vZGUgdG8g dGhlIHRhcmdldCBub2RlLiAmbmJzcDtQYXRoIChyb3V0ZSkgbGF0ZW5jeTxicj4mbmJzcDsgaXMg bWFkZSB1cCBvZiBub2RlcyYjMzk7IGxhdGVuY3kgYW5kIGxpbmtzIV8gcHJvcGFnYXRpb24gZGVs YXkgb24gdGhlPGJyPgombmJzcDsgcGF0aC48YnI+PGJyPmRtbSZndDsgSSB0aGluayB5b3UgbWVh bjo8YnI+ZG1tJmd0OyBQYXRoIChyb3V0ZSkgbGF0ZW5jeSBpcyB1c3VhbGx5IGNvbXB1dGVkIGFz IHRoZSBzdW0gb2YgdGhlPGJyPmRtbSZndDsgbGF0ZW5jaWVzIG9mIHRoZSBpbmRpdnVkYWwgbm9k ZXMgYWxvbmcgYSB0aGUgcGF0aC48L2Rpdj4KPGRpdj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IHJlZDsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRp LWZvbnQtZmFtaWx5OiCxvLiyOyBtc28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWFuc2kt bGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1 YWdlOiBBUi1TQSI+PT09Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiCxvLiy OyBtc28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBt c28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+IDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxMTEx MTE7IEZPTlQtRkFNSUxZOiCxvLiyOyBtc28tYmlkaS1mb250LWZhbWlseTogJiMzOTtUaW1lcyBO ZXcgUm9tYW4mIzM5OzsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1iaWRpLWZvbnQtc2l6 ZTogMTIuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdl OiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5ObywgSSBtZWFuIHBhdGggbGF0ZW5jeSBp cyB0aGUgc3VtIG9mIGFsbCBub2RlIGxhdGVuY2llcyAoc2VjdGlvbiA0LjQpIGFuZCBhbGwgbGlu ayBwcm9wYWdhdGlvbiBkZWxheXMgKHNlbmN0aW9uIDUuMykgYWxvbmcgdGhlIHBhdGguIElmIHRo ZSBvcmlnaW5hbCBzZW50ZW5jZSBpcyBoYXJkIHRvIHJlYWQsIEkgbWF5IGNoYW5nZSBpdC4gPC9z cGFuPjwvZGl2Pgo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6ICMxMTExMTE7IEZPTlQtRkFNSUxZOiCxvLiyOyBtc28tYmlkaS1mb250LWZhbWlseTogJiMz OTtUaW1lcyBOZXcgUm9tYW4mIzM5OzsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1iaWRp LWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0 LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48L3NwYW4+CjxkaXY+PGJy PmRtbSZndDs8YnI+ZG1tJmd0OyBhbHNvLCBub3RlIHRoZSAhXzxicj48YnI+PGJyPiZuYnNwOyBB cyBtZW50aW9uZWQgZWFybGllciwgaXQgY2FuIGJlIG9idGFpbmVkIGJ5IG1ha2luZyBhdmVyYWdl PGJyPiZuYnNwOyBmcm9tIGhpc3RvcmljYWwgZGF0YS48YnI+PGJyPmRtbSZndDsgSSB0aGluayB5 b3UgbWVhbjo8YnI+ZG1tJmd0OyBBcyBtZW50aW9uZWQgZWFybGllciwgcHJvcG9nYXRpb24gZGVs YXkgY2FuIGJlIG9idGFpbmVkPGJyPgpkbW0mZ3Q7IGF2ZXJhZ2luIGhpc3RvcmljYWwgZGF0YS48 YnI+ZG1tJmd0Ozxicj5kbW0mZ3Q7IFNvIHdoZXJlIGRvZXMgdGhpcyBoaXN0b3JpY2FsIGRhdGEg cmVzaWRlPzxicj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6IHJlZDsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiCxvLiyOyBt c28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28t ZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PT09Jmd0Ozwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J TFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiCxvLiyOyBtc28tYmlkaS1mb250LXNpemU6 IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTog S087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxMTExMTE7IEZPTlQtRkFNSUxZOiCxvLiy OyBtc28tYmlkaS1mb250LWZhbWlseTogJiMzOTtUaW1lcyBOZXcgUm9tYW4mIzM5OzsgbXNvLWZv bnQta2VybmluZzogMS4wcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tYW5zaS1s YW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3Vh Z2U6IEFSLVNBIj5lYWNoIG5vZGUgc2hvdWxkIG1haW50YWluIHRoZSBkYXRhLiBJdCBkb2VzIG5v dCBuZWVkIHRvIGtlZXAgYWxsIHRoZSBoaXN0b3JpY2FsIGRhdGEgYnV0IGp1c3QgbWFpbnRhaW4m bmJzcDthbiBhdmVyYWdlLiBIb3dldmVyLCBJIGFsc28gdGhpbmsgdGhhdCBpdCBjb3N0cyBoaWdo IGFuZCBoYXMgbm90IG11Y2ggYmVuZWZpdCBzaW5jZSBwcm9wYWdhdGlvbiBkZWxheSBpcyBtb3N0 bHkgbmVnbGlnaWJsZS4gTmVlZCBmdXJ0aGVyIGRpc2N1c3Npb24uPC9zcGFuPjwvZGl2Pgo8c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxMTExMTE7IEZP TlQtRkFNSUxZOiCxvLiyOyBtc28tYmlkaS1mb250LWZhbWlseTogJiMzOTtUaW1lcyBOZXcgUm9t YW4mIzM5OzsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIu MHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsg bXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48L3NwYW4+CjxkaXY+PGJyPjYuICZuYnNwO09wZW4g aXNzdWVzPGJyPjxicj4mbmJzcDsgT3RoZXIgaXRlbXMgdG8gYmUgYWRkcmVzc2VkIGluIGZ1cnRo ZXIgcmV2aXNpb25zIG9mIHRoaXMgZG9jdW1lbnQ8YnI+Jm5ic3A7IGluY2x1ZGU6PGJyPjxicj48 YnI+PGJyPjxicj5LaW0sIGV0IGFsLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtFeHBpcmVzIEphbnVhcnkgNSwgMjAwOSAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgW1BhZ2UgMTBdPGJyPjxicj5JbnRlcm5ldC1E cmFmdCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Um91dGluZyBNZXRyaWNzIGZv ciBMTE5zICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBK dWx5IDIwMDg8YnI+Cjxicj48YnI+Jm5ic3A7IG8gJm5ic3A7VHJhZmZpYyBmbG93IHJlcXVpcmVt ZW50OiBzZWxlY3Rpb24gb2YgYXBwbGljYWJsZSByb3V0aW5nIG1ldHJpY3M8YnI+Jm5ic3A7ICZu YnNwOyAmbmJzcDtuZWVkcyB0byBiZSBwZXJmb3JtZWQgZGVwZW5kaW5nIG9uIGFwcGxpY2F0aW9u IGFuZCB0cmFmZmljIGZsb3c8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtyZXF1aXJlbWVudHMuICZu YnNwO0ZvciBleGFtcGxlLCB3aGVuIGxhdGVuY3kgaXMgbm90IGEgbWF0dGVyIGF0IGFsbCw8YnI+ CiZuYnNwOyAmbmJzcDsgJm5ic3A7aXQgaXMgcG9zc2libGUgdG8gcmVtb3ZlIGxhdGVuY3kgcmVs YXRlZCBtZXRyaWNzIGluIHRoZSBvYmplY3RpdmU8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtmdW5j dGlvbiB0byBjYWxjdWxhdGUgdGhlIHJvdXRpbmcgcGF0aC4gJm5ic3A7QXMgc3VjaCwgZGlmZmVy ZW50PGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7YXBwbGljYXRpb25zIG9yIFNlcnZpY2UgTGV2ZWwg QWdyZWVtZW50IChTTEEpIG1pZ2h0IGRlbWFuZDxicj4mbmJzcDsgJm5ic3A7ICZuYnNwO2RpZmZl cmVudCByb3V0aW5nIG1ldHJpYyBjb21iaW5hdGlvbiBmb3IgcGF0aCBjYWxjdWxhdGlvbiwgd2hp Y2g8YnI+CiZuYnNwOyAmbmJzcDsgJm5ic3A7Zm9ybXMgYSBkaWZmZXJlbnQgcm91dGUuICZuYnNw O01vcmVvdmVyLCBzb21lIHJvdXRpbmcgYWxnb3JpdGhtIG1heTxicj4mbmJzcDsgJm5ic3A7ICZu YnNwO3N1cHBvcnQgTXVsdGktdG9wb2xvZ3kgcm91dGluZyB3aXRoIHRoZSBhYmlsaXR5IHRvIGNv bXB1dGUgcm91dGVzPGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7YmFzZWQgb24gdGhlIHRyYWZmaWMg ZmxvdyByZXF1aXJlbWVudHMgdXNpbmcgZGlmZmVyZW50IHNldCBvZjxicj4mbmJzcDsgJm5ic3A7 ICZuYnNwO21ldHJpY3MuPGJyPgo8YnI+Jm5ic3A7IG8gJm5ic3A7TWV0cmljIHdlaWdodHMgZXhw bG9pdGF0aW9uOiB3ZWlnaHRzIGZvciB0aGUgbGlzdGVkIG1ldHJpY3Mgc2hvdWxkPGJyPiZuYnNw OyAmbmJzcDsgJm5ic3A7YmUgZGVjaWRlZCBhY2NvcmRpbmcgdG8gYXBwbGljYXRpb25zIGFuZCBk YXRhIGZsb3dzLjxicj48YnI+ZG1tJmd0OyBhcmUgeW91IHN1Z2dlc3RpbmcgZGF0YS1hd2FyZSBy b3V0aW5nIGhlcmU/PGJyPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBDT0xPUjogcmVkOyBGT05ULUZBTUlMWTogsby4sjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ILG8 uLI7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7 IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj49PT0m Z3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6ICMxMTExMTE7IEZPTlQtRkFNSUxZOiCxvLiyOyBtc28tYmlkaS1mb250LWZhbWlseTogJiMz OTtUaW1lcyBOZXcgUm9tYW4mIzM5OzsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1iaWRp LWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0 LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5ZZXMsIGJ1dCB0cmFkZS1v ZmYgc2hvdWxkIGJlIGZ1cnRoZXIgZGlzY3Vzc2VkLjwvc3Bhbj48L2Rpdj4KPHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMTExMTExOyBGT05ULUZBTUlM WTogsby4sjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICYjMzk7VGltZXMgTmV3IFJvbWFuJiMzOTs7 IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNv LWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRp LWxhbmd1YWdlOiBBUi1TQSI+PC9zcGFuPgo8ZGl2Pjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtGb3IgZXhhbXBsZSw8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtsYXRlbmN5IGNyaXRp Y2FsIGFwcGxpY2F0aW9ucyBpbiBtaWxpdGFyeSBzY2VuYXJpb3MgU0hPVUxEIHB1dCBhPGJyPmRt bSZndDsgcy9pbiBtaWxpdGFyeSBzY2VuYXJpb3MvLzxicj5kbW0mZ3Q7IChzaW5jZSB0aGlzIHdv dWxkIGJlIHRydWUgaW4gYW55IGxhdGVuY3kgY3JpdGljYWwgYXBwbGljYXRpb24pPC9kaXY+Cjxk aXY+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiByZWQ7 IEZPTlQtRkFNSUxZOiCxvLiyOyBtc28tYmlkaS1mb250LWZhbWlseTogsby4sjsgbXNvLWJpZGkt Zm9udC1zaXplOiAxMi4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPj09PSZndDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiy OyBtc28tYmlkaS1mb250LWZhbWlseTogsby4sjsgbXNvLWJpZGktZm9udC1zaXplOiAxMi4wcHQ7 IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28t YmlkaS1sYW5ndWFnZTogQVItU0EiPiA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMTExMTExOyBGT05ULUZBTUlMWTogsby4sjsgbXNvLWJp ZGktZm9udC1mYW1pbHk6ICYjMzk7VGltZXMgTmV3IFJvbWFuJiMzOTs7IG1zby1mb250LWtlcm5p bmc6IDEuMHB0OyBtc28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6 IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1T QSI+SSBrbm93IHdoYXQgeW91IG1lYW4sIGJ1dCB0aGlzIGlzIGFuIGV4YW1wbGUuIFRodXMgSSB0 aGluayBpdCdzIGJldHRlciB0byBoYXZlICJpbiBtaWxpdGFyeSBzY2VuYXJpb3MiIHNpbmNlIGl0 IGhlbHBzIHRvIHVuZGVyc3RhbmQgdGhlIGV4YW1wbGUuPC9zcGFuPjwvZGl2Pgo8c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxMTExMTE7IEZPTlQtRkFN SUxZOiCxvLiyOyBtc28tYmlkaS1mb250LWZhbWlseTogJiMzOTtUaW1lcyBOZXcgUm9tYW4mIzM5 OzsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBt c28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJp ZGktbGFuZ3VhZ2U6IEFSLVNBIj48L3NwYW4+CjxkaXY+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO2hpZ2ggd2VpZ2h0IHRvIGxhdGVuY3kgbWV0cmljcyByYXRoZXIgdGhhbiByZXNv dXJjZSBtZXRyaWNzLiAmbmJzcDtPbjxicj4mbmJzcDsgJm5ic3A7ICZuYnNwO3RvcCBvZiB0aGF0 LCBhcHBsaWNhYmxlIG1ldHJpY3Mgb3Igb3B0aW1pemVkIHdlaWdodHMgbWF5IG5lZWQgdG88YnI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDtiZSBjaGFuZ2VkIG9uIGRlbWFuZC48YnI+PGJyPiZuYnNwOyBv ICZuYnNwO01ldHJpY3MgcmVsYXRlZCB0byBzZWN1cml0eTogTWV0cmljcyB0aGF0IHNlY3VyaXR5 IGlzIGFzc29jaWF0ZWQ8YnI+CiZuYnNwOyAmbmJzcDsgJm5ic3A7d2l0aCBuZWVkIHRvIGJlIGZ1 cnRoZXIgY29uc2lkZXJlZC4gJm5ic3A7SWYgYSByb3V0ZSBpcyBjb21wcmlzZWQgb2Y8YnI+Jm5i c3A7ICZuYnNwOyAmbmJzcDthdXRoZW50aWNhdGVkIGFuZCBhdXRob3JpemVkIG5vZGVzIGZvciB0 aGUgZGF0YSwgdGhlbiB0aGUgcm91dGU8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtzaG91bGQgYmUg cHJlZmVyYWJsZS48YnI+PGJyPiZuYnNwOyBvICZuYnNwO0NvbnNpZGVyYXRpb24gb2Ygcm91dGlu ZyBlZmZpY2llbmN5IGFuZCBzdGFiaWxpdHk6IExMTnMgYXJlIGhpZ2hseTxicj4KJm5ic3A7ICZu YnNwOyAmbmJzcDtjb25zdHJhaW5lZCBuZXR3b3JrcywgdGh1cyBpdCBpcyBoYXJkIHRvIG1haW50 YWluIG1hbnkgbWV0cmljcyBmb3I8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtlZmZpY2llbnQgcm91 dGluZyBkdWUgdG8gcmVzb3VyY2UgZGVtYW5kIGFuZCBvdmVyaGVhZC48YnI+PGJyPmRtbSZndDsg bWF5YmU6PGJyPmRtbSZndDsgU2luY2UgTExOcyBhcmUgaGlnaGx5IGNvbnN0cmFpbmVkIG5ldHdv cmtzLCBtYWludGFpbmluZyBtYW55PGJyPgpkbW0mZ3Q7IGRpZmZlcmVudCByb3V0aW5nIG1ldHJp Y3MgaXMgY2hhbGxlbmdpbmcuPGJyPjxicj4mbmJzcDsgJm5ic3A7ICZuYnNwO1JvdXRpbmcgc2hv dWxkIGJlIGxpZ2h0d2VpZ2h0Ljxicj48YnI+ZG1tJmd0OyBhZ2FpbiwgMjExOSBsYW5ndWFnZS4g c2hvdWxkIGJlIHYuIFNIT1VMRCBCRTxicj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6IHJlZDsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZvbnQt ZmFtaWx5OiCxvLiyOyBtc28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3Vh Z2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBB Ui1TQSI+PT09Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiCxvLiyOyBtc28t YmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFy ZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+IDwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxMTExMTE7IEZP TlQtRkFNSUxZOiCxvLiyOyBtc28tYmlkaS1mb250LWZhbWlseTogJiMzOTtUaW1lcyBOZXcgUm9t YW4mIzM5OzsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIu MHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsg bXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5JIHByZWZlciBzaG91bGQgYmUgZm9yIG5vdy48L3Nw YW4+PC9kaXY+CjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xP UjogIzExMTExMTsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAmIzM5 O1RpbWVzIE5ldyBSb21hbiYjMzk7OyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWJpZGkt Zm9udC1zaXplOiAxMi4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjwvc3Bhbj4KPGRpdj48YnI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SW4gYWRkaXRpb24sIGNhcmVmdWwgY29uZGl0 aW9uIHNob3VsZCBiZSBnaXZlbiB0byB0aGU8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtkeW5hbWlj IG5hdHVyZSBvZiBzb21lIG1ldHJpY3MgYW5kIHRoZWlyIGltcGxpY2F0aW9uIG9uPGJyPiZuYnNw OyAmbmJzcDsgJm5ic3A7cm91dGluZyBzdGFiaWxpdHkuPGJyPmRtbSZndDsgeW91IG1lbnRpb24g dGhpcyBzZXZlcmFsIHRpbWVzIChyaWdodGZ1bGx5IHNvKS4gSXQgbWlnaHQgYmU8YnI+CmRtbSZn dDsgbmljZSB0byBoYXZlIGEgY2l0YXRpb24gZm9yIHRoaXMuPGJyPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogcmVkOyBGT05ULUZBTUlMWTogsby4sjsg bXNvLWJpZGktZm9udC1mYW1pbHk6ILG8uLI7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBt c28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJp ZGktbGFuZ3VhZ2U6IEFSLVNBIj49PT0mZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogsby4sjsgbXNvLWJpZGktZm9udC1mYW1p bHk6ILG8uLI7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTog RU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNB Ij4gPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xP UjogIzExMTExMTsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAmIzM5 O1RpbWVzIE5ldyBSb21hbiYjMzk7OyBtc28tZm9udC1rZXJuaW5nOiAxLjBwdDsgbXNvLWJpZGkt Zm9udC1zaXplOiAxMi4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPkkgZG8gbm90IGhhdmUgYW55 IHJlZmVyZW5jZSBoZXJlLiBUbyBtZSBpdCBpcyBxdWl0ZSBvYnZpb3VzLiBCdXQgaWYgeW91IHRo aW5rIGEgY2l0YXRpb24gaXMgc3RpbGwgbmVlZGVkLCBJIHdpbGwgdHJ5IHRvIGZpbmQuPC9zcGFu PjwvZGl2Pgo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6 ICMxMTExMTE7IEZPTlQtRkFNSUxZOiCxvLiyOyBtc28tYmlkaS1mb250LWZhbWlseTogJiMzOTtU aW1lcyBOZXcgUm9tYW4mIzM5OzsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1iaWRpLWZv bnQtc2l6ZTogMTIuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxh bmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48L3NwYW4+CjxkaXY+PGJyPiZu YnNwOyBvICZuYnNwO0luZmx1ZW5jZSBvZiBuZXR3b3JrIHRvcG9sb2d5IGFuZCBkZW5zaXR5OiBO ZXR3b3JrIHRvcG9sb2d5IGFuZDxicj4mbmJzcDsgJm5ic3A7ICZuYnNwO25ldHdvcmsgZGVuc2l0 eSBuZWVkIHRvIGFmZmVjdCByb3V0ZSBjb25zdHJ1Y3Rpb24gaW4gc3VjaCBhIHdheTxicj4mbmJz cDsgJm5ic3A7ICZuYnNwO3RoYXQgdGhleSBuZWVkIHRvIGdpdmUgc29tZSBpbnB1dCB0byBtZXRy aWMgZGVjaXNpb24uICZuYnNwO0Zvcjxicj4KJm5ic3A7ICZuYnNwOyAmbmJzcDtleGFtcGxlLCBz dGFyIHRvcG9sb2d5IGFuZCBtZXNoIHRvcG9sb2d5IHNob3VsZCBlbXBsb3kgZGlmZmVyZW50PGJy PiZuYnNwOyAmbmJzcDsgJm5ic3A7cm91dGluZyBwcm90b2NvbHMuPGJyPjxicj5kbW0mZ3Q7IHdo eT8gc2hvdWxkIGJlIG1hZGUgZXhwbGljdDxicj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgQ09MT1I6IHJlZDsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRpLWZv bnQtZmFtaWx5OiCxvLiyOyBtc28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWFuc2ktbGFu Z3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdl OiBBUi1TQSI+PT09Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IENPTE9SOiAjMTExMTExOyBGT05ULUZBTUlMWTogsby4sjsgbXNvLWJpZGktZm9u dC1mYW1pbHk6ICYjMzk7VGltZXMgTmV3IFJvbWFuJiMzOTs7IG1zby1mb250LWtlcm5pbmc6IDEu MHB0OyBtc28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVT OyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+QWN0 dWFsbHksIEkgaW50ZW5kZWQgdG8gcmVtb3ZlIHRoaXMgZmluYWwgYnVsbGV0LCBidXQgYWNjaWRl bnRhbGx5IEkgZGlkbid0IGRlbGV0ZSBpbiB0aGUgZmlyc3QgZHJhZnQuIEkgd2lsbCByZW1vdmUg aXQgZm9yIHRoZSBuZXh0IHN1Ym1pc3Npb24uJm5ic3A7PC9zcGFuPjwvZGl2PgoKPGRpdj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6ICMxMTExMTE7IEZP TlQtRkFNSUxZOiCxvLiyOyBtc28tYmlkaS1mb250LWZhbWlseTogJiMzOTtUaW1lcyBOZXcgUm9t YW4mIzM5OzsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIu MHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsg bXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48L3NwYW4+PGJyPgombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtPYnZpb3VzbHkgdGhleSBuZWVkIHRvIGFkb3B0IGRpZmZlcmVudCByb3V0aW5n PGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7bWV0cmljcy48YnI+PGJyPmRtbSZndDsgQWdhaW4sIHdo eT8gc2hvdWxkIGJlIG1hZGUgZXhwbGljdDxicj48YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtTaW1p bGFybHksIG5ldHdvcmsgZGVuc2l0eSBpbiB0ZXJtcyBvZiBhdmVyYWdlIG5vZGU8YnI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDtkZWdyZWUgbmVlZHMgdG8gYmUgY29uc2lkZXJlZCB3aGVuIHNldHRpbmcg cm91dGluZyBtZXRyaWNzIGFuZDxicj4KJm5ic3A7ICZuYnNwOyAmbmJzcDt3ZWlnaHRzLiAmbmJz cDtOZXR3b3JrIHNpemUgaW4gdGVybXMgb2YgcGh5c2ljYWwgYW5kIHRvdGFsIG51bWJlciBvZjxi cj4mbmJzcDsgJm5ic3A7ICZuYnNwO25vZGVzIG5lZWRzIHRvIGJlIHRha2VuIGludG8gYWNjb3Vu dCwgdG9vLiAmbmJzcDtJbiBhZGRpdGlvbiwgaW5mbHVlbmNlPGJyPiZuYnNwOyAmbmJzcDsgJm5i c3A7b2YgbmV0d29yayBkZXBsb3ltZW50IG9uIHJvdXRpbmcgbWV0cmljcyBzaG91bGQgYmUgZnVy dGhlcjxicj4mbmJzcDsgJm5ic3A7ICZuYnNwO3N0dWRpZWQuPGJyPgo8YnI+ZG1tJmd0OyBJIGNv dWxkbiYjMzk7dCBwYXJzZSB0aGlzIGxhc3Qgc2VudGVuY2UgKEluIGFkZGl0aW9uLCBpbmZsdWVu Y2U8YnI+ZG1tJmd0OyBvZiBuZXR3b3JrIGRlcGxveW1lbnQgb24gcm91dGluZyBtZXRyaWNzIHNo b3VsZCBiZSBmdXJ0aGVyPGJyPmRtbSZndDsgc3R1ZGllZCkuPGJyPjxicj48YnI+Ny4gJm5ic3A7 U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8YnI+PGJyPiZuYnNwOyBSb3V0aW5nIG1ldHJpY3Mgc2hv dWxkIGJlIGhhbmRsZWQgaW4gYSBzZWN1cmUgYW5kIHRydXN0ZnVsIG1hbm5lci48YnI+CiZuYnNw OyBGb3IgaW5zdGFuY2UsIGEgbWFsaWNpb3VzIG5vZGUgY2FuIG5vdCBhZHZlcnRpc2UgZmFsc2Vs eSB0aGF0IGl0IGhhczxicj48YnI+PGJyPjxicj5LaW0sIGV0IGFsLiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtFeHBpcmVzIEphbnVhcnkgNSwgMjAwOSAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgW1BhZ2UgMTFd PGJyPjxicj5JbnRlcm5ldC1EcmFmdCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Um91dGluZyBNZXRyaWNzIGZvciBMTE5zICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBKdWx5IDIwMDg8YnI+Cjxicj48YnI+Jm5ic3A7IGdvb2QgbWV0cmlj cyBmb3Igcm91dGluZyBhbmQgYmVsb25nIHRvIHRoZSBlc3RhYmxpc2hlZCBwYXRoIHRvIGhhdmUg YTxicj4mbmJzcDsgY2hhbmNlIHRvIGludGVyY2VwdCBwYWNrZXRzLjxicj48YnI+ZG1tJmd0OyBU aGlzIHNlY3Rpb24gbmVlZHMgdG8gYmUgZXhwYW5kZWQuIExldCBtZSBrbm93IGlmIHlvdSYjMzk7 ZCBsaWtlPGJyPmRtbSZndDsgbWUgdG8gY29udHJpYnV0ZSBzb21lIHRleHQuPGJyPgo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IHJlZDsgRk9OVC1GQU1J TFk6ILG8uLI7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiCxvLiyOyBtc28tYmlkaS1mb250LXNpemU6 IDEyLjBwdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTog S087IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PT09Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ILG8uLI7IG1zby1iaWRp LWZvbnQtZmFtaWx5OiCxvLiyOyBtc28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWFuc2kt bGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWxhbmd1 YWdlOiBBUi1TQSI+IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6ICMxMTExMTE7IEZPTlQtRkFNSUxZOiCxvLiyOyBtc28tYmlkaS1mb250LWZh bWlseTogJiMzOTtUaW1lcyBOZXcgUm9tYW4mIzM5OzsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7 IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1z by1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5JIHdvdWxk IHZlcnkgYXBwcmVjaWF0ZSBpZiB5b3UgY29udHJpYnV0ZS48L3NwYW4+PGJyPgo8YnI+OC4gJm5i c3A7SUFOQSBDb25zaWRlcmF0aW9uczxicj48YnI+Jm5ic3A7IFRoaXMgZG9jdW1lbnQgcmVxdWVz dHMgbm8gYWN0aW9uIGJ5IElBTkEuPGJyPjxicj48YnI+OS4gJm5ic3A7QWNrbm93bGVkZ2VtZW50 czxicj48YnI+Jm5ic3A7IFRoZSBhdXRob3JzIHdvdWxkIGxpa2UgdG8gYWNrbm93bGVkZ2UgdGhl IGNvbnRyaWJ1dGlvbnMgb2YgRHIuPGJyPiZuYnNwOyBZb3VuZ0phZSBLaW0gZm9yIGhpcyByZXZp ZXcgYW5kIGNvbW1lbnRzLjxicj4KPGJyPjxicj4xMC4gJm5ic3A7UmVmZXJlbmNlczxicj48YnI+ MTAuMS4gJm5ic3A7Tm9ybWF0aXZlIFJlZmVyZW5jZXM8YnI+PGJyPiZuYnNwOyBbUkZDMjExOV0g Jm5ic3A7QnJhZG5lciwgUy4sICZxdW90O0tleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5k aWNhdGU8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 UmVxdWlyZW1lbnQgTGV2ZWxzJnF1b3Q7LCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Ljxi cj48YnI+MTAuMi4gJm5ic3A7SW5mb3JtYXRpdmUgUmVmZXJlbmNlczxicj4KPGJyPiZuYnNwOyBb SS1ELmlldGYtcm9sbC1pbmR1cy1yb3V0aW5nLXJlcXNdPGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO05ldHdvcmtzLCBELiBhbmQgUC4gVGh1YmVydCwg JnF1b3Q7SW5kdXN0cmlhbCBSb3V0aW5nPGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO1JlcXVpcmVtZW50cyBpbiBMb3cgUG93ZXIgYW5kIExvc3N5IE5l dHdvcmtzJnF1b3Q7LDxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtkcmFmdC1pZXRmLXJvbGwtaW5kdXMtcm91dGluZy1yZXFzLTAwICh3b3JrIGluIHBy b2dyZXNzKSw8YnI+CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO0FwcmlsIDIwMDguPGJyPjxicj4mbmJzcDsgW0ktRC5sZXZpcy1yb2xsLXByb3RvY29scy1z dXJ2ZXldPGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0xldmlzLCBQLiwgVmFzc2V1ciwgSi4sIGFuZCBELiBDdWxsZXIsICZxdW90O092ZXJ2aWV3IG9m PGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0V4aXN0 aW5nIFJvdXRpbmcgUHJvdG9jb2xzIGZvciBMb3cgUG93ZXIgYW5kIExvc3N5PGJyPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO05ldHdvcmtzJnF1b3Q7LCBk cmFmdC1sZXZpcy1yb2xsLXByb3RvY29scy1zdXJ2ZXktMDAgKHdvcmsgaW48YnI+CiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Byb2dyZXNzKSwgTWF5IDIw MDguPGJyPjxicj48YnI+PGJyPjxicj48YnI+PGJyPjxicj48YnI+PGJyPjxicj48YnI+PGJyPjxi cj48YnI+PGJyPjxicj5LaW0sIGV0IGFsLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtFeHBpcmVzIEphbnVhcnkgNSwgMjAwOSAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgW1BhZ2UgMTJdPGJyPjxicj5JbnRlcm5l dC1EcmFmdCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Um91dGluZyBNZXRyaWNz IGZvciBMTE5zICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBKdWx5IDIwMDg8YnI+Cjxicj48YnI+QXV0aG9ycyYjMzk7IEFkZHJlc3Nlczxicj48YnI+Jm5i c3A7IE1pamVvbSBLaW0gKGVkaXRvcik8YnI+Jm5ic3A7IEZ1dHVyZSBUZWNoIExhYi4sIEtUPGJy PiZuYnNwOyAxNyBXb29teWVvbi1kb25nLCBTZW9jaG8tZ3U8YnI+Jm5ic3A7IFNlb3VsICZuYnNw OzEzNy03OTI8YnI+Jm5ic3A7IEtvcmVhPGJyPjxicj4mbmJzcDsgUGhvbmU6ICs4Mi0yLTUyNi02 MDYzPGJyPiZuYnNwOyBGYXg6ICZuYnNwOyArODItMi01MjYtNTA3MTxicj4mbmJzcDsgRW1haWw6 IDxhIGhyZWY9Im1haWx0bzptamtpbUBrdC5jb20iPm1qa2ltQGt0LmNvbTwvYT48YnI+Cjxicj48 YnI+Jm5ic3A7IEpQIFZhc3NldXIgKGVkaXRvcik8YnI+Jm5ic3A7IENpc2NvIERpc3Rpbmd1aXNo ZWQgRW5naW5lZXI8YnI+Jm5ic3A7IDExLCBSdWUgQ2FtaWxsZSBEZXNtb3VsaW5zPGJyPiZuYnNw OyBMJiMzOTtBdGxhbnRpcyAmbmJzcDs5Mjc4MiBJc3N5IExlcyBNb3VsaW5lYXV4PGJyPiZuYnNw OyBGcmFuY2U8YnI+PGJyPiZuYnNwOyBFbWFpbDogPGEgaHJlZj0ibWFpbHRvOmpwdkBjaXNjby5j b20iPmpwdkBjaXNjby5jb208L2E+PGJyPgo8YnI+PGJyPiZuYnNwOyBIYWtqaW4gQ2hvbmc8YnI+ Jm5ic3A7IEZ1dHVyZSBUZWNoIExhYi4sIEtUPGJyPiZuYnNwOyAxNyBXb29teWVvbi1kb25nLCBT ZW9jaG8tZ3U8YnI+Jm5ic3A7IFNlb3VsICZuYnNwOzEzNy03OTI8YnI+Jm5ic3A7IEtvcmVhPGJy Pjxicj4mbmJzcDsgUGhvbmU6ICs4Mi0yLTUyNi01MDcwPGJyPiZuYnNwOyBGYXg6ICZuYnNwOyAr ODItMi01MjYtNTA3MTxicj4mbmJzcDsgRW1haWw6IDxhIGhyZWY9Im1haWx0bzpoamNob25nQGt0 LmNvbSI+aGpjaG9uZ0BrdC5jb208L2E+PGJyPgo8YnI+PGJyPjxicj48YnI+PGJyPjxicj48YnI+ PGJyPjxicj48YnI+PGJyPjxicj48YnI+PGJyPjxicj48YnI+PGJyPjxicj48YnI+PGJyPktpbSwg ZXQgYWwuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0V4 cGlyZXMgSmFudWFyeSA1LCAyMDA5ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBbUGFnZSAxM108YnI+PGJyPkludGVybmV0LURyYWZ0ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSb3V0aW5nIE1ldHJpY3MgZm9yIExMTnMgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEp1bHkgMjAwODxicj4KPGJy Pjxicj5GdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQ8YnI+PGJyPiZuYnNwOyBDb3B5cmlnaHQgKEMp IFRoZSBJRVRGIFRydXN0ICgyMDA4KS48YnI+PGJyPiZuYnNwOyBUaGlzIGRvY3VtZW50IGlzIHN1 YmplY3QgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9uczxicj4mbmJzcDsg Y29udGFpbmVkIGluIEJDUCA3OCwgYW5kIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhl IGF1dGhvcnM8YnI+CiZuYnNwOyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy48YnI+PGJyPiZuYnNw OyBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUg cHJvdmlkZWQgb24gYW48YnI+Jm5ic3A7ICZxdW90O0FTIElTJnF1b3Q7IGJhc2lzIGFuZCBUSEUg Q09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFM8YnI+Jm5ic3A7 IE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFksIFRIRSBJ RVRGIFRSVVNUIEFORDxicj4KJm5ic3A7IFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyBUQVNLIEZP UkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTPGJyPiZuYnNwOyBPUiBJTVBMSUVE LCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0Ug T0Y8YnI+Jm5ic3A7IFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5Z IFJJR0hUUyBPUiBBTlkgSU1QTElFRDxicj4KJm5ic3A7IFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRB QklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLjxicj48YnI+PGJyPklu dGVsbGVjdHVhbCBQcm9wZXJ0eTxicj48YnI+Jm5ic3A7IFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0 aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55PGJyPiZuYnNwOyBJbnRl bGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNs YWltZWQgdG88YnI+CiZuYnNwOyBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ug b2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluPGJyPiZuYnNwOyB0aGlzIGRvY3VtZW50IG9y IHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHM8YnI+Jm5i c3A7IG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2Vu dCB0aGF0IGl0IGhhczxicj4mbmJzcDsgbWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlk ZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gJm5ic3A7SW5mb3JtYXRpb248YnI+CiZuYnNwOyBvbiB0 aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2Fu IGJlPGJyPiZuYnNwOyBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS48YnI+PGJyPiZuYnNwOyBD b3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5k IGFueTxicj4mbmJzcDsgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJs ZSwgb3IgdGhlIHJlc3VsdCBvZiBhbjxicj4KJm5ic3A7IGF0dGVtcHQgbWFkZSB0byBvYnRhaW4g YSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZjxicj4mbmJzcDsg c3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXM8 YnI+Jm5ic3A7IHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24t bGluZSBJUFIgcmVwb3NpdG9yeSBhdDxicj4mbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRm Lm9yZy9pcHIiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL2lwcjwvYT4uPGJy Pgo8YnI+Jm5ic3A7IFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJp bmcgdG8gaXRzIGF0dGVudGlvbiBhbnk8YnI+Jm5ic3A7IGNvcHlyaWdodHMsIHBhdGVudHMgb3Ig cGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnk8YnI+Jm5ic3A7IHJpZ2h0 cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxl bWVudDxicj4mbmJzcDsgdGhpcyBzdGFuZGFyZC4gJm5ic3A7UGxlYXNlIGFkZHJlc3MgdGhlIGlu Zm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0PGJyPgombmJzcDsgPGEgaHJlZj0ibWFpbHRvOmlldGYt aXByQGlldGYub3JnIj5pZXRmLWlwckBpZXRmLm9yZzwvYT4uPGJyPjxicj48YnI+PGJyPjxicj48 YnI+PGJyPjxicj48YnI+PGJyPjxicj48YnI+S2ltLCBldCBhbC4gJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RXhwaXJlcyBKYW51YXJ5IDUsIDIwMDkgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFtQYWdlIDE0XTxi cj48YnI+PGJyPjxicj4tLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLTxicj4KVmVyc2lvbjog R251UEcgdjEuNC45IChHTlUvTGludXgpPGJyPjxicj5pRVlFQVJFQ0FBWUZBa2pVRjlRQUNna1FP UmdEMXFDWjJLZDAyQUNhQXlLQ2gwTFVHQVduNTE1QmRZWGRXRlZsPGJyPnowNEFuMmxDWGpnT2pJ U0hacUxYa3ZLN2ovYkJFV212PGJyPj1zbHBFPGJyPi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0t LTxicj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+ClJvbGwgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpSb2xsQGlldGYub3JnIj5S b2xsQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3JvbGwiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3JvbGw8L2E+PGJyPjxicj48L2Rpdj48L2Rpdj48YnI+PC9kaXY+Cg== ------=_Part_140688_21887504.1222257184528-- --===============0644883593== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0644883593==-- From roll-bounces@ietf.org Wed Sep 24 12:32:25 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045473A6A2C; Wed, 24 Sep 2008 12:32:25 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C311E3A6A2C for ; Wed, 24 Sep 2008 12:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M58A48MyNPjB for ; Wed, 24 Sep 2008 12:32:22 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 77FBC3A6973 for ; Wed, 24 Sep 2008 12:32:22 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id m8OJVeZR032690; Wed, 24 Sep 2008 12:31:40 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id m8OJVeL0032689; Wed, 24 Sep 2008 12:31:40 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 24 Sep 2008 12:31:40 -0700 From: David Meyer To: MiJeom Kim Message-ID: <20080924193140.GA32384@1-4-5.net> References: <20080919212124.GA14414@1-4-5.net> MIME-Version: 1.0 In-Reply-To: X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: roll@ietf.org Subject: Re: [Roll] Metric document: draft-mjkim-roll-routing-metrics-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1500037717==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1500037717== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey MiJeom, > I really appreciate your kind and detail comments.=20 Any time. > Mostly I agree with you in your opinion. However, there are > still things I'd like to discuss.=20 Sure, makes good sense. > > This document specifies routing metrics used in path calculation for > > Routing Over Low power and Lossy networks (ROLL). Low power and > > Lossy Networks (LLNs) have unique characteristics compared with > > traditional wired networks or even with similar ones such as mobile > > ad-hoc networks as indicated in several application-specific > > requirements documents. Since typical IGP routing metrics such as > > hop counts or link metrics are not sufficient for LLNs, > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > dmm> > > dmm> might give a sentence or two about why traditional IGP > > dmm> metrics aren't sufficient in the LLN context > > =3D=3D=3D> I think the sentence "LLNs have unique characteristics" is t= he > > reason. And this is the abstract, so I omitted all the details. However, > > it's not difficult to add some specific reasons such as resource > > constraints, so if you still think it's better to add, let me know. Nah, this isn't a big deal. > > dmm> I.F. Akyildiz, et. al., Computer Networks (38), 2002,, 393-422. > > =3D=3D=3D> Of course, considering a given path will make better route s= election > > possible than considering only individual nodes and links. It applies t= o not > > only power but also most other metrics, I believe. However, it's very > > challenging to consider paths in LLNs due to resource constraints and t= here > > are implementation issues. We may need to delay this issue until path > > calculation using the metrics is discussed. Fair enough. I'll note that we need to keep the number of metrics that we consider in any CBR solution (e.g., 3 or perhaps 4, if we want to be practical). > > dmm> so "relative" above means relative to other resources that > > dmm> are considered "more important"? How would we quantify that? > > =3D=3D=3D> Initially, I meant with "relative" that the residual energy = should > > not be evaluated with absolute values. For example, both devices A and B > > have the same amount of residual energy to last 1 year. A is essential = in > > the network such that the absence of the node causes network > > partition and A is neither rechargeable nor > > replaceable. However, B is easily replaceable. Then, 1 year > > of the power lifetime is a relative value to both devices. There=20 > > may be several ways to quantify that even though these are challenging.= When > > a device is produced or deployed, some parameters indicating the device= is > > rechargeable or replaceable easily or not can be set manually. Or some > > parameters indicating the role of the device in the network can be set = by > > the device itself using context aware capability such that it can recog= nize > > itself as a pivotal device to maintain network connectivity. Understood. Those "relative values" then will have to have well methods for both computation and propogation (I guess that goes w/o saying, even though I just did :-)). > > > > dmm> this implies that the routing protocol needs (must?) have a > > dmm> global view of the residual energy of the network (likely > > dmm> the rate at which certain devices are being dischared as > > dmm> well, and which ones are battery powered and which ones are > > dmm> mains powered). Is that what is intended? > > =3D=3D=3D> The routing protocol does not need to have a global view, bu= t it just > > needs to choose the best next hop among possible candidates. Ok, it sounded like a global energy mininumization problem (which I point out that some WSNs can do; of course, such WSNs aren't IP based). > energy balance among nodes in LLNs. > dmm> ^^^^^^^^^^^^ > dmm> how is "energy balance" defined? > =3D=3D=3D> I may say the amounts of residual energy of all nodes in the n= etwork > are fairly even. Ok. I didn't take that from the statement. Maybe clarify? > complicated processing to improve accuracy of the output data while > data aggregation mostly aims to reduce the amount of data. > Especially in urban applications where sensor nodes collect > dmm> s/Especially/Sensing overlap is common/ > =3D=3D=3D> Even though "overlap" is frequently used in the literature, we= might > need a definition for the term if we want to use it here. I cannot see any > reason to use the term "overlap" here, though. And the suggested > substitution results in connection of two sentences using comma, which is > incorrect. Ok, not a big deal (just pointing out that there is some existing terminology for this condition). > dmm> nice heuristic. Do we have a citation that examines the > dmm> use of this heuristic? > =3D=3D=3D> No, unfortunately we do not have a citation. This is just an i= dea. My point was that it would be nice to understand its properties.=20 > dmm> basically this is an "amplication effect" [RFC 3439] > =3D=3D=3D> you mean amplification? Actually I have not seen the reference= =2E Do you > think it's better to include the citation? Well, its a common issue when you have meshiness. > dmm> is that true, even if a more "dynamic" path has better (optimizes) > dmm> residual energy or some other metric of interest? i.e., is > dmm> the statement too general? > =3D=3D=3D> Dynamicity is just one metric. And we have more metrics to be = used in > path calculation. Thus, we need a weight for each metric. The sentence do= es > not say that dynamicity is the most important metric over other metrics. Humm, ok. I'm not sure but for no its fine. >=20 > A sleeping node should > dmm> question here about 2119 language. SHOULD NOT v. should not > =3D=3D=3D> I think "should not" is okay for now. Need further discussion. I asked the IESG for convential wisdom regarding 2119 language in non-protocol specs. I didn't get much guidance, so I'm guessing its a non-issue. >=20 > dmm> I think you mean: > dmm> Path (route) latency is usually computed as the sum of the > dmm> latencies of the indivudal nodes along a the path. > =3D=3D=3D> No, I mean path latency is the sum of all node latencies (sect= ion 4.4) > and all link propagation delays (senction 5.3) along the path. If the > original sentence is hard to read, I may change it. Might be a good idea. Looks like (at least) mis-interpreted what you meant. > As mentioned earlier, it can be obtained by making average > from historical data. >=20 > dmm> I think you mean: > dmm> As mentioned earlier, propogation delay can be obtained > dmm> averagin historical data. > dmm> > dmm> So where does this historical data reside? > =3D=3D=3D> each node should maintain the data. It does not need to keep a= ll the > historical data but just maintain an average. However, I also think that = it > costs high and has not much benefit since propagation delay is mostly > negligible. Need further discussion. Agreed, thnx. > dmm> are you suggesting data-aware routing here? > =3D=3D=3D> Yes, but trade-off should be further discussed. Again, agreed. > latency critical applications in military scenarios SHOULD put a > dmm> s/in military scenarios// > dmm> (since this would be true in any latency critical application) > =3D=3D=3D> I know what you mean, but this is an example. Thus I think it'= s better > to have "in military scenarios" since it helps to understand the example. My point was that the latency issue isn't specific to the military example. You might give this as *one* example of a latency constrained application. > o Influence of network topology and density: Network topology and > network density need to affect route construction in such a way > that they need to give some input to metric decision. For > example, star topology and mesh topology should employ different > routing protocols. >=20 > dmm> why? should be made explict > =3D=3D=3D> Actually, I intended to remove this final bullet, but accident= ally I > didn't delete in the first draft. I will remove it for the next submissio= n. Sure, happens. > dmm> This section needs to be expanded. Let me know if you'd like > dmm> me to contribute some text. > =3D=3D=3D> I would very appreciate if you contribute. I'll send text. Thnx, Dave --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjalZwACgkQORgD1qCZ2KcgHQCgi+SmnSWTtOFNETpPbcr9lTC7 x84An2CqeDgxKOfb9GDjEERAkAIllqPC =vgPF -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- --===============1500037717== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1500037717==-- From roll-bounces@ietf.org Fri Sep 26 11:38:52 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4023A6AC0; Fri, 26 Sep 2008 11:38:52 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFE333A690A for ; Fri, 26 Sep 2008 11:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3L4FpIvcjDIe for ; Fri, 26 Sep 2008 11:38:50 -0700 (PDT) Received: from psmtp.com (exprod8ob117.obsmtp.com [64.18.3.33]) by core3.amsl.com (Postfix) with ESMTP id 2EE883A69D3 for ; Fri, 26 Sep 2008 11:38:48 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob117.postini.com ([64.18.7.12]) with SMTP; Fri, 26 Sep 2008 11:34:59 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2008092613403121-4752826 ; Fri, 26 Sep 2008 13:40:31 -0500 MIME-Version: 1.0 To: nicolas.riou@fr.schneider-electric.com, pieter.demil@intec.ugent.be, roll@ietf.org, wouter@vooruit.be X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Fri, 26 Sep 2008 13:38:40 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 09/26/2008 01:38:37 PM, Serialize complete at 09/26/2008 01:38:37 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 09/26/2008 01:40:31 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 09/26/2008 01:40:54 PM, Serialize complete at 09/26/2008 01:40:54 PM Subject: [Roll] IETF Building Requirements X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1478039116==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multipart message in MIME format. --===============1478039116== Content-Type: multipart/alternative; boundary="=_alternative 0066683A862574D0_=" This is a multipart message in MIME format. --=_alternative 0066683A862574D0_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Team, I have received comments from JP Vassuer and David Culler and am readying=20 another version of the requirements spec. Can you please forward and/or=20 verify your personal information as noted below so I can add into the=20 spec? Authors? Addresses Jerry Martocci Johnson Control 507 E. Michigan Street Milwaukee, Wisconsin, 53202 USA Phone: 414.524.4010 Email: jerald.p.martocci@jci.com Nicolas Riou ? ? ? Phone: ? Email: nicolas.riou@fr.schneider-electric.com Pieter De Mil Ghent University - IBCN G. Crommenlaan 8 bus 201 Ghent 9050 Belgium Phone: +32-9331-4981 Fax: +32--9331--4899 Email: pieter.demil@intec.ugent.be Wouter Vermeylen Arts Centre Vooruit ??? Ghent 9000 Belgium Phone: ??? Fax: ??? Email: wouter@vooruit.be --=_alternative 0066683A862574D0_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
Team,

I have received comments from JP Vas= suer and David Culler and am readying another version of the requirements spec.  Can you please forward  and/or verify your personal information as noted below so I can add into the spec?


Authors’ Addresses


Jerry Martocci
Johnson Control
507 E. Michigan Street
Milwaukee, Wisconsin, 53202
USA

Phone: 414.524.4010
Email: jerald.p.martocci@jci.com

Nicolas Riou
?
?
?

Phone: ?
Email: nicolas.riou@fr.schneider-electric.com<= /font>



Pieter De Mil
Ghent University - IBCN
G. Crommenlaan 8 bus 201
Ghent  9050
Belgium

Phone: +32-9331-4981
Fax:   +32--9331--4899
Email: pieter.demil@intec.ugent.be<= /font>

Wouter Vermeylen
Arts Centre Vooruit
???
Ghent  9000
Belgium

Phone: ???
Fax:   ???
Email: wouter@vooruit.be --=_alternative 0066683A862574D0_=-- --===============1478039116== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1478039116==-- From roll-bounces@ietf.org Fri Sep 26 15:30:04 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 995A128C11A; Fri, 26 Sep 2008 15:30:04 -0700 (PDT) X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9994E3A69CB; Fri, 26 Sep 2008 15:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080926223001.9994E3A69CB@core3.amsl.com> Date: Fri, 26 Sep 2008 15:30:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D ACTION:draft-ietf-roll-protocols-survey-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Overview of Existing Routing Protocols for Low Power and Lossy Networks Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis Filename : draft-ietf-roll-protocols-survey-01.txt Pages : 22 Date : 2008-9-26 Networks of low power wireless devices introduce novel IP routing issues. Low-power wireless devices, such as sensors, actuators and smart objects, have difficult constraints: very limited memory, little processing power, and long sleep periods. As most of these devices are battery-powered, energy efficiency is critically important. Wireless link qualities can vary significantly over time, requiring protocols to make agile decisions yet minimize topology change energy costs. Routing over such low power and lossy networks has novel requirements that existing protocols may not address. This document provides a brief survey of the strengths and weaknesses of existing protocols with respect to this class of networks. From this survey it examines whether existing protocols as described in RFCs and mature drafts could be used without modification in these networks, or whether further work is necessary. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-protocols-survey-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-9-26152556.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --NextPart-- From roll-bounces@ietf.org Fri Sep 26 15:50:54 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 763C83A6AD0; Fri, 26 Sep 2008 15:50:54 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B58C93A68F7 for ; Fri, 26 Sep 2008 15:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9RDPhFtra5U for ; Fri, 26 Sep 2008 15:50:51 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 0CE9128C11B for ; Fri, 26 Sep 2008 15:50:27 -0700 (PDT) Received: from dnab4233eb.stanford.edu ([171.66.51.235]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1KjM91-0000tw-4l for roll@ietf.org; Fri, 26 Sep 2008 15:50:39 -0700 Message-Id: <6FBCA6DC-8B05-4AE2-A3FA-561F9D727700@cs.stanford.edu> From: Philip Levis To: roll@ietf.org In-Reply-To: <20080926223001.9994E3A69CB@core3.amsl.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 26 Sep 2008 15:50:38 -0700 References: <20080926223001.9994E3A69CB@core3.amsl.com> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: 126b1dc68df40fcb6eeab1e6794671ae Subject: Re: [Roll] I-D ACTION:draft-ietf-roll-protocols-survey-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Sep 26, 2008, at 3:30 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > Title : Overview of Existing Routing Protocols for Low Power and > Lossy Networks > Author(s) : A. Tavakoli, S. Dawson-Haggerty, P. Levis > Filename : draft-ietf-roll-protocols-survey-01.txt > Pages : 22 > Date : 2008-9-26 Changelog: - Added methodology section - Describes the scope of what protocols are considered (RFCs and mature drafts) and why - Describes how the analysis is done - Tightened criteria, adding more precise references to application drafts and division between pass/fail/? - Tightened analysis, being more specific on why protocols have a certain result As always, feedback and suggestions are welcome. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Sat Sep 27 14:03:59 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 323AF3A67EE; Sat, 27 Sep 2008 14:03:59 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18FA3A67EE for ; Sat, 27 Sep 2008 14:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.184 X-Spam-Level: X-Spam-Status: No, score=-1.184 tagged_above=-999 required=5 tests=[AWL=-1.413, BAYES_50=0.001, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDl6VNyozep3 for ; Sat, 27 Sep 2008 14:03:43 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 512D73A635F for ; Sat, 27 Sep 2008 14:03:43 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id m8RL2eqh017181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 27 Sep 2008 14:02:41 -0700 (PDT) Message-ID: <48DE9F6B.2050404@eecs.berkeley.edu> Date: Sat, 27 Sep 2008 14:02:35 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: Cc: sicco.dwars@shell.com, roll@ietf.org, tom.phinney@cox.net Subject: Re: [Roll] Detailed Review of draft-ietf-roll-indus-routing-reqs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2127653867==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============2127653867== Content-Type: multipart/alternative; boundary="------------000407060305080405030907" This is a multi-part message in MIME format. --------------000407060305080405030907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit JP - good comments, thanks. We'll incorporate/address most of these. I have a few questions and comments below. ksjp JP Vasseur wrote: > Hi, > > After the review of draft-ietf-roll-urban-routing-reqs and > draft-ietf-roll-home-routing-reqs (new revision coming soon according > to their authors), here is my review of > draft-ietf-roll-indus-routing-reqs (lots of excellent content). > > 1) Abstract and Section 2 > For wireless devices to have a significant > advantage over wired devices in an industrial environment the > wireless network needs to have three qualities: low power, high > reliability, and easy installation and maintenance. > > JP> I would propose not to "oppose" wireless and wired devices. > Indeed, sensor networks will more than likely be interconnected by a > variety of links. Still those networks will be LLN and will require > these three qualities. I would then suggest to keep the list of > qualities but generalize it to devices in LLN. > > > 2) s/L2N/LLN in the entire document (to match the ROLL charter). > I still owe the WG a terminology ID (will be done early next week). > > 3) I skip the terminology section since it will addressed in the > terminology ID. > > 4) Introduction > > Referring to: > "Wireless field devices enable expansion of networked points by > appreciably reducing cost of installing a device. The cost > reductions come from eliminating cabling costs and simplified > planning. Cabling also carries an overhead cost associated with > planning the installation, determining where the cable has to run, > and interfacing with the various organizations required to coordinate > its deployment. Doing away with the network and power cables reduces > the planning and administrative overhead of installing a device." > > JP> This is a bit arguable ... (look at PLC) and not really a > technical consideration. I would suggest to simply remove this paragraph. Maybe we should have the argument :) Can you elaborate on your thinking? > > 5) Section 2 > > * "wired HART" please add a informative reference. > > 6) s/"In the near future, most low power and lossy network systems will be > for low frequency data collection."/"In the near future, most low > power and lossy network systems in industrial automation environments > will be > for low frequency data collection." > > 7) In several places, you make the assumption that the collected data > is sent to a Sink/... Residing outside of the LLN. Don't you see cases > where there will be intra-LLN flows in Industrial automation ? > And I just read: " In the future, it is envisioned that some open > loop processes will be > automated (closed loop) and packets will flow over local loops and > not involve the L2N access point. " - Thanks. > > 8) you wrote: "More likely though is that loops will be closed in the > field > entirely, which in most cases eliminates the need for having wireless > links within the control loop." > Why does this eliminate the need for wireless links ? > > 9) "L2N-ish" ... You may want to slighlty reword here ;-) > > 10) s/"maximum number of hops from two to twenty."/"maximum number of > hops of twenty" > > 11) Section 2.2 > > You wrote: " The backbone is a high-speed infrastructure network that may > interconnect multiple WSNs through backbone routers. Infrastructure > devices can be connected to the backbone. A gateway / manager that > interconnects the backbone to the plant network of the corporate > network can be viewed as collapsing the backbone and the > infrastructure devices into a single device that operates all the > required logical roles. The backbone is likely to become an > important function of the industrial network." > > Although I do agree that this is a common architecture, you may want > to indicate that this is only *one* possible architecture. > > 12) Could you please use a coherent terminology throughout the > document ? L2N sensor, field devices, ... I'll try to write the > terminology ID this week, then thanks to align the terminology. > > 13) I found this section is bit out of the scope: > > "This multiple domain multiple applications connectivity creates a > significant challenge. Many different applications will all share > the same medium, the ether, within the fence, preferably sharing the > same frequency bands, and preferably sharing the same protocols, > preferably synchronized to optimize co-existence challenges, yet > logically segregated to avoid creation of intolerable short cuts > between existing wired domains. > > Given this challenge, L2N networks are best to be treated as all > sitting on yet another segregated domain, segregated from all other > wired domains where conventional security is organized by perimeter. > Moving away from the traditional perimeter security mindset means > moving towards stronger end-device identity authentication, so that > L2N access points can split the various wireless data streams and > interconnect back to the appropriate domain pending identity and > trust established by the gateways in the authenticity of message > originators." Actually, I think that this is one of the critical hard problems for the IETF in general, and some future re-chartered RoLL in particular, to solve in sensor networks. I'll work with Sicco to make this clearer, but the main point here is that routing in industrial automation (at least) is not just a question of populating look-up tables. If mote A has a packet for mote Z, that packet may take a very different path through the network depending on the application and QoS constraints. Maybe B is the shortest path from A to Z, and certain packets do flow from A to B to Z, but other packets do not have: 1) the right security; 2) the right priority; 3) the right application type; 4) the same QoS contract. The routing algorithm must take into account both the QoS requirements coming down from L4, and the link constraints coming up from L2. > > 14) Question about Figure 1: it looks like we still do have to compute > routes within the LLN ? > Furthermore, thanks to mention that this is one of many potential > architectures. For example, in section 2.2.2 you wrote "2.2.2. > Logical Topologies > > Most of the traffic over the LLN is publish/subscribe of sensor data > from the field device towards the backbone router or gateway that > acts as the sink for the WSN." > > You may want to replace the backbone router/gateway by a sink to make > the statement more general and applicable to other topologies (without > a gateway, ...). The use of gateway is a bit dangerous here unless > carefully defined but we'll discuss terminology in a separate email. > > 15) Section 2.2.2: "Since publishing the data is the raison d'etre for > most of the > sensors, it makes sense to build proactively a set of default routes > between the sensors and one or more backbone router and maintain > those routes at all times. Also, because of the lossy nature of the > network, the routing in place should attempt to propose multiple > forwarding solutions, building forwarding topologies in the form of > Directed Acyclic Graphs oriented towards the sinks." > > Is it a requirement to be able to configure "default routes?" > By "multiple forwarding solutions" do you actually means "multiple > paths" ? > > 16) Comment on "For these reasons, the ROLL routing infrastructure > MUST be able to > compute and update constrained routes on demand (that is reactively), > and it can be expected that this model will become more prevalent for > field device to field device connectivity as well as for some field > device to Infrastructure devices over time." > > * you may want to move the MUST in the routing requirement > sections, to have them all in one place. > * Are you requiring a reactive mechanism > > > 17) Section 3. > * "Service Requirement" - You may want to change the title for > "Traffic Characteristics" just to avoid confusion with upper layer > requirements. *excellent paragraph > ** I'm not sure to see the rationale of the various bullets "data > bandwidth", "Latency", ... In this context of routing requirements. > * You wrote "The routing protocol > MUST be able to set up unidirectional or asymmetrical cost routes > that are composed of one or more non congruent paths." > You may want to reword this sentence, which may be misleading (in > particular, there is no "or" routes can be unidirectional and > asymmetrical"). Did you mean "The routing protocol MUST be able to > compute a set of unidirectional routes with potentially different costs". > > 18) Section 3.1 > > * S/ Time-varying user requirements for latency and bandwidth will require > changes in the provisioning of the underlying L2 protocols/ > Time-varying user requirements for latency and bandwidth may require > changes in the provisioning of the underlying L2 protocols. > > * "The routing protocol MUST route on paths that are changed to > appropriately provision the application requirements." > > JP> This should translate into "The routing protocol MUST dynamically > recompute path if the underlying topology changes. No, I think that you're missing the point. Say I currently have a route from A->B->Z that is provisioned to handle 1 packet every 5 seconds. There are other routes, e.g. A->C->Z that are known to exist, but are not used. Then A requests 100 times more bandwidth, and B announces that it can handle twice the bandwidth, but anything more would violate it's energy-scavenging-limited power restrictions. This triggers both a need to generate new routes, and to update a bunch of L2 provisioning. You could try to auto-detect-and-provision on L2, but if the service request is based on latency instead of BW, then there is no way for L2 to figure that out by itself. Solving the routing problem without some information exchange with L2 is not possible. > > "The routing > protocol MUST support the ability to recompute paths based on > underlying link characteristics that may change dynamically." > > JP> Could you be more accurate ? "What if the BER crosses some > threshold?". Should it trigger a path computation ? If so, you would > need to list all parameters that can trigger a path computation. > Alternatively, (IMO the prefered option) each of the link > characteristic should be reflected in a metric or attribute change > that will trigger a path computation (use filters of course). I'm not sure that I understand. If I change "link characteristics" to "link metrics" does that fix it? > > 19) Section 3.2. > S/"The routing algorithm MUST be able to > generate different routes for different flows."/"The routing > algorithm MUST be able to > generate different routes with different characteritics (e.g. > Optimized according to different cost, ...)." > > 20) Replace globally "low power lossy network" by "LLN". > > 21) Replace globally "#" by "number". > > 22) s/" 3) Probability of failure on demand,"/" 3) Probability of > failure to compute an on demand route" > > 23) In the list of "Reliability Requirements" you may want to add a > "..." since there are many other ones (ability to reroute upon a > network failure, ...). > > 24) "Hop-by-hop path diversity is used to improve latency-bounded > reliability." > > JP> Path diversity does not help with latency-bounded reliability ... > It does help to increase packet delivery if you use a 1+1 technique, > or to find an alternate path or limit the proportion of flows impacted > by a single failure but not for latency. What did you mean ? Path diversity *does* help with latency-bounded reliability, and I have volumes of data to prove it. In LLNs the PDR on individual links can very rapidly change by many tens of percent, up to and including a sudden transition from near 100% to 0%. If I have a 1s latency target for 99.9% of my packets, a substantial change in PDR needs to initiate new path computation, but I can't afford to wait around for the results of that effort - I need another path right now. And that other path can't be something that I created as a backup yesterday and haven't used recently. It needs to be exercised regularly so that I know that I can trust it. > > 25) "The routing protocol MUST support multiple L2N access > points and load distribution among L2N access points. > JP> In order to make this requirement not "topology dependent" could > you reword it "The routing protocol MUST be able to compute paths > towards different destination so as to perform load balancing across a > variety of paths." Hmm. What if the destination is a control system on the (not LLN) plant network, and I have a choice of many different APs? I guess that the diversity requirement in 24) is enough. > > 26) "The routing > protocol MUST support multiple L2N access points when L2N access > point redundancy is required." > > This is not a routing protocol requirement. > > 27) "Because L2Ns are lossy in nature, > multiple paths in a L2N route MUST be supported. " --> already stated. > > 28) Section 6: > > "2) Delivery of common packets to multiple routers over a backbone, > where the packets results in each receiving router initiating > multicast (sometimes as a full broadcast) within the LLN. This > is byproduct of having potentially physically separated backbone > routers that can inject messages into different portions of the > same larger LLN." > > JP> IMO a too solution-specific statement. > > 29) Section 7 > * "The routing algorithm SHOULD always be in the process of > optimizing the system in response to changing link statistics." > JP> The term "optimizing" is worth a few words of explanation. > Optimizing with regards to which objective ? > > * "The > routing algorithm MUST re-optimize the paths when field devices > change due to insertion, removal or failure, and this re-optimization > MUST not cause latencies greater than the specified constraints > (typically seconds to minutes)." > Few comments here: (1) The first "MUST" is not different than the > basic requirement of being able to compute new path upon topology > changes. (2) I would propose to carefully use the term > "re-optimization". Indeed, I guess that you refer to the event where a > "shorter" path is found according to some metrics. Then you are > requiring the ability to switch to a shorter path while bounding the > latency, which requires to only switch if the delta between the old > and new cost is also bounded and also implies other constraints. > Indeed, in distributed systems, you cannot guarantee that systems are > fully synchronized. Thus a router may start using a route that is not > yet ready if some of the next hops have not converged yet, which may > lead to micro-loops. Could you elaborate on this requirement ? > > 30) > * "The routing protocol SHOULD support the wireless worker with fast > network connection times of a few of seconds, and low command and > response latencies to the plant behind the L2N access points, to > applications, and to field devices. " > > Is it a different requirement than the one expressed in Section 7: > > "The routing algorithm MUST find the appropriate > route(s) and report success or failure within several minutes, and > SHOULD report success or failure within tens of seconds." > > > * "The routing protocol SHOULD also > support the bandwidth allocation for bulk transfers between the field > device and the handheld device of the wireless worker. " > > JP> of course, I see what you mean but this should either be removed > or reworded. This may simply refer to topology changes, for which you > already have a routing requirement or some cross-layer function (hope > not). > > "The routing > protocol SHOULD support walking speeds for maintaining network > connectivity as the handheld device changes position in the wireless > network. > > Some field devices will be mobile. These devices may be located on > moving parts such as rotating components or they may be located on > vehicles such as cranes or fork lifts. The routing protocol SHOULD > support vehicular speeds of up to 35 kmph. > " > > JP> You may just want to say that such requirement has also > consequences on non-routing functions. Can you elaborate on this last line? > > 31) Section 9 > > * "Therefore, > the routing protocol MUST support auto-provisioning of field devices." > > JP> To which extent ? Does that mean a true 0-configuration routing > protocol ? If by "true 0-configuration" you mean that someone who knows nothing about networking can bolt 10 pressure sensors onto an oil well head and not have to do anything else to get them to work, then yes. > > *"The protocol also MUST support the distribution of configuration from > a centralized management controller if operator-initiated > configuration change is allowed." > > JP> Not a routing requirement. Or do you refer to the dynamic set up > of a "default DAG/Tree" used to retrieve a more sophisticated "routing > feature" from a centralized tool ? Definitely not a default DAG. Sicco? > > 32) Section 10 > > * s/"1) attacks on the actual application served be the wireless > devices and "/"1) attacks on the actual application served by the > wireless > devices and " > > * "2) attacks that exploit the presence of a wireless access > point that MAY provide connectivity onto legacy wired plant networks, > so attacks that have little to do with the wireless devices in the > L2Ns. "/"2) attacks that exploit the presence of a wireless access > point that may provide connectivity onto legacy wired plant networks, > so attacks that have little to do with the wireless devices in the > LLNs. " > > * "The routing protocol SHOULD place limited trust in the field devices > deployed in the plant network. > " > > JP> Could you elaborate a little bit ? It sounds a bit too vague for a > protocol designer to figure out what action to take according to this > requirement. > > "Standards exist that address those > vulnerabilities." > > JP> ?? > > 33) replace "isn't by is not", "doesn't by does not" , ... > > Thanks. > > Cheers, > > JP. --------------000407060305080405030907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit JP - good comments, thanks.  We'll incorporate/address most of these.
I have a few questions and comments below.

ksjp

JP Vasseur wrote:

Detailed Review of draft-ietf-roll-indus-routing-reqs Hi,

After the review of draft-ietf-roll-urban-routing-reqs and draft-ietf-roll-home-routing-reqs (new revision coming soon according to their authors), here is my review of draft-ietf-roll-indus-routing-reqs (lots of excellent content).

1) Abstract and Section 2
      For wireless devices to have a significant
   advantage over wired devices in an industrial environment the
   wireless network needs to have three qualities: low power, high
   reliability, and easy installation and maintenance.

JP> I would propose not to “oppose” wireless and wired devices. Indeed, sensor networks will more than likely be interconnected by a variety of links. Still those networks will be LLN and will require these three qualities. I would then suggest to keep the list of qualities but generalize it to devices in LLN.


2) s/L2N/LLN in the entire document (to match the ROLL charter).
I still owe the WG a terminology ID (will be done early next week).

3) I skip the terminology section since it will addressed in the terminology ID.

4) Introduction

Referring to:
“Wireless field devices enable expansion of networked points by
   appreciably reducing cost of installing a device.  The cost
   reductions come from eliminating cabling costs and simplified
   planning.  Cabling also carries an overhead cost associated with
   planning the installation, determining where the cable has to run,
   and interfacing with the various organizations required to coordinate
   its deployment.  Doing away with the network and power cables reduces
   the planning and administrative overhead of installing a device.”

JP> This is a bit arguable ... (look at PLC) and not really a technical consideration. I would suggest to simply remove this paragraph.
Maybe we should have the argument :)  Can you elaborate on your thinking?

5) Section 2

* “wired HART” please add a informative reference.

6) s/”In the near future, most low power and lossy network systems will be
   for low frequency data collection.”/”In the near future, most low power and lossy network systems in industrial automation environments will be
   for low frequency data collection.”

7) In several places, you make the assumption that the collected data is sent to a Sink/... Residing outside of the LLN. Don’t you see cases where there will be intra-LLN flows in Industrial automation ?
And I just read: “  In the future, it is envisioned that some open loop processes will be
   automated (closed loop) and packets will flow over local loops and
   not involve the L2N access point. “ - Thanks.

8) you wrote: “More likely though is that loops will be closed in the field
   entirely, which in most cases eliminates the need for having wireless
   links within the control loop.”
Why does this eliminate the need for wireless links ?

9) “L2N-ish” ... You may want to slighlty reword here ;-)

10) s/”maximum number of hops from two to twenty.”/”maximum number of hops of twenty”

11) Section 2.2

You wrote: “ The backbone is a high-speed infrastructure network that may
   interconnect multiple WSNs through backbone routers.  Infrastructure
   devices can be connected to the backbone.  A gateway / manager that
   interconnects the backbone to the plant network of the corporate
   network can be viewed as collapsing the backbone and the
   infrastructure devices into a single device that operates all the
   required logical roles.  The backbone is likely to become an
   important function of the industrial network.”

Although I do agree that this is a common architecture, you may want to indicate that this is only one possible architecture.

12) Could you please use a coherent terminology throughout the document ? L2N sensor, field devices, ... I’ll try to write the terminology ID this week, then thanks to align the terminology.

13) I found this section is bit out of the scope:

“This multiple domain multiple applications connectivity creates a
   significant challenge.  Many different applications will all share
   the same medium, the ether, within the fence, preferably sharing the
   same frequency bands, and preferably sharing the same protocols,
   preferably synchronized to optimize co-existence challenges, yet
   logically segregated to avoid creation of intolerable short cuts
   between existing wired domains.

   Given this challenge, L2N networks are best to be treated as all
   sitting on yet another segregated domain, segregated from all other
   wired domains where conventional security is organized by perimeter.
   Moving away from the traditional perimeter security mindset means
   moving towards stronger end-device identity authentication, so that
   L2N access points can split the various wireless data streams and
   interconnect back to the appropriate domain pending identity and
   trust established by the gateways in the authenticity of message
   originators.”
Actually, I think that this is one of the critical hard problems for the IETF in general, and some
future re-chartered RoLL in particular, to solve in sensor networks.  I'll work with Sicco to make
this clearer, but the main point here is that routing in industrial automation (at least) is not just
a question of populating look-up tables.  If mote A has a packet for mote Z, that packet may take
a very different path through the network depending on the application and QoS constraints.
Maybe B is the shortest path from A to Z, and certain packets do flow from A to B to Z, but
other packets do not have: 1) the right security; 2) the right priority; 3) the right application
type; 4) the same QoS contract.
The routing algorithm must take into account both the QoS requirements coming down from
L4, and the link constraints coming up from L2.

14) Question about Figure 1: it looks like we still do have to compute routes within the LLN ?
Furthermore, thanks to mention that this is one of many potential architectures. For example, in section 2.2.2 you wrote “2.2.2.  Logical Topologies

   Most of the traffic over the LLN is publish/subscribe of sensor data
   from the field device towards the backbone router or gateway that
   acts as the sink for the WSN.”

You may want to replace the backbone router/gateway by a sink to make the statement more general and applicable to other topologies (without a gateway, ...). The use of gateway is a bit dangerous here unless carefully defined but we’ll discuss terminology in a separate email.

15) Section 2.2.2: “Since publishing the data is the raison d'etre for most of the
   sensors, it makes sense to build proactively a set of default routes
   between the sensors and one or more backbone router and maintain
   those routes at all times.  Also, because of the lossy nature of the
   network, the routing in place should attempt to propose multiple
   forwarding solutions, building forwarding topologies in the form of
   Directed Acyclic Graphs oriented towards the sinks.”

Is it a requirement to be able to configure “default routes?”
By “multiple forwarding solutions” do you actually means “multiple paths” ?

16) Comment on “For these reasons, the ROLL routing infrastructure MUST be able to
   compute and update constrained routes on demand (that is reactively),
   and it can be expected that this model will become more prevalent for
   field device to field device connectivity as well as for some field
   device to Infrastructure devices over time.”
  • you may want to move the MUST in the routing requirement sections, to have them all in one place.
  • Are you requiring a reactive mechanism

17) Section 3.
* “Service Requirement” - You may want to change the title for “Traffic Characteristics” just to avoid confusion with upper layer requirements. excellent paragraph
* I’m not sure to see the rationale of the various bullets “data bandwidth”, “Latency”, ... In this context of routing requirements.
* You wrote “The routing protocol
   MUST be able to set up unidirectional or asymmetrical cost routes
   that are composed of one or more non congruent paths.”
You may want to reword this sentence, which may be misleading (in particular, there is no “or” routes can be unidirectional and asymmetrical”). Did you mean “The routing protocol MUST be able to compute a set of unidirectional routes with potentially different costs”.

18) Section 3.1

* S/ Time-varying user requirements for latency and bandwidth will require
   changes in the provisioning of the underlying L2 protocols/ Time-varying user requirements for latency and bandwidth may require
   changes in the provisioning of the underlying L2 protocols.

*  “The routing protocol MUST route on paths that are changed to
   appropriately provision the application requirements.”  

JP> This should translate into “The routing protocol MUST dynamically recompute path if the underlying topology changes.
No, I think that you're missing the point.  Say I currently have a route from A->B->Z that is provisioned to handle 1 packet every 5 seconds.  There are other routes, e.g. A->C->Z that are known to exist, but are not used.  Then A requests 100 times more bandwidth, and B announces that it can handle twice the bandwidth, but anything more would violate it's energy-scavenging-limited power restrictions.  This triggers both a need to generate new routes, and to update a bunch of L2 provisioning.  You could try to auto-detect-and-provision on L2, but if the service request is based on latency instead of BW, then there is no way for L2 to figure that out by itself.  Solving the routing problem without some information exchange with L2 is not possible.

   “The routing
   protocol MUST support the ability to recompute paths based on
   underlying link characteristics that may change dynamically.”

JP> Could you be more accurate ? “What if the BER crosses some threshold?”. Should it trigger a path computation ? If so, you would need to list all parameters that can trigger a path computation. Alternatively, (IMO the prefered option) each of the link characteristic should be reflected in a metric or attribute change that will trigger a path computation (use filters of course).
I'm not sure that I understand.  If I change "link characteristics" to "link metrics" does that fix it?

19) Section 3.2.
S/”The routing algorithm MUST be able to
   generate different routes for different flows.”/”The routing algorithm MUST be able to
   generate different routes with different characteritics (e.g. Optimized according to different cost, ...).”

20) Replace globally “low power lossy network” by “LLN”.

21) Replace globally “#” by “number”.

22) s/” 3)  Probability of failure on demand,”/” 3)  Probability of failure to compute an on demand route”

23) In the list of “Reliability Requirements” you may want to add a “...” since there are many other ones (ability to reroute upon a network failure, ...).

24) “Hop-by-hop path diversity is used to improve latency-bounded
   reliability.”

JP> Path diversity does not help with latency-bounded reliability ... It does help to increase packet delivery if you use a 1+1 technique, or to find an alternate path or limit the proportion of flows impacted by a single failure but not for latency. What did you mean ?
Path diversity *does* help with latency-bounded reliability, and I have volumes of data to prove it.  In LLNs the PDR on individual links can very rapidly change by many tens of percent, up to and including a sudden transition from near 100% to 0%.  If I have a 1s latency target for 99.9% of my packets, a substantial change in PDR needs to initiate new path computation, but I can't afford to wait around for the results of that effort - I need another path right now.  And that other path can't be something that I created as a backup yesterday and haven't used recently.  It needs to be exercised regularly so that I know that I can trust it.

25) “The routing protocol MUST support multiple L2N access
   points and load distribution among L2N access points.  
JP> In order to make this requirement not “topology dependent” could you reword it “The routing protocol MUST be able to compute paths towards different destination so as to perform load balancing across a variety of paths.”
Hmm.  What if the destination is a control system on the (not LLN) plant network, and I have a choice of many different APs?  I guess that the diversity requirement in 24) is enough.

26) “The routing
   protocol MUST support multiple L2N access points when L2N access
   point redundancy is required.”

This is not a routing protocol requirement.

27) “Because L2Ns are lossy in nature,
   multiple paths in a L2N route MUST be supported. “ --> already stated.

28) Section 6:

“2)  Delivery of common packets to multiple routers over a backbone,
       where the packets results in each receiving router initiating
       multicast (sometimes as a full broadcast) within the LLN.  This
       is byproduct of having potentially physically separated backbone
       routers that can inject messages into different portions of the
       same larger LLN.”

JP> IMO a too solution-specific statement.

29) Section 7
* “The routing algorithm SHOULD always be in the process of
   optimizing the system in response to changing link statistics.”
JP> The term “optimizing” is worth a few words of explanation. Optimizing with regards to which objective ?

* “The
   routing algorithm MUST re-optimize the paths when field devices
   change due to insertion, removal or failure, and this re-optimization
   MUST not cause latencies greater than the specified constraints
   (typically seconds to minutes).”
Few comments here: (1) The first “MUST” is not different than the basic requirement of being able to compute new path upon topology changes. (2) I would propose to carefully use the term “re-optimization”. Indeed, I guess that you refer to the event where a “shorter” path is found according to some metrics. Then you are requiring the ability to switch to a shorter path while bounding the latency, which requires to only switch if the delta between the old and new cost is also bounded and also implies other constraints. Indeed, in distributed systems, you cannot guarantee that systems are fully synchronized. Thus a router may start using a route that is not yet ready if some of the next hops have not converged yet, which may lead to micro-loops. Could you elaborate on this requirement ?

30)
* “The routing protocol SHOULD support the wireless worker with fast
   network connection times of a few of seconds, and low command and
   response latencies to the plant behind the L2N access points, to
   applications, and to field devices.  “

Is it a different requirement than the one expressed in Section 7:

“The routing algorithm MUST find the appropriate
   route(s) and report success or failure within several minutes, and
   SHOULD report success or failure within tens of seconds.”


* “The routing protocol SHOULD also
   support the bandwidth allocation for bulk transfers between the field
   device and the handheld device of the wireless worker.   “

JP> of course, I see what you mean but this should either be removed or reworded. This may simply refer to topology changes, for which you already have a routing requirement or some cross-layer function (hope not).

“The routing
   protocol SHOULD support walking speeds for maintaining network
   connectivity as the handheld device changes position in the wireless
   network.

   Some field devices will be mobile.  These devices may be located on
   moving parts such as rotating components or they may be located on
   vehicles such as cranes or fork lifts.  The routing protocol SHOULD
   support vehicular speeds of up to 35 kmph.
“

JP> You may just want to say that such requirement has also consequences on non-routing functions.
Can you elaborate on this last line?

31) Section 9

* “Therefore,
   the routing protocol MUST support auto-provisioning of field devices.”

JP> To which extent ? Does that mean a true 0-configuration routing protocol ?
If by "true 0-configuration" you mean that someone who knows nothing about networking can bolt 10 pressure sensors onto an oil well head and not have to do anything else to get them to work, then yes.

*”The protocol also MUST support the distribution of configuration from
   a centralized management controller if operator-initiated
   configuration change is allowed.”

JP> Not a routing requirement. Or do you refer to the dynamic set up of a “default DAG/Tree” used to retrieve a more sophisticated “routing feature” from a centralized tool ?
Definitely not a default DAG.  Sicco?

32) Section 10

* s/”1) attacks on the actual application served be the wireless
   devices and “/”1) attacks on the actual application served by the wireless
   devices and “

* “2) attacks that exploit the presence of a wireless access
   point that MAY provide connectivity onto legacy wired plant networks,
   so attacks that have little to do with the wireless devices in the
   L2Ns. “/”2) attacks that exploit the presence of a wireless access
   point that may provide connectivity onto legacy wired plant networks,
   so attacks that have little to do with the wireless devices in the
   LLNs. “

* “The routing protocol SHOULD place limited trust in the field devices
   deployed in the plant network.
“

JP> Could you elaborate a little bit ? It sounds a bit too vague for a protocol designer to figure out what action to take according to this requirement.

“Standards exist that address those
   vulnerabilities.”

JP> ??

33) replace “isn’t by is not”, “doesn’t by does not” , ...

Thanks.

Cheers,

JP.
--------------000407060305080405030907-- --===============2127653867== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============2127653867==-- From roll-bounces@ietf.org Tue Sep 30 16:04:40 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4785428C1A6; Tue, 30 Sep 2008 16:04:40 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 151573A68DC for ; Tue, 30 Sep 2008 16:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5stFjRQF0dDy for ; Tue, 30 Sep 2008 16:02:57 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 564043A68BD for ; Tue, 30 Sep 2008 16:02:57 -0700 (PDT) Received: from [192.168.7.188] (69-12-164-140.sfo.archrock.com [69.12.164.140]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id m8UN3EdK000557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 30 Sep 2008 16:03:16 -0700 (PDT) Message-ID: <48E2B028.803@eecs.berkeley.edu> Date: Tue, 30 Sep 2008 16:03:04 -0700 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: roll@ietf.org X-Mailman-Approved-At: Tue, 30 Sep 2008 16:04:39 -0700 Subject: [Roll] Polling the Roll WG for Adoption of the Terminology Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I would like to poll the membership on adoption of the Terminology ID. Link to the draft is below. http://www.ietf.org/internet-drafts/draft-vasseur-roll-terminology-02.txt _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Sep 30 16:53:47 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D9593A6B31; Tue, 30 Sep 2008 16:53:47 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F94A3A6B33 for ; Tue, 30 Sep 2008 16:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z09T+hvmmold for ; Tue, 30 Sep 2008 16:53:44 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id B35F53A6B31 for ; Tue, 30 Sep 2008 16:53:44 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id m8UNs2rO009133; Tue, 30 Sep 2008 16:54:02 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id m8UNs233009132; Tue, 30 Sep 2008 16:54:02 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 30 Sep 2008 16:54:02 -0700 From: David Meyer To: "David E. Culler" Message-ID: <20080930235402.GA9113@1-4-5.net> References: <48E2B028.803@eecs.berkeley.edu> MIME-Version: 1.0 In-Reply-To: <48E2B028.803@eecs.berkeley.edu> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: roll@ietf.org Subject: Re: [Roll] Polling the Roll WG for Adoption of the Terminology Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1103324783==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1103324783== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Sep 30, 2008 at 04:03:04PM -0700, David E. Culler wrote: > I would like to poll the membership on adoption of the Terminology ID. Link to the draft is below. > > http://www.ietf.org/internet-drafts/draft-vasseur-roll-terminology-02.txt > In favor. Dave --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjivBoACgkQORgD1qCZ2KdDBgCeOIkeGtDiwF9Q3iAlAxWohtD0 DGQAnA45Pj1o7JmtGuSaPt+0l7uK7lnN =vKKy -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- --===============1103324783== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1103324783==-- From roll-bounces@ietf.org Wed Oct 1 00:21:54 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855FD3A6C0D; Wed, 1 Oct 2008 00:21:54 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363743A6BDA for ; Wed, 1 Oct 2008 00:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQeXFofzZvJG for ; Wed, 1 Oct 2008 00:21:52 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 61EA73A699C for ; Wed, 1 Oct 2008 00:21:51 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id BA60B70069; Wed, 1 Oct 2008 09:22:13 +0200 (CEST) Received: from PMEXCC41.intranet-paris.francetelecom.fr (unknown [10.196.130.30]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 962ED70005; Wed, 1 Oct 2008 09:22:13 +0200 (CEST) Received: from PMEXCB30.intranet-paris.francetelecom.fr ([10.196.130.37]) by PMEXCC41.intranet-paris.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.2499); Wed, 1 Oct 2008 09:22:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 1 Oct 2008 09:22:12 +0200 Message-ID: <53DE7AEBE1DD5741A44C363427681922036A1CE9@PMEXCB30.intranet-paris.francetelecom.fr> In-Reply-To: <48E2B028.803@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Polling the Roll WG for Adoption of the Terminology Draft Thread-Index: AckjUPmwaEEgFzdxQJukbmws/BIrlQARWbwA From: To: "David E. Culler" , X-OriginalArrivalTime: 01 Oct 2008 07:22:13.0789 (UTC) FILETIME=[6D0524D0:01C92396] Subject: Re: [Roll] Polling the Roll WG for Adoption of the Terminology Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Rollers, I'm in favor of adopting this draft. Cheers, Christian. = -----Message d'origine----- De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de Dav= id E. Culler Envoy=E9 : mercredi 1 octobre 2008 01:03 =C0 : roll@ietf.org Objet : [Roll] Polling the Roll WG for Adoption of the Terminology Draft I would like to poll the membership on adoption of the Terminology ID. Lin= k to the draft is below. http://www.ietf.org/internet-drafts/draft-vasseur-roll-terminology-02.txt _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees. = Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. = France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll